# Yet more 2.6.19 kernel problems!

## andrewwalker27

I've just tried using kernel-2.6.19, and after switching off splashscreen support because of that bug, I found that the new kernel I compiled wouldn't work as it couldn't find my /root partition after booting.

I'm using the same kernel config as previously with 2.6.18 so I can only assume it is a kernel issue. I'm using a sata drive and the kernel seems to find all my usb devices but stalls looking for the root filesystem which is pretty strange as it found /boot partition using the same grub options with the old kernel.

I'm only meddling with 2.6.19 to get my hvr-1300 tv card working so it's not important, but I thought I'd see if anyone else was having similar issues before I do a bug report as it could just be me missing something obvious.

I don't wish to be critical of anybody but I've never had this much trouble with a kernel upgrade before!

----------

## Headrush

I had the exact same issue. For some reason the make oldconfig didn't properly set the same settings or added a new SATA one I missed.

Once I manually went through menuconfig and made sure all SATA parts I needed were compiled in, worked great.

----------

## Shaman

My problem is that RAID devices don't work now.  I can access the drives just fine on their own (VIA ATA/IDE drives) but the RAID software fails right at bootup.  Works fine in 2.6.18.  This is a major setback for my systems.

----------

## Dralnu

I'm running somewhat older hardware, but I've never had much trouble with a kernel upgrade.

Maybe just cp /usr/src/linux-prior /usr/src/linux-newer would be better then make oldconfig?

I could see there being a problem with it not seeing the old config file well, so that may be worth a shot if nothing else (if it is a configure error)

----------

## Headrush

 *Dralnu wrote:*   

> I've never had much trouble with a kernel upgrade.

 

Me neither until this update.

 *Dralnu wrote:*   

> Maybe just cp /usr/src/linux-prior /usr/src/linux-newer would be better then make oldconfig?

 

???? You have to do that before make oldconfig, am I missing something?

----------

## steve_d555

I think there was a change in the configuration for SATA devices because of the move to libata.

See the Changelog.

----------

## Headrush

 *steve_d555 wrote:*   

> I think there was a change in the configuration for SATA devices because of the move to libata.
> 
> See the Changelog.

 

Yes we know.   :Smile: 

We were just saying using the standard method of executing make oldconfig using the previous kernel config doesn't properly set the new kernel config to use the older SATA setup. You have to manually go through and check it.

----------

## Dralnu

 *Headrush wrote:*   

>  *Dralnu wrote:*   I've never had much trouble with a kernel upgrade. 
> 
> Me neither until this update.
> 
>  *Dralnu wrote:*   Maybe just cp /usr/src/linux-prior /usr/src/linux-newer would be better then make oldconfig? 
> ...

 I never ran make oldconfig, and never had problems with my kernel. It was just cp then make && make modules_install (out of habit, not because I have any).

My memory was a bit messed - I thought oldconfig pulled a config file out of somewhere to use it, and didn't need you to cp the old one over.

----------

## steve_d555

 *Headrush wrote:*   

>  *steve_d555 wrote:*   I think there was a change in the configuration for SATA devices because of the move to libata.
> 
> See the Changelog. 
> 
> Yes we know.  
> ...

 

 :Embarassed: 

----------

## Helena

 *Headrush wrote:*   

>  *steve_d555 wrote:*   I think there was a change in the configuration for SATA devices because of the move to libata.
> 
> See the Changelog. 
> 
> Yes we know.  
> ...

 I also ran into this problem. I used a slightly different method: from within

```
make menuconfig
```

I backup the kernel configuration before and then load it back in again after upgrading gentoo-sources. I have been using my own little script for installing a new kernel for almost 3 years now, in which I always backup the previous kernel. So I could start that one and find out what happened  :Smile: .

----------

## chronophobic

Just to add a "me too". 2.6.19 broke the SATA (good thing I keep a Gentoo CD handy) and ati-drivers can't be compiled against it for some reason. First time a kernel update goes so haywire.

----------

## zomps

Didn't have any problem get ati-drivers and fbsplash to compiling

did my own patches for removing the config.h header include

But my biggest problem is, I cannot get it booting

I'm using always make oldconfig

then I enabled CONFIG_ATA_PIIX

and still cannot mount root file system on booting

I think it has different dev node order

before panic I can see scsi order

scsi 2:0:0:0 "My 400GB Drive"

scsi 3:0:0:0 "My 120GB Drive"

but still root=/dev/sd{a,b,c,d}3 isn't working

on 2.6.18 i have root=/dev/sda3

----------

## chronophobic

 *zomps wrote:*   

> Didn't have any problem get ati-drivers and fbsplash to compiling
> 
> did my own patches for removing the config.h header include
> 
> But my biggest problem is, I cannot get it booting
> ...

 

You mean just removing the include fixes the problem and they compile fine? Can you pass those patches this way then? (cuz the way things are going a fix may not find its way in the repository as soon as I'd like it to).

----------

## zomps

for fbsplash there is already 2.6.19-r1 release which should fix this

and for ati-drivers there seems to be already fix in bugzilla https://bugs.gentoo.org/show_bug.cgi?id=156876

----------

## zomps

huh figured my problem out

now CONFIG_BLK_DEV_SD and CONFIG_CHR_DEV_SG should be compiled in to kernel

previously they where modules

----------

## Headrush

 *chronophobic wrote:*   

> Just to add a "me too". 2.6.19 broke the SATA (good thing I keep a Gentoo CD handy) and ati-drivers can't be compiled against it for some reason. First time a kernel update goes so haywire.

 

Any why did you not keep your previous kernel as a backup until you were satisfied with the new one?? Tisk, Tisk.   :Razz: 

(All guess we get laxidazical and pick up bad habits when things seem to always work right before.  :Smile:  )

Helena, by going through manually, I mean make menuconfig.    :Wink: 

----------

## chronophobic

Err... no, "when things seem to always work right before" isn't really a part of the Gentoo experience  :Razz: . I have my system set up so I do keep a kernel as a backup and in theory "make install" shouldn't break anything, but it somehow has. I'm not too bothered, if a fix isn't out by tomorrow I'll just install 2.6.18 again, but I do hate downgrading  :Wink: .

Still, to tell you the truth I didn't expect the kernel to not work with the old config and to break ati-drivers and a few other things without any warning out there about it.

----------

## Headrush

 *chronophobic wrote:*   

> in theory "make install" shouldn't break anything, but it somehow has.

 

Sounds like something might be foobar on your system. (or you did something you didn't realize.  :Smile:  )

You're right, a make install shouldn't affect a different kernel as they are all stored in separate directories in /lib/modules/

----------

## chronophobic

I usually run updates when a good list aggregates and I USUALLY have the common sense of waiting a few days before updating kernels, glibc, or binutils (1 out of 5 installs of which break my system if I do it right after they're released). Something may or may not be foobar (but I doubt it) and that's really beyond the point here - I may not have been extra cautious, but it's absurd to have to take precautions on every update or risk running down the system. Breaking the Ati drivers is bad enough,but hell, if I didn't have a Gentoo CD handy I'd have had a problem because using the old config somehow left me without SATA and thus without a way of the kernel to read the root fs.

In other news, yes, I don't pay much attention to what I do, I could have ran the make install twice thus deleting my backup vmlinuz.old kernel (thanks for the modules tip btw, but I know that already).

----------

## Headrush

 *chronophobic wrote:*   

> Something may or may not be foobar (but I doubt it)

 

Sorry, but if a make install changed something in a different kernel, something is a miss.

 *chronophobic wrote:*   

> and that's really beyond the point here - I may not have been extra cautious, but it's absurd to have to take precautions on every update or risk running down the system.

 

Its absurd to take precautions on changing kernels, wow.

This kernel update was an exception due to the separation of the SCSI and SATA sections. I think it would be wasted time to try to change make oldconfig to fix this kind of change, but a message displayed in the emerge noting this would be helpful.

----------

