installing from external to internal storage with fat boot partition fails at tune2fs

added help wanted type::bug labels

In my case it failed when installing from external to external (not a likely use case, but still likely not valid behaviour.)

Would it make sense to make a bash function or somesuch that figures out what a given file system is and renames it? Then it could be used whenever the script does partition renaming. (I could imagine the boot filesystem or other filesystems being something even more exotic than FAT).

By Théo Friberg on 2021-07-13T18:06:34

Also this would be an interesting first bug for me at least, but I can't promise how much time I can spend on this in the coming days.

By Théo Friberg on 2021-07-13T18:09:50

Also, I'm pretty sure https://gitlab.postmarketos.org/postmarketos/postmarketos-ondev/-/blob/master/ondev-post-install.sh#L23 would blow up if the install partition was eg. f2fs or btrfs. Is there a good reason to assume it's ext?

By Théo Friberg on 2021-07-15T21:03:38

Is there a good reason to assume it's ext?

No good reason, just legacy.

By Oliver Smith on 2021-07-15T21:03:38

Well, here is a tentative (tired brain, untested) sketch. Doesn't take into account the actual main fs type and check for anything else than ext4 and fat16 (eg. my tablet is fat32), if we have some other ext or some other fat it just silently breaks. Not ideal.

0001-Add-mtools-dependency-to-ondev.patch

0001-Detect-pmOS_i_boot-fs-type-and-use-right-tool.patch

By Théo Friberg on 2021-07-13T19:56:56

@ollieparanoid Here's a more finished version, tested to work with fat32, don't know how to test it with ext. (Somehow with qemu?)

Patch to the ondev repo

0001-Detect-pmOS_i_boot-fs-type-and-use-right-tool.patch

Patch to the APKBUILD that marks that patch as a source, bumps pkgrel and adds the right dependency

0001-Add-dosfstools-dependency-to-ondev.patch

By Théo Friberg on 2021-07-14T15:28:02

That apparently fails on qemu where $deviceinfo_boot_filesystem is not set

By Théo Friberg on 2021-07-15T06:40:03

Another swing at the problem, tested in qemu to work with w/e $deviceinfo_boot_filesystem='' means. I then tried to run through ext2 through ext4 and fat16 through fat64 with something else breaking every time. According to grep:

[glados@aperture:~/.local/var/pmbootstrap/cache_git/pmaports/device]$ grep -r boot_filesystem
main/device-qemu-amd64/deviceinfo:deviceinfo_boot_filesystem="fat32"
community/device-asus-me176c/deviceinfo:deviceinfo_boot_filesystem="fat32"
testing/device-tokio-techbook/deviceinfo:deviceinfo_boot_filesystem="fat16"
testing/device-surftab-wintron7.0/deviceinfo:deviceinfo_boot_filesystem="fat16"
testing/device-raspberry-pi0/deviceinfo:deviceinfo_boot_filesystem="fat16"
testing/device-raspberry-pi/deviceinfo:deviceinfo_boot_filesystem="fat16"
testing/device-tablet-x86uefi/deviceinfo:deviceinfo_boot_filesystem="fat16"
testing/device-acer-aspire-switch-10/deviceinfo:deviceinfo_boot_filesystem="fat32"
testing/device-tablet-x64uefi/deviceinfo:deviceinfo_boot_filesystem="fat16"
testing/device-trekstor-surftabduow1/deviceinfo:deviceinfo_boot_filesystem="fat16"
testing/device-raspberry-pi3/deviceinfo:deviceinfo_boot_filesystem="fat16"
testing/device-raspberry-pi4/deviceinfo:deviceinfo_boot_filesystem="fat16"

It would seem that the variable is either unset, fat16 or fat32. Given that qemu didn't end up working with the latter two, I'll try to test them on device (I think the efi speaks both, I'll have to check). If it works with unset, fat16 and fat32, it should work with all devices. (Incidentally, actually wanting to run the installer from sd to sd on rapsberry pi makes some level of sense, as opposed to the usb to usb case I have been testing)

0001-Detect-pmOS_i_boot-fs-type-and-use-right-tool.patch

By Théo Friberg on 2021-07-15T07:39:53

There's two things I'd change in the patches above:

instead of adding dosfstools as dependency of postmaketos-ondev in pmaports, we can run apk add dosfstools inside ondev-prepare.sh if deviceinfo_boot_filesystem is fat* (this script runs as pmbootstrap prepares the installer image). Then it won't get installed for devices that don't need it.
I'd also put a sanity check for deviceinfo_boot_filesystem in ondev-prepare.sh, so it can fail early, as the installer image gets created (instead of failing at the end of the installation)

Do you want to include these changes in your patch and make a merge request?

Thanks for giving this a try @fsmnarmosta!

By Oliver Smith on 2021-07-15T21:03:32

I've been working on a version with a function that checks partition type directly (and does so for the root partition too). I think I could apply the sanity checks to that version too, though I might have a hard dep on lsblk (needed for the sanity check itself). As of now it trips up with lsblk not reporting fat16, fat32 and fat64 but vfat and co. I'll try to fix that and maybe submit a variation of that. As of now the code looks like this (+an lsblk dependency on the ondev package)

0001-Detect-pmOS_i_boot-fs-type-and-use-right-tool.patch

By Théo Friberg on 2021-07-16T16:44:17

Whelp, here is the generic thing. (Tested on both ext bootloader qemu and fat bootloader physical device) I'll have to see if I can make it smarter with regards to the dependency and failing early.

0001-Detect-pmOS_i_boot-fs-type-and-use-right-tool.patch

EDIT:

Having taken a further look at ondev-prepare, it would seem to get run well before any partitioning happens. I don't know how I could detect what the rootfs partition is, so I don't know how to limit the installed dependencies based on that. I could catch boot being something especially oddball though.

Should I just give up on the more complex idea and just worry about renaming the boot partition? (Based on the deviceinfo variable) @ollieparanoid what do you think?

By Théo Friberg on 2021-07-16T17:16:43

installing from external to internal storage with fat boot partition fails at tune2fs

Child items 0

Activity