Attached ext3-formatted external Firewire disk, contains F11 Beta RC3 ISO and images/ folder with install.img. Kernel starts, fw disk is sensed correctly. Select lang and keyboard as usual, select "/dev/sdb1" for external disk, and point to correct path for the ISO and images/ folder. Install image loads, X starts, and the following dialog appears: === Unknown Device === The installation source given by device None could not be found. Please check your parameters and try again. The following message appears in tty3: DEBUG: failed to resolve '/dev/sdb1'
This is because storage is not initialized when we go to look up the device very early in anaconda.
This should be fixed in the next build of anaconda.
Hrm, used a VM to test this. Two disk devices attached, sda is the system drive and sdb is the storage device containing /Fedora-11-Beta-x86_64-DVD.iso (RC5 version) and also /images/install.img. I get the same error, although it happens this time *after* I proceed past the pre-release nag.
Confirmed on physical hardware too. This is anaconda-11.5.0.38.
Any suggested work around for this bug ? I wanted to use hard-drive to install the official beta "Fedora-11-Beta-x86_64-DVD.iso"
Okay, this should be fixed for real in the next build of anaconda. Thanks for retesting.
Same problem for me with x86_64 beta on a dell xps M1330 laptop... sigh ;-( even in f10 beta a problem prevented form installing from hd... sigh Any possibility that starting from a pre-existing fedora system and inserting in its grub.conf updated (so post-beta) isolinux/vmlinuz and isolinux/initr.img for starting installation process, one is able to install using the beta iso? Or what would be the minimalistic approach having the beta iso (x86_64) and wanting to test/install rawhide after beta to both check resolution and test rawhide? Thanks, Gianluca
*** Bug 494086 has been marked as a duplicate of this bug. ***
Possibly related to this storage rewrite: My initial problem with attempting the hard disk install was very confusing because booting the installer apparently decided that my external USB drive should be /dev/sdb and my 2nd SATA fixed drive should be /dev/sdc. It seemed highly counter-intuitive to have a removable device named prior to a fixed device, and no previous versions of fedora have done this to me. Once I unplugged the USB drive, I was able to get to this bug :-). Not sure if I should report this as a separate bug or not, after all there have never been any actual guarantee of disk ordering, but it is definitely weird.
Created attachment 338246 [details] updates.img I created this updates.img using the storage directory and backend.py from anaconda 11.5.0.40-1.src.rpm. I then place this into /images on the usbkey I'm using for the beta isos and it gets picked up and used. I just had to use both a stage2= and repo= at the boot prompt, for this to work
Created attachment 338330 [details] anaconda.log after using the provided updates.img I confirm that with your updates.img put inside the images directory, I was able to install from hd the beta dvd iso, only passing the option "repo=hd:sda6:/" Well done! Now I have my previous f9 partition filled up with upcoming f11, aside with current f10 into another partition... And thanks! I attach my anaconda.log too, in case it could be useful. In case I have also anaconda-yum.conf program.log storage.log syslog X.log Gianluca
> I was able to install from hd the beta dvd iso, only passing the > option "repo=hd:sda6:/" FWIW, also the ability to use UUIDs or labels was added recently (see Bug 488540) which gives some more flexibility, so one could use something like repo=hd:LABEL=INSTALLDISK:/ .
Thanks for confirming.
This problem still exists on RHEL6 Beta. Best Regards Marcus
Then open a new bug against the RHEL6 product. Please don't take over bugs like this.
I've got this problem with a Fedora-14-x86_64-DVD.iso in a USB stick too. The only difference is that by default it uses UUID (repo=hd:UUID=1212-FF34:/) instead. Changing it to /dev/sdb1 or even dropping the --repo option from the command line and choosing it afterwards doesn't solve the problem either. The USB stick content: [diegobz@rasther usbdisk]$ ll -a * -rwxr-xr-x. 1 diegobz root 3520802816 Dec 16 23:37 Fedora-14-x86_64-DVD.iso images: total 151684 drwxr-xr-x. 2 diegobz root 4096 Dec 18 12:26 . drwxr-xr-x. 4 diegobz root 4096 Dec 31 1969 .. -rwxr-xr-x. 1 diegobz root 155316224 Dec 16 19:00 install.img syslinux: total 36344 drwxr-xr-x. 2 diegobz root 4096 Dec 16 23:38 . drwxr-xr-x. 4 diegobz root 4096 Dec 31 1969 .. -rwxr-xr-x. 1 diegobz root 2048 Dec 16 23:37 boot.cat -rwxr-xr-x. 1 diegobz root 84 Dec 16 23:37 boot.msg -rwxr-xr-x. 1 diegobz root 142 Dec 16 23:37 grub.conf -rwxr-xr-x. 1 diegobz root 32045806 Dec 16 23:38 initrd.img -rwxr-xr-x. 1 diegobz root 24576 Dec 16 23:38 isolinux.bin -r-xr-xr-x. 1 diegobz root 14445 Dec 17 00:44 ldlinux.sys -rwxr-xr-x. 1 diegobz root 165080 Dec 16 23:38 memtest -rwxr-xr-x. 1 diegobz root 462737 Dec 16 23:38 splash.jpg -rwxr-xr-x. 1 diegobz root 69611 Dec 16 23:38 splash.lss -rwxr-xr-x. 1 diegobz root 1026 Dec 16 23:38 syslinux.cfg -rwxr-xr-x. 1 diegobz root 462737 Dec 16 23:38 syslinux-vesa-splash.jpg -rwxr-xr-x. 1 diegobz root 2673 Dec 16 23:38 TRANS.TBL -rwxr-xr-x. 1 diegobz root 147728 Dec 16 23:38 vesamenu.c32 -rwxr-xr-x. 1 diegobz root 3782016 Dec 16 23:38 vmlinuz Any hint?
Well, the message is a bit different though: "The installation source given by device ['UUID=1212-FF34'] could not be found. Please check your parameter and try again."
Hi Diego, I'm also having the same issue with Fedora-14-i386-DVD.iso when transferred into a USB key and attempting to boot and install from there. Where you able to solve your issue? I'm also interested in a solution or a workaround for this bug. Any pointers? Thanks, -Ilyes
Hey Ilyes, Unfortunately I haven't tried it anymore.