Bug 753239

Summary: Mount point of second hard drive changes after shutdown followed by restart.
Product: [Fedora] Fedora Reporter: Greta Watson <greta_watson>
Component: udevAssignee: udev-maint
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: harald, jonathan, ovasik, udev-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-12 08:25:59 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Greta Watson 2011-11-11 12:08:19 EST
When I upgraded from Fedora 14 to Fedora 15, the following problem started happening randomly.

After a shutdown and subsequent boot up, my second hard drive could no longer be mounted using "mount /mnt/disk2" and the entry in /etc/fstab:
    /dev/sdb1               /mnt/disk2              ext3    noauto,user     0 0
/etc/fstab had to be changed to use sdf1 instead of sdb1.

A few shutdowns and reboots later, it was back to sdb1.  Now it's back to sdf1.

This makes usage of /etc/fstab rather pointless, as I have to look to see where the hard drive is and modify /etc/fstab before mounting it.  As I have a cron job that runs once a week, it sometimes fails to mount the disk, and thus my backup fails for that week.

This seems to be related to the naming convention change for such items as eth0 and wlan0.  Those changes are annoying, but at least they don't cause jobs to fail.  Until this is fixed, I suppose I will have to remove my entry in /etc/fstab and write a script to do the mount based on where the disk can be found that day.

I'm not sure whether this problem surfaces after a reboot (rather than shutdown and subsequent restart).

Version-Release number of selected component (if applicable):  Fedora 15

How reproducible:  first disk is ext4.  second disk is ext3.  shutdown, wait a while, and then restart, repeatedly until second disk changes mount point.  

Steps to Reproduce:
1.  shutdown, wait a few minutes, and then restart.
2.  check to see what the current designation for the second hard drive is.
3.  repeat steps 1 and 2 until problem occurs.
Actual results:  Second hard drive sometimes changes device node.

Expected results:  Second hard drive should maintain its same node across reboots of the system, so that /etc/fstab and mount commands are consistent.

Additional info:
Comment 1 Ondrej Vasik 2011-11-11 13:51:41 EST
1) Thanks for filing bugzilla report
2) Component is wrong, as filesystem is component which owns and creates basic system directories and has nothing to do with filesystems on your harddrive
3) You could use disk UUID in /etc/fstab if you need the consistency anyway (workaround)

From your report it is hard to say where the real issue is, it could be either hw issue, udev, kernel issue or even something else.

Let's try udev, but be prepared that Harald will probably need more information. (sorry Harald if udev is wrong component for that :) )
Comment 2 Kay Sievers 2011-11-12 08:25:59 EST
Please always use predictable names like UUID=, LABEL=, /dev/disk/by-*/* in
fstab, never the kernel device name.

There is no, and never was a guarantee that the discovery order of devices
in the kernel produces the same names across reboots.

You can just plug in a USB storage device and all the names change. That's
not a bug, it's the expected behaviour.
Comment 3 Greta Watson 2011-11-12 10:49:29 EST
My problem occurs with an internal second drive, not USB.  I thought that internal drives were supposed to stay constant.
Comment 4 Kay Sievers 2011-11-13 07:23:22 EST
Sometimes, when external devices are connected they mix up all
device names, because they are found before the internal ones.

If devices are connected to different buses ATA host adapter,
SCSI host adapter, USB, Firewire, they all have no predictable
probing order, it all depends which bus driver is the first one
that gets initialized during bootup, and all run in parallel.

Nothing guarantees any order here, the kernel device names can
not be used to identify a device across reboots, that's why the
default installation uses UUID= in fstab for many years.