Web lists-archives.com

Re: /dev/disk/by-id/ in testing

David Wright wrote:
> On Sun 06 Jan 2019 at 10:30:26 (+0000), Johan en Katrien Dewaele wrote:
>> my weekly upgrade on testing failed yesterday as,  after an initrd.img was generated, lilo could not run successfully.
>> After checking my /etc/lilo.conf, where I had my boot disk identified by ID as :
>> "boot=/dev/disk/by-id/ata-ST3500320AS_9QM6D0TB" 
>> and comparing it with what is in /dev/disk/by-id I noticed that this identification-id had changed suddeny: see the additional underscores in the names of both harddisks:
>> $ ls -alF /dev/disk/by-id/
>> […]
>> lrwxrwxrwx 1 root root   9 jan  6 10:32 ata-ST3500320AS____9QM6D0TB -> ../../sdb
>> […]
>> lrwxrwxrwx 1 root root   9 jan  6 10:32 ata-WDC_WD10EZRX-00L4HB0____WD-WCC4J1SLKT9F -> ../../sda
>> […]
> In my mind, the suspects would be either the kernel or udev.
> Was either upgraded in your weekly upgrade?
> I'm not sure the kernel would be particularly interested in the disks'
> serial numbers (the part after the underscores) but it's probably the
> easier one to revert temporarily. Not running testing, I don't know
> how much dependencies might make reverting udev tricky.

  first thing i would try is to go back to the previous
known working kernel via dpkg (not apt) and see if that
succeeds in installing and generating an initramfs.

  the problem for me is that i have no lilo and sure
don't want to try it to duplicate the problem since what 
i have is working fine (i learned my lesson when i screwed
up uefi).

  other things to try would be to check the MBR to make
sure it is pointing to the right boot device.  and to
check the partition table and ids and such to make sure
those are correct and that the right partition is marked
as bootable.  mount points, etc.

  as to how those things are picked up by initramfs and
included i've never researched.  if detected file systems
have changed recently for that and included modules and
such ...  i dunno.