Bug 101570 - drive nicknames; reversed LABEL=/ search path; automounting
drive nicknames; reversed LABEL=/ search path; automounting
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Fulbright
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-03 23:45 EDT by Stig Hackvan
Modified: 2007-04-18 12:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-08-06 16:18:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stig Hackvan 2003-08-03 23:45:11 EDT
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 16:42:20 EDT
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 16:09:50 EDT
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 16:15:38 EDT
This is not at all an anaconda problem, though.  mount does the mounting (and
searching by label).

Note You need to log in before you can comment on or make changes to this bug.