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.
In article <199902051014.DAA12006@clemens.dwf.com> you write:
> I believe that this bug has existed for some time (say 2.0.36), and is
> not new to 2.2.1

It is not really a bug, rather a controversed feature. see below.

> Partition Check:
> hda: hda1 hda2! hda3 hda4 < hda5 hda6 hda7 > < hda8 hda9 hda10 hda11 >
[...]
> Right off I have two questions:
> (a) what does the `!' on hda2 imply?
> (b) where do the bogus partitions hda8 - 11 come from?

The '!' means that hda2 is a BSD-labeled partitions, which means that
is contains an A5 or A6 disklabel, and sub-slices. The four such slices
are put at the end of the partition list, that is hda8-hda11 (your
"bogus" partitions are not bogus at all).

This is the same effect than with Solaris:

> 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 >

To be more consistent, the BSD partitions should be labeled this
way: <BSD: [s0] hda15 [s1] hda16 [s2] hda17 [s3] hda18 >

But this is cosmetic.

> (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 hda15-18 partitions are not bogus. They ARE the FreeBSD
partitions. The reason why they are rejected at the end of the list is
a bit tricky; I know the patch author (the patch handling A6 [OpenBSD]
disklabels), so I could ask him (but he will probably answer by himself
on the list).

> 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.

The whole problem is related to the "dynamic numbering" scheme:
partition numbers are attributed "on the fly" and therefore, changes in
the kernel and/or the configuration may change this attribution. Another
way of doing this: you have two scsi adapter, one old Adaptec and a
newer Tekram. When the Adaptec adapter is compiled as a module, the sda
disk is the first one on the Tekram. But, if you compile the Adaptec
driver in the kernel, not as module, it will be detected first and sda
will become the first scsi disk on the Adaptec.

The "root filesystem adjustment" made during the compilation is a hack,
and should not be relied on.

Some unixes (such as Solaris) do not have this problem since they use
a fixed-but-complicated device naming (/dev/rdsk/c0t2d0s1...). If you
really want such a thing, you should try devfs (the patch from Richard
Gooch). It is not yet in the official kernel, but I believe it does such
things, and more (but I have not tried it).

To sum up: there is no real bug; you discovered that you cannot really
and automagically upgrade a kernel. You really need a sysadmin for some
tasks. Same applies to any OS, however: try to swap two disks in a
windows box, and see what happens to your apps when D: becomes E: and E:
becomes D:.

--Thomas Pornin

-
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:0.034 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site