Fedora 9 to 12 – Disk Partitions Issue?
on Dec.06, 2009, under Linux
Fedora 9 to 12
Over the past few days I’ve been upgrading my file/media server from Fedora 9 to Fedora 12. I did this with yum, upgrading from 9 to 10, 10 to 11, and 11 to 12 incrementally, removing conflicts as necessary. This actually went surprisingly well, and at the end, with just one reboot, I had gone from 9 to 12.
It may have booted, but there were a number of things I had to fix afterwards:
- The kernel video mode setting had to be disabled to not break the NVIDIA binary driver (“blacklist nouveau” somewhere in /etc/modprobe.d/). Apparently this is supposed to be handled by installing rpmfusion’s kmod package, but that wasn’t the case for me.
- The X server would crash immediately upon a login. I eventually figured this out to be a missing gnome-session-xsession package. I’m not sure if this is something I had removed for dependency reasons earlier, or if it was split from another package at some point and yum missed it. Either way, it was a real pain to debug, but easy to fix.
- The kernel would not recognize the partitions on three of my disks. This was a major pain, and the main focus of this article.
- I don’t like MythTV 0.22’s new video gallery
Fedora 12 (2.6.31.6-145.fc12.x86_64) Disk Partitions Issue?
So… sdb, sdc, and sde each have a single partition on them, but the kernel (per /proc/partitions and other means) would only report block devices for sdb, sdc, and sde not sdb1, sdc1, and sde1 as should have additionally existed. Naturally, the first thing to consult would be dmesg:
sda: sda1 sda2 sda3 sdb: sdc: sdb1 sdc1 sdd: sde: sdd1 sdd2 sdd3 sde1 sdf: sdf1
At first glance, this looks really, really bad. sdb1 existing on sdc? That’s not supposed to happen. But after looking at it further, and having had some experience debugging multi-threaded things, I became convinced this was the mangled output of multiple parallel partition discovery processes. If that were the case, it looked like it should have been successful, but was not.
So, is this what happened? Googling turned up a bit on the so-called “fastboot” patches to the Linux kernel, at least portions of which have been accepted into recent mainline kernels. Supposedly these would only be enabled with the “fastboot” kernel parameter, but searching the source and docs for the latest kernel didn’t turn up this option. The async libata device discovery does indeed appear to be in 2.6.31 mainline, and I was unable to find a knob to turn it off. There were also references to this interfering with partition discovery. I started the process of rebuilding the kernel to disable this, to see if it fixed the problem, but gave up in favor of a workaround. I’m not fond of maintaining custom kernels – I think the last I did this was to support a boca card.
The workaround. I had noticed that the kernel could be instructed to reread the partition tables (partprobe, for instance) and the missing partitions would appear. I threw in a quick init script to do this and assemble the array early in the startup process:
mdadm --stop /dev/md2 sleep 1 partprobe sleep 2 mdadm --assemble --scan /dev/md2 vgchange -ay mount /storage
So… if I have time, I should complete that kernel rebuild and report this somewhere. In the meantime, I’m posting this for the benefit of others. Lucky for me the partitions affected did not contain my root partition, or this could have been less-work-aroundable.