[RFC] How should `firstboot` behave with extroot?

For Developers
1

Original title: [Request] "mount" output from "by-the-book" extroot

I'm digging into some issues with firstboot (primarily that it doesn't work properly for UBI) and have been looking for what cat /proc/mounts shows with an extroot-enabled system when running. I did take a look at Looking for tutorial for extroot, /mnt, /overlay, etc, but didn't see anything there.

Basically, I'm trying to make sure that "new logic" doesn't destroy something that it shouldn't, and works across the range of configurations.

Also, if you have a strong opinion about if firstboot when executed from a running, extroot-enabled system should wipe the "original" overlay, or the currently active one, I'd appreciate hearing it.

2

imho, i'm sorta sensing ongoing changes... / needs here... the way i'm seeing it is "overlay" dominated fixes when "rom" means many things now...

not sure if you were asking for this... or not but...

extroot-overlay ( non-ubi )

root@wndr3700:~# cat /proc/mounts
/dev/root /rom squashfs ro,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
/dev/sda3 /overlay ext4 rw,relatime,data=ordered 0 0
overlayfs:/overlay / overlay rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
debugfs /sys/kernel/debug debugfs rw,noatime 0 0
/proc/mtd 
root@wndr3700:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00050000 00010000 "u-boot"
mtd1: 00020000 00010000 "u-boot-env"
mtd2: 00780000 00010000 "firmware"
mtd3: 00154440 00010000 "kernel"
mtd4: 0062bbc0 00010000 "rootfs"
mtd5: 003e0000 00010000 "rootfs_data"
mtd6: 00010000 00010000 "art"

if i'm not mistaken... the routine first unmounts any "extroot-overlay" ( likely-all-"extra"-mounts ) prior to going into its zap rootfs_data.../ jffs2reset ? or it's in pre-init... so they are not mounted at that stage... something like that anyway...

extroot-native-device

( on usb -zero overlay -zero rom no idea what firstboot would do here )

[root@syno-rt2600ac / 60°]# cat /proc/mounts
/dev/root / ext4 rw,noatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0
cgroup /sys/fs/cgroup cgroup rw,nosuid,nodev,noexec,relatime,cpuset,cpu,cpuacct,blkio,memory,devices,freezer,net_cls,pids 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
debugfs /sys/kernel/debug debugfs rw,noatime 0 0
1 Like
3

Thanks, yes.

That says that it is

  • external as overlay
  • flash ROM

and not a three-deep arrangement

  • external as overlay
  • flash as overlay
  • flash ROM

(which makes firstboot behavior even more interesting as it looks for rootfs_data by name and erases that)

5

That's pretty interesting to be discussed. I've enabled the usage of the big 42 MB partition for OEM settings in the EA6350v3, as an external overlay instead of the second UBI partition that is "appended" to the OpenWrt firmware, i.e. the rootfs_data.

The thing is that in such case, where the firmware forces the extroot, the firstboot command is useless and I had to patch it myself.

What's the deal? The thing is that I rely on the firstboot command because I use it for the BackToStock script. As the OpenWrt files will interfere with the OEM firmware. When firstboot is called in such a configuration, it does nothing. It says "don't worry, I'll wipe it the next reboot".

The solution I found is to use the find command to delete everything but the directory tree below the /overlay mount point.

What's my opinion? firstboot should wipe both the current overlay and the OpenWrt's overlay which is rootfs_data.

Let's put in perspective:
A user mess up with it's settings in the overlay. They run firstboot (or LuCI) and the router reboots fresh. Once the person restores it's extroot configuration in the OpenWrt's extroot and reboot, the problem will show up again because the currently running overlay never got wiped. Only "the pointer" to the external overlay did.

3 Likes
6

Also, if you have a strong opinion about if firstboot when executed from a running, extroot-enabled system should wipe the "original" overlay, or the currently active one, I'd appreciate hearing it.

My opinion would be to keep extroot as is.

Maybe add some switches to the command

firstboot -W   # Wipe extroot

Or add something to warning after pressing enter

This will erase all settings and remove any installed packages. Are you sure? [N/y] # As it is now

Change to

Exroot detected select 1-delete extroot 2- keep extroot

You selected 1 delete extroot -- This will erase all settings and remove any installed packages. Are you sure? [N/y]

7

I disagree a bit: users which run firstboot or the LuCI factory reset already know that they'll loose everything and that they should backup.
Let's remember, also, that OpenWrt is a product for advanced users, which are not precisely "developers". Some users know how to ssh and run command and have basic knowledge of ash/bash, but they might not know what the heck is jffs2reset.

8

Not too mention, there's always (this may not be quite right due to /overlay/.fs_state)

rm -rf /overlay/*
find /overlay -maxdepth 1 -exec rm -rf {} \;

The second line as, apparently, some "globbing" doesn't catch "dot" files and I'm not a big fan of blindly trusting rm -rf .* not to touch ..

9

I found this to be reliable:

Of course, I can speak by myself but use cases may vary.

1 Like
10

And jffs2reset trying to write deadc0de directly to a NAND-backed MTD device definitely is not

11

It's not if it's not doing it's job when it should. Most of the time jffs2reset will not overwrite any MTD backed because, most of the time, the MTD device is mounted (i.e. busy in kernel terminology), so it will fall back to delete all files in /overlay anyway.
Which is good. I don't blame it, it's a good job. But it will refuse to do it when an external overlay is configured. Instead of deleting the files, as expected, it will say that the rootfs_data will be erased during the next reboot. That's great but it will let the external overlay untouched, which according to me is not consistent because it should guarantee the destruction of the router's running configuration.

12

My two cents: firstboot should disable extroot and leave all files on the external device untouched:

  • On a first boot there is no extroot, so that is what I would expect from firstboot.
  • At least for me, extroot is a means to expand the available space, but also a method to have a second configuration.
  • A user may have an extroot configured, but boot without the device plugged in, and execute a firstboot
13

Let's clarify, @jeff, the difference between an extroot where the situation is similar to ext4 and you cannot wipe it for free... And an external overlay where you should wipe it to avoid further problems.

14

I agree it's expected behavior to run firstboot and start fresh but it would be nice to have switch or even a simple one line command that does the same thing but keeps extroot intact.

It's not like it is a big deal it only takes 5~10 minute's top to get extroot working again.

15

Well, I'm not against it if it's an extroot (i.e. the kernel boots from the device). But I'm against it if it's an external overlay (i.e. the kernel boots from ROM and mounts whatever overlay you setup lately).
That's what I'm arguing but I forgot to do the distinction.