bug#22167: Don't interactively ask questions in script mode
Sunil Mohan Adapa <[email protected]> Tue, 7 Jan 2020 15:05:24 -0800
| Newsgroups | gmane.comp.gnu.parted.bugs |
|---|---|
| Message-ID | <[email protected]> |
On 06/01/20 2:40 pm, Brian C. Lane wrote: > On Tue, Dec 31, 2019 at 05:21:11PM -0800, Sunil Mohan Adapa wrote: >> Hello, >> >> Any updates on this bug or comments on the patches? I believe the fix is >> straight forward and correct. > > Do you mean these? > > https://lists.gnu.org/archive/html/bug-parted/2017-04/msg00000.html Indeed, it seems likes the original implementation simply missed out on these checks judging by how other cases were handled and how --script option is documented. Some of the updates to test cases included in these patches may have been handled with recent changes. > > I really cannot think of a good reason to remove or resize a mounted > partition. Why not unmount it first and avoid the issue completely? > This is a very common scenario when running on single board computers. Disk images from the OS vendors are downloaded and written to SD cards (or eMMC) instead of a typical installation wizard process. These images are of a fixed size, say 4GiB, and when the OS boots for the first time, the last partition is expanded to take up the full size of the disk (typically more than 32GB). After this the users get to use the full storage capacity of the disk. This operation is done by many OS images meant for Raspberry Pi. In my case it is FreedomBox[1], a pure blend of Debian for home servers running on cheap hardware. It is likely that all of these users are avoiding parted for this operation or working around the problem. Since online expansion is supported by many file systems including ext4 and btrfs, when using the underlying tools, I don't see a reason for parted to refuse to do this. Also, since the operation is currently allowed to be performed manually, scripts should have ability to do the same, given that they know that it is safe. Links: 1) https://freedombox.org -- Sunil
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl4VDrQACgkQQ+oc/wqn xfLALw//ftv3U1+6SEPdH6fjOv6hPrrzr7+Ae7r52thlmBUqr36AP4fJUH5QjZQi 7tNya4G9a4+t0+naq+y/n2NKT8dt9a1Bm6dRz4+/ayo6SyBeOWX164U+OUg6rtMH 4JVXd18tdqu0kTDvTnvZLEFrIz9UJ9KLSgUQQ8O0Z16rxqwPJ1syTVfr7o6Tz8XR SZECi2/lHbjGK0tYfWZ1U/FK5djUab6EcyRBD8NULKExaU8ISdhgPNPzb0kdIHD2 0VT66wM6b9ln5HfcDYM3zGjlc18JcNeL9cpjwhpCew9wLM7rVIq9rnrGGaM47mE3 Z7j8lNUG1JUcy0DW/vzsmGrBPSxLZ13Q2DpeGI5q9cy9KVrXVBdo6CGt0z2D7lZ7 Q/5B3m/S+S6KzmOlfl5gQzsNXS5cOPxcgOxNp+hCdx+Q3XLY3Fk9R08yCNURpYAR rOf3upuCLNfPViWVy96tNoiROHR4IoeBRuJTJZe8pZ3bGcU1MTRUaaDcYl6m5Vqq QWAmA5kL0vTS8aMacP+tvLx0rTGpsgHkfn1fbx0PYicW6IznIvR02vE5gNeN4BqB vgBEH62bhBC1LTSld8qWuuiyBSBmZ/Nq3u2F52AlgUt5m71snNf7dEx3ziHMauFB AtiJdO9G4Dl8w+zLYnOH7JK+ZjDnR0UXcZpGd0IP6IsDuoNJmBc= =TVPC -----END PGP SIGNATURE-----