FS#2231 - fstools: PREINIT calling of block extroot doesn't acknowledge non-MTD rootfs overlays #7352
Comments
|
knodel: I wrote a small patch that allows proper rootfs and fstab discovery on devices where the rootfs+overlay reside on a block device partition. Here the dmesg of a current openwrt HEAD build with the patch: Unrelated dmesg entries omitted, full log here: https://gist.github.com/knuddelknoedel/46db572959056d2e69fd861d59ad0daf |
|
val-kulkov: The proposed patch works beautifully to enable extroot on my x86_64 device. With it, I can finally make use of the available space on my /dev/sda without worrying about losing data on it upon a sysupgrade. The sysupgrade process on a x86_64 system that I use to avoid losing data is not yet a straightforward one. First, I burn openwrt-x86-64-combined-squashfs.img on a USB drive. Then, I copy first two partitions from the USB drive to the corresponding partitions on my /dev/sda. Finally, I copy the MBR bootstrap only, without the partition table: "dd if=/dev/sdc of=/dev/sda bs=446 count=1". This procedure retains sda3, my root overlay partition, and sda4, a swap partition. |
|
utrumo: Now on Zyxel Armor Z2 (NBG6817) extroot doesn't work without this patch. To make work extroot on this router we need compile own firmware and apply this patch:
results you can find in:
DEVICE="/dev/mmcblk0p10" // or if you want to use usb-hdd: DEVICE="/dev/sda1" mount "${DEVICE}" /mnt reboot |
|
rmilecki: That fstools patch cannot be applied as is (I reviewed & commented on it). I pushed three related fstools changes:
That moves us closer to fixing this issue. Someone now needs to improve main_extroot() and make it:
It's basically the same logic as what we already have for JFFS2 and UBIFS in that main_extroot() function. |
|
leifliddy: If we're going to use f2fs as the filesystem for the extroot overlay device (which is a great idea), then we should probably include these package as part of the base build for the zyxel_nbg6817: Actually, this brings up another question, why aren't we using the f2fs filesystem for the default overlay device? /dev/loop0 on /overlay type ext4 (rw,noatime,data=ordered) |
|
rmilecki: I just noticed that orignal report was about ext4. Recently I was chatting with m4t who was using f2fs. So this task seems more generic: we need to check /dev/loop0 for /etc/config/fstab with overlay setup. That /dev/loop0 may be ext4 or f2fs (or other?). |
|
leifliddy: I'm not sure if this is the correct forum for this or not, but here goes. https://openwrt.org/toh/zyxel/nbg6817 You'll see that mmcblk0p5 is divided up into two parts mmcblk0p5 rootfs 64 MiB /rom (squashfs) 4MB So, if you've configured mmcblk0p10 to act as the /overlay, Is there a reason we can't just re-partition this entire device, I mean there's no reason for openwrt to need 10 partitions. If we need to maintain the OEM partitioning scheme, then we should make mmcblk0p1 the 4MB /rom partition That's makes the most sense...but I'll save this discussion for another day. Need to do a bit more research on how openwrt is designed.... |
|
leifliddy: @ken would you be able to create a new patch based on the changes Rafał made to fstools? |
|
tofurky: leifliddy, this works for me with f2fs on 19.07.3. note that the change to check_filesystem() isn't strictly necessary, but i found that newer f2fs-tools gave some issues without it. diff --git a/block.c b/block.c
index 569bf56..b88e208 100644
--- a/block.c
+++ b/block.c
@@ -747,7 +747,7 @@ static void check_filesystem(struct probe_info *pr)
pid = fork();
if (!pid) {
if(!strncmp(pr->type, "f2fs", 4)) {
- execl(ckfs, ckfs, "-f", pr->dev, NULL);
+ execl(ckfs, ckfs, "-p", "2", "-f", pr->dev, NULL);
exit(EXIT_FAILURE);
} else if(!strncmp(pr->type, "btrfs", 5)) {
execl(ckfs, ckfs, "--repair", pr->dev, NULL);
@@ -1591,7 +1591,7 @@ static int main_extroot(int argc, char **argv)
#endif
/* As a last resort look for /etc/config/fstab on "rootfs" partition */
- return mount_extroot(NULL);
+ return mount_extroot("/tmp/overlay");
}
static int main_mount(int argc, char **argv)i spent a bit of time trying to figure out the proper way to do it per rafal's suggestion, but was running into segfaults with find_block(NULL, NULL, "loop0", NULL) so i just took the easy way out ;) not sure if i was even close to taking the right approach with that, though. |
|
katrat: Hi, I guess this fix wasn't included in the 19.07.3 release yet, since I am struggling to set up overlayfs on my new NBG6817 with usb hard disk and ext4. Are there any patched images to download/test? Any chance this will be fixed in one of the next releases? I am not that experienced to build/figure out this myself, so any links/instructions are much appreciated. On the other hand, my zyxel isn't productive yet, so I am willing to test... Thanks, |
|
rmilecki: Noone cared to develop a proper patch, people keep posting some hacks that are unacceptable due to breaking other setups. |
|
katrat: Thanks for the quick, if also a bit unsatisfying, answer. I got the zyxel because it seemed to be properly supported by openwrt (and having a bit more oomph than my ageing tp-link). I don't really understand where the problem is: ext4 of f2fs, hard disk or flash drive, or the drives not being ready at boot time, or just some configuration hiccup. Can you suggest what I could do? I don't mind playing around a bit. |
|
rmilecki: |
|
visualage: Is it reasonable to use libfstools to search for rootfs_data volume and mount it, just like what mount_root.c does? |
|
visualage: I made a patch to openwrt to support extroot on non-MTD rootfs_data volumes. It uses libfstools in block.c to support other squashfs volumes, such as /dev/sd* or /dev/mmc*. The patch itself contains a patch to fstools project that can be applied to that codebase directly. I tested the build locally on a x86-64 virtualbox environment as well as rockchip friendlyarm nanopi r2s. It should work on any other environments as long as mount_root works since they use the same underlying library. |
|
visualage: This is the fstools patch. The openwrt patch is just to make sure block-mount depends on libfstools when packaging. |
|
kofec: Hi, |
|
uutrumo: Qi Liu, for wich version of openwrt your patch? |
|
uutrumo: tofurky, your hack works, thank you. --- a/block.c
+++ b/block.c
@@ -747,7 +747,7 @@ static void check_filesystem(struct prob
pid = fork();
if (!pid) {
if(!strncmp(pr->type, "f2fs", 4)) {
- execl(ckfs, ckfs, "-f", pr->dev, NULL);
+ execl(ckfs, ckfs, "-p", "2", "-f", pr->dev, NULL);
exit(EXIT_FAILURE);
} else if(!strncmp(pr->type, "btrfs", 5)) {
execl(ckfs, ckfs, "--repair", pr->dev, NULL);
@@ -1591,7 +1591,7 @@ static int main_extroot(int argc, char *
#endif
/* As a last resort look for /etc/config/fstab on "rootfs" partition */
- return mount_extroot(NULL);
+ return mount_extroot("/tmp/overlay");
}
static int main_mount(int argc, char **argv) |
|
luce.nera: How do I apply these patches and which one to use? |
|
flowercow: i met this bug in 21.02.0-rc4 installed in kvm. Is there any other method to solve this problem? For example, do something in /etc/preinit? |
|
Gandalf: Still got the issue in 21.02.0 !!! |
|
flowercow: i have tried to recompile firmware applying patch as mentioned by utrumo above. |
|
Op3n: The same bug occurs on the latest stable release 20.02, Is there any way to avoid this bug other than by compiling it myself? I prefer use official pre-compiled version on downloads.openwrt.com |
|
katrat: Well, any solutions apart from patching and compiling openwrt ourselves? Does anyone have a precompiled working solution for 21.02? |
|
siicosmos: Need some solution for 21.02 as well. Either patches or a pre-compiled image is fine... |
|
siicosmos: Updates: |
|
Is there a timeline for this being officially fixed? |
|
There is an alternative way for Zyxel NBG6817: change the uboot-env variable so that rootfs is loaded from /dev/mmсblk0p10 Example: view at the contents of the firmware: flash: ( make an overlay: find free loop: Create and format it: Now change uboot-env: The first variable is responsible for booting from the main partition (FF), the second for booting from the alternate partition (01) checking: Everything. Now you can reboot into the main partition and check the result: And no block-mount, blockd are no longer needed ;) |
|
Can't beleve that simple bug keep three or more main version of OpenWrt, even someone above alreay give fix patch on old bug track website, even bug report migrate to github issue now. It still no maintainer to fix it. Maybe it's truely few people use Extroot or change /Overlay mount. I found this bug on my x86 device when 20.02 released, and then I found this bug exist since 18.06, and now 21.02 code still contain this bug. Looks this bug just caused by read fstab config file at wrong path on squashfs, it should read upper layer but actually read the original read-only ROM path, absolutely it will get no file. Hope someone could fix this, someone already give fix code above. |
|
Sorry to bother, really need maintainers to fix this bug, looks just need to merge the code given above. @dangowrt @aparcar @silentcreek @nbd168 |
knodel:
Extroot overlay mount fails on my ZyXEL NBG6817.
I can confirm this bug on both the latest stable 18.06.2, and the snapshot from the 4th of April.
When PREINIT calls 'block extroot', block fails to load the custom fstab from the eMMC ext4 overlay mounted at /tmp/overlay:
Unrelated dmesg entries omitted, full log here:
https://gist.github.com/knuddelknoedel/2985ce7777a0263fbc22a02f8ef5307c
Custom modules are loaded with the correct overlay /tmp/overlay/upper prefix by libfstools, however the forked 'block extroot' process behaves differently when searching for /etc/config/fstab configuration.
Steps to reproduce:
Further notes: adding /etc/config/fstab with the desired /overlay entry to the sysupgrade squashfs image before flashing allows block to successfully find the uci fstab config, however the mounting of the therein configured /overlay mount still fails.
The text was updated successfully, but these errors were encountered: