[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#80325: Installer misreports partition numbers



Paul.Chr@t-online.de (Chris Paul) writes:

> it took me quite a few days to `find ..` your "flavours" in a path requiring 70 chars ... ;-)
> 
> There was no vanilla, but the test results of the rest looks really interesting. 

Vanilla is the same as "no flavor", that is, the images right in
images-1.44/*.bin (rather than images-1.44/compact/*.bin).

> > ... I need to know what "flavor" you were booting from...
> So sit down, ...;-)
> 
> <Long Story>
> Lets begin with my current layout:
> susa:~ # fdisk -l /dev/hda
>  
> Disk /dev/hda: 240 heads, 63 sectors, 3970 cylinders
> Units = cylinders of 15120 * 512 bytes
>  
>    Device Boot    Start       End    Blocks   Id  System
> /dev/hda1   *         1       258   1950448+   6  FAT16
> /dev/hda2           259       775   3908520   a5  BSD/386
> /dev/hda3           776       820    340200   4f  QNX4.x 3rd part
> /dev/hda4           821      3970  23814000    5  Extended
> /dev/hda5           821      1078   1950448+  83  Linux
> /dev/hda6   *      1079      1336   1950448+  eb  BeOS fs
> /dev/hda7          1337      1594   1950448+  83  Linux
> /dev/hda8          1595      2111   3908488+  83  Linux
> /dev/hda9          2112      3117   7605328+  83  Linux
> /dev/hda10         3118      3892   5858968+  83  Linux
> /dev/hda11         3893      3970    589648+  82  Linux
> swap                    
> 
> summary: 
> - 3 primary partitions a the beginning, with a BSD Unix containing slices at pos. 2, 
> - swap at disk/extended partition end (11)
> 
> So now my current OS:
> susa:~ # uname -a
> Linux susa 2.2.16 #1 Wed Aug 2 20:03:33 GMT 2000 i686
> unknown                   
> susa:~ # dmesg | grep hda:.hda1
> hda: hda1 hda2! hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 > <
> hda12 hda13 hda14 hda15 >
> - quite broken! It is a SuSE 7.0 "apm" kernel with default modules, unchanged, AFAIRemember...
> (It __should__ show: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8
> hda9 hda10 hda11 >)


I believe this is not actually broken, but, in fact, the SUSE-supplied
kernel must have been compiled to support BSD disklabels, and
therefore, it looks into the bsd disklabel in hda2 and interprets the
slices defined within as extended partitions.  I would assume, from
the output, you have 4 such slices, and those are probably put onto
hda5 -- hda8, or else hda12 -- hda15 (as you surmise below).

> My custom kernels dont show these "extra partitions" (2.4.0-test5
> and 2.2.12)

Probably because your custom kernel wasn't compiled with
CONFIG_BSD_DISKLABEL ?

> - And [c]fdisk, too.
> 
> Flavors:
> -----------
> 1) idepci:
> - "Show Part. Table (?)" from "Setup (?)" shows something like
> /dev/hda1   not mounted  (type ok)
>         2   not avail.   (type ok)
>         5   not avail.   (type ok)
>         6   not avail.   (type ok)
>         7   not avail.   (type ok)
>         8   not avail.   (type ok)
>         3   not avail.   unknown
>         4   not avail.   extended
>         9   not mounted  linux nat.
>         10  not avail.   unknown         <---(???)
>         11  not mounted  linux nat.
> 
> - dmesg: looks like it should (like hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 >)
> - BUT /var/log/messages: (something like...)
>   user.warn: dbootstrap: no dev. name f. disk /dev/hda part. 12 (skipped)
>   (and same entry for part. 13, 14, 15)

This is because dbootstrap uses libfdisk, which is compiled with BSD
disklabel support, but the kernel doesn't have bsd disklabel support.

> - fdisk: OK

fdisk and cfdisk, unlike dbootstrap/libfdisk, seem to use or not use
the kernel BSD disklabel support, depending on whether the kernel was
compiled to use them.

> 2) compact:
> Same like idepci; BUT: /var/log/messages only warnings for part. 12
> and 13...
> - fdisk: OK

Woah, that's wierd -- why would they be different I wonder.

> 3) udma66:
> - Very much and very fast scrolling-by errors "can't ...(open device???)" before inittial screen...
> - "Show Part. Table (?)" 
> - same like "idepci" (see above) PLUS
>         12  not mounted  
>         13  not mounted  
>         14  not mounted 
>         15  not in use   <- whatever it means...
> - dmesg:  hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 >
> - log/messages: nothing but syslog started...
> - fdisk: OK

Yes, this kernel has CONFIG_BSD_DISKLABEL.

Now, in the compact/idepci case, where we don't have hda12 - hda15, is
it the case that dbootstrap thinks you have hda12 - hda15?  I'm not
sure, but I think it does.

> Remarkable:
> 1) the order of the partitions 1-2-5-6-7-8-3-4-...
>    1 is fat, 2 BSD with slices, 3 unknown to linux (but was the same with ext2), 4 extended.
>    Some process

Well, the kernel.

> inserts the slices with numbers greater than the extended one at the
> places where they are found on disk, ads the real partition (3) and
> the following ...  This ordering keeps constant whether the kernel
> sees more partitions or not...

Are you saying the slices come up has hda5-8 ?

> 2) Part. 10: Why "not available"?
> 3) Part. 15: What could be meant with "not in use"? 

Dunno. It's all kernel stuff.  I have to keep my focus on this issue.

> 4) All that doesnt affect fdisk, mkfs, mount,swapon,... (but
> unfortunatly you might "not quite get what you want"...)

I would think these *would* be affected by the partitions as seen by
the kernel.... are you saying they are not?

> 5) My partitoning is ok: the "newer" lilo (e.g. found on debian)
> boots what it can boot - up to the high cylinders and the great GRUB
> boots them all...

> 6) All that disappeard when I temporarily changed my type-id of the
> BSD-Partition (Did you ever hear of "56  Golden Bow" ?)

No.

> Last but not least: Q.: Why dont you use some fdisk -l | sed | grep
> && awk for display AND mkfs?

Eh?  Are you asking why we have libfdisk at all?  Look at the
functions from libfdisk that are used by dbootstrap and you will see.

-- 
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>




Reply to: