Re: Solaris/UFS partition/slice naming scheme

From: Andries.Brouwer@cwi.nl
Date: Tue Mar 28 2000 - 07:42:06 EST


On Tue, Mar 28, 2000 at 01:36:33PM +0200, Achim Flammenkamp wrote:

> I'm running Linux 2.2.12 Kernel (SuSE 6.2 distribution) on a PC (AMD-K6-III)
> having (among other SCSI discs containing a 2.2.13 system) a EIDE Maxtor disc.
...
> Yesterday night, I run Solaris-2.7 and created INSIDE the /dev/hda3 partition
> Solaris slices named s0,s1,...,s8 by the Solaris system.
> Later I tried to boot again the old Linux 2.2.12 system, The kernel was loaded
> and started (from the /dev/hda2 partition) and it displayed the disc structur as
> /dev/hda1, /dev/hda2, /dev/hda3 <Solaris slices named /dev/hda4, ...., /dev/hda12>,
> /dev/hda13, /dev/hda14 ,... /dev/hda22.
>
> So, the Kernel 2.2.12 renamed the old logical partitions and named the solaris
> slices inside the third partitions as if they were partitions, themselves!
> This has the effect that the old logical partitions seemed to be named-increased
> by 8 and because the kernel can't find his root file-system with his built-in
> name /dev/hda7 it panics.
> Well --- bad.

There are two issues here:

(i) Solaris, BSD, Unixware partitions (slices) were numbered in between
the DOS partitions. This caused shifts in naming when booting a kernel
with or without e.g. Unixware support.
In Linux 2.3.40 this was changed in such a way that (in case of a
DOS-type partition table) first the four primary partitions get
a number, next the logical partitions, and afterwards possible
Solaris, BSD, Unixware sub-partitions.
This makes the numbering a bit more stable.
[It also means that people using Solaris, BSD, or Unixware will see
a shift in numbering when upgrading to a post-2.3.40 kernel. Beware!]

(ii) Since things are numbered sequentially, when you add or remove
anything, all following partitions get a new number. That is unavoidable.
(However, it may be possible to mount by volume label and avoid
unpleasant effects.)

> Next I mounted with the SCSI system running Linux 2.2.13 the /dev/hda15 (the old
> /dev/hda7) root file system and renamed all entries in its /etc/fstab.
> Then I booted again the Linux 2.2.12 kernel with the parameter root=/dev/hda15
> and it booted and found its correct / filesystem, but it didn't find any
> other fs /dev/hda16, /dev/hda17, ... and because fsck can't got access of
> these devices, it went into interactive repair mode after prompting for the root-passwd.

I conjecture that you did not have any device nodes /dev/hda16 etc.
Use mknod to create them.

> I went into this maintenance mode and was stuck when looking into the /etc/mtab:
> only /proc /dev/fd and /dev/hda7 (NOT /dev/hda15) was listed!

Probably the disk was mounted read-only, so /etc/mtab did not reflect
the current situation. Maybe /proc/mounts would have told you.

> I think there is a serious naming bug inside the kernel about giving partition
> names. Furthermore, I would call it a design bug to call the slices in a
> partition like partitions (so it appears that the system can't distinguish
> them from real partitions --- at least it seems to me --- and this mixing-up
> happened).

In reality names are not used anywhere, a block device is specified by
a pair (major,minor). For stuff living on hda, major equals 3 and minor
takes values between 0 and 63, where 0 is the whole disk, and the rest
are partitions or slices or whatever you prefer to call them.
This numbering scheme does not really allow for a hierarchical structure
since 6 bits is not enough.

Andries

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



This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:21 EST