Transition from AUFS to OverlayFS

[macmpi]

With https://github.com/maxnet/berryboot/commit/9e129fd97e582db48b8a3af7aca56af21a4596f7 one major (and wishful) under-the-hood change is happening: transition from aufs to native overlayfs. It's a great move but comes with few questions:

• (1) aufs is still around: is that just temporary for smooth transition (backward compatibility) or is the intent to keep both in the long run? (is important to know for existing installs and berryboot-init scripts fine-tuning moving foward)

• (2) assuming a move to overlayFS, this potentially opens-up ability to swap-in standard Foundation kernels (and assorted pre-compiled drivers) without the need to compile the whole thing: (good to keep-up with kernel fixes independently of berryboot releases) While it may not be recommended, is it safe to assume, or are there still particularities to berryboot kernel that will forbid that? (maybe some simple tool to regenerate initramfs following some kind of rpi-update would be great)

• (3) about versioning & naming Would really be nice if we could programmatically know which berryboot version is running (from CLI & use in berryboot-init). Thanks to add some basic sort of accessible versioning info.

[maxnet]

aufs is still around: is that just temporary for smooth transition (backward compatibility) or is the intent to keep both in the long run?

Haven't decided yet.

While it may not be recommended, is it safe to assume, or are there still particularities to berryboot kernel that will forbid that? (maybe some simple tool to regenerate initramfs following some kind of rpi-update would be great)

I don't like messing with hooks that stick modules into the initramfs, and prefer everything necessary to access the rootfs partition to be in the kernel. While we could access the rootfs paritition if it is on SD card and has ext4 file system (in which case we could load additional needed modules like overlayfs from there), it will not work if the berryboot user select btrfs as file system while formatting, or if storage is on iscsi. btrfs and iscsi_tcp are not statically compiled into the rpf's kernel configuration, but as module.

Also what if there are multiple operating systems installed, and two want to install different kernels?

Location of modules is also problematic. If someone would run rpi-update those would end up in say /data/Raspbian/lib/modules/ Not very accessible to other operating systems...

Of course, operating systems could all have their own kernel if kexec() worked properly. But it does not, and that is probably something that requires fixes in the Pi firmware files as well. So can only be done by the foundation.

[macmpi]

re (2): The main use-case I have in mind is being able to leverage some existing binary wifi (or DAC) modules that are commonly available (like MrEngman's) for Pi Foundation kernels, without need of recompiling them (as we currently need to due to aufs special kernel).

Would berryboot be able to use Pi Foundation kernels, then installing those modules into an OS image (effectively landing into /data/OS_image/lib/modules/) would just probably work. Of course other OS images would have to install other drivers, but I think that's fine: the benefit would still be great (easily track Foundation Kernel evolution & some drop-in binary modules).

I hear you that in current design, this would break non-baseline setups where rootfs has complex mount (btrfs & iscsi). Indeed having those 2 drivers inside initramfs would probably alleviate that constraints...

[maxnet]

Of course other OS images would have to install other drivers

They need the exact same modules, not "other" ones. Linux kernel version must match modules exactly.

[macmpi]

They need the exact same modules, not "other" ones.

I meant: a different OS image may just require different specific modules altogether depending on its purpose (not talking about their matching kernel versions - obviously any used module driver need to match kernel version). So, all-in-all, not a big deal to install such binary modules specifically for each OS.

So the only issue to such scenario is complex mounts requiring btrfs & iscsi, right? Would having them inside initramfs solve that problem?

[maxnet]

I meant: a different OS image may just require different specific modules altogether depending on its purpose (not talking about their matching kernel versions - obviously any used module driver need to match kernel version).

Match as in EXACT kernel version. Not 4.19.something but exact git commit.

So if you run rpi-update and it replaces the main kernel on the SD card, all other operating system will no longer work properly until you install same kernel modules.

[macmpi]

understood that part. But won't initramfs break first anyway?

[maxnet]

But won't initramfs break first anyway?

If you put modules in there, yes. If there are no modules there, and Berryboot would use the overlayfs module located in Raspbian's modules folder if Raspbian is selected as OS, then no.

[macmpi]

crystal clear, thanks.

Last point on (3) then: how can we determine berryboot version running from CLI or within berryboot-init ? Would be really useful to handle features differences. (clue on UI side would be nice too...)

[maxnet]

I am not a big fan of making assumptions based on version number, better test on features instead. E.g. if you want to know if the Berryboot installation is overlayfs capable, test if "overlay" is in /proc/filesystems

There may be corner cases in which that is not the case despite a new Berryboot version number.

[macmpi]

Sure but sometimes updates are rather bug fixes, so it's hard/impractical to live-test a feature to know for sure. Even in absence of a changelog (albeit desirable), one can refer to github to figure-out the match. There's a existing release number which helps for automatic updates: let's just make that available (like within some /etc/os-release file or similar /etc/bb-release), and bump-it when relevant.

[maxnet]

I am actually not bumping that number right now, as I don't want existing installation to upgrade right now. Let new guinea pigs test out new functionality first and all that. :-)

[macmpi]

Sure, I understand the bumping part. (thought update file delivery was independent of release number bumps)

Making that number available (what-ever it ens-up being), is a good & useful thing: echo-ing it in some dummy environment file seems fair & straightforward enough. Thanks for consideration.

PS: sorry can't guinea pig myself as I have no Pi4; I'll wait for a PiZero release ;-)

[Zwen1111]

I have a Pi4 with Raspbian (+IOTStack) installed on a SSD. When I executed "docker-compose up -d" I got "Service 'nodered' failed to build: error creating aufs mount to ...". Is there anything I can do to make it work? Maybe test a beta version of Berryboot?

[C-Fu]

Does this got to do with my issue? https://github.com/maxnet/berryboot/issues/683