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.
> 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
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.
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.
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
> [email protected]
> 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:~#
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
>> [email protected]
>> 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.
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.
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.
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
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
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.
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).
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
>> [email protected]
>> 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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
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.
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
>>> [email protected]
>>> 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.
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. :)
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
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
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
>>>> [email protected]
>>>> 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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
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
> > 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
> 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