v40: resize2fs removed from S02resize init script

[aderumier]

Batocera build version

40 2024/08/01 01:28

Your architecture

x86_64

Your Graphic Processor Unit(s) (GPU)

nvidia rtx2070 super

Issue description

since 7bbbf53,
resize2fs is removed from the S02resize

+           # check & resize the ext4 file system
           if test "${PARTTYPE}" = "ext4"
           then
-               echo "Step $i: Expanding ext4 the file system" >> "$log"
-               textoutput $i 80 "resize2fs ${PART}"
+	           echo "Step $i: Checking ext4 file system" >> "$LOG"
+	           textoutput $i 70 "e2fsck -f -p ${PART}"

I don't understand how this can resize the partition in this case

Detailed reproduction steps

set autoresize=true in /boot/batocera-boot.conf

Details of any attempts to fix this yourself

No response

Details of any modifications you have made to Batocera.

no

Logs and data

No response

[lbrpdx]

It's done via parted earlier

batocera.linux/board/batocera/fsoverlay/etc/init.d/S02resize

Line 97 in 7bbbf53

textoutput $i 30 "parted -s -m -f ${DISK} resizepart ${PARTNUM} 100%"

[lbrpdx]

Did you actually encounter an issue with the partition not resized with the reproduction steps you put in the ticket? Or just a thought reading the code (or actually the comment before the line of code, as it is misleading)?

[aderumier]

It's done via parted earlier

batocera.linux/board/batocera/fsoverlay/etc/init.d/S02resize

Line 97 in 7bbbf53

textoutput $i 30 "parted -s -m -f ${DISK} resizepart ${PARTNUM} 100%"

parted only resize the partition, not the filesystem.
It's working on a first install only, because the script is formating the extended partition.

But for example, if you want to do a image of your disk to transfert it on a bigger one, it'll not work anymore like in v39.
The partition is extended but not the filesystem

you can easily test it in a virtual machine, install batocera, then extend the virtual disk. You'll have the partition increase but not the filesystem.

I think this could be done at step7. (if nofilesystem : mkfs.ext4 else resize2fs)

[lbrpdx]

You originally said "I don't understand how this can resize the partition in this case" but the issue is the resizing of the filesystem after the partition has been extended, I understand the issue better now. You're right it's probably needed in a later step of the script.

[aderumier]

yes, sorry to not be clear enough.

They are also another problem introduce in same commit:

"sgdisk -e" in first step, is throwing an error (exit code 4) if not space is avaiable at the end of the drive.

This is because of a change in textoutput():

    if [ $ret -ne 0 ]; then
        display_error
    fi

It's throwing a warning like "sector overlap...., try to reduce last partition", it's really confusing. (I have already see report on discord some days ago, with users trying to reduce their partition).

the "sgdisk -e" is working fine the first time, but in step 2 we extend the partition to 100%, then if we try to resize again. (but we don't have new space), the script is exiting.
It should continue with other steps, even if the partition are already 100%, we still need to verifiy/extend the filesystem.

[dmanlfc]

we don't use resize2fs ${PART} anymore as it doesn't work across all drive types or fails to produce a valid partition sometimes also.
the partition is formatted at initial boot now after the partition is resized using parted. This is cleaner & more reliable in mine & user testing.
sgdisk -e is correct to be done first as you need to move it to the end of the disk before expanding the partition as per 3)

Users were only seeing errors if they overwrote their batocera-boot.conf files & thus autoresize was re-enabled.
I put some contingency in there to avoid us wiping their disk if people don't follow proper upgrade procedures.

to avoid another round of trying to move the 2nd partition table to the end of the disk if someone does something stupid, you could do. if [ "${TABLETYPE}" = "gpt" ] && "$FORMAT_ALLOWED" = true; then

[aderumier]

sgdisk -e is correct to be done first as you need to move it to the end of the disk before expanding the partition as per

step1 : sgedit -e indeed move the gpt table at the end of the disk
but
step2: parted -f move it again , some sectors later, without the gap betwen gpt headers && gpt entries.

This is the reason why if you relaunch sgedit -e again, it will complain about overlap. (Because both sgedit -e && parted fix don't use same gpt total size, because of the gap difference).
The gpt error is not: "your partition is incorrect, you have an overlap". This is :" I can't move move the gpt table again, because it'll overlap with the parition)

Note that , for example, at first boot, if the format of the drive is going bad,crash,timeout, murphy law...., you're stuck. on next boot, it'll crash on step1 and will not retry to format again.

The only way to be correct, if you want to keep both step1 && step2, it to resize with parted, but not 100%, 100%-1MB. (Like the begin of the drive). Like this, both commands are ok.

(But personnaly, I think it's easier to simply use parted -f && 100%, and not use sgedit -e anymore.)

we don't use resize2fs ${PART} anymore as it doesn't work across all drive types or fails to produce a valid partition sometimes also. the partition is formatted at initial boot now after the partition is resized using parted. This is cleaner & more reliable in mine & user testing.

Yes sure, this make sense to use format at initial boot && format.
My question is: does this script is only here for the initial install boot ?

because parted resize only resize the partition, it's not extending the filesystem.

I known a lot of people, doing an minimal image of a batocera install (with their setup,roms,customisation) for backup purpose , or transfert.
and It'll not be possible to autoresize the filesystem anymore. (Still possible to use resize2fs manually with /userdata/ mounted, but AFAIK , it's a lot slower mounted, I can take hours with 7200k hdd).