DietPi-FS_partition_resize | F2FS filesystem not expanded

[MichaIng]

I downloaded the latest beta image DietPi_RPi-ARMv8-Bullseye_F2FS.7z and installed on my RPi 3B which had Samsung Ultra SD card of size 64GB. I was running stable version of dietpi prior which was formatted for this beta install.

While running the first boot setup itself I could see that the drive manager is only showing less than 1GB file system size for my / folder and is not allowing to increase though I had a 64GB SD card. My install of additional software was all failing since there is not enough free space.

Again formatted the SD and reinstalled the stable version of Dietpi and I could see that the drive manager shows full 64 GB.

Originally posted by @sajimenon in https://github.com/MichaIng/DietPi/issues/6130#issuecomment-1424307892

[MichaIng]

@sajimenon I made a new image from this since it is not related to the beta. The F2FS and Btrfs images are experimental for testing purpose only. However, since we aim to offer them as well when proven stable. Can you show the output of:

cat /var/tmp/dietpi/logs/fs_partition_resize.log

[sajimenon]

@.***:~# cat /var/tmp/dietpi/logs/fs_partition_resize.log Removed /etc/systemd/system/local-fs.target.wants/dietpi-fs_partition_resize.service. Disk /dev/mmcblk0: 59.69 GiB, 64088965120 bytes, 125173760 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x2690c2f9

Old situation:

Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 * 8192 270335 262144 128M c W95 FAT32 (LBA) /dev/mmcblk0p2 270336 2097151 1826816 892M 83 Linux

/dev/mmcblk0p2: New situation: Disklabel type: dos Disk identifier: 0x2690c2f9

Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 * 8192 270335 262144 128M c W95 FAT32 (LBA) /dev/mmcblk0p2 270336 125173759 124903424 59.6G 83 Linux

The partition table has been altered. mount: /: mount point is busy. @.***:~#

[image: image.png]

Warm regards,

Saji Menon 9740210230

On Thu, Feb 9, 2023 at 8:48 PM MichaIng @.***> wrote:

@sajimenon https://github.com/sajimenon I made a new image from this since it is not related to the beta. The F2FS and Btrfs images are experimental for testing purpose only. However, since we aim to offer them as well when proven stable. Can you show the output of:

cat /var/tmp/dietpi/logs/fs_partition_resize.log

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/6143#issuecomment-1424356475, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5Y5OVEVI7XX2SQYVSO5PD3WWUDE7ANCNFSM6AAAAAAUWVWCWA . You are receiving this because you were mentioned.Message ID: @.***>

[MichaIng]

mount: /: mount point is busy.

Ah that is the problem, remounting R/O fails, and online resizing is not supported on F2FS.

Can you try it manually:

mount -o remount,ro /
resize.f2fs "$G_ROOTFS_DEV"
mount -o remount,rw /

Ah, I think the problem is that we are writing this exact log file. Uff this is complicated to solve since we want to have the log file, of course.

Probably a temporary little tmpfs to write the log file to and move to rootfs via exit trap. Or stop writing the log file temporarily, but this makes the script very complicated. I need to think about this...

[Joulinar]

Probably using a temporary filesystem would be easiest

[sajimenon]

Nope it does not work. Fails with the first command itself...

@.***:~# mount -o remount,ro / mount: /: mount point is busy.

Warm regards,

Saji Menon 9740210230

On Thu, Feb 9, 2023 at 10:10 PM MichaIng @.***> wrote:

mount: /: mount point is busy.

Ah that is the problem, remounting R/O fails, and online resizing is not supported on F2FS.

Can you try it manually:

mount -o remount,ro / resize.f2fs "$G_ROOTFS_DEV" mount -o remount,rw /

Ah, I think the problem is that we are writing this exact log file. Uff this is complicated to solve since we want to have the log file, of course.

Probably a temporary little tmpfs to write the log file to and move to rootfs via exit trap. Or stop writing the log file temporarily, but this makes the script very complicated. I need to think about this...

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/6143#issuecomment-1424487600, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5Y5OVFFHPOTY4T6IHCE4V3WWUMYZANCNFSM6AAAAAAUWVWCWA . You are receiving this because you were mentioned.Message ID: @.***>

[rekcodocker]

I had a conversation about this too. When it failed I tried to resize the SD card on my laptop. Resize failed with an error. It was not mounted. So it is not limited to the raspberry. I found that the partition was resized correctly but the F2FS filesystem on the partition was not - because resize-f2fs errored.

Details and the exact output are in #606

My workaround was to use a laptop:

• copy all the files (sudo rsync -ax)
• create a totally new partition on the SD card from scratch, which of course filled the partition
• copy the files back.

This is running on two Rpi3 s right now.

[MichaIng]

I found that the partition was resized correctly but the F2FS filesystem on the partition was not

Yes, partition resizing of course works (otherwise the whole thing would break with any rootfs type), it is F2FS only which has this limitation of not allowing online resizing. Together with the fact that shrinking F2FS is not possible at all, it makes it quite hard to ship images with F2FS rootfs, but we'll be able to deal with those issues. There are a bunch of ways, I just did not decide yet which one is most robust while having least impact on rootfs of other types.

[rekcodocker]

I check every now and then. I still like F2FS support. I have run an f2fs system running Docker, PiHole, Zigbee2Mqtt, NodeRed and MQTT for almost a year now - without FS problems.