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