Nyble FTW! Installing my rambooted environment on linux laptop for rescue with grub

Ok, this came about from many hours … HOURS … of not being able to get rescue CD images to boot correctly on my laptop, or in VMs. Things were broken on them, that I could not fix.

That’s when the thought occurred to me … hey … I’d developed this great project nyble (pronounced nibble), which I build full linux environments from baseline distros (currently debian9, CentOS7, Ubuntu18.04), and can be trivially PXE booted, USB booted, or local install booted.

The problem was I wanted to run xfs_repair on my root disk for my laptop. I tried systemrescuecd which I had been using for about a decade, for this. Old versions worked great. The 5.x and 6.x series … didn’t. I could never get the USB sticks to boot without error, and worse, using the grml-rescueboot with the 5.x, I was unable to unmount the iso from the root directory. Yeah, not so fun.

Nyble’s purpose in life is to be a complete linux environment, rambooted, so you don’t have to worry about issues like this. It is meant to be a hypervisor base OS, a development system, etc. where the OS is, itself, stateless, and you get configuration from a central database. Programmatic booting, driven by anything, but I like to use tiburon for this, as it solves the database backed booting problem beautifully.

This, by the way, turns configuration management into image management (far easier), and post-boot configuration. Think cloud-init like. And cloud-init is installed. As are ansible, and other things. You literally do not need to worry about configuration drift, as you can roll forward/backward and start fresh with a reboot. This is such a powerful concept, as configuration management for stateful systems always devolves in to drift management amongst a team/herd of systems. You want the minimum number of systems to be stateful, so that state change is entirely manageable from well defined identical images, that can be rolled forward, backwards, etc. with a reboot and database update. You can boot/test all your images/configs in VMs before deploying (try that with config management on a stateful VM).

You should never have to fight the underlying system about tool or path location. If you can get nyble to boot, then you have all your tools there. Everything just works.

As it is supposed to.

So …

I built a debian9 image in nyble

sudo make build

I copied the kernel and resulting initramfs to my /boot

<code>sudo mkdir -p /boot/nyble
sudo cp -v /mnt/root/boot/initramfs-ramboot* /mnt/root/boot/vmlinuz* /boot/nyble</code>

Then I created /etc/grub.d/40_nyble

<code>!/bin/sh
exec tail -n +3 $0
#
#
#
menuentry "Nlytiq Nyble Debian9" {
         linux   /boot/nyble/vmlinuz-4.9.0-9-amd64 root=ram rootfstype=ramdisk simplenet=1 verbose udev.children-max=4 rootpw=XYZPDQ123 ramdisktype=zram ramdisksize=8 
         initrd  /boot/nyble/initramfs-ramboot-4.9.0-9-amd64
 }</code>

Then a quick update-grub and reboot

sudo update-grub
reboot

This happens:

Note the nyble boot entry

And then I press enter

[fvplayer id=“1”]

With an interesting root mount.

Note the /dev/zram0

A compressed root mounted ramdisk. With a full debian9 distro, plus many other things.

As I said, Nyble for the win! Good tools should never get in your way. They should make it easier for you to do the things that you want and need to do. And they should make it easy to do the hard things. Nyble is that sort of tool. Simple things are basically trivial. Complex things are possible without much pain.