Fstools Extroot may have a bug

For Developers
1

I am trying to do extroot on DIR-825 19.07-snapshot rom.
But after waiting scsi usb driver loads, block mounting util keep lost original fstab data.
It tries to mount basic rom partition, mtdblock4.

[   11.088512] block: attempting to load /tmp/jffs_cfg/upper/etc/config/fstab
[   11.099320] block: extroot: device not present, retrying in 5 seconds
[   12.163327] scsi 0:0:0:0: Direct-Access     Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[   12.174152] sd 0:0:0:0: [sda] 30277632 512-byte logical blocks: (15.5 GB/14.4 GiB)
[   12.184753] sd 0:0:0:0: [sda] Write Protect is off
[   12.189565] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
[   12.192556] sd 0:0:0:0: [sda] No Caching mode page found
[   12.197890] sd 0:0:0:0: [sda] Assuming drive cache: write through
[   12.214856]  sda: sda1 sda2
[   12.226264] sd 0:0:0:0: [sda] Attached SCSI removable disk
[   18.149599] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
[   18.157193] block: extroot: unable to lookup root device /dev/mtdblock4

extroot fstab looks like this.

config 'global'
	option	anon_swap	'0'
	option	anon_mount	'0'
	option	auto_swap	'1'
	option	auto_mount	'1'
	option	delay_root	'5'
	option	check_fs	'0'

config 'mount'
	option	target	'/mnt/sda'
	option	uuid	'6C57-8A19'
	option	enabled	'0'

config 'mount'
	option	target	'/overlay'
	option  device  '/dev/sda1'
	option	uuid	'a6cadc29-01e9-4a3f-90f2-9ae1d3d6432d'
	option	enabled	'1'

config 'swap'
	option	device	'/dev/sda2'
	option	enabled	'1'

if I set delay_root to 0 in fstab global config. block fsutil finds the mounting device correctly. but mounting is not done as usb devices is not usable yet.

[    9.936160] jffs2: notice: (513) jffs2_build_xattr_subsystem: complete building xattr subsystem, 12 of xdatum (3 unchecked, 9 orphan) and 55 of xref (12 dead, 1 orphan) found.
[    9.960294] mount_root: loading kmods from internal overlay
[   10.251300] kmodloader: loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
[   10.700641] SCSI subsystem initialized
[   10.734434] uhci_hcd: USB Universal Host Controller Interface driver
[   10.762414] usb-storage 1-1:1.0: USB Mass Storage device detected
[   10.769209] scsi host0: usb-storage 1-1:1.0
[   10.773862] usbcore: registered new interface driver usb-storage
[   10.785836] usbcore: registered new interface driver uas
[   10.791834] kmodloader: done loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
[   11.106662] block: attempting to load /tmp/jffs_cfg/upper/etc/config/fstab
[   11.117643] block: extroot: cannot find device with UUID a6cadc29-01e9-4a3f-90f2-9ae1d3d6432d
[   11.127105] mount_root: switching to jffs2 overlay

maybe during the process of cache_load(0) in fstools block. original overlay config is lost.
https://git.openwrt.org/?p=project/fstools.git;a=blob;f=block.c;h=b6d49a8543117bb91fa53bd7c8b1fad5f1e2dbdb;hb=refs/heads/master#l1542

I am not sure what happened exactly. what do you think?

2

I made the system working by adding these lines to rc.local.

export PREINIT=1
mount_root

I got this from this link.

3

I just peeked at fstools/block.c source code.

What's the purpose of the check_extroot() function if the rootfs is already mounted anyway?
(Just wondering, maybe I'm just missing something)

This function has unexpected behaviors under unusual environments causing the extroot to be unmounted when everything should be just fine.

Here is what I observed while trying to setup extroot on openwrt-x86-64-rootfs-squashfs (compiled from src tree) as a Xen DomU guest :

There are specific devices under /dev that could share the same device ID as the rootfs medium.
ie: {/dev/msr0 (/dev/cpu/0/msr)}.id == {/dev/xvda}.id

This can be an issue on systems running on non flash storage (x86 for instance in my case) :
check_extroot() is relying on find_root_dev() that returns the first device under /dev whose ID matches the device where "/" is located.
In this case, the returned device is not necessarily the rootfs device (due to multiple devices sharing the same ID)

This happened to me: /dev/msr0 was returned instead of /dev/xvda, causing further checks in check_extroot() to fail.

Meanwhile, I ended up bypassing check_extroot() call by recompiling fstools to make extroot work as intended as I ran out of ideas..

Regards

4

I'm having the same problem and sadly the tool does not report enough information even to see what went wrong.

5

https://github.com/domo-iot/fstools/tree/extroot-squashfs contains my fix to allow mounting the extroot at boot, https://github.com/openwrt/openwrt/issues/7352 contains some patches that partially fix the problem of not finding the root partition but do not let you mount the extroot w/out rebooting yet.