Bug#80325: Installer misreports partition numbers
"C. Paul" wrote:
> Hi, ...
> one moment - please.
Do you understand what i think the problem is, that libfdisk can see
that your hda2 contains 4 internal partitions, and lists then starting
at hda5, then your extended partitions from hda9 - hda15. Your kernel
doesnt understand that hda2 contains 4 internal partitions, so it just
lists your *extended partitions* not bsd partitions starting from hda5
> What I am trying to say is the following:
> One of the first screens presents me a selection for my swap partition.
> It supposes: /dev/hda15
> but: as there is no /dev/hda15, it fails... (and this was the last warning)
because libfdisk cas see 15 partitions, and swap is the last one, it
just assumes that the kernel can see as many partitions as it can, but
the kernel only sees 11 partitions.
> You select "partition hardisk" for inspection and get the view expected. (see that fdisk -l prev. posting)
But do you expect it to see 11 or 15 partitions, i would expect 15.
> You now want to install debian lets say onto the first logical ext2-partition: (thats /dev/hda5 as seen by fdisk)
Acording to the kernel hda5 is the first logical ext2 partitions, but
libfdisk is listing the 4 BSD slices partitions prior to your extended
partitions, so according to libfdisk your first logical ext2 partition
> from the "initialize a partition" you will select
> (Just recall)
> // begin second line of libfdisk# ./testing
> // /dev/hda1 (DOS 16-bit FAT >=32M), /dev/hda2 (BSD/386), /dev/hda5 (4.2BSD), /dev/hda6 (BSD swap), >/dev/hda7 (4.2BSD), /dev/hda8
> // (4.2BSD), /dev/hda3 (Unknown), /dev/hda4 (DOS Extended), /dev/hda9 (Linux
> // >native), /dev/hda10 (Unknown), /dev/hda11 (Linux native), /dev/hda12 (Linux native), /dev/hda13 (Linux
> // end second line libfdisk# ./testing
> ...-> /dev/hda9!
> (You _might_ assume:
> 1 FAT
> 1 BSD part.
> 4 BSD slices
> 1 Ext2
> 1 Extended
> ( first logical following now...)
> 8 -> ok -> Number 9 next, and this _is_ in _both_ cases/views an ext2 partition _and_ it exists.
> It then will be mounted on /target - I mean _that_ /dev/hda9, that mount mounts if you would supply it per hand.
> (I mean that device name seen by linux in general by would mkswap, will mkfs, and ... will mount, ...)
> I mean the _8G_ one and not the _2G_ one. So: you know which one I mean.
> And as it exists this will _not_ "fail" like the mkswap call. :-)
So you are saying that if you go to the command prompt and mount
/dev/hda5 then when you look at libfdisk it reports the drive you have
just mounted (hda5 acording to the kernel) is actually hda9. That is
consisttent with what i think the problem is
> Thats the point.
> And all this disappears if you change the BSD partition for installing to something like "Golden Bow", as mentioned more early.
Yes, this tricks libfdisk into not recogising that your BSD partition
has 4 sub partitions, so it doesnt have to shift your extended
partitions up by four to fit them in.
> BTW: I dont have any problem with that - really not. This is excellent but free-of-charge/volunteer software.
> I have never before submitted any bug reports but I think you should know that one.
> As I have read somewhere that this is more required than writing software. I did it as student, do it at work, ..
> Adam, Glenn, I will boot a kernel-image-2.2.18pre21 and do a 'cat /proc/partitions'.
> But if you know somebody having more time than me (working hard/married/...)
> If not: I wont give up. Will look at every source file required, author, year, ... _if_ and only _if_ you want me to and have time enough.
I think we are nearly there, im pretty sure that making sure all
different flavours of the kernel understand BSD partitions will fix the
problem, but for peace of mind i would like to see that the kernel does
put your bsd slices at hda5 - hda8 and not hda12 - hda15
> But please: lets first fix "description of the problem"...
> And: I did never submit any bug report before/dont know much about your netiquette... please help me, if you think, help is required.
Bug reports like your are really helpfull, because its hard to test for
I havent played with BSD slices much myself, but if you get too
frustrated with it i could try and track it down myself.