# [solved] after kernel upgrade: /dev/hda -> /dev/sda ?

## uvok

I just tried to upgrade the kernel from 2.6.28-r1 to 2.6.28-r2.

But when I tried to boot, I got an kernel panic (unable to mount....)

after looking for a solution, I found out that the problem could be the root argument:

```
kernel /boot/vmlinuz-2.6.28-gentoo-r2-32bit vga=791 root=/dev/hda7
```

I changed it to

```
kernel /boot/vmlinuz-2.6.28-gentoo-r2-32bit vga=791 root=/dev/sda7
```

and there was no kernel error. But the system complained that it couldn't mount anything, (cause in /etc/fstab, everything is named /dev/hdaX); and there was also a fsck error (bad superblock or so)

How can that be? I am very confused. Referring to the mainboard manual, the hard disk is connected to the IDE connectore. (Actually, only SATA-disks should be /dev/sda?)

Well, I should mention that I compiled the -r1 kernel with genkernel, and the -r2 kernel was compiled without it. (so there is no initrd).

Does anybody have an idea why this is happening?

By the way: the current kernel (-r1) accepts the /dev/hda

hope you understand what I mean,  despite my bad english  :Embarassed: Last edited by uvok on Mon Feb 23, 2009 7:23 pm; edited 1 time in total

----------

## agent_jdh

It means you have (probably) moved from using the old pata ide drivers to the the newer libata system.  This is a good thing (tm).

----------

## Xamindar

Maybe some joker swapped your kernel source with an Ubuntu kernel.  :Laughing: 

I haven't tried compiling this version yet though, I'll let you know if it does it to me - it better not.

----------

## uvok

Appending the configuration files, maybe it'll help:

-r1 config

-r2 config

----------

## mv

What is your problem? You have CONFIG_IDE=n, so how can you expect to get the obsolete ide-drivers?

You will probably have to go through the libata-transition anyway, since - as I understood - it is just a question of time until the old drivers will be removed permanently from the kernel. But once more, what exactly is your problem? Change hd* to sd*, and you will be happy  :Wink: 

One of the disadvantages of the new kernel policy is that the number of your "logical" partitions is limited to 11 - this is a serious restriction, but apparently your are not hit by that one. The fsck error might need closer investigation. I had this error in the transition phase, because a jumper on my hard drive (determining its maximum size) was wrong and the previous driver had somehow ignored this wrong jumper. But it is too early to say something before you have investigated the cause of the fsck.

----------

## Xamindar

 *mv wrote:*   

> 
> 
> One of the disadvantages of the new kernel policy is that the number of your "logical" partitions is limited to 11 - this is a serious restriction

 

What is the purpose of that restriction?

----------

## uvok

Thanks, activating ide worked...

however, now it says that eth0 fails to start.... Think I have to check the configuration again...(2morrow).

To answer your question:

I'm just used to the /dev/hda-naming... Furthermore, I have also an USB-Harddrive which is called /dev/sda at the moment.

fsck.ext3 /dev/hda7 didn't returned any errors (running from a 64-bit gentoo), so the fsck error should have to do with the sda naming; or it has to do with the USB-Harddrive...

----------

## mv

 *Xamindar wrote:*   

>  *mv wrote:*   
> 
> One of the disadvantages of the new kernel policy is that the number of your "logical" partitions is limited to 11 - this is a serious restriction 
> 
> What is the purpose of that restriction?

 

It is not a purpose, just an inconvenient side effect of the way how major/minor numbers of devices are defined:

sdX devices can only have numbers 1-15, hdX devices can have numbers 1-31 (or even more, I did not check).

----------

## agent_jdh

You really want to move to libata (e.g. /dev/sdX) - you were on the right track originally, all you needed to do was boot off an install cd, mount your root fs and edit /etc/fstab /dev/hdX entries to /dev/sdX

You might as well just get it done now, and disable the old ata driver as you originally had when you first compiled -r2 kernel revision.

----------

## bobspencer123

you can also use persistent naming in grub.conf and fstab to avoid confusion with name changes in the future (though not sure if swithing to new drivers would have created a diff. uuid). Here is some info on it from an arch linux wiki.

http://wiki.archlinux.org/index.php/Persistent_block_device_naming

----------

## krinn

 *bobspencer123 wrote:*   

> not sure if swithing to new drivers would have created a diff. uuid)

 

that's why i prefer by label

```
cat /etc/fstab | grep root

# The root filesystem should have a pass number of either 0 or 1.

/dev/disk/by-label/root      /      ext3      noatime      0 1

```

----------

## Cyker

Actually, has anyone looked into re-writing the udev configs so that IDE devices retain their hdx names under libata?

I am still using the BLK_DEV IDE drivers because I don't want my IDE drives being named sdx (That, and there is no real advantage moving to libata for IDE devices to make me want to).

In my mythical ideal world, we'd have hdx (IDE), sdx (SCSI), stx (SATA) and ubx (USB) and all the 'x' numbers would be assigned by port, not order-plugged-in, as it is with usb and libata...

----------

## agent_jdh

 *Cyker wrote:*   

> Actually, has anyone looked into re-writing the udev configs so that IDE devices retain their hdx names under libata?
> 
> I am still using the BLK_DEV IDE drivers because I don't want my IDE drives being named sdx (That, and there is no real advantage moving to libata for IDE devices to make me want to).
> 
> In my mythical ideal world, we'd have hdx (IDE), sdx (SCSI), stx (SATA) and ubx (USB) and all the 'x' numbers would be assigned by port, not order-plugged-in, as it is with usb and libata...

 

As an earlier reply pointed out, the old ata drivers are deprecated and will be phased out at some point in the future.  So you're going to have to change sooner or later.  Might as well just get it out of the road now.  And there is an advantage to moving to libata - it's being actively developed, for a start.

----------

## uvok

But doesn't it have disadvantages to use (S)ATA drivers for an IDE-HDD? That sounds kind of strange to me  :Question: 

And if I use UUID, do I have to write /boot/vmlinux root=/dev/disk/by-uuid/039c8609-ae13-4905-93e9-6fe528b53920 ?

I also read about writung root=UUID=039c8609-ae13-4905-93e9-6fe528b5392 or so...

----------

## krinn

 *uvok wrote:*   

> But doesn't it have disadvantages to use (S)ATA drivers for an IDE-HDD? That sounds kind of strange to me 
> 
> 

 

1/ you won't use an SATA driver to control the IDE drive, you will still use an IDE driver, but that driver looks for SDX names instead of HDX

2/ You'll get advantages (well maybe), for me using the new ide driver from intel, increase my disk performance a bit, i suppose because it include new code for newer controller and optimisation that previous drivers were lacking.

3/ as agent_jdh said:  it's being actively developed, for a start.

----------

## uvok

I changed the kernel configuration, my Harddisk is now /dev/sda...

But grub or the kernel does NOT accept root=/dev/disk/by-uuid/....; I get an kernel panic if I use this; so I  had to change it to root=/dev/sda7....

----------

## Cyker

 *agent_jdh wrote:*   

>  *Cyker wrote:*   Actually, has anyone looked into re-writing the udev configs so that IDE devices retain their hdx names under libata?
> 
> I am still using the BLK_DEV IDE drivers because I don't want my IDE drives being named sdx (That, and there is no real advantage moving to libata for IDE devices to make me want to).
> 
> In my mythical ideal world, we'd have hdx (IDE), sdx (SCSI), stx (SATA) and ubx (USB) and all the 'x' numbers would be assigned by port, not order-plugged-in, as it is with usb and libata... 
> ...

 

As long as they're deprecated and not removed, I'm not too bothered, and as long as they don't obfuscate it I'm sure it will not be too hard to retrofit the IDE code.

I don't trust the libata PATA drivers as they were less stable than the much better tested BLK_DRV drivers on my system when I tried them; BLK_DEV deals with non-perfect IDE connections much better, 'tho slower (If you use a 40-pin IDE cable that is longer than spec as I do, you'll get problems with libata).

Also, it has the same problem as the libata SATA drivers - The devices are numbered as detected; If you leave sata3 unplugged, sata4 becomes sdc instead of sdd, whereas with BLK_DEV, they are assigned by controller port which (IMHO) is much more sensible for stable device assignment.

You can circumvent this somewhat with udev labels, but if you have lots of USB devices, or use eSATA as I do then there is no easy solution to the drive device assignment problem.

At least with BLK_DEV, I can be sure the system will boot up no matter what else is plugged in; This is not the case with libata at the moment.

----------

## general

 *agent_jdh wrote:*   

>  *Cyker wrote:*   Actually, has anyone looked into re-writing the udev configs so that IDE devices retain their hdx names under libata?
> 
> I am still using the BLK_DEV IDE drivers because I don't want my IDE drives being named sdx (That, and there is no real advantage moving to libata for IDE devices to make me want to).
> 
> In my mythical ideal world, we'd have hdx (IDE), sdx (SCSI), stx (SATA) and ubx (USB) and all the 'x' numbers would be assigned by port, not order-plugged-in, as it is with usb and libata... 
> ...

 

as I understand it, udev rules can be written to to show

```

/dev/sata1.1

/dev/sata1.2

/dev/sata2.1

/dev/usb1.1

/dev/ide1.1

/dev/scsi1.1

/dev/root 

```

where every thing (except /dev/root, the uuid specified root) is determined by bus location (where they were plugged in(although this still leaves a usb problem)) and you don't see /dev/sdx at all

EDIT: udev naming on boot requires an initial ram disk (needed for /dev/disk/by-uuid/x)

----------

## Cyker

 *general wrote:*   

>  *agent_jdh wrote:*    *Cyker wrote:*   Actually, has anyone looked into re-writing the udev configs so that IDE devices retain their hdx names under libata?
> 
> I am still using the BLK_DEV IDE drivers because I don't want my IDE drives being named sdx (That, and there is no real advantage moving to libata for IDE devices to make me want to).
> 
> In my mythical ideal world, we'd have hdx (IDE), sdx (SCSI), stx (SATA) and ubx (USB) and all the 'x' numbers would be assigned by port, not order-plugged-in, as it is with usb and libata... 
> ...

 

Perhaps, but my udev-fu is not strong enough to write such a script.

I had a go, but because you can't use the KERNEL="blahblahblah" stuff as a base, I found it very difficult to turn out the desired names without the script being complicated to the point of un-readability. IIRC, the single biggest problem I had was that I don't know a reliable way to differentiate between an IDE device and a SATA device without the kernel - They all look the same to libata. In the end I gave up and stuck to using BLK_DEV  :Sad: 

Given enough time and reading, I assume it is possible, but I don't use Linux to make my life harder!  :Smile: 

----------

## general

 *Cyker wrote:*   

> 
> 
> Perhaps, but my udev-fu is not strong enough to write such a script.
> 
> I had a go, but because you can't use the KERNEL="blahblahblah" stuff as a base, I found it very difficult to turn out the desired names without the script being complicated to the point of un-readability. IIRC, the single biggest problem I had was that I don't know a reliable way to differentiate between an IDE device and a SATA device without the kernel - They all look the same to libata. In the end I gave up and stuck to using BLK_DEV 
> ...

 

I think alot of people would like something like this.so maybe some one should request it in the bugzilla (I don't have an account)

----------

