Description of problem: Installed FC6T3 from DVD, onto Intel SR2500 chassis with 6xSATA drives, anaconda found all drives OK, tried install with mdraid5 over all disks, boots from /boot but fails to find root, retried with LVM over all disks, also failed same thing. linux rescue can see and mount the LVM root, I've seen similar when testing dmraid on FC5T* which makes me think it is mkinitrd related. I haven't disected the initrd image yet, what should I look for? Version-Release number of selected component (if applicable): FC6T3 How reproducible: twice so far Steps to Reproduce: 1. boot from DVD 2. install to mdraid or lvm partition 3. reboot into new system Actual results: panic due to no root partition found
Forgot to mention this is a xen install I just went to look in /boot/initrd*.img and found there isn't one existing or specified in the grub.conf, is that correct? If so is that due to xen, or does fc6 not use an initrd now?
Same problem on a non-xen install. Kernel panic failing to find root (which is on LVM), linux rescue has no problem.
Running mkinitrd and adding that to the grub.conf made it work fine. I think this is an anaconda problem, not a mkinitrd problem.
Confirmed - looking at the boot partition, there is no initrd in the directory and no initrd line in grub.conf.
Can you attach the /root/install.log and /var/log/anaconda.log?
Created attachment 136372 [details] install.log
Created attachment 136373 [details] anaconda.log
Created attachment 136423 [details] /mnt/sysimage/root/install.log Partitions are untouched since the failed installation, booted from DVD in rescue mode, copied files to a usb memory stick, attached here ...
Created attachment 136424 [details] /mnt/sysimage/anaconda.log Do you need anaconda.syslog and install.log.syslog too?
Just had a dig through the log files, this chunk looks significant :-) Installing mkinitrd - 5.1.15-1.i386 Installing kernel-xen - 2.6.17-1.2630.fc6.x86_64 /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory no temporary directory could be found. mkinitrd failed error: %post(kernel-xen-2.6.17-1.2630.fc6.x86_64) scriptlet failed, exit status 1
Plain vanilla AMD x64 installing with FC6T3 64 DVD on to any SATA device seems to give me the same issue, failed to find root. Tried a variety of fixes but now agree with you the mkinitrd may be failing.
*** Bug 206679 has been marked as a duplicate of this bug. ***
Paul -- this looks like an ordering bug
*** Bug 206779 has been marked as a duplicate of this bug. ***
*** Bug 205194 has been marked as a duplicate of this bug. ***
*** Bug 206513 has been marked as a duplicate of this bug. ***
*** Bug 206980 has been marked as a duplicate of this bug. ***
*** Bug 207100 has been marked as a duplicate of this bug. ***
I got the same problem on my notebook. After installing via text-mode, because x-mode didn't work, I#m still missing the initrd. 64-Bit FC63-DVD sorry, but there's no ability to get any logs from the book to my desktop for attaching them here
*** Bug 207395 has been marked as a duplicate of this bug. ***
Would it be reasonable to mark this as an FC6 blocker? It will certainly prevent me installing FC6 on three servers (which I was also hoping to be able to do some xen testing on before FC6 release)
*** Bug 207423 has been marked as a duplicate of this bug. ***
Trying to replicate here and the order is correct: D: 533 7 1 -1 3 25 +MAKEDEV-3.23-1.2.x86_64 D: 534 10 11 -1 4 123 +udev-095-8.x86_64 D: 535 17 15 -1 5 95 +hal-0.5.7.1-3.fc6.x86_64 D: 536 18 15 -1 5 96 +hal-0.5.7.1-3.fc6.i386 D: 537 9 5 -1 6 81 +kudzu-1.2.53-1.x86_64 D: 538 22 2 -1 5 97 +mkinitrd-5.1.15-1.x86_64 D: 539 5 2 -1 6 82 +kernel-2.6.17-1.2630.fc6.x86_64 Is everyone using DVD/iso installs or are people reproducing on nfs/http too?
FWIW, my system used a hard drive install with the DVD iso (AMD64, dualcore, SATA)
(In reply to comment #23) > Trying to replicate here and the order is correct: was that an actual FC6T3 install, or a later rawhide?
(In reply to comment #23) > Trying to replicate here and the order is correct: was that an actual FC6T3 install, or a later rawhide? My install was from a full ISO
I was testing FC6T3 NFS install.
----- Additional Comments From robbiew.com 2006-09-22 09:10 EDT ------- We installed FC6T3 via NFS on a PPC64 machine.
----- Additional Comments From robbiew.com 2006-09-22 09:17 EDT ------- To be clear, the PPC64 install via NFS failed for us.
I've created an updates.img to give me more information on what is occuring as I can't reproduce on my machine I'd be greatful if you could do an install with it as detailed below then attach the /root/install.log to this report. 1) Grab http://people.redhat.com/pnasrat/206453-updates.img Take the updates.img and use dd to write it to a USB key, then use that with "linux updates" at the bootloader prompt. You will need to dd it to the entire USB device, so make sure you backup whatever may be on the USB drive first. As root, ensure the device is seen by the OS but not mounted. dd if=206453-updates.img of=/dev/sda Replace /dev/sda with the name of your USB key drive.
I've dd'ed the updates.img file to an 8MB SD card, that is inserted in a SanDisk Cruzer. Machine booted from DVD with "linux updates", kernel recognises 6x SATA as sda/b/c/d/e/f and cruzer as sdg anaconda starts and gives option of using hdb/sda/b/c/d/e/f for updates, but doesn't give option of sdg, (hdb is the ide DVD drive) Switching to console2 there is no /dev/sd*, and no block device entry in /tmp for sdg. I'm not familiar with using updates disks, any clues?
Ok, I found some jiggery-pokery was required (when anaconda detected hdb and sda-f I had to select one of those devices and then let it fail to see updates on that device, after which it splurged some cyrillic text on screen and refreshed the device list and sdg was then available, so I chose that and it happily saw the updates disk) I then choose to install removing all partitions and anaconda crashed while removing old partitions, so I manually removed all partitions by hand with fdisk, rebooted and tried a clean install, it dies again in "autopart.py line 879 in deletePart/doPartitioning/doClearPartAction" Can't see that it would affect this, but just for the record I am booting using "linux text updates" as xorg has issues with the VGA card in these machines.
I found the same issue with grub.conf/ menu.lst and initrd.img file are not created in x86_64 SMP install on Intel AM64T dual core complient servers. When booting the server after a seemingly perfect install: 1. The grub splash screen comes up. 2. Press enter to select the kernel and boot. 3. Instead of booting a screen error appears: config file (hd0,13)/boot/grub/menu.lst Error 15: File not found Press any key to continue..... Please get this fixed so mkintrd runs during the x86_64 install process.
I wrote the update image to a USB stick as instructed, but the update image doesn't quite seem to work as I'd expect. I booted with "linux updates", and anaconda asked me where the updates are located (fd0, hda, sda, sdb) -- sdb is my USB disk so I chose it. The installation continued happily, but after language and keyboard choices it said "Error mounting file system on sdb1: No such device or address". I tried to rearrange the image so that it'd have a proper ext2 partition on the USB disk and copied the included yuminstall.py script on that partition. However, anaconda didn't accept the USB stick as a valid update source when configured that way. I wonder if it'd work when written to an old-fashioned 3.5" floppy, unfortunately I don't have any here at home at the moment..
Created attachment 136991 [details] /root/install.log OK, I tried again with a slightly different hardware setup, same machine, but 1x SATA instead of 6x SATA, and USB floppy with updates.img instead of SD in USB card reader. After booting from DVD, kernel recognised SATA as sda, floppy as sdb and dvd as hdb, anaconda started and offered to load updates from sda or hdb, I chose sda to force it to fail, then let it splurge the screen and refresh devices to make sdb available, then choose sdb, it loaded updates and managed to get past partitioning this time (possibly less confusion with SATA sda-f plus USB as sdg?) Machine then performed an install, which I confirmed still didn't have an initrd, I've attached the /root/install.log here
OK, some edited highlights and thoughts from the log file D: Requires: mkinitrd YES (added provide) D: Requires: mkinitrd YES (added provide) D: Requires: mkinitrd >= 4.2.21-1 YES (added provide) D: Requires: mkinitrd >= 4.2.21-1 YES (added provide) D: 459 7 1 -1 2 15 +MAKEDEV-3.23-1.2.x86_64 D: 460 10 7 -1 3 11 +udev-095-8.x86_64 D: 461 20 11 -1 4 107 +hal-0.5.7.1-3.fc6.x86_64 D: 462 15 5 -1 4 108 +hal-0.5.7.1-3.fc6.i386 D: 463 21 2 -1 4 109 +mkinitrd-5.1.15-1.i386 D: 464 5 1 -1 5 60 +kernel-xen-2.6.17-1.2630.fc6.x86_64 D: 465 9 1 -1 5 61 +kudzu-1.2.53-1.x86_64 D: 466 5 1 -1 4 110 +which-2.16-7.x86_64 D: 467 3 2 -1 5 62 +htmlview-3.0.0-14.1.noarch should that mkinitrd package be x86_64 instead of, or as well as, i386? D: 472 7 0 -1 3 13 +sudo-1.6.8p12-8.x86_64 D: 473 6 0 -1 6 81 +pinfo-0.6.8-11.2.2.x86_64 D: 474 11 0 -1 6 82 +system-config-services-0.9.0-2.noarch D: 475 9 0 -1 6 83 +system-config-network-tui-1.3.94-1.noarch D: 476 4 0 -1 6 84 +pcmciautils-014-5.x86_64 D: 477 4 0 -1 5 63 +mkbootdisk-1.5.3-2.1.x86_64 D: 478 20 0 -1 5 64 +NetworkManager-0.6.4-5.fc6.x86_64 D: 479 9 0 -1 5 65 +smartmontools-5.36-3.x86_64 D: 480 22 0 -1 4 112 +mkinitrd-5.1.15-1.x86_64 Looks like sudo pulls in the 64bit version Installing lockdev - 1.0.1-10.x86_64 Installing MAKEDEV - 3.23-1.2.x86_64 Installing udev - 095-8.x86_64 Installing hal - 0.5.7.1-3.fc6.x86_64 Installing hal - 0.5.7.1-3.fc6.i386 Installing mkinitrd - 5.1.15-1.i386 Installing kernel-xen - 2.6.17-1.2630.fc6.x86_64 /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory no temporary directory could be found. mkinitrd failed This is the same error as I was getting before Installing kudzu - 1.2.53-1.x86_64 Installing which - 2.16-7.x86_64 Installing htmlview - 3.0.0-14.1.noarch Installing vim-minimal - 2:7.0.086-1.x86_64 Installing logrotate - 3.7.4-5.x86_64 Installing ppp - 2.4.4-1.x86_64 Installing rp-pppoe - 3.5-32.1.x86_64 Installing sudo - 1.6.8p12-8.x86_64 Installing pinfo - 0.6.8-11.2.2.x86_64 Installing system-config-services - 0.9.0-2.noarch Installing system-config-network-tui - 1.3.94-1.noarch Installing pcmciautils - 014-5.x86_64 Installing mkbootdisk - 1.5.3-2.1.x86_64 Installing NetworkManager - 1:0.6.4-5.fc6.x86_64 Installing smartmontools - 1:5.36-3.x86_64 Installing mkinitrd - 5.1.15-1.x86_64 The 64bit version gets installed after the 32bit version has failed to run
Yes as we skip putting down the binary (on an installed system do rpm -q -s mkinitrd.i386 shows the wrong color). Thanks for the log I'll see if I can see what's different between the ordering for your system and mine.
Created attachment 136994 [details] Working install log A copy of the working log with ordering info
Created attachment 136996 [details] install.log with some debugging enabled I wrote the update image to a floppy and installed a very basic FC6t3 x86_64 setup from a DVD. It still complains about /sbin/nash.
I have the same problem with mkinitrd. Even a minimal install (base package only) of FC6T3 x86_64 from DVD produces the error seen above. This is on VMware Server 1.0.1 configuration "other linux kernel 2.6 64bit". VMware is running on a Pentium D 940 processor. /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory /sbin/mkinitrd: line 282: /sbin/nash: No such file or directory If I install the i386 version the error is no longer there and everything works.
(In reply to comment #38) > A copy of the working log with ordering info yes, strangely on your working install the udev dependency give you the x86_64 version of mkinitrd, sudo then goes on to require the i386 version, whereas on mine udev incorrectly requires i386 and sudo requires x86_64 ...
*** Bug 207462 has been marked as a duplicate of this bug. ***
*** Bug 207837 has been marked as a duplicate of this bug. ***
----- Additional Comments From gerhard.stenzel.com 2006-09-25 07:25 EDT ------- I tried with the latest development tree and the install and boot succeeded. I then added the 206453-updates.img to the FC6 test 3 (I use HTTP install) and re-installed. Same problem as before. Hardware is a QS20 (Cell).
Same failure here: FC6t3 x86_64 ISO install w/ default package selection on a Presario V5210US Instructions to salvage your newly installed FC6t3: Boot up on your (first) disk. boot: linux rescue Proceed through steps that lead you to a console. $ chroot /mnt/sysimage $ mkinitrd /boot/initrd-$(uname -r).img $(uname -r) $ echo " initrd /initrd-$(uname -r).img" >> /boot/grub/grub.conf (NOTE: If you have more than one boot entry, edit grub.conf and move the initrd line to the end of the correct entry.) $ reboot
Oh yes, I appreciate that it can be fixed up by hand, but my concern is more that it doesn't need to be fixed up, if rawhide currently installs properly I'd like the difference to be understood so it doesn't regress, bugs that go away by themselves, come back by themselves ;-)
(In reply to comment #45) > $ chroot /mnt/sysimage > $ mkinitrd /boot/initrd-$(uname -r).img $(uname -r) > $ echo " initrd /initrd-$(uname -r).img" >> /boot/grub/grub.conf Confirming that rebuilding the initrd image such is a post-install fix. While this fix shouldn't be needed in the first place, at least it allows testers to go ahead and test the rest of the distro.
*** Bug 206991 has been marked as a duplicate of this bug. ***
*** Bug 205347 has been marked as a duplicate of this bug. ***
You'll be happy to know that the x86_64 prerelease FC6 DVD installed just fine and booted up OK - no missing initrd this time.
Yes, we did a big of a hack to mkinitrd so that the problem "can't" happen... I'm still somewhat interested at looking into the root cause, hence leaving this open for now.
----- Additional Comments From thinh.com (prefers email at th2tran.com) 2006-10-12 13:49 EDT ------- We download ppc64 (Test4) Pre-release DVD image from bittorrent, Set up for network (nfs) install. It installs fine on ppc64 and also on a G5. No initrd and LVM issues. Thanks. DVD install on G5 has problem in setting up the network interface, static or DHCP IP address. So I did "linux askmethod" and use nfs install. Regards, Thinh Tran
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer test releases. We're cleaning up the bug database and making sure important bug reports filed against these test releases don't get lost. It would be helpful if you could test this issue with a released version of Fedora or with the latest development / test release. Thanks for your help and for your patience. [This is a bulk message for all open FC5/FC6 test release bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
This can still be a problem
User pnasrat's account has been closed
Panu -- did we get the change into rpm so that multilib packages are ordered together?
Yes and no :) Not grouped together, but rpm 4.4.2.2(-rcX) orders multilib packages so that the preferred color (whose files will actually end up on disk) gets installed first so these "file not found" issues from scriptlets shouldn't happen anymore.
Probably good enough :)
Any suggestions on how to confirm this fix? I'd like to be able to close this for F8.
As the original reporter of this bug back in FC6 time, I can confirm that F7 installed on the same servers (with xen) without hitting the issue. Whether any issue is still lurking under the surface to catch the unwary is not for me to say.
Closing as fixed. I'd still like to get a good test case to ensure that this thing never comes back. Panu or Jeremy, if you can help with that I'd appreciate it.