lkml.org 
[lkml]   [1999]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectA but that allows you to build a Linux 2.2.1 kernel that will not boot.

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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:2.828 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site