Ubuntu
linux package

Cannot mount /home on /dev/hda16

Bug #134983 reported by OS/2-User
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Either when I try to install Gutsy tribe-5 from or simply only boot-up the Desktop-CD, trying to mount my /home, residing on a JFS partition /dev/hda16 on my only PATA HDD in this system, always fails with this misleading and, according to the openSuSE 10.3 installer message, also quite wrong message (here copied from /var/log/syslog):

Aug 26 21:54:47 ubuntu ubiquity: mount: wrong fs type, bad option, bad superblock on /dev/hda16,
Aug 26 21:54:47 ubuntu ubiquity: missing codepage or helper program, or other error
Aug 26 21:54:47 ubuntu ubiquity:
Aug 26 21:54:47 ubuntu ubiquity: In some cases useful info is found in syslog - try
Aug 26 21:54:47 ubuntu ubiquity: dmesg | tail or so
Aug 26 21:54:47 ubuntu ubiquity:

I don't know yet about "dmesg | tail or so", so I hade to go with what I found in syslog or what Nautilus tells me in its popup window, when I try to access /home.

From the information openSuSE provides during installation, the quite unexpected problem which I'm hitting here, apparently is an artificial limitation to only 15 partitions the kernel can handle!?!

I currently easily exceed this rather low number of usable partitions.

My ancient IBM OS/2 system, sitting in several flavours on a couple of them (JFS and HPFS), can easily handle that count, so I expect no less from the 2007 version of Ubuntu.

- Why does this ridiculous low partition count exist in the first place?
- What is someone with more than 15 partitions supposed to do, when he wants to use any of them with a Linux system? (and no, repartitioning or juggling Linux partitions around is most definitively out of the question.).

Revision history for this message
OS/2-User (fzf7a2c02) wrote :

Booting up with a Knoppix 5.0 CD, it didn't have any problem to have that partition mounted and its contents allocated..
This test confirms, that Gutsy currently is imposing some annoying, artificial limit to supported partitions, starting with hda16 and up.

Revision history for this message
Felix Miata (mrmazda) wrote :

Mandriva 2008 and OpenSUSE have workarounds to use legacy drivers instead of libata to access all existing partitions. Have you found a workaround that works in Gutsy? I'm having no luck. :-(

Revision history for this message
Matthew Garrett (mjg59) wrote :

It's not an artificial limitation - it's a consequence of the move from the legacy IDE stack to libata, which is abstracted through the SCSI layer with the result that only a maximum of 15 partitions per drive are supported.

Revision history for this message
Felix Miata (mrmazda) wrote :

It is artificial in the sense that the kernel developers chose to regard the SCSI partition limit problem of no apparent consequence when choosing to _replace_ the traditional IDE driver system with a libata driver system based upon a SCSI foundation. This they did in the face of ever more gargantuan hard disks.

It's also artificial in that the traditional drivers could still be provided for the benefit of upgraders who need them, as Mandriva and SUSE do.

LVM is not a solution for those who already have the partitions and dependencies on them in their rollout, maintenance and backup systems.

Revision history for this message
In , Felix Miata (mrmazda) wrote :
Download full text (6.2 KiB)

gx260:~ # kpartx -l /dev/sda
sda1 : 0 208782 /dev/sda 63
sda2 : 0 16065 /dev/sda 208845
sda3 : 0 514080 /dev/sda 224910
sda4 : 0 311805585 /dev/sda 755055
sda5 : 0 417627 /dev/dm-3 63
sda6 : 0 13108977 /dev/dm-3 433818
sda7 : 0 514017 /dev/dm-3 13542858
sda8 : 0 2104452 /dev/dm-3 14073003
sda9 : 0 9831717 /dev/dm-3 16177518
sda10 : 0 9831717 /dev/dm-3 26009298
sda11 : 0 9831717 /dev/dm-3 35841078
sda12 : 0 3277197 /dev/dm-3 45672858
sda13 : 0 14345982 /dev/dm-3 48950118
sda14 : 0 481887 /dev/dm-3 63296163
sda15 : 0 2249037 /dev/dm-3 63778113
sda16 : 0 9831717 /dev/dm-3 233151408
sda17 : 0 9831717 /dev/dm-3 242983188
sda18 : 0 9831717 /dev/dm-3 252814968
sda19 : 0 9831717 /dev/dm-3 262646748
sda20 : 0 9831717 /dev/dm-3 272478528
sda21 : 0 9831717 /dev/dm-3 282310308
sda22 : 0 9831717 /dev/dm-3 292142088
sda23 : 0 9831717 /dev/dm-3 301973868

gx260:~ # kpartx -a /dev/sda
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument
device-mapper: reload ioctl failed: Invalid argument

gx260:~ # ll /dev/disk/by-id
lrwxrwxrwx 1 root root 9 Jun 5 23:30 ata-ST3160023A_4JS0L8FE -> ../../sda
lrwxrwxrwx 1 root root 10 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part1 -> ../../sda1
lrwxrwxrwx 1 root root 11 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part10 -> ../../sda10
lrwxrwxrwx 1 root root 11 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part11 -> ../../sda11
lrwxrwxrwx 1 root root 11 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part12 -> ../../sda12
lrwxrwxrwx 1 root root 11 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part13 -> ../../sda13
lrwxrwxrwx 1 root root 11 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part14 -> ../../sda14
lrwxrwxrwx 1 root root 11 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part15 -> ../../sda15
lrwxrwxrwx 1 root root 10 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 Jun 5 23:30 ata-ST3160023A_4JS0L8FE-part6...

Read more...

Revision history for this message
In , Felix Miata (mrmazda) wrote :

Created an attachment (id=220616)
additional partitioning details

Revision history for this message
In , Felix Miata (mrmazda) wrote :

I tried modprobe dm-multipath prior to kpartx -a /dev/sda, but that did not change result.

I am a-865 on freenode's #opensuse-factory.

Revision history for this message
In , Hare-novell (hare-novell) wrote :

There was a bug in kpartx which prevented it from creating the correct dm devices for extended partitions. Please verify that the kpartx changelog contains:

* Wed May 28 2008 <email address hidden>
- Calculate correct partition offset in kpartx (bnc#394658)

Revision history for this message
In , Felix Miata (mrmazda) wrote :

(In reply to comment #3 from Hannes Reinecke)
> Please verify that the kpartx changelog contains:

# changelog kpartx
-bash: changelog: not found
# kpartx --changelog
kpartx: invalid option
# kpartx -v
(usage)
# rpm -qa | grep kpartx
kpartx-0.4.7-127
#

I have no idea how to find this changelog info. 0.4.7-127 is what is now on the mirrors.

Revision history for this message
In , Hare-novell (hare-novell) wrote :

rpm -qi --changelog kpartx
would give you the answer. But seeing the 0.4.7-128 contains the fix, chances are that -127 does not.

Revision history for this message
In , Felix Miata (mrmazda) wrote :

-127 has a 30 May timestamp and shows
* Wed May 28 2008 <email address hidden>
- Calculate correct partition offset in kpartx (bnc#394658)

Apparently -127 is what I used for filing this bug, which still exists now with -128 not yet available.

Revision history for this message
In , Hare-novell (hare-novell) wrote :

Would have been too easy. Hmm.

Revision history for this message
In , Hare-novell (hare-novell) wrote :

Oh for crying out loud.
The DFSee tool is _so_ broken. If you ever come across the author please let him know that there are systems with more than 8 disks.

Sigh.

Revision history for this message
In , Hare-novell (hare-novell) wrote :

Sorry, no luck here.

I managed to re-create the partition table here locally:

yarrow:/tmp/dfsee/linux # kpartx -a -l /dev/sdb
sdb1 : 0 208782 /dev/sdb 63
sdb2 : 0 16065 /dev/sdb 208845
sdb3 : 0 514080 /dev/sdb 224910
sdb4 : 0 311805585 /dev/sdb 755055
sdb5 : 0 417627 /dev/dm-3 63
sdb6 : 0 13108977 /dev/dm-3 433818
sdb7 : 0 514017 /dev/dm-3 13542858
sdb8 : 0 2104452 /dev/dm-3 14073003
sdb9 : 0 9831717 /dev/dm-3 16177518
sdb10 : 0 9831717 /dev/dm-3 26009298
sdb11 : 0 9831717 /dev/dm-3 35841078
sdb12 : 0 3277197 /dev/dm-3 45672858
sdb13 : 0 14345982 /dev/dm-3 48950118
sdb14 : 0 481887 /dev/dm-3 63296163
sdb15 : 0 2249037 /dev/dm-3 63778113
sdb16 : 0 9831717 /dev/dm-3 233151408
sdb17 : 0 9831717 /dev/dm-3 242983188
sdb18 : 0 9831717 /dev/dm-3 252814968
sdb19 : 0 9831717 /dev/dm-3 262646748
sdb20 : 0 9831717 /dev/dm-3 272478528
sdb21 : 0 9831717 /dev/dm-3 282310308
sdb22 : 0 9831717 /dev/dm-3 292142088
sdb23 : 0 9831717 /dev/dm-3 301973868
yarrow:/tmp/dfsee/linux # kpartx -a /dev/sdb
yarrow:/tmp/dfsee/linux # dmsetup table
sdb14: 0 481887 linear 253:3 63296163
sdb3: 0 514080 linear 8:16 224910
sdb13: 0 14345982 linear 253:3 48950118
sdb2: 0 16065 linear 8:16 208845
sdb12: 0 3277197 linear 253:3 45672858
sdb1: 0 208782 linear 8:16 63
sdb11: 0 9831717 linear 253:3 35841078
sdb10: 0 9831717 linear 253:3 26009298
sdb23: 0 9831717 linear 253:3 301973868
sdb22: 0 9831717 linear 253:3 292142088
sdb9: 0 9831717 linear 253:3 16177518
sdb19: 0 9831717 linear 253:3 262646748
sdb21: 0 9831717 linear 253:3 282310308
sdb8: 0 2104452 linear 253:3 14073003
sdb18: 0 9831717 linear 253:3 252814968
sdb20: 0 9831717 linear 253:3 272478528
sdb7: 0 514017 linear 253:3 13542858
sdb17: 0 9831717 linear 253:3 242983188
sdb6: 0 13108977 linear 253:3 433818
sdb16: 0 9831717 linear 253:3 233151408
sdb5: 0 417627 linear 253:3 63
sdb15: 0 2249037 linear 253:3 63778113
sdb4: 0 311805585 linear 8:16 755055

Revision history for this message
In , Hare-novell (hare-novell) wrote :

Can you attach /var/log/messages?
And 'kpartx -v -a /dev/sda' might be helpful, too.

Does it work with OpenSUSE 11.0?

Revision history for this message
In , Felix Miata (mrmazda) wrote :

(In reply to comment #8 from Hannes Reinecke)
> Oh for crying out loud.
> The DFSee tool is _so_ broken. If you ever come across the author please let
> him know that there are systems with more than 8 disks.

He will normally reply to bug reports within 24 hours, but this week and next he is on holiday. I don't know what the "broken" is, so you'll need to report what makes you cry out loud.
http://tech.groups.yahoo.com/group/dfsee-support/?yguid=12054984
http://www.dfsee.com/dfsee/

Revision history for this message
In , Felix Miata (mrmazda) wrote :

Created an attachment (id=221461)
/var/log/messages tail

Revision history for this message
In , Hare-novell (hare-novell) wrote :

Can you try to switch off smartd?
There might be a chance that smartd is keeping the device busy and device is refusing to do something with it.

Revision history for this message
In , Felix Miata (mrmazda) wrote :

(In reply to comment #10 from Hannes Reinecke)
> Does it work with OpenSUSE 11.0?

This particular install reports itself as 11.0 and was updated after report on mailing list of Factory lockdown for 11.0 release. When I try to access gwdg or mirrors.kernel.org ftp 11.0 dirs I get access denied messages.

(In reply to comment #13 from Hannes Reinecke)
> Can you try to switch off smartd?
> There might be a chance that smartd is keeping the device busy and device is
> refusing to do something with it.

I turned it off and rebooted but get the same result.

Revision history for this message
In , Felix Miata (mrmazda) wrote :

Created an attachment (id=221467)
boot track

Revision history for this message
In , Felix Miata (mrmazda) wrote :

Created an attachment (id=221468)
display output of kpartx -v -a /dev/sda

(In reply to comment #10 from Hannes Reinecke)
> And 'kpartx -v -a /dev/sda' might be helpful, too.
 .

Revision history for this message
In , Felix Miata (mrmazda) wrote :

Created an attachment (id=221471)
files created by dfsdisk script

DFSee can use these to precisely replicate the partitioning of my ST3160023A 8.01 /dev/sda. http://www.dfsee.com/dfsee/dfsee9xx_linux.tgz

Revision history for this message
In , Felix Miata (mrmazda) wrote :

(In reply to comment #13 from Hannes Reinecke)
> There might be a chance that ... keeping the device busy and device is
> refusing to do something with it.

Could this problem have anything to do with the fact that the system is a single disk system?

/etc/mtab:
/dev/sda10 / ext3 rw,noatime,nodiratime,acl 0 0
/dev/sda3 /disks/C msdos rw,noexec,nosuid,nodev,dmask=0000,fmask=0111 0 0
/dev/sda5 /disks/hda/boot ext2 rw,noatime,nodiratime,noacl 0 0
/dev/sda6 /disks/D vfat rw,noexec,nosuid,nodev,dmask=0000,fmask=0111,utf8=true 0 0
/dev/sda7 /disks/E msdos rw,noexec,nosuid,nodev,dmask=0000,fmask=0111 0 0
/dev/sda12 /home ext3 rw,noatime,nodiratime,acl 0 0
/dev/sda13 /pub ext3 rw,noatime,nodiratime,acl 0 0
/dev/sda14 /srv ext3 rw,noatime,nodiratime,noacl 0 0
/dev/sda15 /usr/local ext3 rw,noatime,nodiratime,noacl 0 0

Revision history for this message
In , Felix Miata (mrmazda) wrote :

I tried running kpartx -v -a /dev/sda on Mandriva Cooker and get similar messages, e.g. this tail:
device-mapper: table: 252:0: linear: dm-linear: Device lookup failed
device-mapper: ioctl: error adding target to table
device-mapper: reload ioctl failed: Invalid argument
add map sda23: 0 9831717 linear 0:0 302728923

Revision history for this message
In , Hare-novell (hare-novell) wrote :

Pretty much so. device-mapper refuses to create dm-devices if the underlying devices are busy, eg mounted.

So I fear we need to do some initrd hackery here to get the required result.

What you need to do is to create a initrd script /lib/mkinitrd/scripts/boot-dm_linear.sh which just creates a linear table on top of your existing sda device. mkinitrd already has the required infrastructure in
place, so whenever a dm-device is specified as a root device it'll do the right
thing, like running kpartx etc.

Then re-run mkinitrd and everything should be nice an dandy.

Let's see how the mkinitrd script could look like ...

Revision history for this message
In , Felix Miata (mrmazda) wrote :

(In reply to comment #20 from Hannes Reinecke)
> What you need to do is to create a initrd script

Literally? I'm no script writer.

> Let's see how the mkinitrd script could look like ...

I can only guess one line, same as subject, 'kpartx -a /dev/sda', which would only be good if sda is the only disk you want it done on.

Revision history for this message
In , Hare-novell (hare-novell) wrote :

Oh well. It all comes back to me.

There is a script /sbin/activate_dm_linear, which takes the device name as an argument. That will create the required udev rules.
And you need to set 'DM_BLOCK=yes' in /etc/sysconfig/kernel.

Then re-run mkinitrd, reboot and you should be set.

Revision history for this message
In , Felix Miata (mrmazda) wrote :

Created an attachment (id=221792)
output of mkinitrd -v

Revision history for this message
In , Felix Miata (mrmazda) wrote :

Created an attachment (id=221793)
/var/log/boot.msg from using new initrd

(In reply to comment #22 from Hannes Reinecke)
> There is a script /sbin/activate_dm_linear, which takes the device name as an
> argument. That will create the required udev rules.

So all /lib/mkinitrd/scripts/boot-dm_linear.sh needs is? ->

/sbin/activate_dm_linear /dev/sda

> And you need to set 'DM_BLOCK=yes' in /etc/sysconfig/kernel.

With, or without, quotes aroung yes? I tried with.

>Then re-run mkinitrd, reboot and you should be set.

It booted, but paused waiting for root to appear, then gave:
Waiting for device /dev/root to appear: ..............................Could not find /dev/root.
Want me to fall back to /dev/disk/by-id/ata-ST3160023A_4JS0L8FE-part10? (Y/n)
Waiting for device /dev/disk/by-id/ata-ST3160023A_4JS0L8FE-part10 to appear: ok

I don't see anything new in the /dev tree. /dev/mapper only has control. Nothing in /dev/disk beyond 15. Only 3 /dev/d* files.

Revision history for this message
In , Hare-novell (hare-novell) wrote :

Created an attachment (id=227827)
activate_dm_linear

Updated activate_dm_linear script.

Revision history for this message
In , Hare-novell (hare-novell) wrote :

Please use the above script to update the udev rules and re-run mkinitrd.
Ensure that 'kpartx' is listed in the features of the mkinitrd output.
The system should now boot up running on a device-mapper disk with all partitions visible (as device-mapper devices).

Revision history for this message
In , Felix Miata (mrmazda) wrote :

Created an attachment (id=228274)
mkintrd, fdisk -l, mount, /dev/md*, /dev/dm*, /var/log/boot.msg

I don't think it worked.

Revision history for this message
In , Felix Miata (mrmazda) wrote :

It must have worked at some point. Now after some more updates without paying any mind to this, and using 2.6.26-2, mount shows:

/dev/dm-22 on / type ext3 (rw,noatime,nodiratime,acl)
/dev/dm-12 on /disks/hda/boot type ext2 (rw,noatime,nodiratime,noacl)
/dev/dm-26 on /home type ext3 (rw,noatime,nodiratime,acl)
/dev/dm-28 on /pub type ext3 (rw,noatime,nodiratime,acl)
/dev/dm-30 on /srv type ext3 (rw,noatime,nodiratime,noacl)
/dev/dm-32 on /usr/local type ext3 (rw,noatime,nodiratime,noacl)
/dev/dm-24 on /disks/hda/fedora type ext3 (rw,noatime,nodiratime,noacl)

Is it time to try a fresh install and see if the installer offers up all my partitions? If so, do I need to manually intervene with kpartx at installation startup?

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Guys,

As Mathew pointed out, this was a decision implemented from upstream. It's not likely to be resolved for Ubuntu kernels until changes are made upstream.

Changed in linux:
status: New → Won't Fix
Revision history for this message
Felix Miata (mrmazda) wrote :

Leann, the fact that no kernel fix is expected for the foreseeable future is no reason to WONTFIX. A fix will come from somewhere at some point. It's just not entirely clear where it will come from, or when. There has always been a fix available by recompiling the kernel to restore IDE and preload it in initrds, and there is an imminent or existing fix via device mapper and kpartx available for SUSE users: https://bugzilla.novell.com/show_bug.cgi?id=397816

Wontfixing this is like telling upgraders to use SUSE instead.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Felix,

Point taken. I'll change the status to "Confirmed". Thanks.

Changed in linux:
status: Won't Fix → Confirmed
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Jeremy Foshee (jeremyfoshee)
Changed in linux (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.