Bug 206453 (nash-ordering) - multilib ordering problems
Summary: multilib ordering problems
Keywords:
Status: CLOSED RAWHIDE
Alias: nash-ordering
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 205194 205347 206513 206679 206779 206980 206991 207100 207395 207423 207462 207837 (view as bug list)
Depends On:
Blocks: 207282 F8Blocker
TreeView+ depends on / blocked
 
Reported: 2006-09-14 14:30 UTC by Andy Burns
Modified: 2007-11-30 22:11 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-24 15:40:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
install.log (43.84 KB, text/plain)
2006-09-15 16:30 UTC, Trond Eivind Glomsrød
no flags Details
anaconda.log (178.85 KB, text/plain)
2006-09-15 16:31 UTC, Trond Eivind Glomsrød
no flags Details
/mnt/sysimage/root/install.log (72.81 KB, text/plain)
2006-09-16 12:05 UTC, Andy Burns
no flags Details
/mnt/sysimage/anaconda.log (274.37 KB, text/plain)
2006-09-16 12:07 UTC, Andy Burns
no flags Details
/root/install.log (6.67 MB, text/plain)
2006-09-23 07:57 UTC, Andy Burns
no flags Details
Working install log (1.58 MB, text/plain)
2006-09-23 10:11 UTC, Paul Nasrat
no flags Details
install.log with some debugging enabled (456.35 KB, text/plain)
2006-09-23 10:34 UTC, Anssi Johansson
no flags Details

Description Andy Burns 2006-09-14 14:30:17 UTC
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

Comment 1 Andy Burns 2006-09-14 14:39:01 UTC
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?



Comment 2 John Thacker 2006-09-15 03:55:41 UTC
Same problem on a non-xen install.  Kernel panic failing to find root (which is
on LVM), linux rescue has no problem.

Comment 3 John Thacker 2006-09-15 04:02:34 UTC
Running mkinitrd and adding that to the grub.conf made it work fine.  I think
this is an anaconda problem, not a mkinitrd problem.

Comment 4 Trond Eivind Glomsrød 2006-09-15 06:20:53 UTC
Confirmed - looking at the boot partition, there is no initrd in the directory
and no initrd line in grub.conf.

Comment 5 Jeremy Katz 2006-09-15 10:19:13 UTC
Can you attach the /root/install.log and /var/log/anaconda.log?

Comment 6 Trond Eivind Glomsrød 2006-09-15 16:30:04 UTC
Created attachment 136372 [details]
install.log

Comment 7 Trond Eivind Glomsrød 2006-09-15 16:31:33 UTC
Created attachment 136373 [details]
anaconda.log

Comment 8 Andy Burns 2006-09-16 12:05:24 UTC
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 ...

Comment 9 Andy Burns 2006-09-16 12:07:31 UTC
Created attachment 136424 [details]
/mnt/sysimage/anaconda.log

Do you need anaconda.syslog and install.log.syslog too?

Comment 10 Andy Burns 2006-09-16 12:13:07 UTC
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


Comment 11 Justin Farrelly 2006-09-16 18:11:48 UTC
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.

Comment 12 John Thacker 2006-09-18 13:48:46 UTC
*** Bug 206679 has been marked as a duplicate of this bug. ***

Comment 13 Jeremy Katz 2006-09-18 17:45:12 UTC
Paul -- this looks like an ordering bug 

Comment 14 Jeremy Katz 2006-09-18 17:55:04 UTC
*** Bug 206779 has been marked as a duplicate of this bug. ***

Comment 15 Peter Jones 2006-09-20 15:18:55 UTC
*** Bug 205194 has been marked as a duplicate of this bug. ***

Comment 16 Peter Jones 2006-09-20 15:19:58 UTC
*** Bug 206513 has been marked as a duplicate of this bug. ***

Comment 17 Jeremy Katz 2006-09-20 16:05:58 UTC
*** Bug 206980 has been marked as a duplicate of this bug. ***

Comment 18 Jeremy Katz 2006-09-20 17:11:37 UTC
*** Bug 207100 has been marked as a duplicate of this bug. ***

Comment 19 Daniel Bunte 2006-09-20 18:21:17 UTC
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

Comment 20 Jeremy Katz 2006-09-20 22:24:18 UTC
*** Bug 207395 has been marked as a duplicate of this bug. ***

Comment 21 Andy Burns 2006-09-21 06:58:55 UTC
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)

Comment 22 Jeremy Katz 2006-09-21 15:44:56 UTC
*** Bug 207423 has been marked as a duplicate of this bug. ***

Comment 23 Paul Nasrat 2006-09-22 08:34:06 UTC
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?

Comment 24 Trond Eivind Glomsrød 2006-09-22 08:59:10 UTC
FWIW, my system used a hard drive install with the DVD iso (AMD64, dualcore, SATA)

Comment 25 Andy Burns 2006-09-22 12:30:14 UTC
(In reply to comment #23)

> Trying to replicate here and the order is correct:

was that an actual FC6T3 install, or a later rawhide?

Comment 26 Andy Burns 2006-09-22 12:31:22 UTC
(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 

Comment 27 Paul Nasrat 2006-09-22 13:08:39 UTC
I was testing FC6T3 NFS install.

Comment 28 IBM Bug Proxy 2006-09-22 13:15:51 UTC
----- Additional Comments From robbiew.com  2006-09-22 09:10 EDT -------
We installed FC6T3 via NFS on a PPC64 machine. 

Comment 29 IBM Bug Proxy 2006-09-22 13:21:30 UTC
----- Additional Comments From robbiew.com  2006-09-22 09:17 EDT -------
To be clear, the PPC64 install via NFS failed for us. 

Comment 30 Paul Nasrat 2006-09-22 13:52:40 UTC
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.

Comment 31 Andy Burns 2006-09-22 16:31:56 UTC
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?



Comment 32 Andy Burns 2006-09-22 17:37:55 UTC
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.

Comment 33 Michael DeGon 2006-09-22 23:38:35 UTC
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. 


Comment 34 Anssi Johansson 2006-09-23 00:08:09 UTC
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..

Comment 35 Andy Burns 2006-09-23 07:57:53 UTC
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

Comment 36 Andy Burns 2006-09-23 08:13:37 UTC
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


Comment 37 Paul Nasrat 2006-09-23 09:40:53 UTC
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.

Comment 38 Paul Nasrat 2006-09-23 10:11:09 UTC
Created attachment 136994 [details]
Working install log

A copy of the working log with ordering info

Comment 39 Anssi Johansson 2006-09-23 10:34:56 UTC
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.

Comment 40 Ryan Wagoner 2006-09-23 14:49:59 UTC
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.

Comment 41 Andy Burns 2006-09-23 19:46:15 UTC
(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 ...



Comment 42 Yao Qi 2006-09-25 03:10:29 UTC
*** Bug 207462 has been marked as a duplicate of this bug. ***

Comment 43 Jeremy Katz 2006-09-25 15:28:34 UTC
*** Bug 207837 has been marked as a duplicate of this bug. ***

Comment 44 IBM Bug Proxy 2006-09-25 15:48:31 UTC
----- 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). 

Comment 45 Chris Shoemaker 2006-09-26 03:10:10 UTC
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


Comment 46 Andy Burns 2006-09-26 06:07:39 UTC
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 ;-)

Comment 47 Saikat Guha 2006-09-26 19:05:24 UTC
(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.

Comment 48 Will Woods 2006-09-27 18:47:53 UTC
*** Bug 206991 has been marked as a duplicate of this bug. ***

Comment 49 Will Woods 2006-09-28 21:58:03 UTC
*** Bug 205347 has been marked as a duplicate of this bug. ***

Comment 50 Tom Horsley 2006-09-30 23:52:15 UTC
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.


Comment 51 Jeremy Katz 2006-10-01 22:33:03 UTC
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.

Comment 54 IBM Bug Proxy 2006-10-12 17:51:27 UTC
----- 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 

Comment 55 Matthew Miller 2007-04-06 17:58:01 UTC
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.]


Comment 56 Jeremy Katz 2007-04-17 23:06:42 UTC
This can still be a problem

Comment 58 Red Hat Bugzilla 2007-08-21 05:26:16 UTC
User pnasrat's account has been closed

Comment 59 Jeremy Katz 2007-09-10 14:53:07 UTC
Panu -- did we get the change into rpm so that multilib packages are ordered
together?

Comment 60 Panu Matilainen 2007-09-11 04:51:27 UTC
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.


Comment 61 Jeremy Katz 2007-09-11 12:54:26 UTC
Probably good enough :)

Comment 62 Will Woods 2007-10-17 19:38:33 UTC
Any suggestions on how to confirm this fix? I'd like to be able to close this
for F8.

Comment 63 Andy Burns 2007-10-17 19:47:55 UTC
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.

Comment 64 Will Woods 2007-10-24 15:40:03 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.