Problem with random disks mount sequence

[wwp]

Hello Mikkel,


On Mon, 10 Dec 2007 13:00:15 -0600 "Mikkel L. Ellertson" <mikkel at infinity-ltd.com> wrote:

> wwp wrote:
> > Hello there,
> > 
> > 
> > running a Fedora 8.. since I don't know when, my root partition is
> > randomly mounted as /dev/sda3 or /dev/sdc3. This breaks the mount
> > possibilities from within Nautilus, as it seems to be a complete mess
> > w/ detected devices (or remembered?) devices.
> > 
> > It's a D810 laptop, w/ a SATA disk (usually sda, root sda3 and labelled
> > as '/' and swap as SWAP-sda4, sda1 and sda2 being NTFS). When I boot
> > the laptop w/ some USB disks connected (labelled storage3 and
> > storage4), I'll get random mount sequences. At the beginning the USB
> > disks were sdb and sdc and could be mounted w/o problem from Nautilus.
> > But I recently reboot and found that this has changed -> root is sdc3
> > and one of the external USB disks is now sda1.
> > / and swap partitions are in fstab, storage3 and storage4 aren't.
> > 
> > If that doesn't prevent the system from running fine, from within
> > Nautilus, I can't mount the external USB disk anymore, it seems that
> > nautilus remember that 'storage3' was 1st partition, but now it tries
> > to mount /dev/sda1, and fails w/: NTFS signature missing..
> > 
> > Any clues how I could get a fixed mounting sequence? Should I force a
> > specific device (/dev/sdc1) for the labelled partition 'storage3' for
> > instance (and how)? How can it be that the / partition doesn't get the
> > 1st /dev/sdX assignment?
> > 
> > 
> > Regards,
> > 
> > 
> SCSI drives are listed by order of discovery. (SATA drives are
> handled as SCSI drives.) You should not have USB drives discovered
> before your SATA drive. It almost sounds like you have the
> usb_storage module in your initrd file. You may also want to check
> /etc/modprobe.conf fo SCSI controller aliases.

I didn't change factory defaults for kernel config and params, modprobe
settings or initrd contents, it was working fine until I did some
reboots (it worked fine for several reboots, I can't tell if that came
from an upgrade or if it's a random behaviour, and I'm not rebooting
every day). If this problems shows here, it's potentially everyone
else's problem, if it's not BIOS or hardware dependent.


> I normally let HAL mount USB drives - it uses the label for the
> mount point off the /media directory. It is possible to write HAL
> rules that mount specific drives on specific mount points. It is
> also possile to write udev rules that will mount the USB drive based
> on the partition label, just like your root directory is mounted.
> (You need to use the noauto option, so the system does not try to
> mount them on boot.)
> 
> This should give you a couple of ways to try and solve the problem,
> or at least give someone else an idea on more troubleshooting.

Yeah, thanks for the tips. The easy (temporary) workaround I found for
my next reboot was to have the USB disks unplugged before GDM shows up
(one plug to get off, they're connected to a USB concentrator). I
wonder if disabling booting USB devices in the BIOS could help.

I'm a bit amazed in fact, and I say this w/o any irony, really. After so
many years where I could see that the way external devices and fs are
mounted (that started w/ manual fstab handling, then hotplug, udev,
hal, mixing with autofs and gnome mount mechanisms (correct me if I
forget one), it's like we'll never get an auto-mounting mechanism that
is reliable from a Desktop PoV. Maybe it's simply not possible because
software can't guess human expectations, but then, maybe a wizard
should ask what to do when new device IDs get plugged in (remember it
and automount it next time, etc.). Waiting for a smart mount robot, I
think I'll look into the the HAL rules direction!


Regards,

-- 
wwp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20071211/785d529f/attachment-0001.sig>