Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #204107 > unrolled thread

/dev/disk/by-id/ in testing

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  /dev/disk/by-id/ in testing Johan en Katrien Dewaele <jenkdewaele2@yahoo.com> - 2019-01-06 11:40 +0100
    Re: /dev/disk/by-id/ in testing songbird <songbird@anthive.com> - 2019-01-06 14:40 +0100
      Re: /dev/disk/by-id/ in testing Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-06 15:50 +0100
      Re: /dev/disk/by-id/ in testing Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-06 16:10 +0100
    Re: /dev/disk/by-id/ in testing David Wright <deblis@lionunicorn.co.uk> - 2019-01-07 15:30 +0100
      Re: /dev/disk/by-id/ in testing songbird <songbird@anthive.com> - 2019-01-07 16:00 +0100
        Re: /dev/disk/by-id/ in testing deloptes <deloptes@gmail.com> - 2019-01-07 19:10 +0100
          Re: /dev/disk/by-id/ in testing Johan en Katrien Dewaele <jenkdewaele2@yahoo.com> - 2019-01-08 13:00 +0100
            Re: /dev/disk/by-id/ in testing deloptes <deloptes@gmail.com> - 2019-01-08 18:40 +0100
            Re: /dev/disk/by-id/ in testing Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-08 20:20 +0100
              Re: /dev/disk/by-id/ in testing Vincent Lefevre <vincent@vinc17.net> - 2019-01-14 11:10 +0100
                Re: /dev/disk/by-id/ in testing Vincent Lefevre <vincent@vinc17.net> - 2019-01-14 11:20 +0100
                  Re: /dev/disk/by-id/ in testing Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-14 20:30 +0100
                    Re: /dev/disk/by-id/ in testing Vincent Lefevre <vincent@vinc17.net> - 2019-01-15 19:50 +0100
    Re: /dev/disk/by-id/ in testing Vincent Lefevre <vincent@vinc17.net> - 2019-01-14 11:10 +0100

#204107 — /dev/disk/by-id/ in testing

[Multipart message — attachments visible in raw view] — view raw

Hi,

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/

total 0
drwxr-xr-x 2 root root 700 jan  6 11:00 ./
drwxr-xr-x 7 root root 140 jan  6 10:32 ../
lrwxrwxrwx 1 root root   9 jan  6 10:32 ata-PIONEER_DVD_RW_DVR-107D -> ../../sr0
lrwxrwxrwx 1 root root   9 jan  6 10:32 ata-ST3500320AS____9QM6D0TB -> ../../sdb
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-ST3500320AS____9QM6D0TB-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-ST3500320AS____9QM6D0TB-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-ST3500320AS____9QM6D0TB-part5 -> ../../sdb5
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-ST3500320AS____9QM6D0TB-part6 -> ../../sdb6
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-ST3500320AS____9QM6D0TB-part7 -> ../../sdb7
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-ST3500320AS____9QM6D0TB-part8 -> ../../sdb8
lrwxrwxrwx 1 root root   9 jan  6 10:32 ata-WDC_WD10EZRX-00L4HB0____WD-WCC4J1SLKT9F -> ../../sda
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-WDC_WD10EZRX-00L4HB0____WD-WCC4J1SLKT9F-part1 -> ../../sda1
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-WDC_WD10EZRX-00L4HB0____WD-WCC4J1SLKT9F-part2 -> ../../sda2
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-WDC_WD10EZRX-00L4HB0____WD-WCC4J1SLKT9F-part5 -> ../../sda5
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-WDC_WD10EZRX-00L4HB0____WD-WCC4J1SLKT9F-part6 -> ../../sda6
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-WDC_WD10EZRX-00L4HB0____WD-WCC4J1SLKT9F-part7 -> ../../sda7
lrwxrwxrwx 1 root root  10 jan  6 10:32 ata-WDC_WD10EZRX-00L4HB0____WD-WCC4J1SLKT9F-part8 -> ../../sda8


in my lilo.conf I have now (after correction): 


#boot=/dev/sda
#boot = /dev/disk/by-id/ata-WDC_WD10EZRX-00L4HB0_WD-WCC4J1SLKT9F
#boot=/dev/disk/by-id/ata-WDC_WD10EZRX-00L4HB0____WD-WCC4J1SLKT9F
 
#boot=/dev/sdb
boot=/dev/disk/by-id/ata-ST3500320AS____9QM6D0TB
#boot=/dev/disk/by-id/ata-ST3500320AS_9QM6D0TB

My question: is this change intentional?  I thought I was "save";-) identifying my disks by ID ? Or did I miss something?


Thanks for any clarification and best regards,

Johan

[toc] | [next] | [standalone]

#204111

Johan en Katrien Dewaele wrote:

> Hi,
>
> my weekly upgrade on testing failed yesterday as,=C2=A0 after an initrd.img=
>  was generated, lilo could not run successfully.

hi,

  i can't help with lilo, haven't used that in ages...

  i don't mount by ids, i mount by labels, but in looking
at the doc for lilo.conf i see that it should also be
possible to use UUIDs too.

  it makes life on a simple system much easier.


  songbird

[toc] | [prev] | [next] | [standalone]

#204114

Le 06/01/2019 à 14:35, songbird a écrit :
> Johan en Katrien Dewaele wrote:
> 
>> my weekly upgrade on testing failed yesterday as,=C2=A0 after an initrd.img=
>>   was generated, lilo could not run successfully.
> 
>    i can't help with lilo, haven't used that in ages...

This issue is not specific to lilo. It would affect grub-pc updates too, 
as the boot device is automatically recorded by device id.

$ debconf-show grub-pc
(...)
* grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD1200BEVE-00WZT0_...

[toc] | [prev] | [next] | [standalone]

#204116

Le 06/01/2019 à 14:35, songbird a écrit :
> 
>    i don't mount by ids, i mount by labels, but in looking
> at the doc for lilo.conf i see that it should also be
> possible to use UUIDs too.

No, UUIDs and LABELs cannot be used to specify a whole partitioned disk 
as the boot device because they are filesystem metadata. Whole 
partitioned disks are not present in /dev/disk/by-{label,uuid}/.

[toc] | [prev] | [next] | [standalone]

#204172

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.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#204174

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.


  songbird

[toc] | [prev] | [next] | [standalone]

#204187

songbird wrote:

> 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.

don't underestimate udev - AFAIK it is responsible for those names and it
fall recently to systemd, so that you can have more joy.

[toc] | [prev] | [next] | [standalone]

#204207

[Multipart message — attachments visible in raw view] — view raw

    On Monday, January 7, 2019, 7:07:37 PM GMT+1, deloptes <deloptes@gmail.com> wrote:  
 
 songbird wrote:

> 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.

don't underestimate udev - AFAIK it is responsible for those names and it
fall recently to systemd, so that you can have more joy.


Thanks for the suggestion, 
My kernel was not upgraded during the weekly upgrade - I compile it myself.  So I also suspect systemd.
In lilo my root partition was/is identified by UUID and also my other partitions are identified by UUID in /etc/fstab,  there is/was no problem mounting them .Only the location of my boot-disk is identified by "ID" in lilo, seems it is not possible to do this by UUID in lilo.Thinking of switching to grub2 to avoid these problems.

Best regards,Johan




  

[toc] | [prev] | [next] | [standalone]

#204213

Johan en Katrien Dewaele wrote:

> Thinking of switching to grub2 to avoid these problems.
> 

good thinking

[toc] | [prev] | [next] | [standalone]

#204216

Le 08/01/2019 à 12:51, Johan en Katrien Dewaele a écrit :
> 
> Only the location of my boot-disk is identified by "ID" in lilo, seems
> it is not possible to do this by UUID in lilo.

I wrote previously in this thread :

This is because the UUID is only part of filesystem metadata and cannot 
be used to specify a device not containing a filesystem, such as a whole 
partitioned disk. Whole partitioned disks are not present in 
/dev/disk/by-{label,uuid}/.

If LILO's boot sector was located in a primary partition boot record 
(PBR) instead of the disk MBR, you could use the partition's filesystem 
UUID in lilo.conf. Of course this requires to write a standard boot 
program in the MBR and set the partition boot flag.

>Thinking of switching to grub2 to avoid these problems.

I also wrote previously in this thread :

This issue is not specific to lilo. It would affect grub-pc updates too, 
because the boot device is specified by device id.

For example on my system :
$ debconf-show grub-pc
(...)
* grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD1200BEVE-00WZT0_...

The issue would be happen less often - only when updating the grub-pc 
package instead of on any kernel update - but it would still happen.

[toc] | [prev] | [next] | [standalone]

#204393

On 2019-01-08 20:12:43 +0100, Pascal Hambourg wrote:
> This issue is not specific to lilo. It would affect grub-pc updates too,
> because the boot device is specified by device id.
> 
> For example on my system :
> $ debconf-show grub-pc
> (...)
> * grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD1200BEVE-00WZT0_...
> 
> The issue would be happen less often - only when updating the grub-pc
> package instead of on any kernel update - but it would still happen.

... which was what happened to be a few days ago!

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#204395

On 2019-01-14 11:06:01 +0100, Vincent Lefevre wrote:
> On 2019-01-08 20:12:43 +0100, Pascal Hambourg wrote:
> > This issue is not specific to lilo. It would affect grub-pc updates too,
> > because the boot device is specified by device id.
> > 
> > For example on my system :
> > $ debconf-show grub-pc
> > (...)
> > * grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD1200BEVE-00WZT0_...
> > 
> > The issue would be happen less often - only when updating the grub-pc
> > package instead of on any kernel update - but it would still happen.
> 
> ... which was what happened to be a few days ago!

Sorry, s/be/me/

BTW, a display bug in the terminal made the problem worse, because
I could not select a device for GRUB installation. So, currently,
new GRUB versions are no longer installed.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#204419

Le 14/01/2019 à 11:09, Vincent Lefevre a écrit :
> On 2019-01-14 11:06:01 +0100, Vincent Lefevre wrote:
>> On 2019-01-08 20:12:43 +0100, Pascal Hambourg wrote:
>>> This issue is not specific to lilo. It would affect grub-pc updates too,
>>> because the boot device is specified by device id.
>>>
>>> For example on my system :
>>> $ debconf-show grub-pc
>>> (...)
>>> * grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD1200BEVE-00WZT0_...
>>>
>>> The issue would happen less often - only when updating the grub-pc
>>> package instead of on any kernel update - but it would still happen.
>>
>> ... which was what happened to me a few days ago!
> 
> BTW, a display bug in the terminal made the problem worse, because
> I could not select a device for GRUB installation. So, currently,
> new GRUB versions are no longer installed.

Which display bug ? During the system installation ?
You can install new versions of GRUB by hand with

# grub-install /dev/disk/by-id/...

Or you can reconfigure grub-pc with

# dpkg-reconfigure grub-pc

If the display bug is still present in the default "dialog" 
(curses-like) front-end, you can try to use the "readline" (command 
line-like) front-end  with "--frontend=readline" when running 
dpkg-reconfigure.

[toc] | [prev] | [next] | [standalone]

#204433

On 2019-01-14 20:20:49 +0100, Pascal Hambourg wrote:
> Le 14/01/2019 à 11:09, Vincent Lefevre a écrit :
> > On 2019-01-14 11:06:01 +0100, Vincent Lefevre wrote:
> > > On 2019-01-08 20:12:43 +0100, Pascal Hambourg wrote:
> > > > This issue is not specific to lilo. It would affect grub-pc updates too,
> > > > because the boot device is specified by device id.
> > > > 
> > > > For example on my system :
> > > > $ debconf-show grub-pc
> > > > (...)
> > > > * grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD1200BEVE-00WZT0_...
> > > > 
> > > > The issue would happen less often - only when updating the grub-pc
> > > > package instead of on any kernel update - but it would still happen.
> > > 
> > > ... which was what happened to me a few days ago!
> > 
> > BTW, a display bug in the terminal made the problem worse, because
> > I could not select a device for GRUB installation. So, currently,
> > new GRUB versions are no longer installed.
> 
> Which display bug ?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919029

> During the system installation ?

During grub upgrade, when (re-)configuring due to the udev bug.

> You can install new versions of GRUB by hand with
> 
> # grub-install /dev/disk/by-id/...

Yes, but one issue is one may not know where GRUB was installed
in the first place (ditto with the other methods).

> Or you can reconfigure grub-pc with
> 
> # dpkg-reconfigure grub-pc

which yields the display issue... unless I increase the terminal
window size *before* I run this command.

> If the display bug is still present in the default "dialog" (curses-like)
> front-end, you can try to use the "readline" (command line-like) front-end
> with "--frontend=readline" when running dpkg-reconfigure.

OK, thanks, I didn't know.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#204394

On 2019-01-06 10:30:26 +0000, Johan en Katrien Dewaele wrote:
> Hi,
> 
> 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/
> 
> total 0
> drwxr-xr-x 2 root root 700 jan  6 11:00 ./
> drwxr-xr-x 7 root root 140 jan  6 10:32 ../
> lrwxrwxrwx 1 root root   9 jan  6 10:32 ata-PIONEER_DVD_RW_DVR-107D -> ../../sr0
> lrwxrwxrwx 1 root root   9 jan  6 10:32 ata-ST3500320AS____9QM6D0TB -> ../../sdb
[...]
> My question: is this change intentional?  I thought I was "save";-) identifying my disks by ID ? Or did I miss something?

FYI, it was due to a bug in udev, fixed there:

systemd (240-3) unstable; urgency=medium
[...]
  * libudev-util: Make util_replace_whitespace() read only len characters.
    Fixes a regression where /dev/disk/by-id/ names had additional
    underscores.
[...]
 -- Michael Biebl <biebl@debian.org>  Wed, 09 Jan 2019 18:40:57 +0100

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web