Bug 101570

Summary: drive nicknames; reversed LABEL=/ search path; automounting
Product: [Retired] Red Hat Linux Reporter: Stig Hackvan <stig-redhat-bugzilla>
Component: anacondaAssignee: Michael Fulbright <msf>
Status: CLOSED NOTABUG QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-08-06 20:18:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Stig Hackvan 2003-08-04 03:45:11 UTC
Description of problem:

1) I give all of my drives nicknames and then mount them according to those
nicknames.  this disambiguates LABEL=/ mount points and I *highly* recommend
that diskdruid just "get it" about prelabeled partitions...
  a. ask for a short drive nickname (or make one up)
  b. label partitions as "nick:/mountpoint"
  c. detect this pattern when doing future installs and have diskdruid do the
work of assigning partitions according to their labels.  for partitions that are
reformatted, retain the drive's nickname.

2) WHEN IDENTICAL LABELS ARE PRESENT: the kernel seems to push partition labels
onto a stack and then pop them off when searching.  this has the effect of
mounting the LAST drive to match (hdc) instead of the first drive to match (hda)
and this is the opposite of what the BIOS boot sequence does, so it's almost
always going to be the wrong thing to do.

3) OPTIONALLY, extra drives can be automatically mounted according to their
labels.  here's my little bit of shell hackery to do that...

## stig/uways (pts/0) -- 0 jobs -- Sun Aug 03 -- 20:40:10 ##
## /home/stig >>>> wh !!
wh hdprobe
hdprobe is a function
hdprobe ()
{
    hd=${1-hdc};
    shift;
    for dev in $(echo p |/sbin/fdisk /dev/$hd 2>/dev/null|grep ' 83 ' | sed -e
's/ .*//');
    do
        mpoint="$(tune2fs -l $dev |
              sed -n 's=.*volume name: *=/hc=p' |
              sed 's,/hc\([a-z0-9]*\):/*,/\1/,'    )";
        echo "fsck -a $dev ; mount $* $dev $mpoint";
    done | sort +6
}
## stig/uways (pts/0) -- 0 jobs -- Sun Aug 03 -- 20:40:14 ##
## /home/stig >>>> hdprobe
fsck -a /dev/hdc6 ; mount  /dev/hdc6 /ix/
fsck -a /dev/hdc8 ; mount  /dev/hdc8 /ix/home
## stig/uways (pts/0) -- 0 jobs -- Sun Aug 03 -- 20:40:20 ##
## /home/stig >>>> tune2fs -l /dev/hdc6 |grep olume
Filesystem volume name:   ix:/

-- stig

Comment 1 Jeremy Katz 2003-08-05 20:42:20 UTC
The behavior in the installer has changed somewhat so that we'll preserve
existing labels.  The rest of the stuff is either out of the purview of the
installer or not going to happen.  We can't handle every possible way that
someone may want to do something -- as soon as I add one pattern, there will be
50 other people with their own specific requests for how to do things which will
get out of hand quickly.

Comment 2 Stig Hackvan 2003-08-06 20:09:50 UTC
There *IS* a "problem" with the way that redhat does disk labels and/or the way
the kernel goes looking for them.  

Once upon a time, i could take a munged system disk from one box and repair it
by mounting it from a working system... (hda on old box, hdc on repair
box)...(or maybe i just like to move my disks around for kicks)...

Nowadays, with redhat labelling all the disks the same things, and mounting the
root partition according to label, I get the hosed disk showing up as the rootfs
on the it-worked-before repair system.

*THE SEARCH ORDER IS REVERSED*

(to repeat a portion of the original bug report):

2) WHEN IDENTICAL LABELS ARE PRESENT: the kernel seems to push partition labels
onto a stack and then pop them off when searching.  this has the effect of
mounting the LAST drive to match (hdc) instead of the first drive to match (hda)
and this is the opposite of what the BIOS boot sequence does, so it's almost
always going to be the wrong thing to do.

Comment 3 Jeremy Katz 2003-08-06 20:15:38 UTC
This is not at all an anaconda problem, though.  mount does the mounting (and
searching by label).