A but that allows you to build a Linux 2.2.1 kernel that will not boot.

Reg Clemens (reg@dwf.com)
Fri, 5 Feb 1999 03:14:56 -0700 (MST)


I believe that this bug has existed for some time (say 2.0.36), and is
not new to 2.2.1

---
For reference, here is the output from ver_linux

[reg@orion]$ sh ver_linux -- Versions installed: (if some fields are empty or looks -- unusual then possibly you have very old versions) Linux orion.dwf.com 2.2.1 #24 Thu Feb 4 23:13:50 MST 1999 i686 unknown Kernel modules found Gnu C 2.7.2.3 Binutils 2.9.1.0.15 Linux C Library 2.0.7 Dynamic linker ldd (GNU libc) 2.0.7 Linux C++ Library 2.8.0 Procps 1.2.9 Mount 2.8a Net-tools (1999-01-01) Kbd 0.96 Sh-utils 1.16

---

PROBLEM: If one sets the "Solaris (x86) partition table support" option from the partion sub-menue in xconfig (which sets the define CONFIG_SOLARIS_X86_PARTITION) then one ends up with a kernel that will not boot without significant fiddling.

---

For reference, here is how hda is partitioned

hda1 Win98 hda2 FreeBSD hda3 Solaris hda4 Extended hda5 (unused) hda6 Linux hda7 Linux swap

---

During a `normal' boot I see the messages

... Partition Check: hda: hda1 hda2! hda3 hda4 < hda5 hda6 hda7 > < hda8 hda9 hda10 hda11 > hdc: [PTBL] [778/255/63] hdc3 VFS: Mounted root (ext2 filesystem) readonly. ...

Right off I have two questions: (a) what does the `!' on hda2 imply? (b) where do the bogus partitions hda8 - 11 come from?

---

If I invoke the Solaris options above, then at the same point in the boot I see

... Partition Check: hda: hda1 hda2! hda3 <Solaris: [s0] hda5 [s1] hda6 [s2] hda7 [s3] hda8 [s4] hda9 [s6] hda10 [s7] hda10 > hda4 < hda12 hda13 hda14 > < hda15 hda16 hda17 hda18 > hdc: [PTBL] [778/255/63] hdc3 Kernel panic: VFS: Unable to mount root fs on 03:06

So now it is showing me my SOLARIS (sub)partitions. So a question (c) Why does it show my SOLARIS partions and not my FreeBSD partitions? Yes I have BSD Disklabel support turned on. (d) note that there are now bogus partitions hda15-18.

---

So the problem above IS that the kernel gets built expecting to find the root file system in 03:06 (see the above panic) viz /dev/hda6 but its in fact in /dev/hda13 under the new numbering plan.

If I CHANGE /etc/lilo.conf to contain `root=/dev/hda13' to override the incorrect info in the kernel, I get a few lines further in the boot. If I then ALSO change /etc/fstab to point to /dev/hda13 (rather than /dev/hda6) and /dev/hda14 (rather than /hda7) for swap, then I can in fact boot the kernel.

At that point I CAN mount /dev/hda5 and get to my SOLARIS root file system.

---

I dont think that I should have to build 10-20 kernels playing havsies to find the offending option, and I surly shouldnt have to play with the `root=/dev/hda13' stuff to make up for the kernel being built pointing to the wrong place.

Ditto the changes to /etc/fstab.

---

Im not sure WHAT the boot is running to give the above listing of partitions, but running /sbin/fdisk from Linux with the above root/fstab changes still shows the old partition numbering scheme...

---

So Im not sure WHAT the fix should be here, but it should be made more consistant, one cant just point the kernel at the right place (03:13) since the /etc/fstab also needs to be modified. One (minimally) needs to LABEL the additional partitions differently so that they will have a consistant name whether the subpartitions are expanded or not. This latter solution would seemto be fairly simple.

Reg.Clemens reg@dwf.com

[ I can supply other informtion, including the .config file in use, but I dont think its relevant ]

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/