Removing `bedrock` stratum (aka uninstalling)

[tbodt]

I've just started learning about what Bedrock is and how it works, and after perhaps an hour I've decided it should be possible at least in principle to offer an inverse of the hijack operation. I'm opening this issue as a request to point out the fatal flaw in this plan.

First of all you cannot do this is there is more than one stratum active other than the bedrock one. If your bedrock installation includes many contributions from many strata, this operation doesn't make sense. If hijacking is like adding a bedrock stratum, the opposite is like removing the bedrock stratum, and then there has to be exactly one left since the bedrock stratum contained the tools that allow making strata appear merged and with that gone you can only have the one left. This also guarantees that what is left is bootable.

The process goes something like, reboot into a recovery-like mode, merge the files in global paths with the files in the remaining stratum, undo bedrock's customizations to files like /etc/passwd, and pray. I assume that last step is where the problems start?

[tbodt]

IDK why i am taking this idea so seriously but I just went and installed bedrock linux and compared the rootfs before with the stratum after and here are the differences

• directories listed in global.share config are gone, moved out of the stratum to the root. would need to be merged
• lots of files are gone from /etc, as listed in global.etc config. would need to be merged
• symlinks from config are created. would need to be deleted
• some etc injections have occurred as requested in the config. should be as easy to undo as they were to apply
  • /etc/profile gets an extra line to source /bedrock/run/profile
  • /etc/sudoers got an include
• many /etc files have been changed. these are, i suppose, the hardest changes to undo...
  • /etc/environment gets bedrock's path variables
  • /etc/fstab has been...reformatted? and the passno fields have been all set to 0. fine to leave i guess. (but, why did that change?)
  • everyone's shell in /etc/passwd changed to be in /bedrock/cross
  • matching the above, every shell in /etc/shells that started with /usr/bin has been changed to start with /bedrock/cross/bin
  • /etc/login.defs has had the path definition clobbered, and the uid/gid min/max values tweaked

That's a lot of etc files changed. I guess it's not always perfectly possible to remove the changes, but should be possible to end up with a "good enough" system state that at least doesn't reference paths in /bedrock anymore. Anyway, regardless of whether this was a good idea, putting together this list was interesting and fun

[tbodt]

Hm I see - pretty much all of these /etc customizations are carried out by brl apply. It would be easier for me to just read that

[paradigm]

While you're welcome to explore it for your own elucidation or enjoyment, I don't plan on supporting reverting the hijack process in 0.7 Poki. You've correctly touched on a number of key difficulties, including undoing changes to configuration files and, very importantly, the fact Bedrock can't ensure that the one stratum left on the system will be able to provide everything the user wants/needs like the kernel, bootloader, init, login shells, and possibly GUI or networking setup.

The plan for 0.8 Naga includes having two install options:

• Hijack, similar to Poki.
• Hosted, where Bedrock runs "on" another distro more like a typical application rather than hijacking the OS install.

The latter option guarantees that everything essential comes from the host OS, and so there's no problem reverting the install. However, it does mean Bedrock can't offer some functionality like using any stratum's init.

Additionally, with Naga I plan to better organize the code which configures software to utilize cross-stratum functionality (mostly but not only the /etc items you've found):

• This will require any given automated-configuration item to populate a "revert" field which undoes its operation.
• The user will be able to opt in/out of automating configuration, both en mass at install time and fine-tune per item configuration at run time. If the user opts out for a given item, they'll have to manually use long paths or configure the software themselves. Some users, I think, dislike the "magic" of having Bedrock automatically set everything up and would prefer to do more themselves. In this case, Bedrock will have no need to revert anything.

With the hosted install and better management of configuration changes, I plan on officially supporting uninstalling a hosted Naga install.

Following the initial stable Naga release, I may be more open to investigating the ability to undo a hijack install. The issue then will be less about R&D to figure it out than it is a gut-feel check about the risk of some not-super-savvy user, under the impression this is supported, removes strata that provide key features they need and end up breaking their install beyond their ability to recover it. This isn't hypothetical - I've had users do this 0.7 even with install-time molly-guards about the fact it's not supported, and it's a headache every time.

[tbodt]

the fact Bedrock can't ensure that the one stratum left on the system will be able to provide everything the user wants/needs like the kernel, bootloader, init, login shells, and possibly GUI or networking setup.

This one seems like one of the lesser concerns to me - if you have to delete the other strata manually before starting, i think you've guaranteed that the remaining stratum has everything you need. Or is the risk that people will read about how you need to have just one stratum left, then blindly delete strata and break the system before starting the unhijack?

I'm probably not going to go much further with this idea at the moment, but I sure learned a lot, and it was interesting to hear about the plans for 0.8.0. And if I ever do feel like manually unhijacking an install I would know what to do.

Is 0.8.0 in development currently, or just planned?

[paradigm]

the fact Bedrock can't ensure that the one stratum left on the system will be able to provide everything the user wants/needs like the kernel, bootloader, init, login shells, and possibly GUI or networking setup.

This one seems like one of the lesser concerns to me - if you have to delete the other strata manually before starting, i think you've guaranteed that the remaining stratum has everything you need.

That's not necessarily the case. Consider, for example, /boot handling with GRUB. Typically, one stratum is in charge of updating GRUB's configuration when you do things like add/remove kernels. If you remove this stratum, the system still boots with the preexisting global /boot directory, but it's no longer updated. If you later update your kernel, changing its filename/path, without updating GRUB, the next boot will fail.

Tracking which stratum provides/maintains/is-responsible-for features that show up in global paths is an open research problem. I'd love to support a kernel stratum alias similar to the existing dynamically-maintained init stratum alias.

Or is the risk that people will read about how you need to have just one stratum left, then blindly delete strata and break the system before starting the unhijack?

That's a large concern, yes. Some users are likely to think through the process and be careful, but I've had enough bad experiences with less thoughtful/careful users that I'm hesitant to give them more rope with which to hang themselves. I'd prefer to offer some less error-prone path, and the planned hosted install I think is a good incremental step in that direction.

I'm probably not going to go much further with this idea at the moment, but I sure learned a lot, and it was interesting to hear about the plans for 0.8.0. And if I ever do feel like manually unhijacking an install I would know what to do.

I was worried I'd come across as raining on your parade, and I'm happy to hear that you've in fact benefited from your experience.

Is 0.8.0 in development currently, or just planned?

It's currently in active development. I have quite a lot of the theoretical design work done in my head, but sadly actual documentation and implementation is progressing slower than expected due to personal life issues. I hope to put out an alpha hand-wavey Soon™ that is feature incomplete but has obvious structure people can build off of, allowing others to more easily contribute to its development and lessening my place as a bottleneck. I also hope to resolve the personal life issues which limit my ability to work on Bedrock and get back to more rapid development toward an eventual 1.0 release.