Bug 125939 - anaconda doesn't do preexisting label avoidance for reiserfs labels
anaconda doesn't do preexisting label avoidance for reiserfs labels
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Mike McLean
: FutureFeature
: 154706 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-06-14 08:41 EDT by Rory Gleeson
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-02 22:27:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rory Gleeson 2004-06-14 08:41:13 EDT
I'm having an odd problem which I can't track down via Fedora List or
through Bugzilla.

I have an AMD Athlon 3000 / K8V SE Deluxe motherboard.  I'm loading
the standard version of FC2, not the 64 bit, as I'm having a separate
problem loading it, which I won't discuss here.  

Basically, I can install FC2 on my second HD, hdb, without a problem.

I'm currently testing SuSE 9.1 on my  primary drive (hda) (hold the
tomatoes, I'm  just testing it, which is a good thing, as I'm learning
that Fedora is better!).  

First, I successfully load Fedora 2 on my second drive, hdb.  I put
the bootloader on hdb mbr, so I can change the bios and boot each OS
separately, as I don't want them interacting or being
mutually-dependent on a bootloader.

Problem is, every time Fedora is booting up, I get a "superblock"
error on hda2 (which is my main SuSE partition in reiserfs).  

I'm not sure why Fedora is referencing my hda drive on boot, given
that I switch my bios to boot from hdb, and the full Fedora OS and
bootloader are on hdb.  

I haven't seen this with any other distros.  I can reproduce this
100%, making it impossible to boot in to FC2 from my second drive.

Has anyone seen this or is it known?

Rory Gleeson
Toronto, Canada
Comment 1 Jeremy Katz 2004-06-14 12:16:19 EDT
Can you provide the exact text you get as well as where it occurs in
the boot process?
Comment 2 Rory Gleeson 2004-06-14 17:16:38 EDT
Here is where this issue occurs in the boot process and the exact text
(I just wrote all of this out by hand from the screen):

Welcome to Fedora Core
Press "I" to enter Interactive Set-up
(graphical Fedora screen appears for a moment and then reverts back to
this text)
Initializing USB Control  [Ok]
Mounting USB Filesystem   [Ok]
Checking Root Filesystem
(my note: again, hda2 is the main SuSE 9.1 reiserfs partition. FC2 is
loaded on hdb and the bootloader is on hdb mbr)

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap, ufs or something else), then the superblock
is corrupt, and you might trying running e2fsck with an alternate
superblock: e2fsck -b 8193 <device>

:Bad magic number in superblock while trying to open dev/hda2  [failed]

***An error occurred during the file system check.
***Dropping you to a shell; the system will reboot
***when you leave the shell
Give root password for maintenance
(or type Control-D to continue):


I re-installed SuSE 9.1 on hda three times (I can't load the FTP
version on hdb).  I've reinstalled FC2 a number of times, now, on hdb.
  I can still reproduce the above with consistency each time.  Still
can't figure out why FC2 wants to reference hda, in the first place,
which seems to be confusing it for something, from my newbie eyes.

Rory Gleeson
Toronto, Canada
Comment 3 Rory Gleeson 2004-06-21 21:53:01 EDT
Some more info on this bug.  I re-installed SuSE 9.1 (64 bit this
time) on hda.  This time, I changed the file format of the main hda
SuSE root partition from reiserfs to ext2.

When I reinstalled FC2 32bit on hdb, I could now boot in.  So, it
appears that there is some Fedora glitch that forces it to choke when
it see an reiserfs partition on another drive.
Comment 4 Bill Nottingham 2004-06-29 00:13:48 EDT
What does your /boot/grub/grub.conf look like?
Comment 5 Olivier Vanderstraeten 2005-03-23 14:59:43 EST
I am having the same issue and have been unable to resolve it.  My partitions
table appear in this order

hda1 -> mfg diagnostic partition
hda2 -> FAT32
hda4 -> EXTENDED
hda5 -> reiserfs (SuSE 9.2)
hda6 -> swap
hda7 -> ext3 (Fedora Core 3)

FC3 halts the boot process with:
Checking root filesystem

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap, ufs or something else), then the superblock
is corrupt, and you might trying running e2fsck with an alternate
superblock: e2fsck -b 8193 <device>

:Bad magic number in superblock while trying to open dev/hda5  [failed]

Initially I had no problem booting either Linux OSes.  The initial order install
was Windows, FC3 and then SuSE 9.2.  I used the SuSE installed GRUB and manually
added FC3.  I've since had to re-install FC3 and am now running into this issue.
 I did a complete FC3 re-install, including installing the FC3 grub bootloader
but to no avail.  I realize that this probably doesn't register on the
bugs-needing-fixing radar, but I figured I'd document the fact I ran into it as

The grub.conf information used to boot FC3 from either the SuSE installed
bootloader or the FC3 installed bootloader is the same and listed below:

title Fedora Core (2.6.9-1.667)
     kernel /boot/vmlinuz-2.6.9-1.667 ro root=LABEL=/
     initrd /boot/initrd-2.6.9-1.667.img

As I mentioned earlier, these exact 4 lines were added to the SuSE bootloader
after the initial install and FC3 booted w/o issues.

My /etc/fstab file makes no mention of any /dev/hda5 and a grep of /etc and
subdirs. for "hda5" returned nothing.

I did get the system to boot by commenting the section from FC3's
/etc/rc.d/rc.sysinit that deals with fsck.  Certainly not a good choice but it
proves that the error is not in the grub file.  I'm no expert but when I have
time I might try to pour through what I commented out and see what the issue
might be.  If you made it this far- thanks!
Comment 6 Bill Nottingham 2005-03-23 15:05:26 EST
Does your resierfs partition also have a label of '/'?
Comment 7 Olivier Vanderstraeten 2005-03-23 15:23:46 EST
Excuse my limited knowledge of things, but is your question in reference to the
grub.conf (menu.lst) file or to the actual label of the partition(maybe through

If it's in reference to the "root=LABEL=/" string then no, I do not think they
share the same label.  In fact, at this point in time the only linux section in
grub.conf is FC3's as I have not yet added SuSE back in as an option.  When I
was using the grub bootloader installed by SuSE the only "LABEL=" string
appeared in FC3's section.  I suppose that the absence of such a command in
SuSE's section may infer an implied label of '/' but I'm probably making things
more complicated than they are.

If you meant partition label then I'm not sure I know how to get you the info
you need.  fdisk -l returns no label information.

Sorry if this is not what you asked for at all.
Comment 8 Bill Nottingham 2005-03-23 15:36:33 EST
You can determine the label of a reiserfs partition by running:

debugreiserfs /dev/<whatever>

It should print out:

LABEL: <something>

(or just "LABEL:", if there's no label.)
Comment 9 Olivier Vanderstraeten 2005-03-23 16:03:32 EST
The labels were both '/'.  Changing the label fixed the problem.  For the
benefit of others (and myself 5 months down the road):  I used 'reiserfstune -l
suse /dev/hda5' to change the label from '/' to 'suse'.  On the FC3 side I then
uncommented all the fsck related portions of /etc/r.sysinit I had taken out and
rebooted to FC3 without a hitch.

Thanks for all your help.
Comment 10 Bill Nottingham 2005-03-23 16:21:04 EST
Assigning to anaconda as an RFE. What would need to happen here is that anaconda
would need to have code that reads labels for reiserfs, so it could do

I suspect this RFE will be in the 'accepting patches' stage, as opposed to being
specifically scheduled.
Comment 11 Chris Lumens 2005-04-18 15:28:20 EDT
*** Bug 154706 has been marked as a duplicate of this bug. ***

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