switch_root implementation lacks complete functionality

[ghost]

The Toybox switch_root implementation lacks some important functionality.

Most importantly is actually moving /dev, /proc, /sys from the old root to the new root.

See the implementation below for recommendation of moving mounts
ref: https://github.com/karelzak/util-linux/blob/master/sys-utils/switch_root.c
ref: https://github.com/landley/toybox/blob/master/toys/other/switch_root.c

[landley]

There wasn't a switch_root in util-linux when I wrote https://git.busybox.net/busybox/commit/?id=0f34a821ab99 back in 2005 so "complete" sounds like a moving target here. I haven't looked at util-linux's source for license reasons and don't plan to start now. My patch to make CONFIG_DEVTMPFS_MOUNT apply to initramfs bounced (the reply to my third attempt was http://lkml.iu.edu/hypermail/linux/kernel/1709.1/04082.html at which point I lost interest) so when you start init in initramfs, you have no other filesystem mounted. You have to do all the mounts yourself before calling switch_root. If you put them in the old root filesystem instead of the new one, and didn't move them before calling switch_root... that's pilot error? Your script can call --move on the filesystems you added?

It's trivial to add this (an else case to the first if() in del_node) but... is there a reason to care that the third implementation of switch_root (after klibc and busybox) started adding random bells and whistles? There's no standard for this, my version was there first, and your init script did this to itself...?

Rob

[ghost]

Hey Rob,

Thanks for your reply. I was not aware of your history with switch_root attempts, and I came at this only from the perspective of ‘Hey, this worked on until-linux, what gives?’

For now, my init is just handling the moves itself.

is there a reason to care that the third implementation of switch_root (after klibc and busybox) started adding random bells and whistles?

If it’s not a bell and whistle we care to add to toybox, we can close the issue. But surely the third iteration of switch root provided some advantages over the second.

I get that toybox is minimal, but I see no reason to reject a legitimate feature (if it is one) in the name of race to minimalism.

Finally, I’m obviously new to toybox. If there’s a guide to the standard of feature inclusion, I’d love to read it.

[landley]

It's not a definite "no", it's a request for more information. Is there anything you can't do, or is this just a convenience? Did busybox and klibc already change to do what util-linux did? (if it's just util-linux, it'll be eaten by systemd in a couple years and disappear up into the big iron cloud space so not hugely relevant.)

It looks like busybox hasn't added this yet. they did add a "why switch_root" mailing list post I did a decade ago as a big comment though https://git.busybox.net/busybox/tree/util-linux/switch_root.c#n297

Unfortunately what to include or not in toybox isn't black and white, so I don't have a good summary. Instead I half a half-dozen things I could point you at to provide context. The most relevant of which is probably https://landley.net/toybox/roadmap.html .

A lot of other stuff is linked from https://landley.net/toybox/about.html (the design goals page is relevant, and the 2013 talk is still the best overview of what I'm trying to accomplish).

Other context is http://landley.net/aboriginal/about.html#design and below (the project's been replaced by https://github.com/landley/mkroot but the documentation's still relevant), and http://landley.net/aboriginal/history.html

[ghost]

Thanks, this is all very useful information and very exciting.

Is there anything you can't do, or is this just a convenience?

No, it's just a convenience.

Did busybox and klibc already change to do what util-linux did

I'm not experienced enough in either project to go digging, so I'll defer to your judgement.

disappear up into the big iron cloud space

Lol 😄

I think we can close this. I'm fine with the workaround, and the comparable projects don't seem to care about the extra mounts either.