Kernel panic 2.6.12-8-amd64-k8

Bug #21481 reported by Herko van Bergen
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Invalid
High
Unassigned

Bug Description

After upgrading to kernel 2.6.12-8 (with Synaptic (Breezy)) I get the error at
boot: depmod: error while loading shared libraries: libc.so.6 cannot open shared
object files: no such file or directory. Kernel 2.6.12-7 boots without problem.
Is there something wrong with the initrd?

Revision history for this message
Jeff Bailey (jbailey) wrote :

Can you put your /boot/initrd.img-2.6.12-8-amd64-k8 somewhere I can see it? I
haven't had this problem on my amd64 test system, nor heard any other reports,
so I'd like to see what happened.

Tks,
Jeff Bailey

Revision history for this message
Herko van Bergen (herko) wrote :

(In reply to comment #1)
> Can you put your /boot/initrd.img-2.6.12-8-amd64-k8 somewhere I can see it? I
> haven't had this problem on my amd64 test system, nor heard any other reports,
> so I'd like to see what happened.
>
> Tks,
> Jeff Bailey
>

Hi Jeff,
You can find it at http://vanbergen.name/~herko/initrd.img-2.6.12-8-amd64-k8
Thanks for your help.

Revision history for this message
Herko van Bergen (herko) wrote :

(In reply to comment #2)
> (In reply to comment #1)
> > Can you put your /boot/initrd.img-2.6.12-8-amd64-k8 somewhere I can see it? I
> > haven't had this problem on my amd64 test system, nor heard any other reports,
> > so I'd like to see what happened.
> >
> > Tks,
> > Jeff Bailey
> >
>
> Hi Jeff,
> You can find it at http://vanbergen.name/~herko/initrd.img-2.6.12-8-amd64-k8
> Thanks for your help.
>

I would just like to know if you could find somethings since the problem
persists. Thanks!

Revision history for this message
Jeff Bailey (jbailey) wrote :

> I would just like to know if you could find somethings since the problem
> persists. Thanks!

Looking at it, everything should be fine. Are you available to troubleshoot a
bit on IRC? It would help if you have two computers so we can work on one and
talk on the other.

Tks,
Jeff Bailey

Revision history for this message
Herko van Bergen (herko) wrote :

Created an attachment (id=4290)
hwinfo output

Revision history for this message
Herko van Bergen (herko) wrote :

(In reply to comment #4)
> > I would just like to know if you could find somethings since the problem
> > persists. Thanks!
>
> Looking at it, everything should be fine. Are you available to troubleshoot a
> bit on IRC? It would help if you have two computers so we can work on one and
> talk on the other.
>
> Tks,
> Jeff Bailey
>

I don't have 2 computers with internet close to each other, but in different
rooms. Would that be ok?
Btw, 2.6.12-9 has the same problem. Bug no. 16724 also looks a lot like my
problem. I have an AMD Athlon 3500 and a MSI motherboard. I have attached hwinfo
output for you to have a look at.
Herko

Revision history for this message
Jeff Bailey (jbailey) wrote :

> I don't have 2 computers with internet close to each other, but in different
> rooms. Would that be ok?
> Btw, 2.6.12-9 has the same problem. Bug no. 16724 also looks a lot like my
> problem. I have an AMD Athlon 3500 and a MSI motherboard. I have attached hwinfo
> output for you to have a look at.

It's all good. The time to run between two rooms is probably similar to
rebooting. If we can work with this interactively, hopefully we can find the
solution quickly.

When are you available to troubleshoot this with me?

Tks,
Jeff Bailey

Revision history for this message
Adam Conrad (adconrad) wrote :

Are you still seeing this issue? All of Jeff's initramfs-tools bugs got reassigned to me when he moved on to some other projects, and I regret that I missed reading this one until just now.

Revision history for this message
Herko van Bergen (herko) wrote :

Actually I am still having it with Ubuntu's kernel releases. I'm sorry I did not react anymore but I did not have the time to go deeper into the problem. I compiled a kernel which works fine now. However, I would like to fix the problem the moment I have the time for it. If I cannot solve it, I will contact you. Thanks a lot.
Herko

Matt Zimmerman (mdz)
Changed in initramfs-tools:
assignee: adconrad → nobody
Revision history for this message
Simon Law (sfllaw) wrote :

Herko,

I'm going through old bugs and noticed that you reported this against an old
kernel. Is this still an issue with 2.6.15?

Thanks.

Changed in initramfs-tools:
status: Unconfirmed → Needs Info
Revision history for this message
HPO (hpo) wrote :

Hi!

I have the exact same problem on Dapper. Am I missing something somewhere else? Unfortunately, this errors does not seem to have been resolved...

Kernel 2.6.15-26-amd64-generic (or, BTW any older version of supplied kernels)
Athlon 3200
MSI-Board

Of course, I would be willing to assist in any way I can!

Revision history for this message
HPO (hpo) wrote :

It seems, mkinitramfs is including the libraries in /lib64, whereas the started initramfs is looking in /lib. However, I don't know how to change that behaviour...

Revision history for this message
Brian Murray (brian-murray) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Thanks in advance.

Changed in initramfs-tools:
assignee: nobody → brian-murray
Revision history for this message
Herko van Bergen (herko) wrote :

Thanks Brian for contacting me about this problem. It is however no issue for me anymore because I did a fresh install of Ubuntu. So the cause remains unclear i'm afraid.
Thanks again and best regards,
Herko

Revision history for this message
Brian Murray (brian-murray) wrote :

Thanks again for taking the time to report and troubleshoot this issue and I am glad that a newer version of Ubuntu is now working for you. Feel free to submit any future bugs you may find.

Changed in initramfs-tools:
status: Needs Info → Rejected
Revision history for this message
optimix (io-fx) wrote :

Hello,

I have a amd64 machine.
I have upgraded from dapper to edgy, from edgy to feisty and from feisty to gutsy. After the first upgrade and sice then, I have some errors when trying to boot some ubuntu kernels (2.6.15 and 2.6.22-14-generic from gutsy) :

depmod: error while loading shared libraries: libc.so.6 cannot open shared object file: No such file or directory
kbd_mode: error while loading shared libraries: libctutils.so.0 cannot open shared object file: No such file or directory
...

I suppose it's a initrd issue. Any idea how can I fix this ? (or how to examine initrd)

--
Alexandru Munteanu

Revision history for this message
moa3333 (moa3333) wrote :

I have just upgraded to hardy and i have the same error.

I had this error when i upgraded to edgy but i compiled my own kernel.

Now it woks very fine with the old kernel 2.6.22 i have compiled.

Hovever, i am not abe to run kernel 2.6.24 from feisty.

It seems that mkinitramfs is buggy. It compiled libraries for 32 bits and i have a 64 bits computer.

Any help?

Changed in initramfs-tools:
status: Invalid → Confirmed
Revision history for this message
moa3333 (moa3333) wrote :

i mean i had thsi probel when i upgraded to gutsy and to feisty (i don't remeber for edgy)

It seems the only solution is to reinstall the hole ubuntu from scratch???

This is because i have a very old ubuntu upgraded each time a new distribution came out.

Revision history for this message
moa3333 (moa3333) wrote :

In my case it says at boot time:

"/sbin/usplash_write error while loading shared libraries: libc.so.6 ......"

the old kernel works good, so i guess the new kernel is badly configures or something.

Revision history for this message
Removed by request (removed2249328) wrote :

I am experiencing this issue - three years after the initial bug report - on my present system. The hardware is 3 Ghz Core 2 Duos with 8GB of ram and an nVidia 8800GT with 64-bit Ubuntu Hardy Heron and whichever kernel is current in apt today (-19 IIRC)

The specific error message:

------------------------------------------------------------------------------------------
/sbin/usplash_write: "error while loading shared libraries: libc.6.so: cannot open shared object file: No such file or directory"
modprobe: "error while loading shared libraries: libc.6.so: cannot open shared object file: No such file or directory"
ALERT! /dev/disk/by-uuid/<insert hashed root id>/ does not exist. Dropping to a shell
(initramfs)>
------------------------------------------------------------------------------------------

I booted the kernel into Recovery Mode and the system came back up. I took this chance to downgrade the kernel to -18 and the system came back up. I then rebooted and got the exact same problem.

I see that this bug has been around since 2005 and is currently a "Low Priority." I am skeptical that reinstalling my system will fix the problem so hope someone is willing to work with me over IRC or telephone to get to the root of the problem ASAP. I need a stable system and this bug didn't come up until it had been running for 2-3 weeks. I made no recent configuration changes, so I am positive that reinstalling will only give the facade of fixing it and that I may well experience the problem again in less than a month.

Revision history for this message
Removed by request (removed2249328) wrote :

Without my workstation I can't get any work done. If someone has read this bug report and decided not to act on it I would appreciate you telling me that. I have not wiped this workstation as a service to Canonical, but if this bug is going to be ignored I am wasting my time!

Revision history for this message
Brian Murray (brian-murray) wrote :

It would be useful to know what happens when you boot the 2.6.26-19 kernel without usplash. You can do this by editing the grub boot line and removing the word 'usplash'.

Changed in initramfs-tools:
status: Confirmed → Incomplete
Revision history for this message
Removed by request (removed2249328) wrote :

When booting that kernel without usplash I still get the same error output, including the usplash_write error. I removed all instances of usplash from my menu.lst file and for the time being I'm able to boot into my -18 kernel. I don't get the usplash menu on this kernel so I know I removed it correctly in the -19 case. No idea why it is still getting triggered. There is way too much output even with grub's quiet command for me to see if there are any mentions of usplash in the -18 case. Is there a way to log this output?

Revision history for this message
Brian Murray (brian-murray) wrote :

Could you add your '/boot/grub/menu.lst' file as an attachment to your bug report? Additionally the results of 'ls /dev/disk/by-uuid/' when booting the 2.6.26-19 would be interesting.

Revision history for this message
Removed by request (removed2249328) wrote :

menu.lst is attached. Note that I added the amd64 kernel earlier today from debian as a troubleshooting step but it hasn't changed any behavior and gets the same error as the -19 kernel.

Revision history for this message
Removed by request (removed2249328) wrote :

running `ls /dev/disk/by-uuid' is going to be problematic:)

> ls /dev
console null tty0 ... tty8

Revision history for this message
Jason Crain (jason-bluetree) wrote :

Would you mind attaching /boot/initrd.img-2.6.25-2-amd64 ?

Revision history for this message
Jason Crain (jason-bluetree) wrote :

Sorry, it is 2.6.24-19-generic that is not booting properly? Could you attach /boot/initrd.img-2.6.24-19-generic then?

Revision history for this message
Removed by request (removed2249328) wrote :

I attached the 2.6.24-19 guy

Revision history for this message
Jason Crain (jason-bluetree) wrote :

I suspect that the linker is trying to load libc from from /lib/libc.so.6 rather than /lib64/libc.so.6, where it reside in the initrd you provided. Can you show the output of the command "update-initramfs -uv -k 2.6.24-19-generic"? That may fix the problem depending on how it updates the initrd.

If that fails, run this command as root:
echo 'export LD_LIBRARY_PATH=/lib64' > /etc/initramfs-tools/conf.d/ld_library_path
and recreate the initrd with "update-initramfs -u -k 2.6.24-19-generic". That may force it to load libc.so.6 from the correct directory.

If neither of those fix it, can you run the following command from recovery mode and show the output: /lib64/ld-linux-x86-64.so.2 --list /sbin/usplash_write

I would try these myself, but I can't get an x86_64 emulator to work.

Revision history for this message
Removed by request (removed2249328) wrote :

I've attached the output of `update-initramfs -uv -k 2.6.24-19-generic'.

Revision history for this message
Removed by request (removed2249328) wrote :

I ran these commands:

> sudo su
> echo 'export LD_LIBRARY_PATH=/lib64' > /etc/initramfs-tools/conf.d/ld_library_path
>update-initramfs -u -k 2.6.24-19-generic

Then rebooted int the -19 kernel (normal and Recovery, -18 still works fine), and got the following output:
------------------------------------------------------------------------------------------------
[24.229000] ACPI: Processur [CPU1] (supports 8 throttling stages)
[24.229110] ACPI: Exception (Processor_core-0816): AE_NOT_FOUND, processor device is not present.
Done.
Begin: Running /scripts/init-premount ...
Done.
Begin: Mounting root filesystem... ...
Begin: Running /scripts/local-top ...
Done.
Begin: Waiting for root file system... // note that it hangs here
Done.
           Check root= bootarg cat /proc/cmdline
            or missing modules, devices: cat /proc/modules ls /dev
ALERT! /dev/disk/by-uuid/* does not exist. Dropping to a shell!
(initramfs) ls/dev/disk
                  ls: /dev/disk: No such file or directory
------------------------------------------------------------------------------------------------

Here's the output of `/lib64/ld-linux-x86-64.so.2 --list /sbin/usplash_write':
        linux-vdso.so.1 => (0x00007fff1affe000)
        libc.so.6 => /lib/libc.so.6 (0x00007fd112c5f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd112fc4000)

Revision history for this message
Removed by request (removed2249328) wrote :

The usplash issue was fixed for a german ubuntu user here by reinstalling libc6. That fix did not work for me (and as seen above I am no longer getting that error since we ran update-initramfs). http://tinyurl.com/reinstall-libc6

The AE_NOT_FOUND issue is documented in Bug #218118 and doesn't appear related.

Bug #213884 seems very related to this one.

Revision history for this message
Removed by request (removed2249328) wrote :

Please compare my menu.lst (above) with my fstab (here).

Revision history for this message
Jason Crain (jason-bluetree) wrote :

It pauses at "Begin: Waiting for root file system" because the entries in /dev are not available. It pauses hoping that they will soon appear.

I'm not sure why they are not there. Could be udev not starting?

Revision history for this message
Removed by request (removed2249328) wrote :

Before we updated initramfs udev wasn't doing much of anything based on the contents of /dev, but now there are hundreds of entries there. The value of ROOT is /dev/disk/by-uuid/<UUID> but /dev/disk doesn't exist. Could it be because fstab and menu.lst are out of sync? I see some UUID entries in the menu.lst but also some hda entries.

Working backwards, can we compare my -18 and -19 setups and see what the difference is? It's totally odd that one works and the other doesn't. Note that new kernel packages update menu.lst. Perhaps -19 messed something up at that point.

Revision history for this message
Removed by request (removed2249328) wrote :

I have an identical 64-bit workstation that is running the -19 kernel and 32-bit hardy. The menu.lst and fstab files are essentially the same.

Revision history for this message
Jason Crain (jason-bluetree) wrote :

Your fstab and menu.lst look good to me same to me. And if they didn't match, I would expect the error messages to be different.

So if you boot into -19 recovery console, you see entries in /dev ? Do you at least have /dev/hda or /dev/sda entries for your drive? If so, I don't know why it is not creating the entries in /dev/disk/by-uuid. It should create entries based on the following rules:

# by-label/by-uuid (filesystem properties)
IMPORT{program}="vol_id --export $tempnode"
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_LABEL_ENC}=="?*", SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}"

and it gets the information it needs from /lib/udev/vol_id. I can only guess that either it cannot find the vol_id program or vol_id is returning bad information. What does it show when you run "/lib/udev/vol_id /dev/hd??" replacing ?? with letter/number for your root drive?

Revision history for this message
Removed by request (removed2249328) wrote :

In the initramfs shell I have no sd*/hd* entries in /dev so nothing to run vol_id on. After booting the -18 kernel:

------------------------------------------------------------------------------------------------
-> ls /dev/sd* /dev/hd*
ls: cannot access /dev/hd*: No such file or directory
0 brw-rw---- 1 8, 1 Jul 18 13:10 /dev/sda1
0 brw-rw---- 1 8, 5 Jul 18 07:10 /dev/sda5
0 brw-rw---- 1 8, 2 Jul 18 07:10 /dev/sda2
0 brw-rw---- 1 8, 0 Jul 18 07:10 /dev/sda
------------------------------------------------------------------------------------------------
-> for dev in /dev/sd*;do /lib/udev/vol_id $dev;done
/dev/sda: error opening volume
/dev/sda1: error opening volume
/dev/sda2: error opening volume
/dev/sda5: error opening volume
------------------------------------------------------------------------------------------------

But I get the same result on reality, which is the working clone of this workstation running the -19 kernel and 32-bit hardy. On both systems sda1 is the root drive.

Revision history for this message
Jason Crain (jason-bluetree) wrote :

The "error opening volume" message is probably because vol_id needs to be run as root. But that doesn't matter because the problem is /dev/sda* entries are not being created.

Maybe scsi drivers are not loaded? You could try running "modprobe scsi_mod sd_mod sr_mod st sg" from -19 recovery console and see if the devices are created.

Revision history for this message
Removed by request (removed2249328) wrote :

Jason, when I run that command I get:

> [435.476895]: scsi_mod: Unknown parameter: sd_mod
> FATAL: Error inserting scsi_mod. Unknown symbol or unknown parameter.

When I run `modprobe scsi_mod' I get `SCSI subsystem initialized' but no new devices.

Revision history for this message
Removed by request (removed2249328) wrote :

I found another user with this problem but he couldn't fix it so he traded his laptop in for a new model :/

http://ubuntuforums.org/archive/index.php/t-609277.html

Revision history for this message
Removed by request (removed2249328) wrote :

Guys, I'm sorry to rush you but I really need to wipe my workstation and this bug is the only thing stopping me. Could you provide a decision list of things for me to try rather than a constant back and forth. Or better, can we do this over chat? Thanks.

Revision history for this message
Jason Crain (jason-bluetree) wrote :

I'm at a loss. I have no idea why the kernel would not be recognizing the /dev/sdXY devices. Sorry that I cannot help more.

Revision history for this message
Removed by request (removed2249328) wrote :

Alright, thanks for trying Jason.

A last update for any future bug sufferers is that I was able to load the aforementioned kernel modules by modprobing them all individually.

Changed in initramfs-tools:
assignee: brian-murray → nobody
Revision history for this message
sam (shree-pravin005) wrote :

check your fstab file or grub.confg file.

Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for posting this bug.

Does this occur in Lucid?

Revision history for this message
MillenniumBug (millenniumbug) wrote :

Closing this bug report due to lack of activity.

If the problem still exists in 10.10, feel free to open a new report.

Changed in initramfs-tools (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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