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
Can you provide the exact text you get as well as where it occurs in the boot process?
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 fsck.ext3/dev/hda2 (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
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.
What does your /boot/grub/grub.conf look like?
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 fsck.ext3/dev/hda5: 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 well. 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) root(hd0,6) 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!
Does your resierfs partition also have a label of '/'?
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 fdisk)? 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.
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.)
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.
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 avoidance-of-duplicate-labels. I suspect this RFE will be in the 'accepting patches' stage, as opposed to being specifically scheduled.
*** Bug 154706 has been marked as a duplicate of this bug. ***