Red Hat Bugzilla – Bug 465184
hard disk install still not working in fedora 10 beta
Last modified: 2008-10-27 13:28:22 EDT
Description of problem:
I tried my best to follow the instruction under repo= on the web page:
I have an external USB drive, normally mounted as /backup:
/dev/sdc5 on /backup type ext3 (rw)
On that drive I have many ISO images, including the following tree for
x86_64 fedora10 beta:
-rw-r--r-- 1 root root 4232493056 Oct 1 17:39 Fedora-10-Beta-x86_64-DVD.iso
-rw-r--r-- 1 root root 910 Oct 1 17:39 SHA1SUM
drwxr-xr-x 2 root root 4096 Oct 1 17:52 images
-rw-r--r-- 1 root root 103862272 Oct 1 17:45 install.img
I copied the install.img from the iso as well as the initrd.img
and vmlinuz files which I stashed in /boot:
-rw-r--r-- 1 root root 17374095 Oct 1 17:46 initrd.img
-rwxr-xr-x 1 root root 2829920 Oct 1 17:46 vmlinuz
I then added this entry in /boot/grub/grub.conf:
title Install Fedora 10 beta x86_64
kernel /boot/vmlinuz repo=hd:/dev/sdc5/iso-images/Fedora-10-Beta-x86_64-DVD vga=0xF07
I boot, I spin for a vast amount of time trying to read the cdrom drive
which has nothing in it (If the kernel is never gonna fix the drivers
to detect media properly, can we at least add a cancel button in anaconda
to make it stop? Or even make it smart enough to see the repo=hd:
and not even look on the cdrom? Or add a forgodsakedontaccesshthecdrom
Eventually it gets past that and I tell it about my keyboard, then it
tries to boot, and crashes:
loader received SIGSEGV! Backtrace:
Version-Release number of selected component (if applicable):
the fedora 10 beta DVD image (whatever version was shipped on there).
Steps to Reproduce:
1. see above
installer starts up
P.S. That backtrace is from a hand transcription with me attempting
to read my handwriting, so don't be surprised if some e's and c's
or d's and b's got mixed up :-).
I see this same signature (with different addresses in the backtrace).
I was using the i386 F10-Beta release.
You've got a typo in your bootloader config. The following line:
kernel /boot/vmlinuz repo=hd:/dev/sdc5/iso-images/Fedora-10-Beta-x86_64-DVD
Needs to be changed to:
kernel /boot/vmlinuz repo=hd:/dev/sdc5:/iso-images/Fedora-10-Beta-x86_64-DVD
Note the extra colon in the repo= parameter. Anyway I believe I have also fixed the segfault. We'll see with the next build of anaconda.
https://fedoraproject.org/wiki/Anaconda/Options shows this syntax:
I don't see the extra colon there.
Gah, that is definitely an oversight in the documentation. I was sure I had changed that when I reformatted that section. Thanks for pointing it out.
>I don't see the extra colon there.
That's why I did a cut&paste of exactly what I typed in so someone could
find the obscure syntax I didn't quite get right :-).
So what about my other point on the cdrom? Any chance Anaconda will get
a cancel button for the "looking for media on cdrom" screen? Should I
make a separate bugzilla for that? (Or is there one already?).
OK, if I give it the missing ':' it does get much farther, but I left
it installing and came back later to find an unhandled exception
which is "most likely an internal error". Unfortunately, it asks
me to save the detailed exception report, but none of the options
for saving it work. I don't have a 2nd machine running ssh to scp
to, and it didn't ask me for any network config info anyway, so I
doubt it would be able to talk to the network even if I tried.
It also claimed there were no local storage devices to copy it to,
even though I tried sticking in a floppy and a usb stick.
The progress bar was almost done, and it said it was installing the
kernel at the point I found it.
Finally got the exception saved to another system with scp,
figured I ought to call it a separate bug. See bug 465380.
I had not seen this wiki document before trying hard disk installs myself (necessary due to having one of those disabled Intel e1000e NICs in my laptop... I've used network installs exclusively for many years).
This 10-Beta installer behavior seems like a regression in not allowing an interactive way to define the repo (aka method). I was prompted for what looked like a method, but that seems to be where it looked for the install.img and not where it looks for an entire repo or install media image?
I tried many permutations of putting install.img and the DVD ISO image on the same hard disk near each other, and also an unpacked copy of the DVD image tree. I was hoping that the installer would magically detect the presence of the full image "next to" the install.img, but no dice. I didn't guess the exact layout shown in the wiki.
I think the interactive prompts should go something like this:
1. choose install source/method (configuring repo= parameter)
2. make sure this repo has a repo behind it, or keep prompting, e.g. it is
not sufficient to just find install.img here
3. if install.img can also be retrieved from repo, skip to end
4. if necessary, prompted for install.img source (configuring stage2= param)
The current interaction allows you to provide just install.img with no indication that this is now forcing a network based installation (which makes it a dead-end on my machine with no active NIC during install).
There seem to be several points raised above.
I would like to concentrate on the fact
that in Fedora-10 when installing from hard disk
one is no longer asked for the location of the distribution ISO,
but rather for the location of install.img .
As far as I can see, the actual distribution ISO
is never looked at.
Is this deliberate?
Or was it an oversight?
This is all deliberate. Basically we are trying to make things as easy as possible for the common case, which is people either using the media or using the boot.iso + the Fedora mirrors site.
For the rest of us, you'll either need to specify things via stage2=/repo= or use the askmethod boot parameter, which is still there and brings up the familiar method selection screen you are used to.
The purpose of the loader has also changed somewhat to where it basically knows nothing about installation repositories. All it does is look for the stage2 image and then leave the rest up to it. We are deliberately trying to break the tie between install.img and an installation repo, which is why is is sufficient to just find an install.img somewhere.
Deliberate changes are not regressions.
Sorry for hijacking the original bug a little. It sounds like Tom's original bug is resolved with corrections to the document about the repo URL format, and he's opened a separate bug for the later install failure?
I will do another test later with the askmethod parameter and see if I do get prompted for the repo location. After I play, I will file a new bug if I find what seems like a further usability issue.