Arch Linux

On a couple of older i686 laptops, circa 2006, with systemd 232-1, there is some problem where systemd will not be able to recognize the HD partitions, right after the kernel sets-up the drive - a 40GiB and 75GiB Hitachi in these cases. This seems to be something that tracks with the systemd package, as downgrading *just* the systemd package, to 231-4, makes the problem go away. I did *not* see the problem on a couple of newer x86-64 laptop and desktop machines.

The most telling thing that I've noticed so far is that, when systemd fails, the "lsblk -f" command only knows the mount points, and *the UUIDs are all blank*. The lsblk man page says "reads the sysfs filesystem and udev db to gather information". So, if systemd tries to do the same thing, and fails to receive the UUIDs, then everything fails from there - no swap, no root, no journald, ... and systemd is stuck, with timeouts. But then, if systemd is downgraded, the lsblk command works normally, and shows the UUIDs. I also seem to remember that the problem did not occur on the first reboot after the upgrade, which included the recent kernel upgrade. That seems odd. And downgrading the kernel made no difference.

232-1 definitely has some problem on some hardware. I can boot into systemd emergency mode to twiddle things, and downgrade systemd. There are no other oddities so far, while running with the 232-1 systemd in emergency mode. The partitions can all be mounted and read and written. fsck says the fs is clean. blkid -p returns all the correct UUIDs. There is just that issue with lsblk and systemd boot.

If you have any ideas where to look for the cause of this, please let me know. In particular, how could systemd affect lsblk? Something with the udev db? Or with the udevd 232 specifically? Is systemd-udevd not working on i686?

So far, I don't see any complaints on systemd git issues, so this may be specific to Arch.