I run Gentoo on my desktop. It lives on a separate drive, and I use it from time to time whenever I have Linux-related work to do. Recently, though, the install has been feeling its age and certain things have required extensive changes to the base system (specifically new versions of device-mapper).

This post is a warning to anyone wishing to switch to baselayout-2:

MAKE SURE YOUR SYSTEM IS UPDATED BEFORE MIGRATING!

I can’t stress this point enough. If you don’t update your system, you’ll wind up having to pull out older dependencies to remove blocks. In the process, you will discover that certain critical binaries are suddenly missing. This is not the fault of OpenRC nor of the Baselayout and OpenRC Migration Guide. The guide is slightly outdated as many of the manual changes it specifies have since been automated. But I will repeat this: If you’re left with an unbootable system, it is not the fault of OpenRC or the migration guide.

Let’s take a look at what can potentially go wrong.

Borking the Upgrade

If you successfully pull in baselayout-2, openrc, and an updated sysvinit, make changes to your configs as stated in the migration guide, and then boot, there is a small potential you’ll run into a bunch of nasty error messages, including a somewhat ominous:

OpenRC requires tmpfs, ramfs or a ramdisk + ext2 compiled into the kernel.

This is most likely not your problem, particularly if you’re updating a pre-2008.0 Gentoo system (which I was). Keep looking farther up the log, because chances are OpenRC is complaining about the lack of a /bin/mount.

Yep, that’s right. /bin/mount can disappear, and it’s not from the OpenRC migration.

Remember all those blocking packages you pulled out to get a new baselayout shoehorned into place? One of those contained the /bin/mount binary, and you’ll need to do a couple of things to replace it:

• Update sys-apps/util-linux
• Update sys-fs/e2fsprogs
• Important! Update sys-fs/e2fsprogs-libs

If you’re lucky enough to catch this guide before migrating to OpenRC, make absolutely certain you’ve updated the utilities above. Second, make sure your system boots using these new libraries before migration. If you don’t, /bin/mount and /sbin/fsck won’t exist anymore.

If you run emerge -pv e2fsprogs or emerge -pv util-linux from your system prior to the OpenRC migration, you might see something similar to:

Calculating dependencies... done!
[ebuild  N    ] sys-libs/e2fsprogs-libs-1.41.3-r1  USE="nls" 479 kB
[ebuild  N    ] sys-apps/util-linux-2.14.2  USE="crypt nls unicode -loop-aes -old-linux (-selinux) -slang (-uclibc)" 2,888 kB
[blocks B     ] sys-libs/com_err ("sys-libs/com_err" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1)
[blocks B     ] sys-libs/ss ("sys-libs/ss" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1)
[blocks B     ] 

This implies you've got a version of e2fsprogs that won't work with OpenRC. As of this writing, OpenRC appears to depend on e2fsprogs-*-1.41.3-r1. Anything newer than this should work, too. Note that both sys-libs/com_err and sys-libs/ss block newer versions of e2fsprogs; you'll need to remove them (emerge -Ca [offending package]).

Again, verify that /bin/mount and /sbin/fsck exist after pulling in these packages and reboot before migrating to OpenRC. If these binaries disappear, remerge e2fsprogs, e2fsprogs-libs (if needed), and util-linux before rebooting or you'll need a live CD to rescue your system! util-linux may or may not be required; if /usr/bin/mktemp disappears--along with a few other utilities--try remerging this package.

Follow the migration guide, but bear in mind that a couple of the changes it points out may or may not need to be made. Specifically, newer versions of OpenRC appear to migrate your modules.autoload.d/kernel-2.x list; though, you'll want to verify this first!

If your system doesn't boot, don't panic. You can always go back by removing the ~x86 keywords from /etc/portage/package.keywords (if that's how you installed the updated baselayout and sysvinit--which you should, since a system-wide ~x86 is asking for trouble). You'll probably need access to a live CD in the event anything does happen, however.

Something Happened!

It happens. No, really, it does! Everyone who plays with new-release, beta, or unstable software will eventually screw up their Linux install to the point where it no longer boots and that's okay. Unlike the wonderful world of Windows, Linux (and BSD for that matter) installations can be fixed with a little bit of time and expertise--and they don't require a fresh install. Here's what you'll need to fix a non-booting system:

If you have Windows...

...you have several options:

• Grab your original Gentoo disc or burn a new one
• Burn a copy of Knoppix
• Got a copy of Ubuntu? That'll work too!
• Don't want to burn a disc? That's okay--grab Wubi and install Ubuntu on your Windows disk

If you have a couple of Linux distributions installed...

...you can:

• Mount your Gentoo disk and chroot to it
• Use any of the bootable solutions listed above

However, if Gentoo is your only OS...

...why are you reading this? :) You probably know a great deal more about the system than I do!

Here's something really cool if you have access to other Linux distros--be it a live CD or something else you can boot to (Ubuntu via Wubi, for instance). Want access to your Gentoo box? No problem:

(This example assumes / is hda6, /boot is hda1, and /usr is hda7.)

# mkdir /mnt/gentoo
# mount /dev/hda6 /mnt/gentoo
# mount /dev/hda7 /mnt/gentoo/usr
# mount -t proc none /mnt/gentoo/proc
# mount -o bind /dev /mnt/gentoo/dev
# chroot /bin/bash /mnt/gentoo
gentoo# env-update
gentoo# source /etc/profile

That's right, following the Gentoo installation guide can help you fix a broken Gentoo install from another distribution. You can then use this chroot to remerge any missing packages or even back out of the OpenRC migration entirely.

Now there's something you can't do under Windows.