Upgrade to linux-image-2.6.22-14 kernel renders my PC unbootable

maybe, the same bug? https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/150739

2.6.22-14 has rendered my PC unbootable too. This is true for both i386, and AMD64 flavors of the kernel.

The problem appears when it tries to load the ide drivers for the disks I have. Modprobe exists abnormally,
and there's no ide support, so can't be booted. The kernel dumps to busybox.

There are a bunch of messages. The first, which seems a bit unrelated as it is a bit further up the log is:

[xxxx] BUG Unable to handle kernel NULL pointer dereference at virtual address 000000000

A bit further down we have modprobe trying to insmod ide_disk but fails, and exists anormally.

Stacktrace given:

[xxx] ide_in_drive_list 0x45/0x80 [ide_core]
[xxx] idedisk_check_hpa [ide_disk]

The stacktrace continues and I can add more if its needed (gotta do it by hand)

Some info on my hardware

00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
00:0b.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46)
00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

This problem did not exist on 2.6.22-12-i386

I am having a similar problem with kernel 2.6.22-14-386. I am able to boot with 2.6.20-16-386. I'm running kubuntu and this happened after my upgrade to gutsy.

I get to a screen that says it couldn't find the ext3 filesystem on /dev/hdb and the system ends up in repair mode with an option to hit CTRL+D to continue, which does nothing. If I issue a reboot command, it goes to the login, but cannot find my home directory (which is located on the drive it cannot find).

Here's fstab:

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0

UUID=75391bc4-63bb-41e1-ae1f-42b5e700e152 / ext3 defaults,errors=remount-ro 0 1

UUID=6b52dc42-8a81-4ed8-b317-ae604b65592e none swap sw 0 0
/dev/cdrom /media/cdrom0 udf,iso9660 user,noauto 0 0

#ext3 partition on bigmama
/dev/hdb2 /home/BigMama ext3 defaults 1 2

#windows partition on bigmama
/dev/hdb1 /home/windows ntfs-3g defaults,nls=utf8,umask=007,gid=46 0 1

And the complete kernel log for the boot:

Oct 19 17:00:11 jsteel-desktop kernel: Inspecting /boot/System.map-2.6.22-14-386
Oct 19 17:00:11 jsteel-desktop kernel: Loaded 24903 symbols from /boot/System.map-2.6.22-14-386.
Oct 19 17:00:11 jsteel-desktop kernel: Symbols match kernel version 2.6.22.
Oct 19 17:00:11 jsteel-desktop kernel: No module symbols loaded - kernel modules not enabled.
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] Linux version 2.6.22-14-386 (buildd@palmer) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 Sun Oct 14 22:36:54 GMT 2007 (Ubuntu 2.6.22-14.46-386)
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] BIOS-provided physical RAM map:
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] BIOS-e820: 000000007fff0000 - 000000007fff3000 (ACPI NVS)
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data)
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] 1151MB HIGHMEM available.
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] 896MB LOWMEM available.
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] found SMP MP-table at 000f57a0
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] Entering add_active_range(0, 0, 524272) 0 entries of 256 used
Oct 19 17:00:11 jsteel-desktop kernel: [ 0.000000] Zon...

This is an update to the bug I posted. It is my believe that there is something horribly wrong going on during the upgrade that causes subsequent kernel upgrades to be unusable. I bit the bullet and installed Gutsy from scratch after the official release. After doing it, I have no issues.

My thoughts on this: I would NOT recommend an upgrade from either Feisty or any other release to Gutsy. This is bad because not everyone creates multiple partitions or, like in my case, use logical volume manager to keep data separate from the OS. Most users dump everything into / and this is a big problem if one has to dump and reload.

The question to developers: what is the root cause of this behavior? Unless that root cause is found, you will have this issue moving forward as well.

In my case the 2.6.22-14-386 kernel is detecting my hard drives as sdx instead of hdx, so nothing in fstab mounts. I cannot manually mount the drives, and if I change fstab and restart, I get nothing.

It mounts the primary drive fine, but it's supposed to be hda2, yet 22-14 mounts it as sda2. I have a second hard drive with a windows partition (hdb1) and a home partition (hdb2) that are detected as sdb1 and sdb2 with 14-386. If I try to manually mount them, it says /dev/sdb2 is already mounted or /home/BigMama is busy, but they aren't. If I change the fstab entries, it doesn't work either.

I got mine to work by removing evms and related packages, then changing mounting manually.

I mean mounting the drives manually. I believe if I change fstab, it will work now.

I did change fstab to reference /dev/sda2 and /dev/sdb2 instead of /dev/hda2 and /dev/hdb2 and it works now. It seems as if the kernel is detecting my drives as SCSI instead of IDE as they were detected previously.

Do you hava a Seagate harddrive?

The master is a Western Digital WD400EB-00CPF0 and the slave is a Seagate ST3120026A, both as reported by the bios.

I hope this helps answer some questions here:

1) The reason you drives are appearing as /dev/sd* rather than /dev/hd* is because is kernel is now using the libata subsystem which makes all ATA devices appear with the /dev/sd* syntax.
2) As of Ubuntu 7.10 official support of EVMS has been dropped. For more information about this please refer to: https://wiki.ubuntu.com/Evms

Let us know if this helps. Thanks.

I do not have EVMS installed.

Developers, is it ok, that OS doesn't boot on laptops, and we don't have any patches about this bug for more than 3 months?

I experienced the very same problem.

The solution was to remove any evms-packages.
Even though https://wiki.ubuntu.com/Evms states, that it recomends removing emvs during the update process, I was not aware.

Bolek, can you comment if this is still an issue for you since you are the original bug reporter? Please let us know.

Kamba, I'm sorry you are still experiencing issues. Can you verify you have the same hardware at the original reporter? If not, can you please open a new bug. It helps the kernel team if each bug report is about one specific issue on a specific set of hardware. In the new bug report, please be sure to include the information requested by the kernel team at https://wiki.ubuntu.com/KernelTeamBugPolicies . Also please make sure to attach each file separately. Feel free to subscribe me to the bug and I'll be sure to take a look and triage it. Thanks.

Sorry for the delay. This is no longer an issue for me. Since my original
post and initial investigation, I decided to do a straight up re-load. That
fixed my issue.

On 12/13/07, Leann Ogasawara <email address hidden> wrote:
>
> Bolek, can you comment if this is still an issue for you since you are
> the original bug reporter? Please let us know.
>
> Kamba, I'm sorry you are still experiencing issues. Can you verify you
> have the same hardware at the original reporter? If not, can you please
> open a new bug. It helps the kernel team if each bug report is about
> one specific issue on a specific set of hardware. In the new bug
> report, please be sure to include the information requested by the
> kernel team at https://wiki.ubuntu.com/KernelTeamBugPolicies . Also
> please make sure to attach each file separately. Feel free to subscribe
> me to the bug and I'll be sure to take a look and triage it. Thanks.
>
> --
> Upgrade to linux-image-2.6.22-14 kernel renders my PC unbootable
> https://bugs.launchpad.net/bugs/152820
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

Bolek,
Monmouth Junction, NJ

Ok. I'll open a new bug.
No, i do not have EXACTLY the same hardware configuration as topic starter. BUT!

From september i have reported about my problem in some existing bugreports, and created the new one https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/151088
which even remains unanswered! From the beginning of october!!! So, whats the point to create another one NEW bug report?

Here, https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/123789 , i, among many others, reported about boot problem on laptops. Different laptops, different hardware - but one problem.

Here is another report i commented: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/150739

It is not only my problem, or problem of some specific configuration. It is laptop problem, i think.

Here is my case:

"for last half-an-hour tried to boot on 2.6.22-14 kernel in recovery mode. It stops on different places every time, so i do not know, how log/dmesg useful would be. For one attempt i've even saw a user@mycomp sign. When i typed "startx" - KDE started but have freezed on "initializing services" - the second graphics icon."

one more

"Kernel 2.6.22 hangs every time at different places. Sometimes after "Searching for file needed to boot", sometimes even after a type "startx", sometimes on another points of booting progress."

I have Asus X50M. Nvidia GeForce GO 6100. Upgrade to Gutsy from original sources in Adept Manager

Sorry for, maybe, too demandful post, but i am just tired of this. I use 2.6.20-15-generic for now, and i cann't install nvidia graphics driver on this, i cann't open .mdb files from MS Access...

So many problems hard to solve, if you are not supermegaarchy system administrator. is it user friendly OS? i just don't want to install MS products again...

Hi Bolek, thanks for the update. I'm going to close this report for now as this is no loner an issue for you.

Kamba, I'll follow up with you at bug 151088. However, just to answer some of the questions you raised here. . . the reason we ask that bug reports specifically target one particular bug on a specific set of hardware is so that it is easier for our development teams to focus on a fix. If you report a bug that says for example "Sound is broken" or "Suspend/Resume fails", that's a very generic issue. Depending on the type of hardware you have, you'll be exercising different drivers, and probably be requiring different fixes. If we don't narrow the report down to a specific target, the report can grow wildly out of control and not be very useful to the team debugging the issue nor to any reporters who are subscribed to the bug. Also, as you can see with what happened in this report, the bug will be sometimes be resolved for some but not for others. This often leads to confusion and frustration not only for bug reporters but also for our development teams. It is unfortunate that some new bug reports do remain in the "New" and "Unassigned" state. It is not a matter of importance regarding the bug, but rather an issue of resources. We are actively trying to resolve this situation. We really do appreciate the reports users like yourself submit and apologize for any sort of frustration that may arise. I hope this helped explain things a little. Thanks.

I would disagree that this issue is *fixed*. Bolek indicated that an *upgrade* from Feisty to Gutsy on a certain architecture (including a SiS 5513 IDE driver) will cause the computer to be unbootable, while a fresh install on the same computer will have it working like a charm.

There is some discussion as to possibly some changes needed in /etc/fstab in order to get everything working again. Perhaps this is all it takes, in my experience of trying this fix, it did not work.

At this point, it sounds like this could very well be an issue that could be fixed with proper documentation. Things are different between Feisty and Gutsy, and evidently a straight update as documented in the release notes is not working. It should be documented in the release notes how to switch a Feisty system over to a Gutsy system.

I'm at the point of having a broken system after a straight update. And just changing /etc/fstab did not do the trick for me. What else might I need to change?

David,

Can you boot with any of the kernels, such as 2.6.20-16-386? If you can, can you attach the contents of /var/log/kern.log?

Also, David, have you removed the evms packages? If you're not sure, running the command

dpkg-query -s evms

will give you the status. If the status says deinstall ok config-files, then you're good. If it says install ok installed, then you'll need to remove it:

sudo apt-get remove evms.

Here's a quick rundown of my Gutsy kernel issue.

Feisty was working fine with my computer. An upgrade to Gutsy worked -- with the exception of needing to either use the Feisty kernel, or compile my own with the SiS 5513 module compiled (it was removed by the Ubuntu folks).

Then I finally read through this bug. There is critical information hidden away here that really needs to be documented better. I tried to switch everything in /etc/fstab from '/dev/hd*' to /dev/sd*'. That got me further, but failed to completely work. I was finally able to get to a console prompt, though. I determined that it was now finding my root directory, but directories that were on other partitions were no longer found.

End result: /etc/fstab needs to have the '/' (root) directory set as /dev/sd*, but all other partitions need to be set as /dev/hd*. Kinda weird, but it works. I am finally using the stock Gutsy Ubuntu kernels -- and they work!

(no -- my system did not have any of the evms packages installed)

Could someone from the kernel team please review what all needed to change in setup for those of us that use IDE drives? I'm guessing that a number of issues could be resolved just by properly documenting the necessary changes when upgrading from Feisty to Gutsy. /etc/fstab clearly needs to change for those that use IDE drives. What else needs to change? These change notes need to be added to the upgrade notes (http://www.ubuntu.com/getubuntu/upgrading).

As requested, I am including my kern.log. The latest boot messages would be from the 2.6.22-14 kernel.

It appears that the *intent* with Gutsy was to switch the drives over to /dev/sd* completely. That did not happen for SiS 5513 IDE controllers.

According to my personal experience, these changes allowed me to use the stock Ubuntu kernels:

Feisty: No changes from previous installs. Feisty kernels were working fine with SiS 5513.

Gutsy: Some report fresh install with Gutsy works fine. An upgrade is another matter. Change the /etc/fstab file for the / (root) partition only to /dev/sd* instead of /dev/hd*.

Hardy: Change the /etc/fstab file for all partitions to use /dev/sd* instead of /dev/hd*. Also, if you specify the boot directory by /dev (instead of UUID) in /boot/grub/menu.lst, change to /dev/sd* there also.

These kind of changes need to be noted in the distribution notes for upgrading.

Cheers!

How can i make this changes, if 2.6.22 kernel won't boot?

P.S. I do not have digital photocamera, so its not easy for me to present screenshots here.

Here is my fstab (on 2.6.20-15-generic)

proc /proc proc defaults 0 0
# Entry for /dev/sda1 :
UUID=222b8e3c-9dda-4ac5-90ba-4fec03f27d09 / ext3 nouser,defaults,errors=remount$
# Entry for /dev/sda5 :
UUID=b0e315c0-125c-4415-8559-3f183332d03d none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,atime,noauto,rw,dev,exec,suid 0 0
/dev/sda5 /media/Main vfat sw,uid=0,gid=0,auto,rw,user 0 0
UUID=b0e315c0-125c-4415-8559-3f183332d03d <mount\040point> swap noauto 0 0
/dev/hdc /media/Main auto users,atime,noauto,rw,nodev,noexec,nosuid 0 0
------------------------------------------

sda5 - its for my external HDD (500Gb)
P.P.S. Thank you, Leann.

I mean, screenshots of unsuccessful boot attempts)))

David: I see this exact issue even on a freshly installed system, and my fstab and menu.lst files only contain UIDs (no reference to /dev/{sh}d* at all!)

I can confirm that my drive was changed from hdaN to sdbN in the switch from feisty to gutsy.

The following might help . . .

https://help.ubuntu.com/community/UsingUUID

Not sure if I'm having the same issue, but looks similar
I have a "sis5513" IDE controller and "Toshiba mk8025gas" hard drive. The update to gusty went ok (had to remove evms).
However yesterday (28.12.07) I've updated my system. The linux-image-2.6.22-14-386_2.6.22-14.47_i386.deb has been installed among others. Now my system is unbootable. The kernel doesn't detect my hard drive. As a result I'm getting "ALERT! /dev/disk... not found blah-blah" and initramfs command prompt.

I have a laptop here too with Gutsy using a SiS5513 HDD controller. It fails to boot using the 'default' kernel, 2.6.22-14.

My current workaround is to set 2.6.20 as the default kernel, which still has the module, but I can hardly call that a proper solution. Why has this driver been removed? Will it return in newer kernel versions?

For those who have *some* method of booting into their system...

It should be noted that there were a number of issues related to booting as a result of what was done in Gutsy. See bug 133666 for one prominent example. This documents an issue that had a known fix that will not be put into Gutsy simply because this show-stopping bug was found only after the release of Gutsy when people actually started using the distribution. This is actually an upstream thing -- the Linux kernel had the bug in 2.6.22, but it had been fixed in 2.6.23 and beyond.

As I understand the situation, Linux is trying to alter how drives are accessed. For many of us, that means that instead of /dev/hd*, we now have /dev/sd*. UUID's do not change between the two access methods, but there were some kernel bugs that were not identified until after Gutsy. There is no intention to pull these bugs out of Gutsy. Instead, they are asking that people test out the Hardy kernels to make sure that these issues are truly fixed in Hardy.

I'm of the understanding that this is done by temporarily altering the /etc/apt/sources.list in order to include the Hardy main and restricted repositories. Once you have retrieved the Hardy kernels, and installed them on your system, you can change /etc/apt/sources.list back to just Gutsy repositories. Unless you actually want to test Hardy, it is advised that you do not do any upgrades while you are using the altered sources.list.

At this point, the primary concern is if these issues are not fixed in the Hardy kernels. If there are still issues in the 2.6.24 kernels, please document the bugs appropriately.

I was able to modify my sources.list and test linux-image-2.6.24-5-386. I use the nvidia driver, so it could not load the kernel module, but it worked with the nv driver. The devices mounted fine without modification.

After booting to the gutsy kernel and removing the hardy kernel, apt gave me the following:

Log started: 2008-02-01 11:19:39
(Reading database ... 177899 files and directories currently installed.)
Removing linux-image-2.6.24-5-386 ...
Running postrm hook script /sbin/update-grub.
Your /etc/kernel-img.conf needs to be updated. Read grub's NEWS.Debian[1]
file and follow its instructions.

 1. /usr/share/doc/grub/NEWS.Debian.gz

Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... found: (hd0,1)/boot/grub/splashimages/36909-soft-tux.xpm.gz

Found kernel: /boot/vmlinuz-2.6.22-14-386
Found kernel: /boot/vmlinuz-2.6.20-16-386
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done

The link /vmlinuz is a damaged link
Removing symbolic link vmlinuz
 you may need to re-run your boot loader[grub]
The link /initrd.img is a damaged link
Removing symbolic link initrd.img
 you may need to re-run your boot loader[grub]
Log ended: 2008-02-01 11:20:10

The machine booted fine though and the grub menu was intact. I'm going to research this now.

Thanks.