Hi everyone,
so after a day of tinkering, building and compiling from source code I have finally managed to mount the mmcblk0p10 3GB partition as an overlay extroot partition in OpenWRT 19.07-snapshot.
I have read the forum, specifically this thread , they were talking about adding kmod-fs-ext4, block-mount, blockd packages to the build, it was supposed to solve the problem, when even after going through the official extroot tutorial, the partition wasn't mounted, logs saying fstools can't find fstab file. I am not sure if this solves the issue on 18.06, but it certainly doesn't work on 19.07.
What solved the issue was using patch from this bug report. I wasn't able to find much info about it, so I had to find which file to patch, it is located here: /openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/fstools... (the fstools folder can have different version in the name). I couldn't find any mention about it in the main thread which is now locked, so I hope it's okay to post this in the new one.
If anyone wants to build it themselves, it is ok to use the official extroot tutorial , but you have to mount the old overlay to /tmp/overlay, not /rwm as the tutorial says.
My question is.. is there any chance this patch will be pulled into the 19.07 official branch, so in the future I can use the pre-built images to flash new versions? Even though I had a lot of "fun" compiling my build, it is rather time consuming.
Also if anyone is interested, I can provide the final sysupgrade image from the current 19.07-snapshot (as of today).
The thread you're quoting was not about extroot, it was exclusively about fixing the problem that the normal (non-extroot) overlay[0] couldn't be mounted on the release image[1]. This particular issue has been fixed for 18.06.0 and later (but was -and still is- broken in 17.01.x).
Your quest for using the bu2 (/dev/mmcblk0p10) partition as on-device extroot, respectively the bugreport/ patch you're referencing, may[2] have uncovered a different issue. In order to get this fixed for 19.07.0, the referenced patch (or a revised version thereof) would have to be merged into master (snapshots) first, before it would be eligible for backporting (cherry-picking) to the openwrt-18.06 branch, so getting it fixed in master should be your primary concern.
On a very personal note, I wonder why you're looking for using bu2 as extroot in the first place? The nbg6817 offers you roughly 60 MB[3] for your overlay on a default release image, which is quite a bit for running OpenWrt[4]. If your intent would be more towards using bu2 for data storage, rather than runtime-installed binary packages, it would probably be a better approach to just mount it as normal (non-extroot) data partition[5].
--
[0] the normal extroot is behind the rootfs, on the same (sub-split) partition as the rootfs itself, namely (part of-) /dev/mmcblk0p5 or /dev/mmcblk0p8.
[1] it was lacking ext4 kernel modules, but the overlay is using an ext4 filesystem - which weren't preinstalled by default in the 17.01.x release images.
[2] I'm careful in declaring it as "may", as it's not quite clear to me if the blockd infrastructure is supposed to be safe to use under pre-init circumstances, this would be something to involve the blockd maintainers in for that bugreport.
[3] the openwrt-19.07 rootfs is roughly 3.6 MB in size at the moment, so 64 MB - 3.6 MB - $some_padding = ~60 MB free space. On my personal (quite a bit larger) builds I still have ~50.2 MB free space on my overlay.
[4] I'm not saying that it would be impossible to fill it up with OpenWrt packages (installed at runtime via opkg), but you do have quite some leeway before that constraint becomes an issue.
[5] e.g. /dev/mmcblk0p10 3.1G 21.4M 2.9G 1% /srv, which I am using to service profiles and firmware files for my SIP phones via tftp(d) from /srv/tftp/.
Thanks for the response and clarification. I know that the thread I was quoting wasn't about extroot, but I found anyone metioned it there aswell, specifically here, that's why I was pointing to that one.
You are right about the space, I might be a bit paranoid about running out of space because it happened to me multiple times with the TP-Link Archer C7 (but that one had only 16MiB of flash) and I thought since it's already there and I play with it quite a lot, why not have all the space available, but I agree that only reason to have it as root would be for opkg packages, otherwise it could be mounted as separate partition.
I am not sure how this procedure with patches, backporting and pull requests works for OpenWrt git, so I thought I would just post it here in case somebody wanted to do the same (even if out of curiosity or having some other purpose for that)
Hi.
How can i use mmcblk0p10 as extroot? On this partition i have near 4Gb and there is enough for me.
I want to try to use docker on this router for my home pet projects. I need > 150mb on disk only for install docker package from this article.
I was make all settings from this article and have got this error on every boot of my device:
logread | sed -n -e "/- preinit -/,/- init -/p"
Fri Nov 1 00:31:41 2019 user.info kernel: [ 9.905354] block: attempting to load /etc/config/fstab
Fri Nov 1 00:31:41 2019 user.err kernel: [ 9.905569] block: unable to load configuration (fstab: Entry not found)
Fri Nov 1 00:31:41 2019 user.err kernel: [ 9.909456] block: no usable configuration
Fri Nov 1 00:31:41 2019 user.info kernel: [ 9.917423] mount_root: switching to ext4 overlay
I can mount this partition by hand using this command: mount /dev/mmcblk0p10 /overlay
and it works, but only until next reboot.
Hi, this is exactly what I said in this original post, I even posted the bug report, and yes, you need to apply this patch (it's actually just one file - all of them have the same contents). What you need to do is to clone the openwrt github repository, run the setup to download all necesary files, then apply the patch and then use the installer to build the firmware for your specific device, then compile it. If you trust me enough not to include any malicious code to the firmware I can provide you with my compiled firmware which has this working from a commit about a month old of 19.07
I discussed it with @slh and he pointed out that for most people those 60MiB of storage would be enough to install packages, and only few people would benefit the increased storage, that's why I made the tutorial for myself and didn't bother to make the pull request, but I guess the patch could still be applied and then people could decide whether they want to make it available using extroot or not.
You are right, I thought about it, but since I already made the changes to the file without saving the original I was just too lazy and a bit busy to clone a fresh copy and make the diff, since it was just for my use But I guess I will do it with the next upgrade.
Is there a developer of openwrt? Please add this patch to master!
InToSSH, you do not need kmod-fs-autofs4, kmod-fs-ext4, kmod-fs-f2fs, kmod-lib-crc32 and mount /dev/loop0 to /tmp/overlay.
Only this packages are needed: block-mount, blockd and kmod-usb-storage.
make directory for patch: mkdir ./package/system/fstools/patches
write patch content from https://patchwork.ozlabs.org/patch/1082599/ to ./package/system/fstools/patches/001-add_propper_rootfs_and_fstab_discovery_on_a_block_device_partitions.patch
build image:
./scripts/feeds update -a
./scripts/feeds install -a
export MAKEFLAGS=-j5
make menuconfig
=============================================================
system ⇒ Qualcomm Atheros IPQ806X y
Target Profile ⇒ Zyxel NBG6817 y
Base system ⇒
⇒ block-mount y (for extroot on mmcblk0p10)
⇒ blockd y (for extroot on mmcblk0p10)
Kernel modules ⇒ USB Support ⇒ kmod-usb-storage y (for usb-hdd support)
LuCI ⇒
⇒ Collections ⇒ luci y
⇒ Applications ⇒ luci-app-advanced-reboot y
=============================================================
make defconfig
make download
ionice -c 3 nice -n19 make
results you can find in:
./bin/targets/ipq806x/generic/
flash this firmware to router
scp ./bin/targets/ipq806x/generic/openwrt-ipq806x-zyxel_nbg6817-squashfs-sysupgrade.bin root@openwrt:/tmp
ssh root@openwrt
sysupgrade -v /tmp/openwrt-ipq806x-zyxel_nbg6817-squashfs-sysupgrade.bin
set extroot:
ssh root@openwrt
DEVICE="$(awk -e '/\s/overlay\s/{print $1}' /etc/mtab)"
uci -q delete fstab.rwm
uci set fstab.rwm="mount"
uci set fstab.rwm.device="${DEVICE}"
uci set fstab.rwm.target="/rwm"
uci set fstab.rwm.enabled="1"
uci commit fstab
DEVICE="/dev/mmcblk0p10" // or if you want to use usb-hdd: DEVICE="/dev/sda1"
mkfs.ext4 -F "${DEVICE}" // Careful, formats the disk without asking for confirmation!
eval $(block info "${DEVICE}" | grep -o -e "UUID=\S*")
uci -q delete fstab.overlay
uci set fstab.overlay="mount"
uci set fstab.overlay.uuid="${UUID}"
uci set fstab.overlay.target="/overlay"
uci set fstab.overlay.enabled="1"
uci commit fstab
mount "${DEVICE}" /mnt
cp -a -f /overlay/. /mnt
umount /mnt
This is my first message here and the topic is reason for signing up, so please don't hate me))
Did I get it right that after new OpenWRT version released(we all know it will have not this patch) I should repeat the list BEFORE flashing this newer version? Does this mean that OEM firmware applied upon patched firmware will brick the router?
As far i understand (i could be wrong) for update from old version of openwrt to new you just need to flash fresh sysupgrade.bin, than mount by hand extroot and delete .flashextroot-uuid on it.
A few days ago i compile fresh firmware (with this patch) version from master and install it:
I can provide you with my compiled firmware which has this working from a commit about a month old of 19.07
But I guess I will do it with the next upgrade.
