OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Ken - 09.04.2019

FS#2231 - fstools: PREINIT calling of block extroot doesn't acknowledge non-MTD rootfs overlays

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:

[...]
Thu Apr  4 12:01:51 2019 user.info kernel: [    3.508150] init: - preinit -
Thu Apr  4 12:01:51 2019 kern.info kernel: [    8.592387] EXT4-fs (loop0): recovery complete
Thu Apr  4 12:01:51 2019 kern.info kernel: [    8.595484] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
Thu Apr  4 12:01:51 2019 user.info kernel: [    8.598875] mount_root: loading kmods from internal overlay
Thu Apr  4 12:01:51 2019 user.info kernel: [    8.649260] kmodloader: loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
Thu Apr  4 12:01:51 2019 user.info kernel: [    8.663223] kmodloader: done loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
Thu Apr  4 12:01:51 2019 user.info kernel: [   10.119972] block: attempting to load /etc/config/fstab
Thu Apr  4 12:01:51 2019 user.err kernel: [   10.120211] block: unable to load configuration (fstab: Entry not found)
Thu Apr  4 12:01:51 2019 user.err kernel: [   10.124238] block: no usable configuration
Thu Apr  4 12:01:51 2019 user.info kernel: [   10.132103] mount_root: switching to ext4 overlay
Thu Apr  4 12:01:51 2019 user.info kernel: [   10.292110] procd: - early -
Thu Apr  4 12:01:51 2019 user.info kernel: [   10.292264] procd: - watchdog -
Thu Apr  4 12:01:51 2019 user.info kernel: [   10.988093] procd: - watchdog -
Thu Apr  4 12:01:51 2019 user.info kernel: [   10.988475] procd: - ubus -
Thu Apr  4 12:01:51 2019 user.info kernel: [   11.046160] procd: - init -
[...]

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:

  1. Flash any current openwrt sysupgrade image on a device where the rootfs+overlay don’t reside on MTD storage
  2. Configure an appropriate /overlay uci fstab extroot entry as specified in the respective wiki documentation
  3. Reboot

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.

Ken commented on 09.04.2019 16:28

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:

Mon Apr  8 22:25:35 2019 user.info kernel: [    3.335289] init: - preinit -
Mon Apr  8 22:25:35 2019 user.info kernel: [    8.035073] mount_root: loading kmods from internal overlay
Mon Apr  8 22:25:35 2019 user.info kernel: [    8.046998] kmodloader: loading kernel modules from //etc/modules-boot.d/*
Mon Apr  8 22:25:35 2019 user.info kernel: [    8.048462] kmodloader: done loading kernel modules from //etc/modules-boot.d/*
Mon Apr  8 22:25:35 2019 user.info kernel: [    8.828623] block: attempting to load /tmp/overlay/upper/etc/config/fstab
Mon Apr  8 22:25:35 2019 user.err kernel: [    8.828798] block: unable to load configuration (fstab: Entry not found)
Mon Apr  8 22:25:35 2019 user.info kernel: [    8.834600] block: attempting to load /tmp/overlay/etc/config/fstab
Mon Apr  8 22:25:35 2019 user.err kernel: [    8.841281] block: unable to load configuration (fstab: Entry not found)
Mon Apr  8 22:25:35 2019 user.info kernel: [    8.847486] block: attempting to load /etc/config/fstab
Mon Apr  8 22:25:35 2019 user.err kernel: [    8.854319] block: unable to load configuration (fstab: Entry not found)
Mon Apr  8 22:25:35 2019 user.err kernel: [    8.859098] block: no usable configuration
Mon Apr  8 22:25:35 2019 kern.info kernel: [    8.985003] EXT4-fs (loop0): recovery complete
Mon Apr  8 22:25:35 2019 kern.info kernel: [    8.986207] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
Mon Apr  8 22:25:35 2019 user.info kernel: [    8.988754] mount_root: loading kmods from internal overlay
Mon Apr  8 22:25:35 2019 user.info kernel: [    9.013356] kmodloader: loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
Mon Apr  8 22:25:35 2019 user.info kernel: [    9.013492] kmodloader: done loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
Mon Apr  8 22:25:35 2019 user.info kernel: [   10.011824] block: attempting to load /tmp/overlay/upper/etc/config/fstab
Mon Apr  8 22:25:35 2019 kern.info kernel: [   10.017872] EXT4-fs (mmcblk0p10): mounted filesystem with ordered data mode. Opts:
Mon Apr  8 22:25:35 2019 user.info kernel: [   10.162997] mount_root: switched to extroot
Mon Apr  8 22:25:35 2019 user.info kernel: [   10.331230] procd: - early -
Mon Apr  8 22:25:35 2019 user.info kernel: [   10.331412] procd: - watchdog -
Mon Apr  8 22:25:35 2019 user.info kernel: [   11.009306] procd: - watchdog -
Mon Apr  8 22:25:35 2019 user.info kernel: [   11.009775] procd: - ubus -
Mon Apr  8 22:25:35 2019 user.info kernel: [   11.064866] procd: - init -

Unrelated dmesg entries omitted, full log here: https://gist.github.com/knuddelknoedel/46db572959056d2e69fd861d59ad0daf

Val Kulkov commented on 14.05.2019 20:51

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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing