April 20, 2015, 08:34:34 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Visit our home page for VL info. To search the old message board go to The first VL forum is temporarily offline until we can find a host for it. Thanks for your patience.
Now powered by KnowledgeDex.
   Home   Help Search Login Register  
Please support VectorLinux!
Pages: [1]
Author Topic: Kernel 2.6.22 changes /dev/sda to /dev/hda  (Read 3791 times)
Posts: 96

Eko M. Budi

« on: July 13, 2007, 10:46:40 pm »

FYI, kernel 2.6.22 has changed something.

In my laptop (Toshiba Satelite M55 series),
kernel 2.6.21 and older reports the harddisk as /dev/sda.
Now kernel 2.6.22 lists it as /dev/hda, the same as kernel 2.4.31.

Global Moderator
Posts: 2160

« Reply #1 on: July 14, 2007, 05:30:29 am »

I'm guessing that your laptop has a sata drive (from sda), right?
There were quite a few changes made to both libata and libsata in 2.6.22 acording to KernelTrap, so maybe that could be an explanation for the name change.
« Last Edit: July 14, 2007, 05:35:02 am by easuter » Logged

Posts: 96

Eko M. Budi

« Reply #2 on: July 22, 2007, 07:08:37 pm »

I know.
Just to let you know, because it is potential to screw up your machine.
I got 3 different partitions (VL, VL, Slack).
After installing the new kernel in VL and rerun vliloconf,
other partitions that have the older kernel won't boot.

The solution was to reinstall the new kernel to all partitions.
Posts: 35

« Reply #3 on: July 22, 2007, 08:14:18 pm »

This was a real problem for me as I still boot from the (Windows) MBR to lilo on the boot sector of the linux partition. After editing /etc/lilo.conf under the running kernel (2.6.21), lilo refused to run after changing the root =  option from /dev/sdax to /dev/hdax. I also couldn't see how to have an older kernel and the newer kernel in lilo at the same time.

The solution found here is to re-compile the 2.6.22 kernel with CONFIG_IDE_GENERIC not set, then it all goes back to /dev/sda and problem solved. There are a couple of other solutions there too, but this seemed the neatest.

Posts: 86

« Reply #4 on: August 08, 2007, 03:45:37 pm »

Please don't cuss the kernel - it is one of best tested
(& least understood) portions of any Linux distribution

Potential  >  In Linux there is always alternate solutions:
The "standard practice" is to edit the loader
to boot any (uniquely named) kernel version desired.
Just as long as the path is correct.

I.E. The loader may have several "test" versions
concurrent to your (stable/production) favourite.

Another reason-  it's not wise to use "make CLEAN or MRPROPER"
at least until  certain old headers/etal are no longer desired.

What better way to have a fail-safe_fall-back escape route?

RFE ? >
it did whatever it is that it does while it is doing what it does when one doesn't know what it is doing. So that worked. I guess.
As I have & can personally   Huh v/ouch 
Automation will never replace backups (or outguess user)
Pages: [1]
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!