Switching from (deprecated) IDE driver -> SATA (PATA support)

Switching from (deprecated) IDE driver -> SATA (PATA support)

[Justin Piszcz]

When switching (removing IDE support) in favor of the new PATA support 
under the SATA menu, is there any best practice/or method of knowing what 
the new root hdd will be upon reboot?

Example:
If I have 10 sata disks and 2 IDE disks on various cards/controllers, how 
do I know /dev/hda will become /dev/sda?  In one test on a system I have 
here, /dev/hda became /dev/sdb2 after reboot, not an issue if the box is 
local, but if the box is remote, how do you cope with this?  I ask now 
because some IDE drivers have been removed (nvidia I believe? in 2.6.28) 
and I cannot upgrade the kernel anymore unless I move to the 
PATA-supported SATA driver, but I have no idea what the root disk will be 
after a reboot and there is a high probability it will not come back after 
a reboot..

Justin.

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Alan Cox]

> and I cannot upgrade the kernel anymore unless I move to the 
> PATA-supported SATA driver, but I have no idea what the root disk will be 
> after a reboot and there is a high probability it will not come back after 
> a reboot..

Easiest is to use labels. Old ide will keep hda,b,c,d constant
providing you have interfaces using the legacy IDE port mappings (0x1f0
and 0x170). Libata doesn't do that as pretty much every distribution had
already switched to volume labels, and the user space can do the job far
better than the kernel - especially as the newer devices with modern
interfaces don't have the old BIOS/DOS legacy ideas any more.

Mount by label also means you can flip back and forth between the
different drivers and kernel revisions.

Alan

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Justin Piszcz]

On Sun, 25 Jan 2009, Alan Cox wrote:

> Easiest is to use labels. Old ide will keep hda,b,c,d constant
> providing you have interfaces using the legacy IDE port mappings (0x1f0
> and 0x170). Libata doesn't do that as pretty much every distribution had
> already switched to volume labels, and the user space can do the job far
> better than the kernel - especially as the newer devices with modern
> interfaces don't have the old BIOS/DOS legacy ideas any more.
>
> Mount by label also means you can flip back and forth between the
> different drivers and kernel revisions.
>
> Alan
>

That works well with ext* filesystems as one can set it anytime with 
e2label if I recall; however, how can one do this with XFS, is it 
possible without booting off a boot-cd etc?

Here is the filesystem information:
p254:~# xfs_info /dev/sdd2
meta-data=/dev/root              isize=256    agcount=16, agsize=1186676 blks
          =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=18986816, imaxpct=25
          =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096 
log      =internal               bsize=4096   blocks=9270, version=1
          =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=65536  blocks=0, rtextents=0

When I try to label it:
p254:~# xfs_admin -L "root" /dev/sdd2
xfs_admin: /dev/sdd2 contains a mounted filesystem

fatal error -- couldn't initialize XFS library

The label is currently not set:
p254:~# xfs_admin -l  /dev/sdd2
label = ""
p254:~#

I guess my next step is to try UUID?

        Instead of giving the device explicitly, one may indicate the (ext2  or
        xfs)  filesystem that is to be mounted by its UUID or volume label (cf.
        e2label(8) or  xfs_admin(8)),  writing  LABEL=<label>  or  UUID=<uuid>,
        e.g.,   `LABEL=Boot'   or  `UUID=3e6be9de-8139-11d1-9106-a43f08d823a6'.
        This will make the system more robust: adding or removing a  SCSI  disk
        changes the disk device name but not the filesystem volume label.

p254:~# xfs_admin -U generate /dev/sdd2
xfs_admin: /dev/sdd2 contains a mounted filesystem

fatal error -- couldn't initialize XFS library
p254:~#

Hmm, am I out of luck?

Justin.

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Justin Piszcz]

On Sun, 25 Jan 2009, Justin Piszcz wrote:

>
>
> On Sun, 25 Jan 2009, Alan Cox wrote:
>
>> Easiest is to use labels. Old ide will keep hda,b,c,d constant
>> providing you have interfaces using the legacy IDE port mappings (0x1f0
>> and 0x170). Libata doesn't do that as pretty much every distribution had
>> already switched to volume labels, and the user space can do the job far
>> better than the kernel - especially as the newer devices with modern
>> interfaces don't have the old BIOS/DOS legacy ideas any more.
>> 
>> Mount by label also means you can flip back and forth between the
>> different drivers and kernel revisions.
>> 
>> Alan
>> 
>
> That works well with ext* filesystems as one can set it anytime with e2label 
> if I recall; however, how can one do this with XFS, is it possible without 
> booting off a boot-cd etc?
>
> Here is the filesystem information:
> p254:~# xfs_info /dev/sdd2
> meta-data=/dev/root              isize=256    agcount=16, agsize=1186676 blks
>         =                       sectsz=512   attr=0
> data     =                       bsize=4096   blocks=18986816, imaxpct=25
>         =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096 log      =internal 
> bsize=4096   blocks=9270, version=1
>         =                       sectsz=512   sunit=0 blks, lazy-count=0
> realtime =none                   extsz=65536  blocks=0, rtextents=0
>
> When I try to label it:
> p254:~# xfs_admin -L "root" /dev/sdd2
> xfs_admin: /dev/sdd2 contains a mounted filesystem
>
> fatal error -- couldn't initialize XFS library
>
> The label is currently not set:
> p254:~# xfs_admin -l  /dev/sdd2
> label = ""
> p254:~#
>
> I guess my next step is to try UUID?
>
>       Instead of giving the device explicitly, one may indicate the (ext2 
> or
>       xfs)  filesystem that is to be mounted by its UUID or volume label 
> (cf.
>       e2label(8) or  xfs_admin(8)),  writing  LABEL=<label>  or 
> UUID=<uuid>,
>       e.g.,   `LABEL=Boot'   or 
> `UUID=3e6be9de-8139-11d1-9106-a43f08d823a6'.
>       This will make the system more robust: adding or removing a  SCSI 
> disk
>       changes the disk device name but not the filesystem volume label.
>
> p254:~# xfs_admin -U generate /dev/sdd2
> xfs_admin: /dev/sdd2 contains a mounted filesystem
>
> fatal error -- couldn't initialize XFS library
> p254:~#
>
> Hmm, am I out of luck?
>
> Justin.
>

It comes with one :)
# xfs_admin -u  /dev/sdd2
UUID = 77ae4251-631f-4656-a365-c5723f5c5da8

Will try to use this to boot; however, I'd prefer the labels over the 
UUID, wish there was an easy way to set it.

Justin.

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Justin Piszcz]

On Sun, 25 Jan 2009, Justin Piszcz wrote:

>
>
> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>
>> 
>> 
>> On Sun, 25 Jan 2009, Alan Cox wrote:
>> 
>>> Easiest is to use labels. Old ide will keep hda,b,c,d constant
>>> providing you have interfaces using the legacy IDE port mappings (0x1f0
>>> and 0x170). Libata doesn't do that as pretty much every distribution had
>>> already switched to volume labels, and the user space can do the job far
>>> better than the kernel - especially as the newer devices with modern
>>> interfaces don't have the old BIOS/DOS legacy ideas any more.
>>> 
>>> Mount by label also means you can flip back and forth between the
>>> different drivers and kernel revisions.
>>> 
>>> Alan
>>> 
> It comes with one :)
> # xfs_admin -u  /dev/sdd2
> UUID = 77ae4251-631f-4656-a365-c5723f5c5da8
>
> Will try to use this to boot; however, I'd prefer the labels over the UUID, 
> wish there was an easy way to set it.
>
> Justin.
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>

One final question, without udev, how does one determine the UUID of a non-XFS
partition, e.g., swap?

$ ls -l
total 0
lrwxrwxrwx 1 root root  9 2009-01-25 01:54 203fcd30-4e56-40e9-a8e5-93ddc8eb536a -> ../../md0
lrwxrwxrwx 1 root root 10 2009-01-25 01:54 2ef862e1-cf78-4065-a205-d1784716d633 -> ../../sdd1
lrwxrwxrwx 1 root root 10 2009-01-25 01:54 77ae4251-631f-4656-a365-c5723f5c5da8 -> ../../sdd2

p254:~# find /proc/|grep -i uuid
/proc/sys/kernel/random/uuid
p254:~# find /sys/|grep -i uuid 
p254:~#

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Justin Piszcz]

On Sun, 25 Jan 2009, Justin Piszcz wrote:

>
>
> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>
>> 
>> 
>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>> 
>>> 
>>> 
>>> On Sun, 25 Jan 2009, Alan Cox wrote:
>>> 
>>>> Easiest is to use labels. Old ide will keep hda,b,c,d constant
>>>> providing you have interfaces using the legacy IDE port mappings (0x1f0
>>>> and 0x170). Libata doesn't do that as pretty much every distribution had
>>>> already switched to volume labels, and the user space can do the job far
>>>> better than the kernel - especially as the newer devices with modern
>>>> interfaces don't have the old BIOS/DOS legacy ideas any more.
>>>> 
>>>> Mount by label also means you can flip back and forth between the
>>>> different drivers and kernel revisions.
>>>> 
>>>> Alan
>>>> 
>> It comes with one :)
>> # xfs_admin -u  /dev/sdd2
>> UUID = 77ae4251-631f-4656-a365-c5723f5c5da8
>> 
>> Will try to use this to boot; however, I'd prefer the labels over the UUID, 
>> wish there was an easy way to set it.
>> 
>> Justin.
>> 
>> _______________________________________________
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
>> 
>
> One final question, without udev, how does one determine the UUID of a 
> non-XFS
> partition, e.g., swap?
>
> $ ls -l
> total 0
> lrwxrwxrwx 1 root root  9 2009-01-25 01:54 
> 203fcd30-4e56-40e9-a8e5-93ddc8eb536a -> ../../md0
> lrwxrwxrwx 1 root root 10 2009-01-25 01:54 
> 2ef862e1-cf78-4065-a205-d1784716d633 -> ../../sdd1
> lrwxrwxrwx 1 root root 10 2009-01-25 01:54 
> 77ae4251-631f-4656-a365-c5723f5c5da8 -> ../../sdd2
>
> p254:~# find /proc/|grep -i uuid
> /proc/sys/kernel/random/uuid
> p254:~# find /sys/|grep -i uuid p254:~#
>
>

In lilo.conf:
root="UUID=77ae4251-631f-4656-a365-c5723f5c5da8"

image=/boot/2.6.28-4
         label=2.6.28-4
         read-only
         root="UUID=77ae4251-631f-4656-a365-c5723f5c5da8"

The /etc/fstab entry works, but not the LILO one.

Also I found a bug (OOPS) with a box I was testing the new subsystem 
(SATA vs. old IDE) with, will send a bug report shortly.

Justin.

Re: Switching from (deprecated) IDE driver -> SATA (PATA support) (found solution)

[Justin Piszcz]

On Sun, 25 Jan 2009, Justin Piszcz wrote:

>
>
> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>
>> 
>> 
>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>> 
>>> 
>>> 
>>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>>> 
>>>> 
>>>> 
>>>> On Sun, 25 Jan 2009, Alan Cox wrote:

        root=<root-device>
               This specifies the device that should be mounted  as  root.   It
               may  be  specified as a global option.  If the special name cur-
               rent is used, the root device is set to the device on which  the
               root  file  system  is  currently  mounted. If the root has been
               changed with  -r , the respective device is used. If  the  vari-
               able `root' is omitted, the root device setting contained in the
               kernel image is used.  (And that is set at  compile  time  using
               the  ROOT_DEV  variable in the kernel Makefile, and can later be
               changed with the rdev(8) program.)

Change root= to root=current && lilo && reboot, this works as well, note I did
have the proper UUIDs set in /etc/fstab before doing this.

Trying without changing /etc/fstab, back to old entries:
/dev/hda2     /               xfs     noatime         0       1
/dev/hda1      none            swap    sw              0       0
#UUID=77ae4251-631f-4656-a365-c5723f5c5da8      /               xfs     noatime         0       1
#UUID=2ef862e1-cf78-4065-a205-d1784716d633      none            swap    sw              0       0

(which are wrong)

p254:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdd2              73G  2.2G   71G   3% /
p254:~# df -h

But using current!

p254:~# grep current /etc/lilo.conf
# case it installs in the MBR, and will overwrite the current MBR.
root=current
         root=current
p254:~#

p254:~# reboot

Does it come back?

$ uptime
  07:55:16 up 0 min,  1 user,  load average: 0.71, 0.20, 0.07

Yes it does, so the work-around is to use root=current, fix up your /etc/fstab
and other files after.

Justin.

Re: Switching from (deprecated) IDE driver -> SATA (PATA support) (found solution (scratch that))

[Justin Piszcz]

On Sun, 25 Jan 2009, Justin Piszcz wrote:

>
>
> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>
>> 
>> 
>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>> 
>>> 
>>> 
>>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>>> 
>>>> 
>>>> 
>>>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Sun, 25 Jan 2009, Alan Cox wrote:

Hm, I may have spoke too fast:

Added: (IDE ONLY), no SATA:
image=/boot/2.6.26-6
         label=2.6.26-6
         read-only
         root=current

p254:/boot# lilo
Added 2.6.26-6 *
Added 2.6.28-4
p254:/boot#

Set to current.

p254:/boot# grep =current /etc/lilo.conf
root=current
         root=current
p254:/boot#

The reason current may have worked before is because I manually booted with
root=/dev/sdd2 (after I saw the error that it could not find root,302, etc)

So I am booting the old kernel without the SATA drivers with root=current
to see if it works..

Nope, so I need to figure out how to get the UUID= option working in LILO.

Justin.

Re: Switching from (deprecated) IDE driver -> SATA (PATA support) (found solution (scratch that))

[Michael Tokarev]

Justin Piszcz wrote:
> 
> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>>>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>>>>> On Sun, 25 Jan 2009, Justin Piszcz wrote:

Wow, that's quite some ping-pong!.. ;)

[]
> Hm, I may have spoke too fast:
> 
> Added: (IDE ONLY), no SATA:
> image=/boot/2.6.26-6
>         label=2.6.26-6
>         read-only
>         root=current
> 
> p254:/boot# lilo
> Added 2.6.26-6 *
> Added 2.6.28-4
> p254:/boot#
> 
> Set to current.
> 
> p254:/boot# grep =current /etc/lilo.conf
> root=current
>         root=current
> p254:/boot#
> 
> The reason current may have worked before is because I manually booted with
> root=/dev/sdd2 (after I saw the error that it could not find root,302, etc)
> 
> So I am booting the old kernel without the SATA drivers with root=current
> to see if it works..
> 
> Nope, so I need to figure out how to get the UUID= option working in LILO.

There's no way without using initramfs.  Lilo only records the unix device
number (like 8:1 for /dev/sda1) and passes it to kernel (replacing `current'
with that number).  But for different kernels (IDE vs PATA drivers) the
number will be different.  Lilo itself - when booting at least - can not
know which device it will be.

The only universal solution is to use smart initramfs that will populate
/dev/disk/by-label/ etc (using udev maybe).

Another solution is to explicitly specify root=/dev/sda1 or root=/dev/hda1
when using pata- or ide-enabled kernels, in lilo.conf.

/mjt

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Eric Sandeen]

Justin Piszcz wrote:

> One final question, without udev, how does one determine the UUID of a non-XFS
> partition, e.g., swap?
> 
> $ ls -l
> total 0
> lrwxrwxrwx 1 root root  9 2009-01-25 01:54 203fcd30-4e56-40e9-a8e5-93ddc8eb536a -> ../../md0
> lrwxrwxrwx 1 root root 10 2009-01-25 01:54 2ef862e1-cf78-4065-a205-d1784716d633 -> ../../sdd1
> lrwxrwxrwx 1 root root 10 2009-01-25 01:54 77ae4251-631f-4656-a365-c5723f5c5da8 -> ../../sdd2
> 
> p254:~# find /proc/|grep -i uuid
> /proc/sys/kernel/random/uuid
> p254:~# find /sys/|grep -i uuid 
> p254:~#

blkid:

[root@mythbox ~]# blkid /dev/sda?
/dev/sda1: LABEL="/movies" UUID="38da660b-3600-4508-a608-2e1a20041ecb"
TYPE="xfs"
/dev/sda2: LABEL="/video" UUID="7b5583ae-cd42-4db1-9868-d96a5ccd3fea"
TYPE="xfs"
/dev/sda3: LABEL="/boot" UUID="379dbe60-1988-47b9-9891-17038abcc1f0"
TYPE="ext3" SEC_TYPE="ext2"
/dev/sda5: LABEL="/" UUID="c7bd2307-e067-4185-a7a0-d8d54057f3b9" TYPE="xfs"
/dev/sda6: TYPE="swap" LABEL="SWAP-sda6"
UUID="ea3f5dae-2509-4764-a93e-b777e72fdfbd"

-Eric

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Bill Davidsen]

Justin Piszcz wrote:
> 
> 
> On Sun, 25 Jan 2009, Justin Piszcz wrote:
> 
>>
>>
>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>>
>>>
>>>
>>> On Sun, 25 Jan 2009, Alan Cox wrote:
>>>
>>>> Easiest is to use labels. Old ide will keep hda,b,c,d constant
>>>> providing you have interfaces using the legacy IDE port mappings (0x1f0
>>>> and 0x170). Libata doesn't do that as pretty much every distribution 
>>>> had
>>>> already switched to volume labels, and the user space can do the job 
>>>> far
>>>> better than the kernel - especially as the newer devices with modern
>>>> interfaces don't have the old BIOS/DOS legacy ideas any more.
>>>>
>>>> Mount by label also means you can flip back and forth between the
>>>> different drivers and kernel revisions.
>>>>
>>>> Alan
>>>>
>> It comes with one :)
>> # xfs_admin -u  /dev/sdd2
>> UUID = 77ae4251-631f-4656-a365-c5723f5c5da8
>>
>> Will try to use this to boot; however, I'd prefer the labels over the 
>> UUID, wish there was an easy way to set it.
>>
>> Justin.
>>
>> _______________________________________________
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
>>
> 
> One final question, without udev, how does one determine the UUID of a 
> non-XFS
> partition, e.g., swap?
> 
One uses blkid. Which suggests that you can solve your name problem by not using 
names and switching to UUID.


-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Justin Piszcz]

On Sun, 25 Jan 2009, Bill Davidsen wrote:

> Justin Piszcz wrote:
>> 
>> 
>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>> 
>>> 
>>> 
>>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>>> 
>>>> 
>>>> 
>>>> On Sun, 25 Jan 2009, Alan Cox wrote:
>>>> 
>>>>> Easiest is to use labels. Old ide will keep hda,b,c,d constant
>>>>> providing you have interfaces using the legacy IDE port mappings (0x1f0
>>>>> and 0x170). Libata doesn't do that as pretty much every distribution had
>>>>> already switched to volume labels, and the user space can do the job far
>>>>> better than the kernel - especially as the newer devices with modern
>>>>> interfaces don't have the old BIOS/DOS legacy ideas any more.
>>>>> 
>>>>> Mount by label also means you can flip back and forth between the
>>>>> different drivers and kernel revisions.
>>>>> 
>>>>> Alan
>>>>> 
>>> It comes with one :)
>>> # xfs_admin -u  /dev/sdd2
>>> UUID = 77ae4251-631f-4656-a365-c5723f5c5da8
>>> 
>>> Will try to use this to boot; however, I'd prefer the labels over the 
>>> UUID, wish there was an easy way to set it.
>>> 
>>> Justin.
>>> 
>>> _______________________________________________
>>> xfs mailing list
>>> xfs@oss.sgi.com
>>> http://oss.sgi.com/mailman/listinfo/xfs
>>> 
>> 
>> One final question, without udev, how does one determine the UUID of a 
>> non-XFS
>> partition, e.g., swap?
>> 
> One uses blkid. Which suggests that you can solve your name problem by not 
> using names and switching to UUID.

This will fix the /etc/fstab issue but not LILO/boot one, per the earlier 
poster, need an initrd/etc for that.

Justin.

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Bill Davidsen]

Justin Piszcz wrote:
> 
> 
> On Sun, 25 Jan 2009, Bill Davidsen wrote:
> 
>> Justin Piszcz wrote:
>>>
>>>
>>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>>>
>>>>
>>>>
>>>> On Sun, 25 Jan 2009, Justin Piszcz wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, 25 Jan 2009, Alan Cox wrote:
>>>>>
>>>>>> Easiest is to use labels. Old ide will keep hda,b,c,d constant
>>>>>> providing you have interfaces using the legacy IDE port mappings 
>>>>>> (0x1f0
>>>>>> and 0x170). Libata doesn't do that as pretty much every 
>>>>>> distribution had
>>>>>> already switched to volume labels, and the user space can do the 
>>>>>> job far
>>>>>> better than the kernel - especially as the newer devices with modern
>>>>>> interfaces don't have the old BIOS/DOS legacy ideas any more.
>>>>>>
>>>>>> Mount by label also means you can flip back and forth between the
>>>>>> different drivers and kernel revisions.
>>>>>>
>>>>>> Alan
>>>>>>
>>>> It comes with one :)
>>>> # xfs_admin -u  /dev/sdd2
>>>> UUID = 77ae4251-631f-4656-a365-c5723f5c5da8
>>>>
>>>> Will try to use this to boot; however, I'd prefer the labels over 
>>>> the UUID, wish there was an easy way to set it.
>>>>
>>>> Justin.
>>>>
>>>> _______________________________________________
>>>> xfs mailing list
>>>> xfs@oss.sgi.com
>>>> http://oss.sgi.com/mailman/listinfo/xfs
>>>>
>>>
>>> One final question, without udev, how does one determine the UUID of 
>>> a non-XFS
>>> partition, e.g., swap?
>>>
>> One uses blkid. Which suggests that you can solve your name problem by 
>> not using names and switching to UUID.
> 
> This will fix the /etc/fstab issue but not LILO/boot one, per the 
> earlier poster, need an initrd/etc for that.
> 
Good point, I have not used LILO since about Slackware 8.1, or any system w/o 
initrd in ages. I suppose there is a benefit to running without initrd, but I 
confess that I can't remember what it is. So I don't immediately consider the 
issues and limitations if you run without initrd.

Well I answered how to GET the UUID, he didn't ask me how to USE it. And I 
certainly didn't think of it, even though the info was there. :-(

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Lennart Sorensen]

On Sun, Jan 25, 2009 at 07:15:40AM -0500, Justin Piszcz wrote:
> It comes with one :)
> # xfs_admin -u  /dev/sdd2
> UUID = 77ae4251-631f-4656-a365-c5723f5c5da8
> 
> Will try to use this to boot; however, I'd prefer the labels over the 
> UUID, wish there was an easy way to set it.

I prefer UUIDs.

Much mroe likely to have the same label on multiple drives than the same
UUID.  I don't want to have to worry about what label some usb device
might have if I happen to have it plugged in during a reboot.

Labels do tend to be shorter and more human readable of though.

-- 
Len Sorensen

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Sergei Shtylyov]

Hello.

Lennart Sorensen wrote:

>> It comes with one :)
>> # xfs_admin -u  /dev/sdd2
>> UUID = 77ae4251-631f-4656-a365-c5723f5c5da8
>>
>> Will try to use this to boot; however, I'd prefer the labels over the 
>> UUID, wish there was an easy way to set it.
>>     
>
> I prefer UUIDs.
>
> Much mroe likely to have the same label on multiple drives than the same
> UUID.

   For example, CentOS 4.3 went crazy in such case, being unable to 
mount anything but root IIRC.

MBR, Sergei

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Mark Lord]

Alan Cox wrote:
..
> Mount by label also means you can flip back and forth between the
> different drivers and kernel revisions.
..

That only works with an initrd or initramfs,
not with kernel-only boots.  Real P.I.T.A. that is.

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Bartlomiej Zolnierkiewicz]

On Sunday 25 January 2009, Justin Piszcz wrote:
> When switching (removing IDE support) in favor of the new PATA support 
> under the SATA menu, is there any best practice/or method of knowing what 
> the new root hdd will be upon reboot?
> 
> Example:
> If I have 10 sata disks and 2 IDE disks on various cards/controllers, how 
> do I know /dev/hda will become /dev/sda?  In one test on a system I have 
> here, /dev/hda became /dev/sdb2 after reboot, not an issue if the box is 
> local, but if the box is remote, how do you cope with this?  I ask now 
> because some IDE drivers have been removed (nvidia I believe? in 2.6.28) 
> and I cannot upgrade the kernel anymore unless I move to the 
> PATA-supported SATA driver, but I have no idea what the root disk will be 
> after a reboot and there is a high probability it will not come back after 
> a reboot..

Hmmm?  That's news to me and I wonder where did you hear that?

The only driver that got removed recently was HPT34X (for very, very
old HPT controllers) which was broken for ages.  In reality we are
adding new IDE host drivers and not removing them.

In 2.6.28 we got support for TX4938 and TX4939 chipsets.  2.6.29-rc1
contains a new driver for IT8172 and 2.6.29-final will hopefully have
drivers for AT91 and CS5536 chipsets.  Moreover except CS5536 all of
above chipsets are not support in other ways under Linux...

While we are at it 2.6.29 also got a whole bunch of updates to the core
IDE code -- this includes complete rewrite of locking scheme (which
is now superior to some other solutions), latency improvements for IRQ
handling and port of ide-cd over generic ATAPI support (not to mention
whole stack of bugfixes and cleanups).

Thanks,
Bart

PS as usual I encourage people to try different solutions and choose
whatever works best for them (please also remember that giving feedback
is very important if you want to see some things improved).

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Justin Piszcz]

On Sun, 25 Jan 2009, Bartlomiej Zolnierkiewicz wrote:

> On Sunday 25 January 2009, Justin Piszcz wrote:
>> When switching (removing IDE support) in favor of the new PATA support
>> under the SATA menu, is there any best practice/or method of knowing what
>> the new root hdd will be upon reboot?
>>
>> Example:
>> If I have 10 sata disks and 2 IDE disks on various cards/controllers, how
>> do I know /dev/hda will become /dev/sda?  In one test on a system I have
>> here, /dev/hda became /dev/sdb2 after reboot, not an issue if the box is
>> local, but if the box is remote, how do you cope with this?  I ask now
>> because some IDE drivers have been removed (nvidia I believe? in 2.6.28)
>> and I cannot upgrade the kernel anymore unless I move to the
>> PATA-supported SATA driver, but I have no idea what the root disk will be
>> after a reboot and there is a high probability it will not come back after
>> a reboot..
>
> Hmmm?  That's news to me and I wonder where did you hear that?
>
> The only driver that got removed recently was HPT34X (for very, very
> old HPT controllers) which was broken for ages.  In reality we are
> adding new IDE host drivers and not removing them.
>
> In 2.6.28 we got support for TX4938 and TX4939 chipsets.  2.6.29-rc1
> contains a new driver for IT8172 and 2.6.29-final will hopefully have
> drivers for AT91 and CS5536 chipsets.  Moreover except CS5536 all of
> above chipsets are not support in other ways under Linux...
>
> While we are at it 2.6.29 also got a whole bunch of updates to the core
> IDE code -- this includes complete rewrite of locking scheme (which
> is now superior to some other solutions), latency improvements for IRQ
> handling and port of ide-cd over generic ATAPI support (not to mention
> whole stack of bugfixes and cleanups).
>
> Thanks,
> Bart
>
> PS as usual I encourage people to try different solutions and choose
> whatever works best for them (please also remember that giving feedback
> is very important if you want to see some things improved).
>

Correction, it was the HPT controller as you noted, broken? Was working 
for me in 2.6.26.3 :)

CONFIG_BLK_DEV_HPT34X=y
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_BLK_DEV_HPT366=y

Justin.

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Bartlomiej Zolnierkiewicz]

On Sunday 25 January 2009, Justin Piszcz wrote:
> 
> On Sun, 25 Jan 2009, Bartlomiej Zolnierkiewicz wrote:
> 
> > On Sunday 25 January 2009, Justin Piszcz wrote:
> >> When switching (removing IDE support) in favor of the new PATA support
> >> under the SATA menu, is there any best practice/or method of knowing what
> >> the new root hdd will be upon reboot?
> >>
> >> Example:
> >> If I have 10 sata disks and 2 IDE disks on various cards/controllers, how
> >> do I know /dev/hda will become /dev/sda?  In one test on a system I have
> >> here, /dev/hda became /dev/sdb2 after reboot, not an issue if the box is
> >> local, but if the box is remote, how do you cope with this?  I ask now
> >> because some IDE drivers have been removed (nvidia I believe? in 2.6.28)
> >> and I cannot upgrade the kernel anymore unless I move to the
> >> PATA-supported SATA driver, but I have no idea what the root disk will be
> >> after a reboot and there is a high probability it will not come back after
> >> a reboot..
> >
> > Hmmm?  That's news to me and I wonder where did you hear that?
> >
> > The only driver that got removed recently was HPT34X (for very, very
> > old HPT controllers) which was broken for ages.  In reality we are
> > adding new IDE host drivers and not removing them.
> >
> > In 2.6.28 we got support for TX4938 and TX4939 chipsets.  2.6.29-rc1
> > contains a new driver for IT8172 and 2.6.29-final will hopefully have
> > drivers for AT91 and CS5536 chipsets.  Moreover except CS5536 all of
> > above chipsets are not support in other ways under Linux...
> >
> > While we are at it 2.6.29 also got a whole bunch of updates to the core
> > IDE code -- this includes complete rewrite of locking scheme (which
> > is now superior to some other solutions), latency improvements for IRQ
> > handling and port of ide-cd over generic ATAPI support (not to mention
> > whole stack of bugfixes and cleanups).
> >
> > Thanks,
> > Bart
> >
> > PS as usual I encourage people to try different solutions and choose
> > whatever works best for them (please also remember that giving feedback
> > is very important if you want to see some things improved).
> >
> 
> Correction, it was the HPT controller as you noted, broken? Was working 
> for me in 2.6.26.3 :)
> 
> CONFIG_BLK_DEV_HPT34X=y
> # CONFIG_HPT34X_AUTODMA is not set
> CONFIG_BLK_DEV_HPT366=y

HPT34X driver got removed not HPT366.

However if you need we can bring support for HPT34x hardware back. :)

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Bill Davidsen]

Bartlomiej Zolnierkiewicz wrote:
> On Sunday 25 January 2009, Justin Piszcz wrote:
>> On Sun, 25 Jan 2009, Bartlomiej Zolnierkiewicz wrote:
>>
>>> On Sunday 25 January 2009, Justin Piszcz wrote:
>>>> When switching (removing IDE support) in favor of the new PATA support
>>>> under the SATA menu, is there any best practice/or method of knowing what
>>>> the new root hdd will be upon reboot?
>>>>
>>>> Example:
>>>> If I have 10 sata disks and 2 IDE disks on various cards/controllers, how
>>>> do I know /dev/hda will become /dev/sda?  In one test on a system I have
>>>> here, /dev/hda became /dev/sdb2 after reboot, not an issue if the box is
>>>> local, but if the box is remote, how do you cope with this?  I ask now
>>>> because some IDE drivers have been removed (nvidia I believe? in 2.6.28)
>>>> and I cannot upgrade the kernel anymore unless I move to the
>>>> PATA-supported SATA driver, but I have no idea what the root disk will be
>>>> after a reboot and there is a high probability it will not come back after
>>>> a reboot..
>>> Hmmm?  That's news to me and I wonder where did you hear that?
>>>
>>> The only driver that got removed recently was HPT34X (for very, very
>>> old HPT controllers) which was broken for ages.  In reality we are
>>> adding new IDE host drivers and not removing them.
>>>
>>> In 2.6.28 we got support for TX4938 and TX4939 chipsets.  2.6.29-rc1
>>> contains a new driver for IT8172 and 2.6.29-final will hopefully have
>>> drivers for AT91 and CS5536 chipsets.  Moreover except CS5536 all of
>>> above chipsets are not support in other ways under Linux...
>>>
>>> While we are at it 2.6.29 also got a whole bunch of updates to the core
>>> IDE code -- this includes complete rewrite of locking scheme (which
>>> is now superior to some other solutions), latency improvements for IRQ
>>> handling and port of ide-cd over generic ATAPI support (not to mention
>>> whole stack of bugfixes and cleanups).
>>>
>>> Thanks,
>>> Bart
>>>
>>> PS as usual I encourage people to try different solutions and choose
>>> whatever works best for them (please also remember that giving feedback
>>> is very important if you want to see some things improved).
>>>
>> Correction, it was the HPT controller as you noted, broken? Was working 
>> for me in 2.6.26.3 :)
>>
>> CONFIG_BLK_DEV_HPT34X=y
>> # CONFIG_HPT34X_AUTODMA is not set
>> CONFIG_BLK_DEV_HPT366=y
> 
> HPT34X driver got removed not HPT366.
> 
> However if you need we can bring support for HPT34x hardware back. :)

I don't think "bring it back" is enough, it had some major issues as I recall. I 
actually have a pile of these, but not running any recent kernel.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[david]

On Thu, 29 Jan 2009, Bill Davidsen wrote:

>>>> 
>>> Correction, it was the HPT controller as you noted, broken? Was working 
>>> for me in 2.6.26.3 :)
>>> 
>>> CONFIG_BLK_DEV_HPT34X=y
>>> # CONFIG_HPT34X_AUTODMA is not set
>>> CONFIG_BLK_DEV_HPT366=y
>> 
>> HPT34X driver got removed not HPT366.
>> 
>> However if you need we can bring support for HPT34x hardware back. :)
>
> I don't think "bring it back" is enough, it had some major issues as I 
> recall. I actually have a pile of these, but not running any recent kernel.
>

what was the problem with these? I have somthing in this family in one of 
my secondary boxes (I'd have to go check exactly which model)

David Lang

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Alan Cox]

> what was the problem with these? I have somthing in this family in one of 
> my secondary boxes (I'd have to go check exactly which model)

343/363 don't work unless you use the alternate access via the BAR4
register range and leave BAR0-3 alone. That means you can't use the
standard IDE setup helper logic with them.

366 and later (which is almost certainly what you will have) replace this
with a different collection of errata which are handled by both sets of
drivers.

Alan

Re: Switching from (deprecated) IDE driver -> SATA (PATA support)

[Alan Cox]

> > However if you need we can bring support for HPT34x hardware back. :)
> 
> I don't think "bring it back" is enough, it had some major issues as I recall. I 
> actually have a pile of these, but not running any recent kernel.

And me - I've spent some time trying to dig deeper into the DMA on the
HPT343 but there isn't any useful documentation and Andre didn't have any
immediate insights (other than a slightly less than printable review of
his opinion of the device)

In PIO its pretty solid, but for the original 343 at least DMA is still a
bit of a mystery that might not be solved without a bus analyser - for
one it completes DMA transfers but they don't seem to arrive in the
location specified in the PRD, even if you try obvious errata type things
like 64K alignment.

Unfortunately if the errata is something gross like flipping bits in PRD
addresses we aren't going to be able to figure it out.

Alan