|
My working fstab:
LABEL=/ / ext3 defaults 1 1 tmpfs /tmp tmpfs size=4g 0 0 tmpfs /var/tmp tmpfs size=4g 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/sda2 swap swap defaults 0 0 /dev/sda3 /home ext3 defaults 1 2 The form that it takes when it is broken: LABEL=/ / ext3 defaults 1 1 tmpfs /tmp tmpfs size=4g 0 0 tmpfs /var/tmp tmpfs size=4g 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/libata-migrate/by-id/ata-ST9320421AS_5TJ0CYZZ-part2 swap swap defaults 0 0 /dev/libata-migrate/by-id/ata-ST9320421AS_5TJ0CYZZ-part3 /home ext3 defaults 1 2 Note that rPL2 has removed the dep on libata-migrate in order to allow users of rPL2 to avoid running libata-migrate when they have no need for it to run.
In mkinitrd, I see:
for i in /boot/grub/grub.conf /etc/bootloader.conf /etc/fstab \
/etc/smartd.conf /boot/grub/device.map /etc/mtools.conf $RCFILE
do
[ -f $i ] && DEVSUB="$DEVSUB $i"
done
rm -f /etc/sysconfig/devsub # or it may not modify $RCFILE
[ -n "$DEVSUB" ] && /usr/bin/devsub /etc/sysconfig $DEVSUB
The rm -f there might be the culprit – it's not supposed to run all the time; the whole point of that /etc/sysconfig/devsub file is to know whether devsub needs to be re-run. So I think we need to review differences between the FL and rPL mkinitrds in the if [ -x /sbin/libata-migrate-links ]; then section for relevant differences, and also remove libata-migrate by default because it is no longer necessary. Today I erased two older versions of kernel. Later I couldn't boot into the dual-boot windows vista. Turned out /etc/fstab was modified to contain the invalid /dev/libata-* path.
I have removed libata-migrate from systems I manage as an effective workaround for this issue.
libata-migrate is not needed on foresight; foresight really isn't affected by the migration issue between rpl1 and rpl2 that prompted writing libata-migrate, because production foresight 1 had and used libata modules already. Therefore, I wouldn't invest energy in fixing libata-migrate, I'd just remove it. Preferably entirely, but if not entirely, then byDefault=False. |
||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Normal
fails to boot due to libata-migrate
In an update around November 10th, this happened (I did not notice it until I tried to reboot and the reboot failed), and then it happened again tonight on another update (but this time I looked for it and caught it before rebooting...)
I am wondering whether the Foresight mkinitrd is missing something from the rPL mkinitrd, and also whether the right answer is to remove libata-migrate. Its only real purpose was to facilitate migrations from rPL1 to rPL2, and anyone who is going to migrate from FL1 to FL2 at this point probably is going to have more difficult issue to deal with...
It seems likely that this happens on any system that doesn't use mount-by-label, so it is probably easy to reproduce.