Bug 474399

This may be related: just before anaconda shows the list of available disks, VC1 displays the message:
ERROR: only one argument allowed for this option

perhaps a command used to probe the raid bios fails because it gets the wrong arguments?

Yet another piece of information: that error message is from dmraid (or dmsetup?).
What now seems to work, is to leave the raid disks alone during installation, and afterwards, use dmraid -ay and mount the disk (eg from /etc/rc.local).
Also, fsck seems ok, when specifically asked to check the devicemapper device, eg. fsck -Cy /dev/mapper/isw_bibcgjfjbe_Volume0p1
A command like fsck /data2 (reference by label) is NOT ok, because the system sees a partition with label /data2 on both /dev/sdb and on /dev/sdc, and once a check on such a member disk is performed, the data seems to be messed up.

Anaconda *should* discover the isw RAID set on /dev/sd[bc].
Changing component to get Anaconda team involved.

I would think that this would be a higher priority as can not install on RAID mainboards ?
Anyone know a workaround maybe with boot options that can force Anaconda to see the mainboard RAID drives ?
Guess have to go back to using FC9 for a while and upgrade later.

(In reply to comment #4)
> I would think that this would be a higher priority as can not install on RAID
> mainboards ?
> Anyone know a workaround maybe with boot options that can force Anaconda to see
> the mainboard RAID drives ?
> Guess have to go back to using FC9 for a while and upgrade later.

Comment 4 was describing problem with FC 10 not 9 commented here by mistake was lead to this bugzilla from another post discussing version 10 problems.
Version 9 sees mainboard RAID correctly but version 10 will not on several machines

(In reply to comment #5)
> (In reply to comment #4)
> > I would think that this would be a higher priority as can not install on RAID
> > mainboards ?
> > Anyone know a workaround maybe with boot options that can force Anaconda to see
> > the mainboard RAID drives ?
> > Guess have to go back to using FC9 for a while and upgrade later.
> 
> Comment 4 was describing problem with FC 10 not 9 commented here by mistake was
> lead to this bugzilla from another post discussing version 10 problems.
> Version 9 sees mainboard RAID correctly but version 10 will not on several
> machines
Well, just can not get right, bugzilla says version 9, but main post was indeed about version 10 so guess I am in the right place

My original problem was Fedora 10. So perhaps I made the wrong choice when I entered the bug report. I'll see if I can correct that, and the severity as well.

As for my workarounds in comment #2 (which can only be used when / and /usr are not on theh RAID volume of course), does anyone know of a better way to add the RAID volume after installation? What configuration files need to be tweaked to make the system see the dmraid volume on boot, in stead of running dmraid -ay and mounting the volume later? Fixing this would already be a good help, since then the volume could be included in /etc/fstab, with file system checks at the right moment, etc. 
The best thing would of course be if the bug in anaconda and/or the devicemapper tools was found and corrected.

My computer also has a hardware RAID (driven by the '3w-xxxx' kernel module), and it, too, cannot boot Fedora 10 for the reasons described, above.  Fedora 8 and 9 have run on it without these problems (along with Fedoras back to Fedora Core 2).  The CPU is the x86_64 architecture.  I have attempted both an F10 installation from scratch and an F9 installation followed by running 'preupgrade' to install "in place."  Neither approach has worked.

There are a number of 'modprobe' commands included in the 'init' script that is included in the Fedora 9 'initrd' that are not included in the 'init' script that is included in the Fedora 10 'initrd'.  These commands are listed below:

Fedora 9 'init':  (line numbers included to provide context)

    39  echo Creating block device nodes.
    40  mkblkdevs
    41  echo "Loading ehci-hcd module"
    42  modprobe -q ehci-hcd
    43  echo "Loading ohci-hcd module"
    44  modprobe -q ohci-hcd
    45  echo "Loading uhci-hcd module"
    46  modprobe -q uhci-hcd
    47  mount -t usbfs /proc/bus/usb /proc/bus/usb
    48  echo "Loading ext3 module"
    49  modprobe -q ext3
    50  echo "Loading scsi_mod module"
    51  modprobe -q scsi_mod
    52  echo "Loading sd_mod module"
    53  modprobe -q sd_mod
    54  echo "Loading 3w-xxxx module"
    55  modprobe -q 3w-xxxx
    56  echo "Loading shpchp module"
    57  modprobe -q shpchp
    58  echo "Loading dm-mod module"
    59  modprobe -q dm-mod
    60  echo "Loading dm-mirror module"
    61  modprobe -q dm-mirror
    62  echo "Loading dm-zero module"
    63  modprobe -q dm-zero
    64  echo "Loading dm-snapshot module"
    65  modprobe -q dm-snapshot
    66  echo Making device-mapper control node
    67  mkdmnod

Fedora 10 'init':

    43  echo Creating block device nodes.
    44  mkblkdevs
    45  echo Creating character device nodes.
    46  mkchardevs
    47  echo Making device-mapper control node
    48  mkdmnod

(Similarly, the kernel modules that are probed for are included in the Fedora 9 'initrd', but are missing from the Fedora 10 'initrd'.)

In the Fedora 9 'init', there is a 'modprobe' command and a 'rmmod' command between 'mkdmnod' and 'mkblkdevs' that is absent from Fedora 10's 'init':

Fedora 9:

    66  echo Making device-mapper control node
    67  mkdmnod
    68  modprobe scsi_wait_scan
    69  rmmod scsi_wait_scan
    70  mkblkdevs
    71  echo Scanning logical volumes
    72  lvm vgscan --ignorelockingfailure

Fedora 10:

    47  echo Making device-mapper control node
    48  mkdmnod
    49  mkblkdevs
    50  echo Scanning logical volumes
    51  lvm vgscan --ignorelockingfailure

Are these missing 'modprobe' and 'rmmod' commands intentional in Fedora 10?  That is, have their functions been replaced or superceded by some other program?

Fedora 9 'initrd': initrd-2.6.25-14.fc9.x86_64.img
Fedora 10 'initrd': initrd-2.6.27.5-117.fc10.x86_64.img

most mainboard raid uses the dm raid driver so that must be the problem, not detecting because it is not probing for it !
Great work.
would be great if someone could create an ISO with those added back in and see if the install works then.

Many of the kernel modules that are available in Fedora 9 are not
available with either kernel released so far in Fedora 10.

MISSING: Here is a list of the kernel modules that are missing from Fedora 10,
but which are available and probed for in Fedora 9 on my computer, as
listed in Comment #8, above.

1.  ehci-hcd.ko
2.  ohci-hcd.ko
3.  uhci-hcd.ko
4.  ext3.ko
5.  scsi_mod.ko
6.  sd_mod.ko
7.  dm-mod.ko
8.  dm-mirror.ko
9.  dm-zero.ko
10. dm-snapshot.ko

AVAILABLE: The following kernel modules are probed for on my computer
by Fedora 9, and are available on Fedora 10:

1. 3w-xxxx.ko
2. shpchp.ko

Have the missing kernel modules been omitted intentionally?  If so,
what modules replace them?

(In reply to comment #9)
> most mainboard raid uses the dm raid driver so that must be the problem, not
> detecting because it is not probing for it !
> Great work.
> would be great if someone could create an ISO with those added back in and see
> if the install works then.

Would you please provide more specific information about the "dm raid driver?"

Here are the contents of the 'md' directory.  Are you referring to one or more of these kernel modules?

/lib/modules/2.6.27.5-117.fc10.x86_64/kernel/drivers/md/

dm-crypt.ko      dm-round-robin.ko  linear.ko     raid0.ko   raid1.ko
dm-multipath.ko  faulty.ko          multipath.ko  raid10.ko  raid456.ko

(In reply to comment #8)
> My computer also has a hardware RAID (driven by the '3w-xxxx' kernel module),
> and it, too, cannot boot Fedora 10 for the reasons described, above.
>

...
 
> In the Fedora 9 'init', there is a 'modprobe' command and a 'rmmod' command
> between 'mkdmnod' and 'mkblkdevs' that is absent from Fedora 10's 'init':
> 
> Fedora 9:
> 
>     66  echo Making device-mapper control node
>     67  mkdmnod
>     68  modprobe scsi_wait_scan
>     69  rmmod scsi_wait_scan
>     70  mkblkdevs
>     71  echo Scanning logical volumes
>     72  lvm vgscan --ignorelockingfailure
> 

Success.  The newly-release 'mkinitrd' and 'nash' have provided a fix that corrects the problem listed, above.  I would like to thank Hans de Goede for providing this fix.

$ rpm -q --changelog mkinitrd
* Mon Dec 08 2008 Hans de Goede <hdegoede> - 6.0.71-3
- Use scsi_wait_scan on scsi devices instead of stabilized (#470628)

Here, in brief, are the steps I took to make Fedora 10 boot on my computer:

1. Install Fedora 10 from the x86_64 DVD.

2. Reboot, selecting the Rescue mode from the DVD's menu.

3. Allow NetManager to create a network connection.

4. Mount the filesystem using "chroot /mnt/sysimage".

5. Update 'mkinitrd' and 'nash' via 'yum': # yum update mkinitrd nash

6. Run the commands described in https://admin.fedoraproject.org/updates/FEDORA-2008-11149, namely,
     # mv  /boot/initrd-$(uname -r).img   /boot/initrd-$(uname -r).img.old
     # mkinitrd  /boot/initrd-$(uname -r).img   $(uname -r)

7. Reboot.  The new 'initrd' now recognizes my hardware RAID as /dev/sda, and Fedora 10 boots without error.

I have the same problem, but with two SATA disks in RAID1 (motherboard hardware) as the whole system. I cannot do step 1 in Comment #12 as I get the 'Multiple devices on your system are labeled /boot..' and in rescue mode, only some of the directories are visible.

I probably need a respin of the Fedora 10 x86_64 install disk, with the missing kernel modules present.

Let me know when this is available.

(In reply to comment #13)
> I have the same problem, but with two SATA disks in RAID1 (motherboard
> hardware) as the whole system. I cannot do step 1 in Comment #12 as I get the
> 'Multiple devices on your system are labeled /boot..' and in rescue mode, only
> some of the directories are visible.
> 

Something you might try is to re-install Fedora 10 from scratch, but be sure to have a working network connection.  If you do, then on the screen that lets you select the repositories, you can select the "update" repositories, also.  With this selected, Fedora will download all latest upgrades to the packages that you have selected (for example "Office/Productivity"), including the new version of mkinitrd.  I have not tried this myself.  It would be good to know whether this will work to fix the problem.

The fly in this procedure is the 'loading from scratch'. I have about 200GB on this RAID pair and I have already backed up the necessary stuff, investing about a day in the process (computer time, not mine).

The problem of necessary updates, or missing pieces is a continuing feature of Fedora transitions. FC7 and FC8 also had anaconda/RAID problems. I skipped FC9 after a day of anaconda agony.

There seems to be a policy of sticking with whatever golden DVD was produced on the day it was released, with no way to incorporate solutions to problems developed after the release day. I would like to see this policy changed.

Also, referring to Comment #14, because of the conflict between FC10 install and my hardware RAID, I don't even get to the point where I might 'load from scratch'.

(In reply to comment #15)
> The fly in this procedure is the 'loading from scratch'. I have about 200GB on
> this RAID pair and I have already backed up the necessary stuff, investing
> about a day in the process (computer time, not mine).
> 

On January 7, the Fedora Unity Project announced the first Fedora 10 re-spin, which should have the necessary fixes (I have not tried it).  See here:

   http://spins.fedoraunity.org/spins

Or, possibly, more specifically, here:

   http://spins.fedoraunity.org/unity/fedora-10-everything-spin/fedora-10-everything-torrents

My guess was that the unity re-spin would have taken longer than my original suggestion because the re-spin is a larger download.

(In reply to comment #15)
>...
> There seems to be a policy of sticking with whatever golden DVD was produced on
> the day it was released, with no way to incorporate solutions to problems
> developed after the release day. I would like to see this policy changed.

I think that I was mistaken in my previous comment (Comment #17).  The re-spin that was announced by the Fedora Unity Project was for Fedora 9, not Fedora 10.  A Fedora Unity re-spin for Fedora 10 is likely what you are requesting in Comment #15.  The Fedora Unity re-spins are periodic (irregular) releases that are announced between major releases.  They incorporate all fixes that have been created up to a given point in time so that new users do not have to download the "golden" DVD plus all fixes that have been generated up to that time.  See http://spins.fedoraunity.org/.

Unfortunately, this does not help you with your problem until a Fedora Unity re-spin is announced for Fedora 10.

Downloading 'yum update' fixes is not my problem. This can happen while the machine is doing other useful work. This is a normal part of the lifetime of most modern operating systems.

My problem is just getting the install DVD to boot. It appears that to do this, a respin is necessary. My problem (and others with hardware RAID) happens in the first few milliseconds of the 'Big Bang'. This is well before the time when 'yum update' revisions are useful.

I just need a bootable DVD which contains the essentials necessary to support life in the first few seconds. Once this level of intelligence has been achieved, 'yum update' can give me civilization.

Change last word of paragraph 2 of Comment #19 from 'useful' to 'possible'.

It might be reasonable to decouple the boot part of a release from the mass of packages. The boot part could be a CD rather than a DVD.

A typical re-spin is just used to provide updated packages so that folks without high speed internet connections can have more recent packages. This is a worthwhile idea, but keep in mind that this re-spun disk image must also be downloaded. And, a day after it is created, it is out of date. Faced with the decision to download a re-spun image or do a 'yum update', I would do the yum update.

The boot part of a new release could have a well tested mkinitrd and well tested RAID disk components. Maybe even a streamlined PXE boot and/or a flash drive install. Plus the clue sheets to tell yum that this is a FC11 release and not just FC10 (for example). Once this boot skeleton is in place, 'yum update' can take over and provide the improved packages that match the new release version.

The icing on this cake is to use the initially downloaded (separate?) release DVD as an additional repository for yum. Packages that have not been updated since the release DVD was cut would be installed from the DVD. Updated packages would be taken from the on-line repositories. This would optimize the tradeoff between bandwidth used and vintage of the packages.

Relative to Comment #10, I have successfully installed FC10 on two i386 systems which have software RAID scsi disks.

These installs went smoothly after keying in the scsi_mod.scan=sync kernel option and cleaning out all disk labels and UUIDs from the grub.conf and fstab.

Hardware RAID seems to be a different problem.

I've managed to reproduce and I believe fix this using a system with isw raid. I've provided updates.img files for this here;
http://people.atrpms.net/~hdegoede/updates474399-i386.img
http://people.atrpms.net/~hdegoede/updates474399-x86_64.img

To use this with an i386 install using isw "hardware" raid type the following at the installer bootscreen (press <tab> to get to the cmdline editor):
updates=http://people.atrpms.net/~hdegoede/updates474399-i386.img

For an x86_64 install use:
updates=http://people.atrpms.net/~hdegoede/updates474399-i386.img

Please let me know if this resolves the issue for you.

Sounds good, will try.

One question though - the URL is the same for both i386 and x86_64. Is this intentional?

Whoops:

I'm looking at the bottom link in your post. I should probably look further up the page where you have http://people.atrpms.net/~hdegoede/updates474399-x86_64.img

Will try

Doesn´t look good.

I booted up from the x86_64 FC10 DVD and hit tab. It broke in at the point where the questions about install or update, rescue, boot from local, etc.

The line looked like:

> linux = vmlinuz ..    (something like this - I don´t have this screen now

I backspaced back to the > and then put in the updates=http://... line

After the ´enter´, it went into the install/update line (I did not select it though).

Then normal through the questions about Language and Keyboard, then it asked whether I wanted an install or upgrade. I selected upgrade, and the path to root appeared (correctly) in the popup button.

I hit Next and then the install failed with a message about too many /boot labels.

======

I wonder whether the system knows enough to access the http file? I did not get to the screens asking for IP address, gateway, dns...

(In reply to comment #26)
> Doesn´t look good.
> 
> I booted up from the x86_64 FC10 DVD and hit tab. It broke in at the point
> where the questions about install or update, rescue, boot from local, etc.
> 
> The line looked like:
> 
> > linux = vmlinuz ..    (something like this - I don´t have this screen now
> 
> I backspaced back to the > and then put in the updates=http://... line
> 

Erm, you shouldn't have removed what was already there, that is why it went back to the menu, what you should do is:

When you start the installer, you will first get a screen asking you if you want to "install / upgrade an existing system" or run memtest. At this screen press <tab>, this will give you a commandline with the command behind the selected option already typed in. *After* this command first type a space and then type:
updates=http://people.atrpms.net/~hdegoede/updates474399-i386.img

Then press enter, and the installer will start normally, using some updated files provided in the updates.img (may ask you to help it with network config to get the updates.img)

Note if you are doing a 64 bit install the correct command to add to the existing cmdline is:
updates=http://people.atrpms.net/~hdegoede/updates474399-x86_64.img

You can check if you actually got the updates.img, by going to virtual terminal two (press ctrl+alt+f2 once in the graphical part of the installer) and type:
ls /tmp/updates

You should see a "block" directory under there, if you have that then you are using the updates.img.

Well, it looked promising.

However, after I keyed in the updates=http:... and hit enter, I got a dialog box asking which of my two network interfaces I wanted to go through (something like that).

I selected my eth1 interface with the arrow keys and then tabbed to the OK button and hit return.

I then got a dialog box saying:

Waiting for Network Manager to configure eth1:..

I waited, and then a dialog box saying:

There was an error configuring your network interface.

-- with a button asking Retry?

---

Even though the ´Network Manager´ never asked me for an IP address or gateway or dns, I hit Retry.


After awhile, I got a dialog box saying:

Error downloading updates image

Unable to download the updates image. Please modify the updates location below or Cancel to proceed without updates.

I double checked the updates address (correct) and tried again. Same result.

-----

I did this process twice with the same results.

-----

After a reboot, I can access ifconfig, ip, vi /etc/resolv.conf (in the RAM image?), and can configure my eth1 interface so that ping www.google.com works.

However, from that point, I can only do a reboot, which wipes out all of that good network stuff.

I think your suggestion and updates file would work, except for the Network Manager not following through properly. It cannot get any configuration information from the hard disk, because without your update, it cannot read the hard disk. A catch 22?

------

Before your reply, I was working on another path - using jigdo to create my own respin of FC10. Too bad there is no .jigdo file for the Install DVD, only the Everything DVD set. Do you know of a way to extract a .jigdo file from a DVD?

(In reply to comment #28)
> Well, it looked promising.
> 
> However, after I keyed in the updates=http:... and hit enter, I got a dialog
> box asking which of my two network interfaces I wanted to go through (something
> like that).
> 
> I selected my eth1 interface with the arrow keys and then tabbed to the OK
> button and hit return.
> 
> I then got a dialog box saying:
> 
> Waiting for Network Manager to configure eth1:..
> 

That is strange, there should be a dialog in between asking you if you want to use dhcp or specify settings manually, did that not appear?

Anyways there are other ways to use an updates.img, by putting it on an usb stick for example, or burning it to the cd / dvd:
http://fedoraproject.org/wiki/Anaconda/Updates

> ------
> 
> Before your reply, I was working on another path - using jigdo to create my own
> respin of FC10. Too bad there is no .jigdo file for the Install DVD, only the
> Everything DVD set. Do you know of a way to extract a .jigdo file from a DVD?

I'm afraid I'm not familiar with jidgo.

(In reply to comment #29)

> That is strange, there should be a dialog in between asking you if you want to
> use dhcp or specify settings manually, did that not appear?

No dialog box asking about DHCP or settings. Only asked which interface I wanted to use eth0 or eth1

> 
> Anyways there are other ways to use an updates.img, by putting it on an usb
> stick for example, or burning it to the cd / dvd:
> http://fedoraproject.org/wiki/Anaconda/Updates

I tried the 'linux updates'. I did this by hitting TAB which gave me:

> vmlinuz ...

Since the Anaconda instructions start with 'linux', I backspaced back to the > and then typed in

linux updates

Hitting enter then caused the system to continue to boot. No dialog asking where the updates might be (I have prepared a CD). It continued to boot and asked questions about language and keyboard and then hit the multiple /boot label problem and stopped.

In another variation, I waited the 55 second timeout instead of hitting enter. Same result.

In another variation, I hit TAB again after having put the linux updates in. The line served up to be edited was the original > vmlinuz .. and not the linux updates line just put in.

Too many things are not working the way they 'should'..
> 
> > ------
> > 
> > Before your reply, I was working on another path - using jigdo to create my own
> > respin of FC10. Too bad there is no .jigdo file for the Install DVD, only the
> > Everything DVD set. Do you know of a way to extract a .jigdo file from a DVD?
> 
> I'm afraid I'm not familiar with jidgo.

As a sanity check, I downloaded the latest respin of the FC9 install disk and  keyed in

> linux updates

in place of the > vmlinuz initrd = initrd.img

line obtained when using TAB to break into the 1st question screen.

The results here were the same as using the FC10 install DVD. It is just like my keying is totally ignored. No errors, no asking for update file location..

---

My second sanity check was to key in the updates=http://... following the > vmlinz initrd=... to get your updates file from the Internet.

This was more successful - I did get a dialog box asking for the appropriate network parameters. (I did not go ahead because I was using an FC9 DVD and your updates were for FC10).

=== What was different? ====

Over the last few days, I have noticed that neither eth0 or eth1 were ´active´ when rebooting. I checked the System -> Network -> Devices tab -> Edit button and the box ´Activate device when computer starts´ was checked. Apparently this is not enough because when I checked the box above titled ´Controlled by NetworkManager´, the next time I rebooted, the two ethernet devices were shown as active. This was the configuration in place when I tried the FC9 DVD.

I will now go back and retry your network install of the updates to see if this checkbox change on my running FC8 system makes a difference..

No, no change in behavior. The message dialog box on the FC10 trial says:

Waiting for Network Manager to configure eth1

On the FC9 trial, the equivalent message says:

Sending request for IP information for eth1

----

In the one case the Network Manager didn´t do anything and
in the other case, the Sending request.. did result in an appropriate dialog box asking for the information.

Perhaps a diff of the FC9 respin Anaconda and the new FC10 Anaconda would shed some light.

(In reply to comment #32)
> No, no change in behavior. The message dialog box on the FC10 trial says:
> 
> Waiting for Network Manager to configure eth1
> 
> On the FC9 trial, the equivalent message says:
> 
> Sending request for IP information for eth1
> 
> ----
> 
> In the one case the Network Manager didn´t do anything and
> in the other case, the Sending request.. did result in an appropriate dialog
> box asking for the information.
> 
> Perhaps a diff of the FC9 respin Anaconda and the new FC10 Anaconda would shed
> some light.

Network configuration during the install was completely redone in F-10, so a diff is going to be of little use. It seems that network manager is having issues on your system (that is a different bug). Perhaps you can try putting the updates.img on a usbstick instead, see:
http://fedoraproject.org/wiki/Anaconda/Updates

(In reply to comment #33)

> Network configuration during the install was completely redone in F-10, so a
> diff is going to be of little use. It seems that network manager is having
> issues on your system (that is a different bug). Perhaps you can try putting
> the updates.img on a usbstick instead, see:
> http://fedoraproject.org/wiki/Anaconda/Updates

You suggested this route in your Comment #29 and it was unsuccessful.

I will play around with more Anaconda Options as detailed in:

  http://fedoraproject.org/wiki/Anaconda/Options

Maybe some of these will work better than wishful thinking.

Hello all together, since last weekend i want to install Fedora 9 or 10 with Raid function on a Gigabyte GA-P965 DS4 rev2.0. I use the INTEL ICH8R SATA Control in Raid mode. The first time i installed F10 the Raid function was not detected. I`m looking for a solution and i found it here the updates.img for x86_64 F10.

Thanks to Hans de Goede!!!

It work for me. Installation was completed successfully, after reboot i look for the device /dev/mapper/isw... but i cannot find anything. I realized that F10 uses the device /dev/sda... to access my data.

The command:
dmraid -r

shows me two hard disks in Raid set isw...

I tried to activate them without success
dmraid return with a message like this Raid set isw... wasn`t activated.

dmesg show 2 lines like this...
device-mapper: table: 253:0: linear: dm-multipath: Device lookup failed
device-mapper: ioctl: error adding target to table

After that i used the rescue mode and the update.img for x86_64,
and every thing works fine. I updated all packages and created new initrd file
with the new mkinitrd. 

It`s still the same after reboot and normal F10 boot the same problem.

What does the update.img for F10 do, i saw some phyton scripts in /tmp/updates/block directory in rescue mode. What do i need to get F10 running with Raid function.

What does the rescue and install mode with update.img do?
What normal F10 doesn`t do after installation?

thanks

(In reply to comment #35)
> Hello all together, since last weekend i want to install Fedora 9 or 10 with
> Raid function on a Gigabyte GA-P965 DS4 rev2.0. I use the INTEL ICH8R SATA
> Control in Raid mode. The first time i installed F10 the Raid function was not
> detected. I`m looking for a solution and i found it here the updates.img for
> x86_64 F10.
> 
> Thanks to Hans de Goede!!!
> 
> It work for me. Installation was completed successfully, after reboot i look
> for the device /dev/mapper/isw... but i cannot find anything. I realized that
> F10 uses the device /dev/sda... to access my data.
> 

Chances are the mkinitrd has not done the right thing, see the latest comment in bug 476818 for a possible cause of this.

Can you please in rescue mode (with the updates.img) do the following:
chroot /mnt/sysimage
mkdir t
cd t
zcat /boot/initrd-*.img | cpio -i

Then there should be a number of files under the "t" directory including a file called "init", this is a text file, can you please save it somewhere and attach it here? Then I can confirm wether mkinitrd is indeed the cause of this next problem.

Thank you!

> I tried to activate them without success
> dmraid return with a message like this Raid set isw... wasn`t activated.
> 

Did your system/raid work properly under FC8 or FC9 ??

Thanks Hans de Goede,

> Can you please in rescue mode (with the updates.img) do the following
(Sorry it's not colored and not link to your comment #36, i have to read
the bugzilla readme :) )

thats sounds really good, i will try it in the afternoon or tomorrow.
I have to take a bakup of my running Fedora Core 9 on this raid before
i can install Fedora Core 10 again.

replay to comment #37
> Did your system/raid work properly under FC8 or FC9 ??

Yes, yesterday i installed Fedora Core 9 form iso CD image and the
installer detected my raid an installed FC9 on it.
The firstboot scripts crashed and so no new normal user for X login
was credted. In Runlevel 3 i updated FC9 with "yum update" and
created a normal user with "useradd".

Reboot FC9, login and raid worked perfect.

But i still want to get FC10 running i think there are so many things different
 and better to the previous releases of FC.
Fedora Core 10 is a major step in the correct direction.

> Can you please in rescue mode (with the updates.img) do the following:
> chroot /mnt/sysimage
> mkdir t
> cd t
> zcat /boot/initrd-*.img | cpio -i
> 
> Then there should be a number of files under the "t" directory including a file
> called "init", this is a text file, can you please save it somewhere and attach
> it here? Then I can confirm wether mkinitrd is indeed the cause of this next
problem.

Today i installed Fedora Core 10 again to attach the init textfile from my ramdisk init-2.6.27.5-117.fc10.x86_64.txt to confirm that my system is badly configured by me i updated the kernel with yum. Next compared the two init text files form the installation kernel with current kernel version=2.6.27.9-159.fc10.x86_64) ramdisk file. If you believe it or not a diff shows no differences :) between them.

And here is my init text file, in replay to comment #36
(line numbers included. I love the power of command line tools)
 
    1	#!/bin/nash
     2	
     3	mount -t proc /proc /proc
     4	setquiet
     5	echo Mounting proc filesystem
     6	echo Mounting sysfs filesystem
     7	mount -t sysfs /sys /sys
     8	echo Creating /dev
     9	mount -o mode=0755 -t tmpfs /dev /dev
    10	mkdir /dev/pts
    11	mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
    12	mkdir /dev/shm
    13	mkdir /dev/mapper
    14	echo Creating initial device nodes
    15	mknod /dev/null c 1 3
    16	mknod /dev/zero c 1 5
    17	mknod /dev/systty c 4 0
    18	mknod /dev/tty c 5 0
    19	mknod /dev/console c 5 1
    20	mknod /dev/ptmx c 5 2
    21	mknod /dev/fb c 29 0
    22	mknod /dev/tty0 c 4 0
    23	mknod /dev/tty1 c 4 1
    24	mknod /dev/tty2 c 4 2
    25	mknod /dev/tty3 c 4 3
    26	mknod /dev/tty4 c 4 4
    27	mknod /dev/tty5 c 4 5
    28	mknod /dev/tty6 c 4 6
    29	mknod /dev/tty7 c 4 7
    30	mknod /dev/tty8 c 4 8
    31	mknod /dev/tty9 c 4 9
    32	mknod /dev/tty10 c 4 10
    33	mknod /dev/tty11 c 4 11
    34	mknod /dev/tty12 c 4 12
    35	mknod /dev/ttyS0 c 4 64
    36	mknod /dev/ttyS1 c 4 65
    37	mknod /dev/ttyS2 c 4 66
    38	mknod /dev/ttyS3 c 4 67
    39	/lib/udev/console_init tty0
    40	daemonize --ignore-missing /bin/plymouthd
    41	echo "Loading i2c-core module"
    42	modprobe -q i2c-core
    43	echo "Loading i2c-algo-bit module"
    44	modprobe -q i2c-algo-bit
    45	echo "Loading drm module"
    46	modprobe -q drm
    47	echo "Loading radeon module"
    48	modprobe -q radeon
    49	plymouth --show-splash
    50	echo Setting up hotplug.
    51	hotplug
    52	echo Creating block device nodes.
    53	mkblkdevs
    54	echo Creating character device nodes.
    55	mkchardevs
    56	echo Making device-mapper control node
    57	mkdmnod
    58	mkblkdevs
    59	echo Scanning logical volumes
    60	lvm vgscan --ignorelockingfailure
    61	echo Activating logical volumes
    62	lvm vgchange -ay --ignorelockingfailure  VolGroup00
    63	resume UUID=a1cee331-28d7-48cf-b277-d214cf51bee1
    64	echo Creating root device.
    65	mkrootdev -t ext3 -o defaults,ro /dev/VolGroup00/lvROOT
    66	echo Mounting root filesystem.
    67	mount /sysroot
    68	cond -ne 0 plymouth --hide-splash
    69	echo Setting up other filesystems.
    70	setuproot
    71	loadpolicy
    72	plymouth --newroot=/sysroot
    73	echo Switching to new root and running init.
    74	switchroot
    75	echo Booting has failed.
    76	sleep -1


It's like i estimate device-mapper is activated in line 56-58, before the lvm is activated in line 59 to 62. So a lvm can be part of my a raid system.

My kernel update with yum to kernel version 2.6.27.9-159.fc10.x86_64 produced a error message a few seconds before finished the update.

message: error can't connect to dbus.

Is it possible that this message comes form the ramdisk creation process?
And as result the device-mapper can't be activated?
Is it possible to compare a init text file of my system created by a FC9 with a FC10 installtion? 

I'm very happy if you take a look at my init file

Thanks!!!!!!!!!!!!

(In reply to comment #39)
> > Can you please in rescue mode (with the updates.img) do the following:
> > chroot /mnt/sysimage
> > mkdir t
> > cd t
> > zcat /boot/initrd-*.img | cpio -i
> > 
> > Then there should be a number of files under the "t" directory including a file
> > called "init", this is a text file, can you please save it somewhere and attach
> > it here? Then I can confirm wether mkinitrd is indeed the cause of this next
> problem.
> 
> Today i installed Fedora Core 10 again to attach the init textfile from my
> ramdisk init-2.6.27.5-117.fc10.x86_64.txt to confirm that my system is badly
> configured by me i updated the kernel with yum. Next compared the two init text
> files form the installation kernel with current kernel
> version=2.6.27.9-159.fc10.x86_64) ramdisk file. If you believe it or not a diff
> shows no differences :) between them.

Judging from your init file mkinitrd indeed is the culprit here, or atleast your initrd is the cause of the system not working properly.

This (the initrd part) seems very much like bug 476818, see bug 476818 Comment #22 for the likely cause of this. 

Can you please boot the F-10 installer in rescue mode (with the updates.img) and then run the following 2 commands:
dmraid -ay -t
dmsetup table

Then I can confirm that the problem you are now seeing indeed is the same as bug 476818

Hi,
I have a Asus Maximus Formula with the ICH9R and have the same problems.
I used the the .img from Hans de Goede (thanks by the way;) ) and manage to start correctly the installer.

I spent a bit of time debugging mkinitrd to check if the raid modules were stored in the image file, only to find out that the 2.6.27.9-159.fc10.x86_64 doesn't have the dm-log dm-mirror dm-mod dm-snapshot dm-zero compiled (just check your /lib/modules/.6.27.9-159.fc10.x86_64/kernel/drivers/md); mkinitrd doesn't find the modules but doesn't report any error.

I compiled these modules and installed them, then I create a new image with mkinitrd.
I extracted the .img to double-check the dm* modules, and now they are present.

When the system boots I have an error on dm-log (invalid argument). I have to be doing something bad in the compilation procedure.


I copied the dm directory from the vanila kernel 2.7.27-9, then I create the following Makefile:

obj-m += dm-log.o dm-mirror.o dm-mod.o dm-snapshot.o dm-zero.o

dm-mod-objs	:= dm.o dm-table.o dm-target.o dm-linear.o dm-stripe.o \
		   dm-ioctl.o dm-io.o dm-kcopyd.o dm-uevent.o
dm-multipath-objs := dm-path-selector.o dm-mpath.o
dm-snapshot-objs := dm-snap.o dm-exception-store.o
dm-mirror-objs	:= dm-raid1.o
md-mod-objs     := md.o bitmap.o
raid456-objs	:= raid5.o raid6algos.o raid6recov.o raid6tables.o \
		   raid6int1.o raid6int2.o raid6int4.o \
		   raid6int8.o raid6int16.o raid6int32.o \
		   raid6altivec1.o raid6altivec2.o raid6altivec4.o \
		   raid6altivec8.o \
		   raid6mmx.o raid6sse1.o raid6sse2.o

KVERSION = 2.6.27.9-159.fc10.x86_64

obj-dm-snapshot	+= dm-snapshot.o
obj-dm-mirror	+= dm-mirror.o dm-log.o
obj-dm-zero	+= dm-zero.o


all: 
make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
clean: 
make -C /lib/modules/$(KVERSION)/build M=$(PWD) clean


I am using the F9 kernel for now... hope this helps.

Check Bug #471737 also - see comments below:

> A) Using Fedora 10 Preview the RAID array is not recognized at all. 
> In the anaconda installer just appear 2 separate SATA disks.

> B) Using Fedora 9 and Fedora 10 Beta the RAID array is recognized but when
> booting appears an error message which is actually not affecting the
> functionality of the OS (The system boots up OK).

This is an open bug, reported on 2008-11-15 in the preview version of FC10

Created attachment 329807 [details]
dmraid -a y t

Created attachment 329808 [details]
dmsetup table

Yes, you are right.

It looks like bug 476818 Comment #22 the following lines proof it.

dmraid -a y t
isw_fdbchebca_VOLUME0: 0 976766712 mirror core 2 131072 nosync 2 /dev/sda 0 /dev/sdb 0 1 handle_errors

dmsetup table
isw_fdbchebca_VOLUME0: 0 976766712 mirror core 2 131072 nosync 2 8:16 0 8:0 0 1 handle_errors

8:0  /dev/sda
8:16 /dev/sdb

In bug 476818 Comment #22 the order of the disks within the raid is in opposite,
But in bug 476818 Comment #25 the order within the raid is correct it's 2 times sda=8:0 and sdb=8:16?

I'm sure that i have got the same as described in bug 476818 Comment #22.

Thanks for your professional support.
Have a nice weekend, today is friday so i stoped working for the moment and start playing ice hockey :)

(In reply to comment #41)
> Hi,
> I have a Asus Maximus Formula with the ICH9R and have the same problems.
> I used the the .img from Hans de Goede (thanks by the way;) ) and manage to
> start correctly the installer.
> 
> I spent a bit of time debugging mkinitrd to check if the raid modules were
> stored in the image file, only to find out that the 2.6.27.9-159.fc10.x86_64
> doesn't have the dm-log dm-mirror dm-mod dm-snapshot dm-zero compiled (just
> check your /lib/modules/.6.27.9-159.fc10.x86_64/kernel/drivers/md); mkinitrd
> doesn't find the modules but doesn't report any error.
> 
> I compiled these modules and installed them, then I create a new image with
> mkinitrd.

Those modules are not really missing, they are now compiled staticly into the kernel as they are almost always used.

Your problem most like is the same as bug 476818 Comment #22, can you please execute the following 2 commands, and paste the output here, then I can confirm if it is the same problem:

dmraid -a y t
dmsetup table

Thanks for the help.
dmraid -ay t:
isw_cjggfiehfb_Volume0: 0 1250275328 striped 2 256 /dev/sda 0 /dev/sdb 0
isw_cjggfiehfb_Volume0p1: 0 307210932 linear /dev/mapper/isw_cjggfiehfb_Volume0 63
isw_cjggfiehfb_Volume0p2: 0 819186480 linear /dev/mapper/isw_cjggfiehfb_Volume0 307210995
isw_cjggfiehfb_Volume0p3: 0 8385930 linear /dev/mapper/isw_cjggfiehfb_Volume0 1126397475
isw_cjggfiehfb_Volume0p4: 0 115491285 linear /dev/mapper/isw_cjggfiehfb_Volume0 1134783405


dmsetup table:
isw_cjggfiehfb_Volume0: 0 1250275840 striped 2 256 8:0 0 8:16 0
isw_cjggfiehfb_Volume0p4: 0 115491285 linear 253:0 1134783405
isw_cjggfiehfb_Volume0p3: 0 8385930 linear 253:0 1126397475
isw_cjggfiehfb_Volume0p2: 0 819186480 linear 253:0 307210995
isw_cjggfiehfb_Volume0p1: 0 307210932 linear 253:0 63

I am using the 2.6.27.9-73.fc9.x86_64 kernel.

Is this kernel, or a mkinitrd bug?

(In reply to comment #46)
> (In reply to comment #41)
> > Hi,
> > I have a Asus Maximus Formula with the ICH9R and have the same problems.
> > I used the the .img from Hans de Goede (thanks by the way;) ) and manage to
> > start correctly the installer.
> > 
> > I spent a bit of time debugging mkinitrd to check if the raid modules were
> > stored in the image file, only to find out that the 2.6.27.9-159.fc10.x86_64
> > doesn't have the dm-log dm-mirror dm-mod dm-snapshot dm-zero compiled (just
> > check your /lib/modules/.6.27.9-159.fc10.x86_64/kernel/drivers/md); mkinitrd
> > doesn't find the modules but doesn't report any error.
> > 
> > I compiled these modules and installed them, then I create a new image with
> > mkinitrd.
> 
> Those modules are not really missing, they are now compiled staticly into the
> kernel as they are almost always used.
> 
> Your problem most like is the same as bug 476818 Comment #22, can you please
> execute the following 2 commands, and paste the output here, then I can confirm
> if it is the same problem:
> 
> dmraid -a y t
> dmsetup table

(In reply to comment #47)
> Thanks for the help.
> dmraid -ay t:
> isw_cjggfiehfb_Volume0: 0 1250275328 striped 2 256 /dev/sda 0 /dev/sdb 0
> isw_cjggfiehfb_Volume0p1: 0 307210932 linear /dev/mapper/isw_cjggfiehfb_Volume0
> 63
> isw_cjggfiehfb_Volume0p2: 0 819186480 linear /dev/mapper/isw_cjggfiehfb_Volume0
> 307210995
> isw_cjggfiehfb_Volume0p3: 0 8385930 linear /dev/mapper/isw_cjggfiehfb_Volume0
> 1126397475
> isw_cjggfiehfb_Volume0p4: 0 115491285 linear /dev/mapper/isw_cjggfiehfb_Volume0
> 1134783405
> 
> 
> dmsetup table:
> isw_cjggfiehfb_Volume0: 0 1250275840 striped 2 256 8:0 0 8:16 0
> isw_cjggfiehfb_Volume0p4: 0 115491285 linear 253:0 1134783405
> isw_cjggfiehfb_Volume0p3: 0 8385930 linear 253:0 1126397475
> isw_cjggfiehfb_Volume0p2: 0 819186480 linear 253:0 307210995
> isw_cjggfiehfb_Volume0p1: 0 307210932 linear 253:0 63
> 

Hmm, seems to be a different problem.

> Is this kernel, or a mkinitrd bug?
> 

Probably mkinitrd.

Regards,

Hans

I think so; from what I have seen, the mkinitrd needs the dm-* modules to create the .img but since they are now built-in into the kernel, the image isn't properly created.
The solution should be to compile the dm-* as modules, and not static into the kernel.

(In reply to comment #48)
> (In reply to comment #47)
> > Thanks for the help.
> > dmraid -ay t:
> > isw_cjggfiehfb_Volume0: 0 1250275328 striped 2 256 /dev/sda 0 /dev/sdb 0
> > isw_cjggfiehfb_Volume0p1: 0 307210932 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 63
> > isw_cjggfiehfb_Volume0p2: 0 819186480 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 307210995
> > isw_cjggfiehfb_Volume0p3: 0 8385930 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 1126397475
> > isw_cjggfiehfb_Volume0p4: 0 115491285 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 1134783405
> > 
> > 
> > dmsetup table:
> > isw_cjggfiehfb_Volume0: 0 1250275840 striped 2 256 8:0 0 8:16 0
> > isw_cjggfiehfb_Volume0p4: 0 115491285 linear 253:0 1134783405
> > isw_cjggfiehfb_Volume0p3: 0 8385930 linear 253:0 1126397475
> > isw_cjggfiehfb_Volume0p2: 0 819186480 linear 253:0 307210995
> > isw_cjggfiehfb_Volume0p1: 0 307210932 linear 253:0 63
> > 
> 
> Hmm, seems to be a different problem.
> 
> > Is this kernel, or a mkinitrd bug?
> > 
> 
> Probably mkinitrd.
> 
> Regards,
> 
> Hans

I used the Fedora Unity 2008-12-17 respin of fc9 to upgrade from fc8. It seemed to go OK.

A surprise was the change in inittab useage. I was running djbdns tools on fc8 and after the fc9 install, djbdns was not running. A quick google fixed the problem.

I followed the update with 'yum update' (only possible after djbdns was working).

------

The results from the requested commands are:

/sbin/dmraid -ay -t

isw_cdjgadhfa_Seagate160-0: 0 312576264 mirror core 2 131072 nosync 2 /dev/sda 0 /dev/sdb 0 1 handle_errors
isw_cdjgadhfa_Seagate160-01: 0 401562 linear /dev/mapper/isw_cdjgadhfa_Seagate160-0 63
isw_cdjgadhfa_Seagate160-02: 0 312159015 linear /dev/mapper/isw_cdjgadhfa_Seagate160-0 401625

/sbin/dmsetup table

isw_cdjgadhfa_Seagate160-0: 0 312576264 mirror core 2 131072 nosync 2 8:0 0 8:16 0 1 handle_errors
isw_cdjgadhfa_Seagate160-0p2: 0 312159015 linear 253:0 401625
isw_cdjgadhfa_Seagate160-0p1: 0 401562 linear 253:0 63
VolGroup00-LogVol01: 0 4063232 linear 253:2 308019584
VolGroup00-LogVol00: 0 308019200 linear 253:2 384

I compiled and installed the vanilla 2.6.27.9 but still didn't boot (but I use the 2.6.27.9 from f9 and it works) so I think this proves the problem is with mkinitrd. 

I tried to use the mkinitrd from f9 (on the vanilla 2.6.27.9) but now I get "Couln't stabilize" or similar message.

Any thoughts?

Thanks,
Rolando

(In reply to comment #49)
> I think so; from what I have seen, the mkinitrd needs the dm-* modules to
> create the .img but since they are now built-in into the kernel, the image
> isn't properly created.
> The solution should be to compile the dm-* as modules, and not static into the
> kernel.
> 
> (In reply to comment #48)
> > (In reply to comment #47)
> > > Thanks for the help.
> > > dmraid -ay t:
> > > isw_cjggfiehfb_Volume0: 0 1250275328 striped 2 256 /dev/sda 0 /dev/sdb 0
> > > isw_cjggfiehfb_Volume0p1: 0 307210932 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > > 63
> > > isw_cjggfiehfb_Volume0p2: 0 819186480 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > > 307210995
> > > isw_cjggfiehfb_Volume0p3: 0 8385930 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > > 1126397475
> > > isw_cjggfiehfb_Volume0p4: 0 115491285 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > > 1134783405
> > > 
> > > 
> > > dmsetup table:
> > > isw_cjggfiehfb_Volume0: 0 1250275840 striped 2 256 8:0 0 8:16 0
> > > isw_cjggfiehfb_Volume0p4: 0 115491285 linear 253:0 1134783405
> > > isw_cjggfiehfb_Volume0p3: 0 8385930 linear 253:0 1126397475
> > > isw_cjggfiehfb_Volume0p2: 0 819186480 linear 253:0 307210995
> > > isw_cjggfiehfb_Volume0p1: 0 307210932 linear 253:0 63
> > > 
> > 
> > Hmm, seems to be a different problem.
> > 
> > > Is this kernel, or a mkinitrd bug?
> > > 
> > 
> > Probably mkinitrd.
> > 
> > Regards,
> > 
> > Hans

(In reply to comment #48)
> (In reply to comment #47)
> > Thanks for the help.
> > dmraid -ay t:
> > isw_cjggfiehfb_Volume0: 0 1250275328 striped 2 256 /dev/sda 0 /dev/sdb 0
> > isw_cjggfiehfb_Volume0p1: 0 307210932 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 63
> > isw_cjggfiehfb_Volume0p2: 0 819186480 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 307210995
> > isw_cjggfiehfb_Volume0p3: 0 8385930 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 1126397475
> > isw_cjggfiehfb_Volume0p4: 0 115491285 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 1134783405
> > 
> > 
> > dmsetup table:
> > isw_cjggfiehfb_Volume0: 0 1250275840 striped 2 256 8:0 0 8:16 0
> > isw_cjggfiehfb_Volume0p4: 0 115491285 linear 253:0 1134783405
> > isw_cjggfiehfb_Volume0p3: 0 8385930 linear 253:0 1126397475
> > isw_cjggfiehfb_Volume0p2: 0 819186480 linear 253:0 307210995
> > isw_cjggfiehfb_Volume0p1: 0 307210932 linear 253:0 63
> > 
> 
> Hmm, seems to be a different problem.
> 
> > Is this kernel, or a mkinitrd bug?
> > 
> 
> Probably mkinitrd.
> 
> Regards,
> 
> Hans

(In reply to comment #14)
> 
> Something you might try is to re-install Fedora 10 from scratch, but be sure to
> have a working network connection.  If you do, then on the screen that lets you
> select the repositories, you can select the "update" repositories, also.  With
> this selected, Fedora will download all latest upgrades to the packages that
> you have selected (for example "Office/Productivity"), including the new
> version of mkinitrd.  I have not tried this myself.  It would be good to know
> whether this will work to fix the problem.

I have now tried the above steps (required for new disk drives), and this has worked without any additional steps required on my part.  Once the installation completed (in less than 30 minutes), the reboot recognized the two-disk RAID1 as the boot disk (hardware RAID).  Upon reboot, my computer is now running the latest kernel version, 2.6.27.12-170.2.5, along with the latest updates for the other packages in the Office/Productivity set (including 'mkinitrd-6.0.71-3').

This may be worth trying for anyone who still does not have a working Fedora 10 with a RAID setup.  Of course, the speed of your installation will vary, depending on your connection speed, disk speed, etc.  You will require a working network connection that NetworkManager is able to negotiate with to establish an installation-time network connection to the internet.

Did someone manage to do this procedure using fake raid (e.g. using ICH9R)?


(In reply to comment #52)
> (In reply to comment #14)
> > 
> > Something you might try is to re-install Fedora 10 from scratch, but be sure to
> > have a working network connection.  If you do, then on the screen that lets you
> > select the repositories, you can select the "update" repositories, also.  With
> > this selected, Fedora will download all latest upgrades to the packages that
> > you have selected (for example "Office/Productivity"), including the new
> > version of mkinitrd.  I have not tried this myself.  It would be good to know
> > whether this will work to fix the problem.
> 
> I have now tried the above steps (required for new disk drives), and this has
> worked without any additional steps required on my part.  Once the installation
> completed (in less than 30 minutes), the reboot recognized the two-disk RAID1
> as the boot disk (hardware RAID).  Upon reboot, my computer is now running the
> latest kernel version, 2.6.27.12-170.2.5, along with the latest updates for the
> other packages in the Office/Productivity set (including 'mkinitrd-6.0.71-3').
> 
> This may be worth trying for anyone who still does not have a working Fedora 10
> with a RAID setup.  Of course, the speed of your installation will vary,
> depending on your connection speed, disk speed, etc.  You will require a
> working network connection that NetworkManager is able to negotiate with to
> establish an installation-time network connection to the internet.

I have hardware Raid (set using Bios). It is ICH9R on an Asus P5K-E

I am using fc9 now (from the 12/17/2008 respin of fc9) and it works fine.

(In reply to comment #54)
> I have hardware Raid (set using Bios). It is ICH9R on an Asus P5K-E
> 
> I am using fc9 now (from the 12/17/2008 respin of fc9) and it works fine.

Thanks for the reply, but did someone manage to use fake raid on f10 using the update repos on install?

Today I extracted the initrd.img from both my f9 and f10 kernel; then I overwrited the init script of f10 with the init from f9 image; afterwords I recreated the f10 image.
I manage to boot but I got some errors before udev appears:
Buffered IO Error on sda
...
Unable to stabilize - Waiting 10 seconds
But still manage to boot.

Reading the dmesg I see several "attempt to access beyond end of device sda"
(both this situations doesn't happen with my f9 kernel/image)



(In reply to comment #48)
> (In reply to comment #47)
> > Thanks for the help.
> > dmraid -ay t:
> > isw_cjggfiehfb_Volume0: 0 1250275328 striped 2 256 /dev/sda 0 /dev/sdb 0
> > isw_cjggfiehfb_Volume0p1: 0 307210932 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 63
> > isw_cjggfiehfb_Volume0p2: 0 819186480 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 307210995
> > isw_cjggfiehfb_Volume0p3: 0 8385930 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 1126397475
> > isw_cjggfiehfb_Volume0p4: 0 115491285 linear /dev/mapper/isw_cjggfiehfb_Volume0
> > 1134783405
> > 
> > 
> > dmsetup table:
> > isw_cjggfiehfb_Volume0: 0 1250275840 striped 2 256 8:0 0 8:16 0
> > isw_cjggfiehfb_Volume0p4: 0 115491285 linear 253:0 1134783405
> > isw_cjggfiehfb_Volume0p3: 0 8385930 linear 253:0 1126397475
> > isw_cjggfiehfb_Volume0p2: 0 819186480 linear 253:0 307210995
> > isw_cjggfiehfb_Volume0p1: 0 307210932 linear 253:0 63
> > 
> 
> Hmm, seems to be a different problem.
> 
> > Is this kernel, or a mkinitrd bug?
> > 
> 
> Probably mkinitrd.
> 
> Regards,
> 
> Hans

(In reply to comment #56)
> ...
> Unable to stabilize - Waiting 10 seconds
> But still manage to boot.

Check out Bug #470628
(stabilization) Boot message: Could not detect stabilization, waiting 10 seconds

It is marked CLOSED NEXTRELEASE..

There is a fix mentioned, it might be helpful for you.

I investigated the f9 init script and the following portion is missing from the init generated from the f10 mkinitrd:

rmparts sdb
rmparts sda
dm create isw_bahdhbhgib_Volume0 0 1250275840 striped 2 256 8:0 0 8:16 0
dm partadd isw_bahdhbhgib_Volume0
resume /dev/mapper/isw_bahdhbhgib_Volume0p2

This is clearly a bug of mkinitrd.

*** Bug 475024 has been marked as a duplicate of this bug. ***

(In reply to comment #58)
> I investigated the f9 init script and the following portion is missing from the
> init generated from the f10 mkinitrd:
> 
> rmparts sdb
> rmparts sda
> dm create isw_bahdhbhgib_Volume0 0 1250275840 striped 2 256 8:0 0 8:16 0
> dm partadd isw_bahdhbhgib_Volume0
> resume /dev/mapper/isw_bahdhbhgib_Volume0p2
> 
> This is clearly a bug of mkinitrd.

That is a (fixed) mkinitrd issue see bug 476818, check that bug for an update and instructions on how to use the update.

This bug is for tracking the anaconda issue where it does not recognize an isw raid array during installation time (mkinitrd comes in to play booting the installed system).

As for this bug, I believe this is fixed by my updates.img, and it is fixed properly (as in works out of the box) in rawhide. Since there is no way to update the installer in a released version (by policy we never respin the gold iso's), I'm closing this with a resolution of rawhide.

It might be good to put a note in the Knowledge base about how to fix this.

Or better yet while the "we don't respin" policy is probably a pretty good idea, maybe a specific list of know issues that a respin would fix but instead are fixed with these updates and how to fix them might be good.

Hopefully the issue of Install/Update to systems which have RAID disks will get better attention and more testing before the next release.

This has been a problem in every release since FC7: see for example Bug #241949 which has 'CLOSED NEXTRELEASE' status.

(In reply to comment #62)
> Hopefully the issue of Install/Update to systems which have RAID disks will get
> better attention and more testing before the next release.
> 

Its definitely getting more attention! (Just look at my BZ activity wrt this). As for more testing, there is only so much testing we ourselves can do. If you care about this please give the F-11 beta (s) a try. And if things don't work be sure to get my attention (just drop me a personal mail, I get too much bugzilla mail so if only entered it in BZ it may snow under).

Note that the F-11 alpha is not much better wrt this then F-10, so little use in trying that.

OK Hans, you have a point, but we do about the testing too.   

The problem is that the alpha and beta releases are generally only setup really to allow for very standard installs. Usually upgrades are a problem to do and test, and then once we have a release the programs show up because now we actually can really test them in the environment where they will be used.

One issue has been that in the past the ISOs issued in the beta have not allowed for an over the wire upgrade and install.   For many environments especially the ones that have these types of issues (RAID, high performance, etc) this is the type of install used.   The preupgrade system also doesn't seem to be made ready during the alpha cycle.   This is a great and fabulous tool, and one that should get more consideration as it would allow better testing.

How about a request for testing.   Really that I have ever seen there are some comments about how important testing is.   And I realize that you don't even know what all needs to be tested because entirely you don't know what will end up breaking.   But I suspect that you have a general idea.   You know where there have been major changes.  Especially when things go to beta how about a list of areas that need checking and then a bi-result ability to comment on these areas.  Right now the only feed back you really get is "this doesn't work".  I would think that the "this works for me" would be even more important.

The information about what has been tested and is working is important in several ways.   The first is if you really need to get something tested, and a bunch of people have said "hey it is working here" then you know you got it right and it is ready.  If nobody has commented on having tested that function you can work on encouraging people to test it.   Maybe even removing the well tested things from the list.   Second if some people are having problems and others success, then you can contact the successful people and see what is different this could speed the development of fixes.

How about using the bugzilla system and adding an additional product "fedora beta".   Only developers can add bugs to this list or close them.   These are not actually bugs, but a list of what needs to be tested.   Bugs found go back in bugs in fedora under rawhide. If you open a bug you note if back on the fedora beta product too.  Now many people like me have allocations from our employers to test open source software.   Some companies understand that if they are using this stuff this is kind of the cost.   So if you were to put out a list of things to test rather than a generic "please test this" you might get a better result.

Because RAID problems stop install/update cold, and because of your policy not to respin faulty golden DVDs, this is a real roadblock for the RAID user community.

It is as much a policy problem as software/hardware problem.

I suggest forking the anaconda testing and release so that the (RAID | over the wire | USB flash drive) user community can test this aspect only. Ahead of incorporation into a FC release.

See my Comment #21.

I couldn't agree more with Comment #64 Testing is very important. If the developers can't do the testing, then a mechanism needs to be developed to get the user community involved - early enough to be useful.

Whoops, too bad, no respin -- doesn't seem to solve the problem of testing.

Bob:

From my stand point the problem was the fact that the net install iso only became available late in the beta cycle.   Had it been available sooner I would have tested this sooner and would have reported the problem sooner.   I think the beta should come out with a full set of functional ISOs.

As for the current problem, I can understand the "we don't respin" thing.  However what is needed is a seperate page specifically dedicated to these show stoppers that are also hit by the we don't respin thing.   Basically this would be a detailed set of instructions for using the update images, along with a list of updates and what they fix.   Most of the actual show stopper problems by the time you reach production will only be experienced by people who can actually deal with the update images with reasonable instructions and information as to which one to use.

I thought I had the solution - a Fedora Unity F10 Re-Spin:

Fedora-Unity-20090210-10-x86_64-DVD.iso

It should contain all of the fixes up to Feb 10 2009, yes?

Unfortunately, it still contains a boot up bug.

I tried it a few minutes ago and after answering the languages and selecting 'update', I got an alert box with the text:

---- Duplicate Labels ----
Multiple devices on your system are labeled fb5b8c8a-bo3a-434c-9490-b0e2f7519603

Labels across devices must be unique for your system to function properly.

Please fix this problem and restart the installation process

                     -Exit Installer-
----------

I have 3 partitions on my RAID 1 disk pair, a /, a /boot, and a swap.

The complaining label appears to be a UUID=fb5b8c... on the /boot partition.

--

I would guess that it is not looking at the RAID pair, but is looking at each disk individually.

I will try again, using the kernel boot parameter scsi_mod.scan=sync

No, the scsi_mod.scan=sync doesn't work.

I worked around the problem by installing Fedora 9 and upgrading it to 10 as described on http://fedoraproject.org/wiki/YumUpgradeFaq

The upgrade went just fine.

From http://fedoraproject.org/wiki/YumUpgradeFaq

----
"The recommended installation method is with a boot media with the Anaconda installer as detailed in the Installation Guide..

When upgrading with yum you don't get any help from Anaconda, .... But the system must be rebooted to get the new kernel and system libraries and services running, so currently you can't avoid having some downtime.

Rebooting after such an upgrade is always very exciting."
-------

I would rather folks would look at the current Bug #474399.

If the recommended Anaconda process doesn't work - using upgraded components in a Unity re-spin - why is this bug classified as "CLOSED RAWHIDE" ??

(In reply to comment #70)
> I would rather folks would look at the current Bug #474399.
> 
> If the recommended Anaconda process doesn't work - using upgraded components in
> a Unity re-spin - why is this bug classified as "CLOSED RAWHIDE" ??

Because a F-10 respin is not rawhide. The fixes for this are not released asd F-10 updates, so a respin wont pick them up.

One thing not mentioned yet is F-11.   Has anyone verified that this is fixed in the F-11 alpha?

(In reply to comment #71)
> (In reply to comment #70)
>
> > a Unity re-spin - why is this bug classified as "CLOSED RAWHIDE" ??
> 
> Because a F-10 respin is not rawhide. The fixes for this are not released asd
> F-10 updates, so a respin wont pick them up.

If there is no way for motherboard raid users to test these 'fixes', then we are doomed to see the problems in FC11 too..

Why not release these fixes - so they get a good testing prior to FC11??

(In reply to comment #72)
> One thing not mentioned yet is F-11.   Has anyone verified that this is fixed
> in the F-11 alpha?

F11 alpha fails with my ICH8R RAID 1. When I try to proceed from the keyboard selection screen I get an error dialog saying "Could not stat device /dev/mapper/isw_bfghbfehhc_Volume0 - file or directory does not exist". I guess the rawhide fix was made after the alpha release?

(In reply to comment #74)
> (In reply to comment #72)
> > One thing not mentioned yet is F-11.   Has anyone verified that this is fixed
> > in the F-11 alpha?
> 
> F11 alpha fails with my ICH8R RAID 1. When I try to proceed from the keyboard
> selection screen I get an error dialog saying "Could not stat device
> /dev/mapper/isw_bfghbfehhc_Volume0 - file or directory does not exist". I guess
> the rawhide fix was made after the alpha release?

Some fixes were made after the alpha release, some before. In fact I'm still working on fixing nvidia jbod / spanning mode. I've got that coded out now, I just need to test it (I have the HW) and then rawhide should be in pretty good shape wrt to dmraid setups.

I understand this is all pretty frustrating. I shall try to publish some instructions on how to try the latest rawhide when I think it is in good state for dmraid testing. I'm afraid currently it is not (it is close, but not quite there yet).

Rest assured this has my full attention and many many issues have been fixed in rawhide. F-11 should be much better wrt dmraid (and about time!).