You are not logged in.

#1 2006-12-05 19:55:32

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Kernel 2.6.19: Max 15 partitions on SCSI device

This is quick warning for those of you with Intel chipsets, kernel 2.6.19 and a passion for partitioning.

I have 16 partitions on my IDE hard disk which the kernel now wants to pretend is SATA and because it wants to pretend it is SATA it won't recognize the final partition.  There may be a workaround which I have not yet discovered but I figured it was worth flagging up.

Offline

#2 2006-12-05 20:21:12

brain0
Developer
From: Aachen - Germany
Registered: 2005-01-03
Posts: 1,382

Re: Kernel 2.6.19: Max 15 partitions on SCSI device

There is a way around: Just force your system to load "piix" first (for example by explicitly specifying it in mkinitcpio.conf), your drive will then use the old driver/subsystem again.

Offline

#3 2006-12-05 20:55:56

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: Kernel 2.6.19: Max 15 partitions on SCSI device

Should that not be in the wiki/news items?  Is there a little mis-information bee propagated around the upstream changes?

Offline

#4 2006-12-05 21:13:21

brain0
Developer
From: Aachen - Germany
Registered: 2005-01-03
Posts: 1,382

Re: Kernel 2.6.19: Max 15 partitions on SCSI device

There is. It seems nobody understands the issue properly.

Offline

#5 2006-12-05 21:31:49

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: Kernel 2.6.19: Max 15 partitions on SCSI device

Except you.  Wouldn't it be prudent to update your colleagues then, rather than them sending us all off down the garden path with unnecessary device name changes etc?

Offline

#6 2006-12-05 21:55:08

brain0
Developer
From: Aachen - Germany
Registered: 2005-01-03
Posts: 1,382

Re: Kernel 2.6.19: Max 15 partitions on SCSI device

I thought I wrote a complete statement somewhere on the forums. But I just discovered I wrote it only on the arch development mailing list:

I wrote:

Let me first say this: The general case is that everything works as it is. All devices will still have the same names. Nothing will change unless you explicitly switch to the new drivers. There is only one very unfriendly driver: piix.

piix is a driver for Intel IDE chipsets, I had more than one such computer. ata_piix was known as an SATA driver for Intel chipsets.

Now, kernel devs merged all piix (ide) devices into the ata_piix driver, which thus has become a mixed sata/ide driver. And that is where the trouble starts: We have to include the driver into initramfs images for either sata or pata. Now there are 3 possible scenarios:

1) You have only ide devices an image with only ide drivers. Nothing will change, you will be fine.
2) You have only ide devices and your image has the default configuration, meaning ide and sata are included. In that case, both the piix and ata_piix drivers are included in the image. Unfortunately, udev loads the ata_piix driver first, thus your hda devices become sda. This is also easily solved by appending "disablemodules=ata_piix" to your
kernel commandline and then disabling "sata" in your initramfs.
3) This is the most serious case: you have both sata and ide devices that now work with the ata_piix driver. That means ata_piix will be loaded, your hda becomes sda and your sda becomes something like sdc. But even this can be solved by forcing to load the piix driver before the ata_piix driver, so that your devices are still sda.

I knew that this would happen (and that it would only happen with the piix/ata_piix devices), so you can blame me. You can also blame the kernel developers for not splitting pata and sata into two separate drivers in this case.

I have been encouraging people to switch to label or uuid-based block device naming for some time now. In the last few weeks, I have switched naming schemes on a daily basis without ever having to change grub or fstab. Users won't even notice some changes, even if the naming scheme changes with every update.

One comment on that though, simply saying "disablemodules=ata_piix" won't boot, you'd have to manually load piix from the "break=y" shell to make it boot. I was also thinking about a failsafe tool that would ask you which modules (not) to load, but it only exists in my fantasy right now.

Offline

#7 2006-12-05 23:45:14

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: Kernel 2.6.19: Max 15 partitions on SCSI device

Nice work smile

Offline

#8 2007-01-29 21:13:59

foxbunny
Member
From: Serbia
Registered: 2006-10-31
Posts: 759
Website

Re: Kernel 2.6.19: Max 15 partitions on SCSI device

brain0 wrote:

2) You have only ide devices and your image has the default configuration, meaning ide and sata are included. In that case, both the piix and ata_piix drivers are included in the image. Unfortunately, udev loads the ata_piix driver first, thus your hda devices become sda. This is also easily solved by appending "disablemodules=ata_piix" to your....

Now with 0.8 voodoo beta1 installed from the CD, I see what this means. But the systems works just fine with the sdX naming scheme, so should I even worry about changing it back to hdX?

Offline

#9 2008-03-03 08:46:16

occam
Member
From: Melbourne, Australia
Registered: 2005-01-16
Posts: 82

Re: Kernel 2.6.19: Max 15 partitions on SCSI device

Well, this thread tells me what my problem may be!  I am running 2.6.24.3-1 with SATA drives only, and I cannot reliably create more than 15 partitions on a hard disk.
Mind you, by manually creating device nodes (and setting their group to disk) I can get partitions 16 and 17 mounted - but with the wrong sizes.
So - either I give up on my nice disk structure and revert to folders in a common partition (rathed BIG it becomes), or someone can tell me how to handle the problem better.  Or maybe this is something that will be solved in the near future?


Moduli non sunt multiplicandi praeter necessitatem

Offline

#10 2008-03-05 23:46:14

Romashka
Forum Fellow
Registered: 2005-12-07
Posts: 1,054

Re: Kernel 2.6.19: Max 15 partitions on SCSI device

This was discussed on lkml long ago and AFAIR kernel devs didn't want to increase the limit, so I doubt it will change in the future.


to live is to die

Offline

Board footer

Powered by FluxBB