Why people insist on using /boot

You might or might not know that for a while now I’ve passed most of my time idling and chatting in #gentoo-it, trying to offer support whenever I can (when the user asking support deserves it at least). One of the strangely quite common type of support request involved to some extent the standalone /boot partition.

But why people insist on using a standalone /boot partition?

The /boot partition, where you add not only the grub configuration (with its stages), but also the kernels (you might, and probably should, have multiple copies), with their System.map, and optionally their configuration files, the eventual splashscreen for grub and some other stuff, was classically used to allow grub to access the kernel even on systems with a BIOS unable to allow access over the 1024 sector of an hard drive (grub can’t obviously have drivers for all the controllers, so it only uses the BIOS to access the disk). As a partition that would cross that boundary wouldn’t be properly readable by the BIOS, and thus by grub, the common solution was to put a small /boot before that boundary, and then leave the root partition to cross it, as once the kernel booted, the limitation could be ignored safely.

There are of course other cases where a standalone /boot partition could be useful, one case can be to have a way for grub to start and load the kernel, which in turn can boot with a rootfs stored on a device that the BIOS wouldn’t have been able to see (like a software raid1 or a PCI controller that couldn’t be detected); this is my reason to use a /boot on a CF memory card for Klothos: OpenBOOT doesn’t recognize the Promise SATA controller (I just have a SATA disk for that box), and thus I need to boot the kernel from an EIDE-compatible storage (in this case, the CF through an adapter). Please note that Klothos runs FreeBSD; more on that later.

Other cases where having /boot standalone can help is for half-thin clients where the kernel is stored locally, and then the rootfs is mounted via NFS: you can use a simple storage, like the CF I use, to keep /boot, and then load the rest, if the network card doesn’t support proper network boot.

But for the average user, does /boot provide any advantage? Maybe the only one is to avoid the user from deleting the kernel with rm -rf / but that’s almost useless: you would have screwed your system anyway at that point. I find it actually has a big disadvantage: if the user forgets to put it in fstab, he’d have to always mount it before running a make install for the kernel, and that’s something easily forgot.

Also, the use of a different partition for /boot confuses the hell out of some users, who don’t really understand the difference between Linux’s root filesystem’s partition and grub’s root. When I get a support request about installing grub, and I understand the user is confusing the root= parameter to the kernel and the (root hdX,Y) parameter for grub, my suggestion is to just get rid of the standalone /boot.

Not only this, it’s also difficult to decide the size for such a partition: a lot of people would use a size too small, or too big and then waste space.

Now about FreeBSD, well, it also uses a /boot directory, although it contains not only the kernel but also all its modules, and it makes it way harder to move it on a standalone partition. The FreeBSD documentation doesn’t really cover that option, and even looking around you’ll see a lot of people telling you it can’t be done, that FreeBSD ain’t Linux and that /boot is not something to move to its own partition. The truth is that sometimes you just need to do it, and you can, it’s just something much harder to do than in Linux. I had my own trouble, but then solved it.

So, while I can’t say I like FreeBSD idea of hiding the information that shouldn’t be used by the average user, I think that they are cutting out a lot of possible problems this way, and I think that Linux documentation should actively discourage average users of modern system from using a standalone /boot partition.

So my suggestion is: if you can’t name the reason why you’re using /boot as a standalone partition, then don’t use it.

Coming of PAM 0.99 in stable tree

As I failed to prepare some write up for the GWN about this, I think I should at least put a notice on the blog, that people will almost certainly link on the forums for the people who will, certainly, complain about the upgrade.

While the upgrade to 0.99 is basically painless for almost all users, some will experience ebuilds dying if they have orphan files in /etc/pam.d, and others might need to install extra packages to be able to use their specific PAM configuration.

For this, a guide has been written: the Linux-PAM 0.99 upgrade guide. I made sure that the most common searches on Google points to that guide, so that users with a little clue, googling, would find it easily. For the people who experience failures due to old modules being used, the guide is also linked in the postinst messages.

If you know how your system works and what you did to it, the upgrade will be as easy as breathing; if you don’t, you might find strange that things like cron, gdm/kdm, dovecot and other services doesn’t let you in anymore… I found these suggestions too obvious for the upgrade guide, but seems like there are at least some users who don’t have a clue about the common practices about Gentoo systems administration, so they might come useful:

  • always check what is going to be upgraded, or if you’re so crazy to use automatic scheduled upgrades, make sure to check what has been updated;
  • always run etc-update without discarding configuration files changes at the first glance if you don’t understand them (this is critical or you might not be able to login on your system anymore after Linux-PAM upgrade);
  • when you upgrade PAM, restart the services using it, like vixie-cron, dovecot, xdm/gdm/kdm/entrance, and so on (the same applies if you upgrade OpenSSL: restart Apache, Dovecot, and other services that might be providing SSL-based connections).

Now again, please read the Linux-PAM 0.99 upgrade guide, and if you’re still wondering: the package is named sys-libs/pam, but the official name is Linux-PAM, even if it runs fine on FreeBSD, DragonflyBSD and GNU Hurd.

I don’t have 72 hours days!

So seems like even if I try to explain on my blog that I try to do my best with the time, that is not enough to understand why not everything is currently working at the state of the art on Gentoo/FreeBSD.

I know, that the guide isn’t updated and there are black spots and holes that needs to be fixed, but I don’t have vmware-server merged right now (I unmerged it while I was trying to reduce this system to a minimum for a time), and thus I cannot test it first hand yet. I’ll try to do so soon.

I know I have to fix the install-sh trouble that Alex already reported, but I have not yet a good enough idea to fix it.

I’m working on getting dbus in shape on FreeBSD. Unfortunately for some reasons it started fine the first time, then crashed after a while, and now I cannot start it anymore. I’ve already told Timothy about it and he’s working on fixing the issue.

I still have to look at projectM ebuild I was asked to look at; I haven’t looked at MoodBar to add it to portage yet; I’ve yet to look for RubyRipper (sorry Ben I didn’t answer you yet either, I’ll try to look at the ebuild when I have time).

As I said, I’m trying not to prioritise exclusively the things I use directly, so to give a fair share of possibility for other stuff to be done, but I might fail to produce much this way, at least on the short timings (as I said before, bribes are accepted to change my priorities), so you have to bear with me if you want something done now, or you can just submit patches, they are always welcome, even more than bribes.

My break, Amarok, guides

Okay, I confirmed once and definitely my break scheduled for 8^th^–27^th^ of August. Thanks a lot to all the people who supported me on that through the comments :)

And thanks to Ian Monroe, also the Amarok bump problem is solved: he’ll notice me when the release will be done and I’ll see to come back for a day just to bump it out, and after that I’ll return to my vacation.. *Looks at the books ready to be read* Yeah good vacation coming :)

Today I also updated the xine, vlc and ALSA guides, so that they actually reflect the current state of the affairs. I also planned on writing a guide on PulseAudio, but that’s not easy to do considering that, well, there’s not much history to write about.

I might be writing something about kde.eclass, either now or when I’ll be back from the vacation, as that is really a bad ass piece of code, with lots of quirks, and maybe this way I can avoid being asked the same identical questions by some devs from time to time.

Returning a second to PulseAudio, I’m sorry I was late with bumping a few versions around; unfortunately I, well, missed it. I was so much focused on the upcoming KDE release that I literally didn’t see it. To avoid this (pretty embarrassing) situation in the future, I’ve subscribed to all the freshmeat project pages involved.

I’ll also try, during my break, to think about upgrading enterprise. Although a 3500+ CPU isn’t bad at all, and copes well with a normal user system, with all the builds I need to do every day while testing stuff, it’s becoming pretty limited. I’ll be looking forward to buy an Athlon64x2 4600+, as the motherboard supports it with just a BIOS update (thanks Asus!), and the recent cuts to the prices made it go down to €245, which isn’t bad by itself. It’s a bit more of a problem if I combine with a need of another 1GB RAM stick, that will cost me €89 (I currently have a single 1GB RAM stick, which would be a bit of a bottleneck if I go for a X2). If I get another job, I’ll be for sure considering this. Too bad the shops here does not have a special “free software developer” discount ;)

I had a couple more of topics I wanted to write about, more and less related to Gentoo, nothing about the current hot topics actually, but I’ll try to write about them in the next days, they might be interesting to someone.

Documenting before break?

So, as I announced some time ago, next month I’m going on a three weeks break. I really need to relax for a while, as I’m really really under stress in this moment. The whole KDE release, plus other things that happened, were able to upset me so much that I feel like exploding.

Now, while I’m in break, what would happen to the packages that I usually maintain? Probably most of them will lag down. Unfortunately Amarok is unlikely to get into the previously scheduled release of 6^th^ August (that would be just fine to me, as I’m leaving the 8^th^) so if I’m not able to come back for the time needed to bump it, it will probably be lagged down. Yes, there are herds, but.. to be honest, I’m kinda territorial on Amarok alone, probably because there are a few quirks with the ebuild and I’m usually in contact enough with upstream to know what to do.

Also, I’d like if nobody touched xine-lib for the time being, there are many things there that might get messed up if done the wrong way, and although I started documenting its maintainership, I never completed it. I’m fine if somebody bumps ALSA, but I’m afraid nobody would (as they’d know that whoever touches it is going to be enforced in helping out with its long-term maintainership ;) that is why I’m now constricted to maintain it for instance.

Now, before going away, I might end up cleaning up the documentation of the packages, so to let people know what to do and how, and I might even go down on writing something from scratch to pulseaudio, if I find the time and the like. Unfortunately, even if I had time, right now I’m not in the like at all. I’m depressed by the requests I get (of things to do, improve, fix, cleanup, make easier) even when I do the better I can.

Oh well, will try to do something useful in the next days, at least for the sake of the users who trust me :)