[This message has also been posted to linux.debian.user.]

I've revved four machines from Sarge to Etch now,
following the release notes and letting it replace
devfs with udev. All worked fine.

The fifth machine was a mess. It's got two
PATA drives, on the first PATA channel on a
motherboard with two unused SATA sockets.
There is also a disk controller with two
PATA channels, unused, in a PCI slot.

Under my static device directory:
/dev/hda my Debian workstation
/dev/hdb archive drive
/dev/hdc DVD player
/dev/hdd CD writer
/dev/hd[e-h] test drives that come and go
/dev/sd[ab] SATA drives

When I boot linux-image-2.6.18-4-686, it sees
/dev/hde my Debian workstation
/dev/hdf archive drive
/dev/hdg DVD player
/dev/hdh CD writer
and panics, no /sbin/init found. Apparently
udev thinks the SATA drives aren't SCSI, and counts
the addin card first. So I changed
the partition names in /etc/fstab to match.

Now the boot stops shortly after listing the
partitions and NIC

ata2: SATA max UDMA/133 cmd 0x...
scsi0: ata_piix
hde: ... (the 160 GB drive)
hdf: ... (the 60 GB drive)
hdg: ... (the 48x DVD)
hdh: ... (the 52x CD)
eth0: RealTek RT8139...

Begin: Mounting root file system
Begin: Running /scripts/loca-top
device-mapper initialized
Done.
Begin: Waiting for root file system...
(here it hangs for about a minute)
Done.
Check root= bootarg cat /proc/cmdline
or missing modules, devices: cat /proc/modules ls /dev
Alert! /dev/hda1 does not exist. Dropping to a shell!


Busybox...
/bin/sh: can't access tty: job control turned off.
(initramfs)


This happens with either version of the fstab. Changing
the root device on the kernel command line has no effect.
(Apparently root=/dev/hde doesn't survive initramfs, where
root is /dev/ramdisk or something.)
So I went back to my old kernel. But I'm going to have
to get udev working eventually. I've read the udev manpage
and the three unofficial howtos.
Apparently I'm going to have to dig the serial numbers
or some other unique identifier out of each drive
and figure out how to write rules to force udev to
name the drives the way they have been since 1991.

If this had happened with a paying customer I would have
been in real trouble.
Has anyone else seen this problem? Is it the reason
there's been so much resistance to udev?
How did you nail down your device names?


Cameron



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Apr 11, 2007 at 10:26:54PM -0700, cls@truffula.sj.ca.us wrote:
> [This message has also been posted to linux.debian.user.]
>
> I've revved four machines from Sarge to Etch now,
> following the release notes and letting it replace
> devfs with udev. All worked fine.
>
> The fifth machine was a mess. It's got two
> PATA drives, on the first PATA channel on a
> motherboard with two unused SATA sockets.
> There is also a disk controller with two
> PATA channels, unused, in a PCI slot.
>
If you're not using the extra disk controller, take it out
of the PCI slot. I had precisely this problem with a
Promise card whereby you could install onto the drives on
the motherboard controller but thereafter on reboot the
BIOS wouldn't see them because the PCI controller took priority.


AndyC


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Apr 12, 2007 at 07:03:43AM +0000, Andrew M.A. Cater wrote:
> On Wed, Apr 11, 2007 at 10:26:54PM -0700, cls@truffula.sj.ca.us wrote:
> > [This message has also been posted to linux.debian.user.]
> >
> > I've revved four machines from Sarge to Etch now,
> > following the release notes and letting it replace
> > devfs with udev. All worked fine.
> >
> > The fifth machine was a mess. It's got two
> > PATA drives, on the first PATA channel on a
> > motherboard with two unused SATA sockets.
> > There is also a disk controller with two
> > PATA channels, unused, in a PCI slot.
> >
> If you're not using the extra disk controller, take it out
> of the PCI slot. I had precisely this problem with a
> Promise card whereby you could install onto the drives on
> the motherboard controller but thereafter on reboot the
> BIOS wouldn't see them because the PCI controller took priority.
>
one way to get consident device names for udev is to use one of the
unique identifiers in menu.lst and fstab.
this is in my menu.lst
---------------------------------------------------------------------------------------------------------------------
kernel /boot/vmlinuz-2.6.20-14-386 root=UUID=be3621bb-9392-4f4a-83f6-e7f9fa05d430 ro quiet splash vga=791
---------------------------------------------------------------------------------------------------------------------
this is in my fstab
---------------------------------------------------------------------------------------------------------------------
UUID=be3621bb-9392-4f4a-83f6-e7f9fa05d430 / ext2 defaults,errors=remount-ro 0 1
---------------------------------------------------------------------------------------------------------------------
the easiest way to get the UUID is to use live cd with udev and
ls -l /dev/disk/by-uuid/
-Kev
--
| .''`. == Debian GNU/Linux == | my web site: |
| : :' : The Universal |mysite.verizon.net/kevin.mark/|
| `. `' Operating System | go to counter.li.org and |
| `- http://www.debian.org/ | be counted! #238656 |
| my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to Debian! |
|_______ Unless I ask to be CCd, assume I am subscribed _______|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGHhZfv8UcC1qRZVMRApFBAJ4zOhd+v+wxIfoc/OSmnqu90YGlfgCdFb+y
C9xMzifza5jtvojDVS2N3fU=
=ThGG
-----END PGP SIGNATURE-----

On Wed, Apr 11, 2007 at 10:26:54PM -0700, cls@truffula.sj.ca.us wrote:
> [This message has also been posted to linux.debian.user.]
>
> I've revved four machines from Sarge to Etch now,
> following the release notes and letting it replace
> devfs with udev. All worked fine.
>
> The fifth machine was a mess. It's got two
> PATA drives, on the first PATA channel on a
> motherboard with two unused SATA sockets.
> There is also a disk controller with two
> PATA channels, unused, in a PCI slot.
>
> Under my static device directory:
> /dev/hda my Debian workstation
> /dev/hdb archive drive
> /dev/hdc DVD player
> /dev/hdd CD writer
> /dev/hd[e-h] test drives that come and go
> /dev/sd[ab] SATA drives
>
> When I boot linux-image-2.6.18-4-686, it sees
> /dev/hde my Debian workstation
> /dev/hdf archive drive
> /dev/hdg DVD player
> /dev/hdh CD writer
> and panics, no /sbin/init found. Apparently
> udev thinks the SATA drives aren't SCSI, and counts
> the addin card first. So I changed
> the partition names in /etc/fstab to match.
>
> Now the boot stops shortly after listing the
> partitions and NIC
>
> ata2: SATA max UDMA/133 cmd 0x...
> scsi0: ata_piix
> hde: ... (the 160 GB drive)
> hdf: ... (the 60 GB drive)
> hdg: ... (the 48x DVD)
> hdh: ... (the 52x CD)
> eth0: RealTek RT8139...
>
> Begin: Mounting root file system
> Begin: Running /scripts/loca-top
> device-mapper initialized
> Done.
> Begin: Waiting for root file system...
> (here it hangs for about a minute)
> Done.
> Check root= bootarg cat /proc/cmdline
> or missing modules, devices: cat /proc/modules ls /dev
> Alert! /dev/hda1 does not exist. Dropping to a shell!
>
>
> Busybox...
> /bin/sh: can't access tty: job control turned off.
> (initramfs)
>
>
> This happens with either version of the fstab. Changing
> the root device on the kernel command line has no effect.
> (Apparently root=/dev/hde doesn't survive initramfs, where
> root is /dev/ramdisk or something.)
> So I went back to my old kernel. But I'm going to have
> to get udev working eventually. I've read the udev manpage
> and the three unofficial howtos.
> Apparently I'm going to have to dig the serial numbers
> or some other unique identifier out of each drive
> and figure out how to write rules to force udev to
> name the drives the way they have been since 1991.
>
> If this had happened with a paying customer I would have
> been in real trouble.
> Has anyone else seen this problem? Is it the reason
> there's been so much resistance to udev?
> How did you nail down your device names?

For /etc/fstab, instead of using /dev/* you can use LABEL= and give
filesystem volume labels.

However, your problem is the kernel finding root, which happens before
udev starts. This would be set in the initramfs, so look there.

How _I_ solve this is that my root is on LVM on raid1. The kernel
assembes the raid arrays by searching all disks for raid configuration,
then my root is on /dev/mapper/system-root (system being the volume
group, root being the logical volume).

I wonder if you used lvm for your root partition without raid, would it
work?

Good luck.

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org