initramfs not generated correctly on dist-upgrade

Ok, I completely uninstalled my kernel image then reinstalled it and it worked. This makes me think that there was something wrong with the upgrade dependancy order that caused it to do its initrd stuff before the environment was properly set up. Thus it shouldn't affect new installations but may provide a confusing and discoraging barrier to people upgrading to test dapper.

Most likely an issue with mkinitramfs.

I ran into this problem as well after dist-upgrading an IBM T42 from breezy -> dapper. Unfortunately because I'm clever, I forgot to make a backup of the broken initrd image before rerunning dpkg-reconfigure. However, just running dpkg-reconfigure was enough to fix the problem.

Same problem with breezy to dapper upgrade. I will try dpkg-reconfiguring kernel-image, but at now my pc is unbootable... I have to copy a running kernel from a live cd...

I've been running Dapper for a while, and the most recent kernel that works is 2.6.15-13. After that, I get the same problem (with kernels -15 and -16).

Incidentally, I believe this was right about the time that I started getting a graphical grub menu. Perhaps while changing over to the graphical grub menu, something was accidentally changed in the kernel settings or init process..?

I still have my initrd's and kernel, if it would be useful..

I got the same issue when I tried to dist-upgrade from Breezy to Dapper.

I was able to boot by copying initrd.img-2.6.15-17-k7 from one of my working Dapper computer to the machine I was trying to upgrade.

To fix the problem permanently, I did:
mkiniramfs -o initrd.img-2.6.15-17-k7 2.6.15-17-k7

and copied the new initrd.img file in /boot/

After that, my system worked perfectly.

Note: I'm not sure which package is reponsible for the creation of the the initrd.img... Before manually creating the file (using mkinitramfs) I tried to do a dpkg-reconfigure linux-image-2.6.15-17-k7 but it didn't work...

Problem reappears on this end too - it's not specific to my motherboard, the IDE extender card I have also can not be found, nor my SATA cards.

As others have said, the only fix I can give when it fails is to:

Boot into a breezy kernel (2.6.12)
mkinitrd -o /boot/initrd-2.6.15-18-k7 2.6.15-18-k7

This was from a breezy to dapper upgrade.

Additionally, most of the time, a busybox shell does NOT appear. It appears with release 17, but NOT 18.

The system is a 32-bit Athlon XP 2500+, ASUS A7N8X-E Deluxe motherboard.

I can confirm it happening as of 2006-03-20.

I did a dist-upgrade from Breezy to Dapper (~1700 packages upgraded) and all went seemingly well, until rebooting and the kernel (2.6.15-18) telling me that /dev/md0 did not exist.
I rebooted again, trying the 2.6.12-10 kernel that was left over from Breezy, but that initrd was similarly broken (which was somewhat surprising and irritating as it had worked perfectly for months).

To rescue the system, booting from CD, mounting /dev/md0 on /target and then chrooting into it, mounting /usr and /var before doing 'dpkg-reconfigure linux-image-2.6.15-18-k7' was required to fix the broken initrd.

Just saying that the problem is still present.

It just happened to me on an upgrade to dapper 2006-03-24.

Still present.

dpkg-reconfigure linux-image-2.6.15-19-k7 fixed it for me.

Asus A7V8X motherboard.

Same happened with me, dist-upgrade from breezy to dapper. My fix: wait until busybox drops you to a shell (takes a little while). modprobe ide-disk; modprobe ide-generic; cat /sys/block/hda/dev; mknod /dev/hda1 b 3 1;C-d # And then I watch as my system continues boot.

My root filesystem is on hda1 as you might've guessed. cat /sys/block/hda/dev returns the major and minor numbers of hda on your system (3:0).

After this I can use the tips above to make a new and working initrd.img.

We need for someone to save a copy of their broken initramfs when this happens, in order to analyze and fix the problem.

I'm having the same problem and have saved a copy of initrd.img-2.6.15-20-powerpc. Tell me how can I send the file, and I will send it.

Click on "Add attachment" on the left side of the page

This file was generated with command dpkg-reconfigure linux-image-$(uname -r).
After running this command, I added a .gz extension, and gunzipped the file to find out what was happening. Since I didn't find anything, I ran gzip again and removed the .gz extension. I hope this file to be useful.

This happened to me too, attaching initrd

To clarify, I upgraded to dapper from breezy using the mvo's new dist-upgrader tool. I experienced the same problem as everyone else, so I booted into my breezy kernel and ran dpkg-reconfigure linux-image-2.6.15-20-686. Same problem, so I attached my initrd. It's my test box so I am just leaving it, if you need anything else from it just let me know.

infinity has confirmed that this is not the problem I am facing, disregard please. :)

This also happened to me; in my case, the /var partition filled up during the configuration step of my apt upgrade, and dpkg failed on some early configuration (meaning that everything else, including the initramfs package, was not configured.) The crucial problem is that dpkg/apt/synaptic does NOT report the correct issue ("/var is full - your system is in an invalid state; please do..."); it just says "could not configure this dumb braille package that you're never going to want to use anyway".

When I rebooted, the new kernel did not work, and other kernels were only basically functional (because many things were in an unconfigured state; so, X did not work, network was down, usb devices didn't work, etc etc).

I got out of it by running update-initramfs on the new kernel; when I rebooted again, this got me into X, and it was only then that I discovered that /var was full, and that there was a bunch of dpkg configuring that still needed to be done. Used synaptic to clear some of apt's cache to create space, and all was good.

I reproduced the exact problem on my ibook, which was much more hairy, since in that case *neither* of the kernels worked (yaboot is much less than grub, in terms of features) and for the longest time I could not figure out how to eject the cd drive to boot from a live cd (since the eject button is handled via software which loads after the kernel). For a while, I thought I had a paperweight on my hands (until I discovered the "paperclip trick" for opening the ibook's cd drive, thanks to a pointer from the ubuntuforums).

This is a potentially big problem...the fix should be made in breezy well prior to dapper's release.

See also bug: 36849, which is similar if not identical.

Found this after adding a bug report. Identical issue, see #45698

Found this also after adding bug report #47577

I've got the same problems as above.
System: P4, Via chipset, plain ATA drive,
kernel and custom image 2.6.15-23-686.

-386 also fails the same way, custom or not.

Dapper has been released, and the kernel
and initrd has not changed.

I've tried various tricks to load drivers
when the kernel hangs and finally drops
into a simple shell, but there is nothing
to be found. The kernel doesn't seem to
even have the ATA driver.

I have a system currently in this state, and I've made a backup of the whole system in this state, preserving original timestamps etc, so let me know if need anything else s.a. system logs, directory listings, dpkg logs, forensic reports on system changes, etc.

Here is my <a href="www.connact.com/~phawkins/toast/initrd.img-2.6.15-23-386">initrd.img-2.6.15-23-386</a>

How I got here:
A third-party installation script had upgraded my system to dapper, leaving the system in a mostly-breezy/a few dapper apps state; I decided to upgrade core apps, and upgraded the kernel from 2.6.12-10-386 to 2.6.15-23-386, using the dummy "always points to the latest available kernel" package. Never futz with the system late at night.

I get the same symptoms as others, including not being able to boot from the 2.6.12-10-386 image; when I boot using the 2.6.15-23-386 recovery from the grub menu, the last few lines I see are:
Begin: Loading essential drivers ...
Capability LSM initialized
Done.
Begin: Running /scripts/init-premount ...
Done.
Begin: Running /scripts/local-top
Done.
Begin: Waiting for root file system ... ...
Done.
ALERT! /dev/hda1 does not exist. Dropping to a shell!

and then the BusyBox banner.

I've made working images for 2.6.15-23-386 and -686:
http://purehatred.org/image/

I used the surviving kernel from Breezy to boot, installed yaird,
and ran mkinitrd.yaird to generate them. Both are tested on other
people's systems.

There's definitely something wrong with both mkinitramfs and
mkinitrd, which yaird manages to do right.

is this still an issue in feisty

I have recently upgraded to feisty, and have just run into the same problem.

I think I first upgraded the initram-stuff (which complained that the kernel was too old), then I upgraded the kernel.
Re-installing and dpkg-reconfigure'ing does not seem to work.

In the initrd-shell, the only devices listed in /sys/block are the ram-devices and hdd (an ATAPI dvd drive).
This is after modprobe ide-disk and ide-generic.
So it seems all the IDE stuff except ATAPI does not work...

An initrd.img with the problem is attached.

(My planned next steps: running mkinitramfs by hand, and/or looking at which modules are normally used.)

Regards,
eriksoe

update:
The point where it fails seems to be when the kernel detects the IDE devices:
...
hda: ERROR, PORTS ALREADY IN USE
hdb: ERROR, PORTS ALREADY IN USE
...

This kind of error has been reported elsewhere (on ubuntuforums) - I'll go look there for an answer.

eriksoe

I have found this to occur in Feisty.

I attempted to update the kernel to that in Gutsy - added Gutsy to the repository list.
On rebooting, the boot stops at the point where it tries to mount the hard disc (inferred from symptoms).

After many minutes, I get a prompt from busybox.

When I check /dev, there are no nodes for hard discs (I don't apologise for the Australian spelling).

If I copy the deb to a debian (etch/lenny) system and install, then copy the initrd.img to the ubuntu system, it all works. This initrd is larger than the native ubuntu one.

Looking at the descriptions in this post it seems that the following occurs:

Installing a kernel from the next version i.e during an upgrade, creates a faulty initrd.img.
Booting this new system with the old kernel, then re-installing the new kernel creates a good initrd.img.

It seems to me that the 'older' environment is causing a problem with the initrd creation.

Summary should be changed from "initramfs not generated correctly on upgrade to Dapper" to "initramfs not generated correctly on dist-upgrade". This just happened to me going from Gutsy to Hardy. Marking kernels for reinstallation and applying in Synaptic made system bootable with Hardy kernels and newer larger initrds.

1)My platform is amd64.
I've upgraded from Gutsy to Hardy beta.
After the rebooting my computer hung up on """Begin: Waiting for root file system... ..."""
I pressed "reset" and booted old kernel 2.6.22-14, then i run "sudo
update-initramfs -k all -u"
as a result the problem was fixed(2.6.24 now working fine).

2)Investigation:
I decompress two file initrd.img-2.6.24-12-generic and initrd.img-2.6.24-12-generic.bak.

The following difference was disclosed:

*** bak 2008-03-23 16:25:21.000000000 +0300
--- new 2008-03-23 16:25:30.000000000 +0300
***************
*** 69,79 ****
--- 69,88 ----
  ./etc/usplash.conf
  ./etc/udev
  ./etc/udev/rules.d
+ ./etc/udev/rules.d/80-programs.rules
+ ./etc/udev/rules.d/20-names.rules
+ ./etc/udev/rules.d/65-persistent-storage.rules
+ ./etc/udev/rules.d/05-options.rules
+ ./etc/udev/rules.d/05-udev-early.rules
+ ./etc/udev/rules.d/90-modprobe.rules
+ ./etc/udev/rules.d/95-udev-late.rules
  ./etc/udev/udev.conf
  ./etc/default
  ./etc/default/console-setup
  ./etc/console-setup
  ./etc/console-setup/boottime.kmap.gz
+ ./var
+ ./var/run
  ./usr
  ./usr/lib
  ./usr/lib/usplash
***************
*** 129,137 ****
--- 138,161 ----
  ./bin/gunzip
  ./bin/minips
  ./lib
+ ./lib/libvolume_id.so.0
  ./lib/libntfs-3g.so.23
  ./lib/libc.so.6
  ./lib/libconsole.so.0
+ ./lib/udev
+ ./lib/udev/scsi_id
+ ./lib/udev/ata_id
+ ./lib/udev/firmware_helper
+ ./lib/udev/usb_id
+ ./lib/udev/usb_device_name
+ ./lib/udev/watershed
+ ./lib/udev/vol_id
+ ./lib/udev/pnp_modules
+ ./lib/udev/vio_type
+ ./lib/udev/ide_media
+ ./lib/udev/path_id
+ ./lib/udev/edd_id
+ ./lib/udev/dvb_device_name
  ./lib/brltty
  ./lib/brltty/brltty.sh
  ./lib/librt.so.1

in /var/log/dist-upgrade/apt-term.log :

/\/\/\/\/\/\/\/\/\/\/
Running depmod.
update-initramfs: Generating /boot/initrd.img-2.6.24-12-generic
cp: невозможно выполнить stat для `/etc/udev/rules.d/05-udev-early.rules': No such file or directory
/\/\/\/\/\/\/\/\/\/\/

Bug 223066 (which I just filed a few days ago) may be a duplicate of this issue.

I saw the exact same behavior when upgrading from Fiesty to Gutsy. I continued running with the fiesty kernel (2.6.20.15 I believe is the only one that continues to boot), and I am still doing so even after upgrading to Hardy last week. I have uninstalled/reinstalled both the generic and 386 kernels and done half a dozen initrd recreations and so far nothing has done any good. I get dropped to a busybox, every single time.

Given the activity on this Bug (plus the 10+ duplicates of it, not to mention the countless forum posts/mailing lists inquiries for the same issue) can we at the very least bump this to critical, and possibly get someone actually ASSIGNED to it?

I looked at /usr/share/initramfs-tools/hooks/udev and I think this is what happened in Boris' case: He did not have /etc/udev/rules.d/05-udev-early.rules for some reason (beyond me) and since the script sets -e, it just stops at the first error and will not continue copying other udev rules and the /lib/udev stuff.

The script should have:
- cp -p /etc/udev/rules.d/$rules ${DESTDIR}/etc/udev/rules.d
+ [ -e /etc/udev/rules.d/$rules ] && cp -p /etc/udev/rules.d/$rules ${DESTDIR}/etc/udev/rules.d

or the calling scripts should check return status properly.

I suspect that the problems in that I had setup two kernel "generic" and "server".
The process of "Processing triggers for initramfs-tools ..." generates "initramfs" only for "kernel-server", in this case.
You can'll see from the file named "apt-term.log" from http://launchpadlibrarian.net/12831435/dist-upgrade.tgz .

On previous occasions very little information.......

I'm a new user, who partitioned [160GB] and installed 8.04 AMD dual boot [w/XP] on Dell/Vostro machine (much fun).

Now, Ubuntu won't reboot and NONE of the Live CDs will either. GRUB is working fine (wherever that resides) so XP comes up.

Basically, initramfs "hangs", followed by repeated ATA0 ... errors. Others have many related stories out there. No need to circumvent kernel as others have done but appreciate any [tips or] new distribution of 8.04 to resolve.

I offer any details, if needed, to help expedite resolution.

Found Dell/Vostro machine w/Ubuntu login screen this AM.

I assume a power flicker led to reboot and initramfs loop eventually ended!

With this opportunity, I picked up 61 updates [10AM today] most installed, some errors noted. Checked again got 11 w/errs. Then got 33 more updates that installed cleanly requesting a re-boot. I could not!

FYI, Similar loop occurs.

Bob, if the live CD fails to boot, that's probably another issue so please report that in another bug report.

Yea, live CD does not boot (80/20 rule)! I do have the installed system working by booting recovery [check /etc/fstab and mtab].

Problem occurs on newer combined DVD/Hard drive "SATA controls" that can't determine what HDMA? speed [most times]. [not sure about technical details but this is the condition]

Reported elsewhere [dogpile search] to only happen on dual CPU processors (AKA Intel 2180). I suspect error occurs when different CPU handles 'setup' requests separately. initramfs 'looping' persists as speed is never negotiated [133, then 66, finally 33]. Slowing down the DVD drive on bootup (audio CD in drive) helps. Go figure.

Looks like there is an 'initramfs' update out there today, I'll put it on.

Does anyone have a handle on this? How can I help resolve? Is there some maintenance group I can communicate with?

Bob, as I said, please file a bug (or search to see if it's already filed) on "linux". That's a kernel issue and not related to this bug report.

As stated, I searched everywhere and find varying platform scenarios that experience this condition.

[Unless I'm missing something] this Bug 32123 is reported a kernel issue [linked to milestone ubuntu 6.06], someone felt it needs that level support. I'm new to Ubuntu, not systems.

The right group may be able to awaken some driver folks, single thread some 'stack' items, or otherwise resolve whatever the root cause to cripple boot up. This only happens on my fastest, newest PC. After research, lt's circumvented, so priority is now low to me. I only wanted to help and thought feedback channels [details] would be available.

I'm having the same issue with a Vostro 200. Weird thing is that it worked fine for a while (couple of weeks, occasional use) but now is completely hosed.

LiveCD won't boot (disk has fresh install of Vista - it's 160GB).

Alternate installer CD installs fine (to a different disk, complete erase-and-install) but then the boot fails in the same way.

But this *used* to work on this exact box. The disk I mention just above is the one that the original installation was on to!

This machine has no floppy, and I've disabled it in the BIOS. Is there anything else in BIOS that might be causing this?

On another forum, I found detail on a workaround <http://ubuntuforums.org/showthread.php?t=536850> near the end.

In grub, replace "quiet splash" with "all_generic_ide", and once the system is up, do likewise in /boot/grub/menu.lst

See that post for details if this is unfamiliar.

Yes, research shows this appears to be a chronic Dual CPU problem with Linux mis-handling initiation for various devices [media card readers, HDMA speed, DVD/hard disk controls, NICs]. Doubt BIOS has any effect.

I too had no trouble back in May with the 'live-cd' and eventually configured my 160G disk and installed 8.04, as described above (may 11). Since then it is hit or miss startup w/o a recovery boot. As suggested here, I searched Linux kernel issues and only 'live-cd' problem found [Bug 223656] was Intel Duo dealing with a NIC. I added comment to that. Bug 223656 seems to be handled by a Dell Kernel team. Maybe if you add a comment there too, we will hear something about this.

Ironically, I bought this new Dell specifically with XP to avoid Vista and setup dual boot Linux [AMD64].
Ubuntu [i386] runs fine on four other HPs and one Toshiba laptop.

This bug is, as the title "initramfs not generated correctly on dist-upgrade" says, about a broken initramfs when upgrading from a release to another, which is resolved by regenerating the initramfs. Please understand that if a live CD does not boot, it is off-topic and just adds confusion to this bug report. We have to deal with only one issue per report, also because once the issue here is solved, the bug will be closed and all your comments on other issues will be forgotten. Sorry if this sounds harsh, but the last 8 comments (9 including this) are off-topic and can only lead to more people posting me-too's on the wrong issues. And please don't apologize here or comment further, just file a new bug. For discussions, please use the forums. Thanks for your comprehension and your continued bug reporting.

Just for the record:
Here the solution seemed to be to remove all entries containing pata_via from /etc/modprobe.d/blacklist.local
I probably had added it before in response to bug 213639 (or for some other obscure reason), though I couldn't remember it anymore.

I noticed I could start the new kernel by entering "modprobe pata_via" from the busybox command line and then leaving it via Ctrl-D, you should maybe try if that works for you as well to find the true source of the problem on your machines. The pata_via is only relevant on mainboards with VIA chipsets, of course. If unsure, boot from the live cd and find your used modules either with "grep ata /proc/modules" or "lsmod | grep ata".

I don't know if I had the same bug (doesn't look like an iniramfs problem any more) but the symptoms were very very similar, so maybe someone else might have been suffering from the same problem.

Recent releases of Ubuntu have much better initramfs handling; I'm assuming this bug is fixed. If you encounter other bugs in current Ubuntu releases, please continue to file bug reports about them.