Wandering Thoughts archives

Fedora 18's TexLive packaging failure

Fedora 18's texlive package has a problem. Actually it has at least two problems, one of which makes it our problem. The first problem is that other packages require bits of it to be installed; this is the only reason I have any texlive packages installed. The second problem is that the TexLive package maintainers have chosen to split it up into a truly absurd number of sub-packages. Many of these sub-packages are small, only a few kilobytes (some are below a kilobyte), and some of them are actually empty.

(Other fun things include multiple copies of the GPL, duplicated between various sub-packages. For some packages, the GPL text is the largest single file. Also, some of those empty packages are explicit dependencies of other packages. Why? Who knows.)

Another issue seems to be that texlive's internal dependencies keep creeping around in a way that expands the number of texlive packages installed on your machine over time. My work machine crept up to over a thousand texlive packages, amounting to a fifth of all packages installed on it, and I've seen texlive package updates require additional texlive packages.

This isn't just a problem of massive clutter and its discontents, or of stupid packaging gone absurd. Various yum operations, such as installing package updates, take an amount of time proportional to the amount of packages (no matter how small or empty the package is). Having hundreds of little texlive packages installed thus slows them down drastically; the straw that broke the camel's back on my work machine was a package update that took more than an hour because it was updating over a thousand texlive packages. This elevates texlive's absurd number of sub-packages from merely a bad idea to actively harmful (both because long package update times annoy people and because they encourage people not to update things at all).

I don't know how Fedora allowed things to reach this level of absurdity. But it is absurd and stupid. I've filed a bug about the package count (I didn't discover the other absurdities until now) but to be honest I don't expect anything to change.

(By the way, having this many texlive packages doesn't help people in the least if they want a minimal texlive installation. There are so many packages and they are so absurdly named that I defy anyone who is not deeply immersed in TexLive arcana to figure out what packages they need and what packages they don't.)

I'm sure that the TexLive packagers have some reason for doing all of this; people are rarely crazy. It's just that their reason is a bad one because it has led them into a maze of absurdities. To me this smells of a vastly over-engineered solution, perhaps one put together in the nominal name of efficiency. If so, it has backfired (as these things often do); in a quest for efficiency it has instead created great inefficiency.

What I needed to do with Grub2 to change my boot disk

On my work machine I have been very slowly migrating away from a pair of old drives to a pair of new drives. For quite a while the only thing the old drives have been used for has been booting from and holding /boot; today I finally removed the single surviving old disk and moved to booting off the new disks. It turned out to be somewhat more involved than I expected.

The initial state was /dev/sda as the old drive with /boot as a plain filesystems, /dev/sdb and /dev/sdc as the new drives with /boot-n (the new version of /boot) as a mirrored RAID array and filesystem. My first step (some time ago actually) was to run grub2-install to install the boot blocks on sdb (and sdc, although I have no idea if those work). Unfortunately I forgot to save the exact commands I used to do this. My notes say that I bind-mounted /boot-n on top of /boot during this process so that grub2-install would see the right thing in the right place but I'm not sure how I handled device mappings.

Today I changed my /etc/fstab to fix up the mounts (basically changing /boot-n into /boot), shut the machine down, pulled the old drive, shuffled the cables around, and booted up. The machine started Grub2 but then couldn't boot Linux, ultimately because it couldn't find the kernel and initramfs. This happened because I forgot to update grub.cfg to tell it the new location and UUIDs of the new /boot. Although Grub2 could find the new /boot in order to load grub.cfg, the various kernel stanzas in grub.cfg re-specify where to find the kernel and initramfs with boiler plate like this:

set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  bfe06079-ea84-49cb-a028-d5b1ad47cfba
else
  search --no-floppy --fs-uuid --set=root bfe06079-ea84-49cb-a028-d5b1ad47cfba
fi
linux /vmlinuz-....

(The complexity of a Grub2 grub.cfg is why I'm not really fond of Grub2. I'm not sure we need a shell script interpreter embedded in the boot system, and if it has to be fully programmable I wish they'd used a better language.)

Since my /boot was no longer (MS-DOS) partition 1 or a filesystem with that UUID, this failed and everything bombed out. To get the machine booted I dropped into the Grub2 command line and used its ls command to see what was there (per the Fedora page on Grub2). After finding that I wanted 'md/13' (I believe) I went back and changed the 'set root=...' line to specify it, then told Grub2 to try booting. This worked, although Grub2 warned me that it still couldn't find the particular UUID.

Fixing this permanently required revising grub.cfg; I actually did this twice, once the hard way and once the easy way. The hard way is to use blkid to look up the new /boot's UUID then carefully edit all of the stanzas to change the set root=... bit to md/13 and change the UUID in the search lines. While this worked I didn't think that all of those --hint-... bits were correct any more and they made me nervous.

The easy way to fix this is to use grub2-mkconfig -o /tmp/foo and then pick through /tmp/foo for the official and proper way to do all of this boiler plate. It turned out to be (for me):

set root='mduuid/<md-uuid>'
....
search --no-floppy --fs-uuid --set=root --hint='mduuid/<md-uuid>' <fs-uuid>

(grub2-mkconfig looked up the UUIDs for itself.)

(The really easy way would be to just use grub2-mkconfig to regenerate your grub.cfg, but I have an old-style grub.cfg that I happen to like and didn't want to have replaced with the new Fedora 18 grub2-mkconfig version. Also note that the grub.cfg that grub2-mkconfig creates for you may look nothing like the grub.cfg that the Fedora installer creates. This is a complete mess and I hope that Fedora fixes it someday.)

I'm sure that I'm going to need to do this again sometime in the future. In that future, the smart thing to do will be to update grub.cfg before the initial reboot (after the final copy from the old /boot, for obvious reasons). I'm not sure if grub2-mkconfig would give the right results (even with making the new /boot the actual /boot), but clearly I can just look up the UUIDs by hand.

PS: no, I don't know why Grub2 and grub.cfg don't have a final fallback of 'where you got the grub.cfg from'. Probably it's for the same reason that Grub2 needs a shell script interpreter.