Messages in this thread | | | Date | Tue, 28 Mar 2000 14:42:06 +0200 (MET DST) | From | Andries.Brouwer@cwi ... | Subject | Re: Solaris/UFS partition/slice naming scheme |
| |
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/
| |