10.3 and new disk naming tree - Suse

This is a discussion on 10.3 and new disk naming tree - Suse ; The old naming method of disk devices (like sda, sdb, ...) in /boot/grub/menu.lst and /etc/fstab seems to be available if you do a mkinitrd after changing the files to sda1, ... Is there anything else to be concerned about ? ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: 10.3 and new disk naming tree

  1. 10.3 and new disk naming tree


    The old naming method of disk devices (like sda, sdb, ...) in
    /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
    mkinitrd after changing the files to sda1, ... Is there anything else to
    be concerned about ? I am not sure how the
    /etc/udev/rules.d/60-persistent-storage.rules apply ? For now it works
    but hopefully the naming will not change from one boot to the next.

    Craig


    You have

    brw-r----- 1 root disk 8, 0 Nov 3 10:59 /dev/sda
    brw-r----- 1 root disk 8, 1 Nov 3 10:59 /dev/sda1
    brw-r----- 1 root disk 8, 2 Nov 3 10:59 /dev/sda2
    brw-r----- 1 root disk 8, 3 Nov 3 10:59 /dev/sda3
    brw-r----- 1 root disk 8, 4 Nov 3 10:59 /dev/sda4
    brw-r----- 1 root disk 8, 5 Nov 3 10:59 /dev/sda5
    brw-r----- 1 root disk 8, 6 Nov 3 10:59 /dev/sda6
    brw-r----- 1 root disk 8, 7 Nov 3 10:59 /dev/sda7
    brw-r----- 1 root disk 8, 8 Nov 3 10:59 /dev/sda8
    brw-r----- 1 root disk 8, 16 Nov 3 10:59 /dev/sdb
    brw-r----- 1 root disk 8, 32 Nov 3 10:59 /dev/sdc
    brw-r----- 1 root disk 8, 48 Nov 3 10:59 /dev/sdd
    brw-r----- 1 root disk 8, 64 Nov 3 10:59 /dev/sde

    and the new /dev/disk/... like

    ../by-id:
    total 0
    lrwxrwxrwx 1 root root 9 Nov 3 10:59
    ata-SAMSUNG_SP1604N_S013J10X663452 -> ../../sda
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    ata-SAMSUNG_SP1604N_S013J10X663452-part1 -> ../../sda1
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    ata-SAMSUNG_SP1604N_S013J10X663452-part2 -> ../../sda2
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    ata-SAMSUNG_SP1604N_S013J10X663452-part3 -> ../../sda3
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    ata-SAMSUNG_SP1604N_S013J10X663452-part4 -> ../../sda4
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    ata-SAMSUNG_SP1604N_S013J10X663452-part5 -> ../../sda5
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    ata-SAMSUNG_SP1604N_S013J10X663452-part6 -> ../../sda6
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    ata-SAMSUNG_SP1604N_S013J10X663452-part7 -> ../../sda7
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    ata-SAMSUNG_SP1604N_S013J10X663452-part8 -> ../../sda8
    lrwxrwxrwx 1 root root 9 Nov 3 10:59 edd-int13_dev80 -> ../../sda
    lrwxrwxrwx 1 root root 10 Nov 3 10:59 edd-int13_dev80-part1 -> ../../sda1
    lrwxrwxrwx 1 root root 10 Nov 3 10:59 edd-int13_dev80-part2 -> ../../sda2
    lrwxrwxrwx 1 root root 10 Nov 3 10:59 edd-int13_dev80-part3 -> ../../sda3
    lrwxrwxrwx 1 root root 10 Nov 3 10:59 edd-int13_dev80-part4 -> ../../sda4
    lrwxrwxrwx 1 root root 10 Nov 3 10:59 edd-int13_dev80-part5 -> ../../sda5
    lrwxrwxrwx 1 root root 10 Nov 3 10:59 edd-int13_dev80-part6 -> ../../sda6
    lrwxrwxrwx 1 root root 10 Nov 3 10:59 edd-int13_dev80-part7 -> ../../sda7
    lrwxrwxrwx 1 root root 10 Nov 3 10:59 edd-int13_dev80-part8 -> ../../sda8
    lrwxrwxrwx 1 root root 9 Nov 3 10:59
    scsi-SATA_SAMSUNG_SP1604NS013J10X663452 -> ../../sda
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    scsi-SATA_SAMSUNG_SP1604NS013J10X663452-part1 -> ../../sda1
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    scsi-SATA_SAMSUNG_SP1604NS013J10X663452-part2 -> ../../sda2
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    scsi-SATA_SAMSUNG_SP1604NS013J10X663452-part3 -> ../../sda3
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    scsi-SATA_SAMSUNG_SP1604NS013J10X663452-part4 -> ../../sda4
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    scsi-SATA_SAMSUNG_SP1604NS013J10X663452-part5 -> ../../sda5
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    scsi-SATA_SAMSUNG_SP1604NS013J10X663452-part6 -> ../../sda6
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    scsi-SATA_SAMSUNG_SP1604NS013J10X663452-part7 -> ../../sda7
    lrwxrwxrwx 1 root root 10 Nov 3 10:59
    scsi-SATA_SAMSUNG_SP1604NS013J10X663452-part8 -> ../../sda8
    lrwxrwxrwx 1 root root 9 Nov 3 10:59
    usb-Generic_USB_CF_Reader_9205291-0:1 -> ../../sdc
    lrwxrwxrwx 1 root root 9 Nov 3 10:59
    usb-Generic_USB_MS_Reader_9205291-0:3 -> ../../sde
    lrwxrwxrwx 1 root root 9 Nov 3 10:59
    usb-Generic_USB_SD_Reader_9205291-0:0 -> ../../sdb
    lrwxrwxrwx 1 root root 9 Nov 3 10:59
    usb-Generic_USB_SM_Reader_9205291-0:2 -> ../../sdd

    ../by-label:
    total 0
    lrwxrwxrwx 1 root root 10 Nov 3 10:59 HP_PAVILION -> ../../sda2
    lrwxrwxrwx 1 root root 10 Nov 3 10:59 HP_RECOVERY -> ../../sda1

    ../by-path:
    total 0
    lrwxrwxrwx 1 root root 9 Nov 3 10:59
    pci-0000:00:02.0-usb-0:2:1.0-scsi-0:0:0:0 -> ../../sdb
    lrwxrwxrwx 1 root root 9 Nov 3 10:59
    pci-0000:00:02.0-usb-0:2:1.0-scsi-0:0:0:1 -> ../../sdc
    lrwxrwxrwx 1 root root 9 Nov 3 10:59
    pci-0000:00:02.0-usb-0:2:1.0-scsi-0:0:0:2 -> ../../sdd





  2. Re: 10.3 and new disk naming tree

    Craig Andersen wrote:
    >
    > The old naming method of disk devices (like sda, sdb, ...) in
    > /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
    > mkinitrd after changing the files to sda1, ... Is there anything else to
    > be concerned about ?


    Yes, the fact that one part of you HD's can still be called hdX instead
    of the expected sdX. This means that I now have hdX and sdX for my IDE
    drives. St00pid!

    houghi
    --
    Personally, I think most sports fans are a little "gay". They'd
    rather watch a bunch of sweaty guys jumping all over eachother,
    than, say fashion TV - where hot models walk down the runway.

  3. Re: 10.3 and new disk naming tree

    On Fri, 2007-11-09 at 11:16 -0600, Craig Andersen wrote:
    > The old naming method of disk devices (like sda, sdb, ...) in
    > /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
    > mkinitrd after changing the files to sda1, ... Is there anything else to
    > be concerned about ? I am not sure how the
    > /etc/udev/rules.d/60-persistent-storage.rules apply ? For now it works
    > but hopefully the naming will not change from one boot to the next.


    /dev/sd* names can change order based on controllers and LUNs
    being added.

    The names under /dev/disk/by-id are persistent.

    I usually use /dev/sd* for / for booting on the kernel line (not
    sure if /dev/disk names work there)... and then use the
    /dev/disk names in /etc/fstab for the other mounts.

    If you keep your primary boot drive at the first drive (e.g.
    /dev/sda), then the rest can float around if you /dev/disk
    instead of the volatile names.



  4. Re: 10.3 and new disk naming tree

    Chris Cox wrote:

    > On Fri, 2007-11-09 at 11:16 -0600, Craig Andersen wrote:
    >> The old naming method of disk devices (like sda, sdb, ...) in
    >> /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
    >> mkinitrd after changing the files to sda1, ... Is there anything else to
    >> be concerned about ? I am not sure how the
    >> /etc/udev/rules.d/60-persistent-storage.rules apply ? For now it works
    >> but hopefully the naming will not change from one boot to the next.

    >
    > /dev/sd* names can change order based on controllers and LUNs
    > being added.
    >
    > The names under /dev/disk/by-id are persistent.
    >
    > I usually use /dev/sd* for / for booting on the kernel line (not
    > sure if /dev/disk names work there)... and then use the
    > /dev/disk names in /etc/fstab for the other mounts.
    >
    > If you keep your primary boot drive at the first drive (e.g.
    > /dev/sda), then the rest can float around if you /dev/disk
    > instead of the volatile names.


    The real hassle is that the apparent drive enumeration order is changed when
    you originally have a SATA-only system and later install PATA drives. The
    dev/disk method gets you into conflicts with BIOS boot algorithms as your
    original GRUB blocks are on what appear to the BIOS as secondary channels -
    it wants to put the PATA drives first. Practically, this has caused me
    more grief with Windows than anything else, but it does open the
    possibility of some disastrous fat finger scenarios by mapping drives to
    places you don't expect - as described earlier regarding installations.

    I've got a load of 100-300G PATA drives laying around so I run up against
    these issues frequently.

    --
    Will Honea

    --
    Posted via a free Usenet account from http://www.teranews.com


  5. Re: 10.3 and new disk naming tree

    Will Honea wrote:
    > Chris Cox wrote:
    >
    >
    >> On Fri, 2007-11-09 at 11:16 -0600, Craig Andersen wrote:
    >>
    >>> The old naming method of disk devices (like sda, sdb, ...) in
    >>> /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
    >>> mkinitrd after changing the files to sda1, ... Is there anything else to
    >>> be concerned about ? I am not sure how the
    >>> /etc/udev/rules.d/60-persistent-storage.rules apply ? For now it works
    >>> but hopefully the naming will not change from one boot to the next.
    >>>

    >> /dev/sd* names can change order based on controllers and LUNs
    >> being added.
    >>
    >> The names under /dev/disk/by-id are persistent.
    >>
    >> I usually use /dev/sd* for / for booting on the kernel line (not
    >> sure if /dev/disk names work there)... and then use the
    >> /dev/disk names in /etc/fstab for the other mounts.
    >>
    >> If you keep your primary boot drive at the first drive (e.g.
    >> /dev/sda), then the rest can float around if you /dev/disk
    >> instead of the volatile names.
    >>

    >
    > The real hassle is that the apparent drive enumeration order is changed when
    > you originally have a SATA-only system and later install PATA drives. The
    > dev/disk method gets you into conflicts with BIOS boot algorithms as your
    > original GRUB blocks are on what appear to the BIOS as secondary channels -
    > it wants to put the PATA drives first. Practically, this has caused me
    > more grief with Windows than anything else, but it does open the
    > possibility of some disastrous fat finger scenarios by mapping drives to
    > places you don't expect - as described earlier regarding installations.
    >
    > I've got a load of 100-300G PATA drives laying around so I run up against
    > these issues frequently.
    >
    >

    What would happen with a ide promise type controller card I wonder?

    Jack

  6. Re: 10.3 and new disk naming tree

    Chris Cox wrote:
    >On Fri, 2007-11-09 at 11:16 -0600, Craig Andersen wrote:
    >> The old naming method of disk devices (like sda, sdb, ...) in
    >> /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
    >> mkinitrd after changing the files to sda1, ... Is there anything else to
    >> be concerned about ? I am not sure how the
    >> /etc/udev/rules.d/60-persistent-storage.rules apply ? For now it works
    >> but hopefully the naming will not change from one boot to the next.


    >/dev/sd* names can change order based on controllers and LUNs
    >being added.


    >The names under /dev/disk/by-id are persistent.


    >I usually use /dev/sd* for / for booting on the kernel line (not
    >sure if /dev/disk names work there)... and then use the
    >/dev/disk names in /etc/fstab for the other mounts.


    >If you keep your primary boot drive at the first drive (e.g.
    >/dev/sda), then the rest can float around if you /dev/disk
    >instead of the volatile names.


    Some of that is not convenient for users. For example
    I often have linux on the high part of the main disk
    in a dual disk system.

    But never mind that. It seems to me that there was
    another way to do it.

    The problem, IIRC, is that the same device might be named
    differently (in the /dev/hda scheme) depending on race
    conditions and the addition of other disks, etc.

    This is a problem. But the new cure is not friendly
    to human beings.

    The right way to do it, in my opinion, is for the computer
    to maintain a list of device names, true IDs that will not
    change. And then on each boot map these to their given
    /dev/hdx names.

    That way each disk has a simple to use name and there is
    no chance of mixing things up.

    As it is now, the *human* has to do that bit of mapping,
    and computers are far better at it than humans.

    --
    --- Paul J. Gans

  7. Re: 10.3 and new disk naming tree

    jrchilds wrote:
    > What would happen with a ide promise type controller card I wonder?


    I have an extra IDE controler.
    The hda-hdd become sda-sde and the hde-hdh become hda-hdd.

    Sucks!

    houghi
    --
    You can have my keyboard ...
    if you can pry it from my dead, cold, stiff fingers

  8. Re: 10.3 and new disk naming tree

    Paul J Gans wrote:
    > Some of that is not convenient for users. For example
    > I often have linux on the high part of the main disk
    > in a dual disk system.
    >
    > But never mind that. It seems to me that there was
    > another way to do it.
    >
    > The problem, IIRC, is that the same device might be named
    > differently (in the /dev/hda scheme) depending on race
    > conditions and the addition of other disks, etc.
    >
    > This is a problem. But the new cure is not friendly
    > to human beings.


    A problem? I would say rightout dangerous.
    I had hde and hdf for my data and backup. hda and hdb are the things I
    play with.

    So when I installed 10.3, it proposed to re-format hda. I almost agreed
    to default. Luckily I wanted to look at the rest when I suddenly saw a
    sda drive. That made me look at the sizes and realize that I almost had
    formatted my drive with my main data.

    houghi
    --
    You can have my keyboard ...
    if you can pry it from my dead, cold, stiff fingers

  9. Re: 10.3 and new disk naming tree

    On Sat, 10 Nov 2007, houghi wrote:-

    >jrchilds wrote:
    >> What would happen with a ide promise type controller card I wonder?

    >
    >I have an extra IDE controler.
    >The hda-hdd become sda-sde and the hde-hdh become hda-hdd.


    Have you opened a bug report about that? AFAIK, all the IDE drives are
    now supposed to be accessed using libata, and should all be identified
    as various sdx devices.

    >Sucks!


    In that sort of situation, it does.

    I've not yet installed on a system with PATA and SATA, or an additional
    IDE controller so don't know what effect it would have. Damn! Now I've
    had my curiosity tweaked...


    Regards,
    David Bolt

    --
    www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
    | SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit
    SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit |
    RISC OS 3.11 | RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC

  10. Re: 10.3 and new disk naming tree

    David Bolt wrote:
    > On Sat, 10 Nov 2007, houghi wrote:-
    >
    >>jrchilds wrote:
    >>> What would happen with a ide promise type controller card I wonder?

    >>
    >>I have an extra IDE controler.
    >>The hda-hdd become sda-sde and the hde-hdh become hda-hdd.

    >
    > Have you opened a bug report about that? AFAIK, all the IDE drives are
    > now supposed to be accessed using libata, and should all be identified
    > as various sdx devices.


    No and I do not realy have time to follow up on it. Perhaps I will when
    the Alpha's or Beta's for 11.0 come out.

    houghi
    --
    You can have my keyboard ...
    if you can pry it from my dead, cold, stiff fingers

  11. Re: 10.3 and new disk naming tree

    houghi wrote:
    >Paul J Gans wrote:


    >> This is a problem. But the new cure is not friendly
    >> to human beings.


    >A problem? I would say rightout dangerous.
    >I had hde and hdf for my data and backup. hda and hdb are the things I
    >play with.


    >So when I installed 10.3, it proposed to re-format hda. I almost agreed
    >to default. Luckily I wanted to look at the rest when I suddenly saw a
    >sda drive. That made me look at the sizes and realize that I almost had
    >formatted my drive with my main data.


    What did you think of my proposal to solve the problem?

    --
    --- Paul J. Gans

  12. Re: 10.3 and new disk naming tree

    Paul J Gans wrote:

    > What did you think of my proposal to solve the problem?
    >


    I wasn't sure about who (BIOS? OS?) kept the map. I would think that a
    relatively simple change to Linux to set the mapping (and utilities to
    manage it) would be quite workable. The functionality would be transparent
    to "ordinary" users while providing a useful control to those of us
    with "strange" configuration requirements. I have one machine here with a
    builtin PATA and both addon SCSI and SATA boards. I'll bet I can create
    some really wierd situations with that.

    I doubt that changing BIOS behavior is an option but I would be all for such
    a system at the OS level.

    --
    Will Honea

    --
    Posted via a free Usenet account from http://www.teranews.com


  13. Re: 10.3 and new disk naming tree

    Will Honea wrote:
    >Paul J Gans wrote:


    >> What did you think of my proposal to solve the problem?
    >>


    >I wasn't sure about who (BIOS? OS?) kept the map. I would think that a
    >relatively simple change to Linux to set the mapping (and utilities to
    >manage it) would be quite workable. The functionality would be transparent
    >to "ordinary" users while providing a useful control to those of us
    >with "strange" configuration requirements. I have one machine here with a
    >builtin PATA and both addon SCSI and SATA boards. I'll bet I can create
    >some really wierd situations with that.


    >I doubt that changing BIOS behavior is an option but I would be all for such
    >a system at the OS level.


    As far as I know, linux doesn't pay attention to the BIOS. It
    scans for the drives directly.

    What I meant was that since linux *now* collects the hardware
    long names *and* has a list of the corresponding old /dev/hdx
    designators, would it not be better if it presented the
    old designators to us, the human beings, and kept the long
    names for its own use?

    --
    --- Paul J. Gans

  14. Re: 10.3 and new disk naming tree

    houghi wrote:
    > Craig Andersen wrote:
    >> The old naming method of disk devices (like sda, sdb, ...) in
    >> /boot/grub/menu.lst and /etc/fstab seems to be available if you do a
    >> mkinitrd after changing the files to sda1, ... Is there anything else to
    >> be concerned about ?

    >
    > Yes, the fact that one part of you HD's can still be called hdX instead
    > of the expected sdX. This means that I now have hdX and sdX for my IDE
    > drives. St00pid!
    >
    > houghi


    I have one machine installed fresh 10.3 on top of 10.2 with the old /home.

    On that one I had only IDE drives and they all got to be /dev/sdx.

    Then I added one SATA drive and everything is still /dev/sdx.

    Another machine with only IDE was done by upgrading to 10.3 on top of 10.0.

    Everything is still /dev/hdx

    Then there is one that has IDE and SCSI drives.

    In 10.0 there were /dev/hdx and /dev/sdx (correct IMO)
    Now, as 10.3 there's only /dev/sdx, fresh install.

    I wonder...

    Vahis
    --
    "Only wimps use tape backup: _real_ men just upload their important
    stuff on ftp, and let the rest of the world mirror it "
    Linus Torvalds 1996.

  15. Re: 10.3 and new disk naming tree

    Paul J Gans wrote:

    > What I meant was that since linux *now* collects the hardware
    > long names *and* has a list of the corresponding old /dev/hdx
    > designators, would it not be better if it presented the
    > old designators to us, the human beings, and kept the long
    > names for its own use?


    Agreed! Are we voting?

    Between adapters and jumpers, this has been a PITA since DOS days.

    --
    Will Honea

    --
    Posted via a free Usenet account from http://www.teranews.com


  16. Re: 10.3 and new disk naming tree

    Paul J Gans wrote:
    > houghi wrote:
    >>Paul J Gans wrote:

    >
    >>> This is a problem. But the new cure is not friendly
    >>> to human beings.

    >
    >>A problem? I would say rightout dangerous.
    >>I had hde and hdf for my data and backup. hda and hdb are the things I
    >>play with.

    >
    >>So when I installed 10.3, it proposed to re-format hda. I almost agreed
    >>to default. Luckily I wanted to look at the rest when I suddenly saw a
    >>sda drive. That made me look at the sizes and realize that I almost had
    >>formatted my drive with my main data.

    >
    > What did you think of my proposal to solve the problem?


    I am not sure what the reason for the change was, but the best solution
    for me would be to change it back like it was. IDE devices are hdX

    houghi
    --
    The blue light suddenly flashed on my horrified face. What a disaster!
    Oh, the humanity! I never thought it would happen to me. How terrifying
    it is to see for yourself "*The Blue Screen of Death*".

  17. Re: 10.3 and new disk naming tree

    On Sun, 11 Nov 2007 20:52:51 +0100, houghi wrote:

    > IDE devices are hdX


    SATA disks are IDE devices too.

  18. Re: 10.3 and new disk naming tree

    Mark South wrote:
    > On Sun, 11 Nov 2007 20:52:51 +0100, houghi wrote:
    >
    >> IDE devices are hdX

    >
    > SATA disks are IDE devices too.


    Then they should be hdX too, or whatever it was in 10.2.

    houghi
    --
    You tried, and you failed, so the lesson is, never try. - Homer J. Simpson.

  19. Re: 10.3 and new disk naming tree

    Mark South wrote:
    >On Sun, 11 Nov 2007 20:52:51 +0100, houghi wrote:


    >> IDE devices are hdX


    >SATA disks are IDE devices too.


    Yes, but IDE devices are not always SATA devices. In the
    good old days IDE drives were /dev/hdx and SATA's were
    /dev/sdx. Now both are /dev/sdx, which is confusing at
    best and dangerous at worst.

    --
    --- Paul J. Gans

  20. Re: 10.3 and new disk naming tree

    On Mon, 12 Nov 2007 17:21:28 +0000, Paul J Gans wrote:

    > Mark South wrote:
    >>On Sun, 11 Nov 2007 20:52:51 +0100, houghi wrote:

    >
    >>> IDE devices are hdX

    >
    >>SATA disks are IDE devices too.

    >
    > Yes, but IDE devices are not always SATA devices.


    Indeed. I was pointing out that the thinking was not very precise in a
    discussion that relies on clear thinking.

    > In the good old days IDE drives were /dev/hdx


    And there you fell into it too. *PATA* IDE drives were /dev/hd?, SATA IDE
    drives were always handled by the SCSI layer.

    > and SATA's were
    > /dev/sdx. Now both are /dev/sdx, which is confusing at
    > best and dangerous at worst.


    The only place that it can make a difference to complain is the lkml, and
    there will only be sympathy if someone offers to maintain the PATA
    library, since it's old and difficult to maintain and used only for PATA,
    whereas everything else can use libata.

+ Reply to Thread
Page 1 of 2 1 2 LastLast