Bug 101570 - drive nicknames; reversed LABEL=/ search path; automounting
Summary: drive nicknames; reversed LABEL=/ search path; automounting
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-04 03:45 UTC by Stig Hackvan
Modified: 2007-04-18 16:56 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-08-06 20:18:10 UTC
Embargoed:


Attachments (Terms of Use)

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).


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