4040 7.10 usbroot not recognizing ext3 file system

[programminghoch10]

Hi,
I was trying to install unbound and some other network management stuff and because of easy access and big image sizes i decided to use usbroot. I was using usbroot previously (<7.x) and it always worked like a charm and was very reliable.
Now i made myself another internal image which basically only has usbroot and some smaller stuff for debugging or easy access (like Dropbear or nano shell).
after some minor troubles I managed my box to detect and also (freetz)mount the ext3 usb stick in uStor01

However usbroot page does not recognize that the file system is ext3, it says "unknown" and the selection boxes are greyed out.

Now here is what i tried:

• resetting the box to factory defaults (including the freetz uninstall image)
• reformatting the usb stick in case of bad fs
• using several configs, also tried disabling and enabling freetzmount ext3 box in the menuconfig incase dependencies werent set before
• I enabled usbroot without selecting the partition, the kernel_args were set correctly to /dev/sda1 and ext3 fs but it still ended in bootloop.
• going back to 7.01
• using a different usb stick which has prooven to work on an 4020 with fritzos 7.01

It all did not result in any step towards booting from the usb stick.

In the AVM-Webinterface the usb stick shows up correctly as ext3 and is accessible in FritzNAS

I already googled, and although there is no such problem, i found that apparently the command "fstyp" has something to do with fs recognition of usbroot. I dont know the syntax and the usage isnt very specific, but "fstyp /dev/sda1" fails (and yes, /dev/sda1 is the correct and available usb partition)
On the 4020 fstyp returns ext3 as expected (same usb stick).
(just for completeness, the 4020 i was comparing too has got the "newest" firmware for it, but the freetz build could be up to half a year old, maybe something regarding fstyp has changes since then)

I dont know whether i documented everything important, please just ask if there is something missing.

config.txt

[PeterPawn]

Looks like no-one else wants to answer (at least not yet, since 19 hours) ... so I'll do it now. Please take note of the circumstance, that I'm not a Freetz rep and my answer may be the wrong one. It's your decision, whether you want to consider it for your further thoughts/actions.

---

Your expectations are too optimistic in my opinion. Are you really sure, you've used the usbroot package with some version, that was based on a kernel newer than 3.x?

I can't see any preparations for Linux kernel version 3 and later in this script - seems to me, as if the highest supported kernel version (where the device really gets mounted from mount_usbroot()) is 2.6.32: https://github.com/Freetz/freetz/blob/master/make/usbroot/files/root/etc/init.d/rc.usbroot#L155

Usually the start of usbroot is made with init=<path_to_rc.usbroot_script> in the kernel command line arguments.

Therefore the kernel mounts the root filesystem and calls the specified command (or script) instead of the usual init command.

This script has to mount the USB storage device now and to call the usual init program afterwards: https://github.com/Freetz/freetz/blob/master/make/usbroot/files/root/etc/init.d/rc.usbroot#L601

To mount the USB device, it has to start the USB host first - have a look at the S46-usb and rc.usbhost scripts from your firmware image, they may be found in the build/orginal sub-directory of your Freetz build tree.

To start the USB host (and that means: immediately at system start, not while initializing the system later, where S46-usb gets called at some point in the future), it has to load some modules first.

For other kernel versions, loading these modules is done from this case selection: https://github.com/Freetz/freetz/blob/master/make/usbroot/files/root/etc/init.d/rc.usbroot#L155

Such a path of execution doesn't exist for kernel version 3 and later ... as a result, the storage device for your usbroot system is never mounted, if your device gets started with rc.usbroot as initial command.

Instead this statement gets executed: https://github.com/Freetz/freetz/blob/master/make/usbroot/files/root/etc/init.d/rc.usbroot#L553 and your box resumes the normal boot process, because the root device will never get replaced and the later called init program continues the initialization of the original FRITZ!OS system.

---

TL;DR: I don't believe, there was ever a successful start of a FRITZ!Box device with an activated usbroot package for a kernel version above 3.0 - but please take care of my 1st paragraph.

Even if you would get managed to let the system recognize the correct filesystem of your USB storage device, your device would not start with this partition as root device - at least not with the current implementation of usbroot startup script. To use usbroot, you've to adapt the script to newer kernel versions first.

If you run into problems with a filesystem image, that's too big for the available flash memory, consider to use an externals extension - this one should work, even on a 4040 device.

[programminghoch10]

I thought so that I've seen a new version run usbroot, but maybe i was wrong. I'll try to get into this in about 1.5 Weeks when I'm back from holidays.

[programminghoch10]

okay, so

you were right, the usb stick i tested on the 4020 worked with old versions but doesn't with 7.
I guess that I'm not able to rewrite usbroot.rc for it to work, but I'll definitly try to.

The only thing I don't get yet is why doesn't it start normally. You mentioned that the script resumes the init process without replacing the filesystem. However it doesn't boot normally, instead it gets stuck in a bootloop. (both 4040 and 4020)

Thank you for mentioning the externals extension, I never knew what it was, but I'll get into it soon.

[olistudent]

I have taken a quick look into this topic...

The first problem is that switching init to /etc/init.d/rc.usbroot doesn't work on devices with "inner"and "outer" filesystem. When rc.usbroot is started from kernel command line the root filesystem isn't mounted. So there are no modules in /lib because you have to mount /filesystem_core.squashfs first and switch root...

I doubt there is the possibility to add files to the outer filesystem at the moment? So this would be the first challenge. Then the rc.usbroot script has to be adopted for kernel version 3.10 and xhci usbhost module...

Regards,
Oliver

[PeterPawn]

I doubt there is the possibility to add files to the outer filesystem at the moment?

Easy as taking candy from a baby, as long as the needed space isn't too large.

You may re-mount "/wrapper" on such devices (as r/w, it's mounted r/o by AVM) and you get immediately access to the free space from the YAFFS2 filesystem, that's stored in this partition.

I'm storing (regularly) 16 MB in an additional image there and there are still 4 MB available - all data taken from a 7490 device, which has most files/needs most space in stock firmware, compared to other VR9 models.

root@fb7490:~ $ l /wrapper/
drwxr-xr-x    1 root     root          2048 Jul  7 14:48 .
drwxr-xr-x   15 root     root           270 Jun  5 21:33 ..
drwxrwxr-x    1 1000     1001          2048 Sep 18  2018 bin
drwxrwxr-x    1 1000     1001          2048 Apr 25  2016 config
drwx------    1 root     root          2048 May 22 10:48 core
-rw-r--r--    1 root     root      16752640 Jul  7 14:28 custom.custom
drwxr-xr-x   10 root     root         14040 Jul 27 11:16 dev
drwxrwxr-x    1 1000     1001          2048 Jul 13 23:28 etc
-rw-r--r--    1 root     root      26984448 Jun  5 21:34 filesystem_core.squashfs
drwx------    1 root     root          2048 Jun  5 21:41 lib
drwx------    1 root     root          2048 Jan  1  1970 lost+found
drwx------    1 root     root          2048 May 22 10:48 proc
drwx------    1 root     root          2048 Jun  5 21:41 sbin
drwx------    1 root     root          2048 Jun  5 21:41 tmp
drwx------    1 root     root          2048 May 22 10:48 var
root@fb7490:~ $ df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                48.0M     44.0M      4.0M  92% /wrapper
devtmpfs                118.4M     76.0K    118.3M   0% /wrapper/dev
/dev/loop0               25.8M     25.8M         0 100% /
devtmpfs                118.4M     76.0K    118.3M   0% /dev
tmpfs                   118.6M      1.8M    116.8M   1% /var
/dev/mtdblock4            2.0M    920.0K      1.1M  45% /var/flash
/var/dev/nand           406.0M     38.9M    367.1M  10% /var/media/ftp
tmpfs                   118.6M         0    118.6M   0% /var/media/ftp/volatile
/dev/sda3               162.3G     81.3G     72.7G  53% /var/media/ftp/YourFritz
/dev/sda2                63.0G     13.7G     46.1G  23% /var/media/ftp/system
/dev/loop1               16.0M     16.0M         0 100% /var/custom
/dev/loop2               23.3M     23.3M         0 100% /var/bintools
root@fb7490:~ $ grep "wrapper " /proc/mounts
/dev/root /wrapper yaffs ro,relatime 0 0
root@fb7490:~ $

TL;DR: It's possible to store data there ... either from the running system (e.g. while enabling USB root mode) or from the Freetz toolchain already.

The cumulated space requirements (FRITZ!OS + Freetz additions) have to be honoured ... the YAFFS2 partition is only 48 MB in size and a bigger SquashFS image reduces the available space in the uncompressed part.

On VR9 devices (with this wrapper partition) it's nevertheless the better idea, to replace the used pivot_root-ing to the SquashFS image from vendor with switching to the own root.

I would modify the inittab file in the YAFFS2 partition for this purposes ... and consider to leave the kernel arguments (init=sth.) untouched in this case. But this prevents an "easy way back" ... but there's a second system on these devices, ready to be used, if the USB root version fails.

[WileC]

Is your problem still under FOS 7.12?

[programminghoch10]

If AVM didn't randomly go back in their kernel version, then yes it should still be there.