[nSLUG] Device enumeration flip flop
George N. White III
gnwiii at gmail.com
Wed Mar 19 15:52:24 ADT 2008
Sounds all too familiar. I just went thru similar nonsense from F8, which
let me configure partitions and then said there wasn't enough space on
/boot (which I generously set to 120G but RH considered less than the
minimum of 60G -- probably confused by encountering a 500G drive on
old hardware). I used grub from the rescue disk to install /boot on
another partition, but after upgrading RH tried boot the partition that it
had previously rejected, so back to the rescue disk.
The good news it that it has now accepted the other
partition thru several updates. I think the initial attempt had partly
installed to the original partition. It may be that RH updater stores
some disk layout information, or maybe it tries to generate the
information from information on the disk. Self-healing seems
like a good idea, but can get in the way when you want to change
Most of my problems with grub have come from mistakes in
grub's notation for identifying partitions. It is helpful to check
using grub's "find" to make sure files can be found. I is all
to easy to miss some "(n,m)" sprinkled around in menu.lst.
Booting from knoppix so you can print and carefull inspect
key files for typos/unexpected changes can be helpful.
These days it may be most cost effective to just by a new
disk and install the system. You end up with a disk that
should last a few years and has ample free space and
probably better performance. Also, you know how long
it will take, whereas debugging can be open ended.
On Wed, Mar 19, 2008 at 3:24 PM, D G Teed <donald.teed at gmail.com> wrote:
> There is an Intel system I have which apparently has a bad motherboard
> and there is no spare on hand, but there is a mostly similar server
> spare which can take it's system disk. We added a scsi card
> to the spare so it can resume the service run from an external array.
> It boots from SATA disks.
> As the spare system booted from the original system disk,
> we could only get this seemingly classic error:
> mount: count not find filesystem '/dev/root'
> setuproot: moving /dev failed: No such file or directory
> setuproot: error mounting /proc: No such file or directory
> setuproot: error mounting /sys: No such file or directory
> switchroot: mount failed: No such file or directory
> Kernel panic - not syncing: Attempted to kill init!
> The disk was from a degraded Linux MD raid 1, but it
> had booted fine before on the original system. The partition
> for / was changed into ext3, and no change. It seems to be
> somehow related to not getting what it needs from initrd (standard
> issue from Redhat, mentioned in menu.1st), but
> I don't know.
> From a rescue cdrom boot, it was clear the device
> enumeration order had changed, and now sda to sdf
> was the external array. I figured e2label could address
> that, but no luck - same error.
> RH was installed on a fresh disk on a SATA drive /dev/sdf
> It was not able to boot - no grub error.
> Finally I decided to put the MBR on the first disk of the SCSI
> array, to restore the service the server provides.
> Using a RH rescue CD, I've put MBR on SCSI disk 1 (sda),
> telling it that root is on hd5,0 (sdf1) - first SATA.
> Installing grub on SCSI's first disk brought me the grub screen
> but it wouldn't boot until I edited within the grub boot screen
> and told it to use root(hd0,0)
> When the fresh OS install booted, I want to try my original system
> disk on sdg1, but now I found this was a device on SCSI.
> Huh? Somewhere along the way, what was known as /dev/sdf
> from the rescue cdrom (same as installer) had turned
> into /dev/sda, and /dev/sdg was now /dev/sdb.
> Did I trigger this flip/flop with the use of the "device" line
> in grub shell?
> This presents confusion, because I don't know what disk enumeration
> to use at what point in fixing our grub set up. Labels do not
> apply to grub root statements. If I could better control the
> enumeration order it would be great, but the CMOS doesn't
> seem to support it, except possibly under a very complicated
> feature called the "EMI shell".
> So far, I was able to boot the fresh install once, but attempts to
> do the same for the original OS disk have failed - with what
> I believe are device enumeration issues.
> Has anyone run into this kind of a challenge before, and it so,
> what did you do to tame the beast?
> nSLUG mailing list
> nSLUG at nslug.ns.ca
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the nSLUG