This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 465184 - hard disk install still not working in fedora 10 beta
hard disk install still not working in fedora 10 beta
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10Preview
  Show dependency treegraph
 
Reported: 2008-10-01 19:00 EDT by Tom Horsley
Modified: 2008-10-27 13:28 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-27 13:28:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tom Horsley 2008-10-01 19:00:14 EDT
Description of problem:
I tried my best to follow the instruction under repo= on the web page:

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

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:

/backup/iso-images/Fedora-10-Beta-x86_64-DVD/:
-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

/backup/iso-images/Fedora-10-Beta-x86_64-DVD/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:

/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
	root (hd0,1)
	kernel /boot/vmlinuz repo=hd:/dev/sdc5/iso-images/Fedora-10-Beta-x86_64-DVD vga=0xF07
	initrd /boot/initrd.img

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
option?).

Eventually it gets past that and I tell it about my keyboard, then it
tries to boot, and crashes:

loader received SIGSEGV!  Backtrace:
/sbin/loader(loaderSegvHandler+0x7e)[0x40966e]
/lib64/libc.so.6[0x5cf0130]
/lib64/libc.so.6(_strlen+0x10)[0x5d3fc50]
/lib64/libc.so.6(_IO_vfprintf+0x3dbe)[0x5d085ce]
/lib64/libc.so.6(__vfprintf_chk+0x95)[0x5dbddd5]
/sbin/loader(logMessageV+0xfc)[0x40ecdc]
/sbin/loader(logMessage+0x86)[0x40cd86]
/sbin/loader(mountHardDrive+0x5ce)[0x4181fe]
/sbin/loader(main+0xaa5)[0x40a985]
/lib64/libc.so.6(__libc_start_main+0xe6)[0x5cdb566]
/sbin/loader[0x407869]


Version-Release number of selected component (if applicable):
the fedora 10 beta DVD image (whatever version was shipped on there).

How reproducible:
every time

Steps to Reproduce:
1. see above
2.
3.
  
Actual results:
loader segfault

Expected results:
installer starts up

Additional info:
Comment 1 Tom Horsley 2008-10-01 19:08:12 EDT
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 :-).
Comment 2 David 2008-10-01 19:25:03 EDT
I see this same signature (with different addresses in the backtrace).
I was using the i386 F10-Beta release.

loader 0x804fd20
0x132400
libc 0x41320b
libc 0x3debb6
libc 0x498f81
loader 0x80538c4
loader 0x805392f
loader 0x805f7ad
loader 0x8051153
libc 0x3b16e5
loader 0x804d981
Comment 3 Chris Lumens 2008-10-02 10:28:37 EDT
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
vga=0xF07

Needs to be changed to:

 kernel /boot/vmlinuz repo=hd:/dev/sdc5:/iso-images/Fedora-10-Beta-x86_64-DVD
vga=0xF07

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.
Comment 4 David 2008-10-02 10:57:50 EDT
https://fedoraproject.org/wiki/Anaconda/Options shows this syntax:

repo=hd:<device>/<path>

I don't see the extra colon there.
Comment 5 Chris Lumens 2008-10-02 11:44:24 EDT
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.
Comment 6 Tom Horsley 2008-10-02 14:14:21 EDT
>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?).
Comment 7 Tom Horsley 2008-10-02 18:06:03 EDT
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.
Comment 8 Tom Horsley 2008-10-02 20:19:51 EDT
Finally got the exception saved to another system with scp,
figured I ought to call it a separate bug. See bug 465380.
Comment 9 Need Real Name 2008-10-03 13:15:49 EDT
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).
Comment 10 Timothy Murphy 2008-10-05 09:00:17 EDT
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?
Comment 11 Chris Lumens 2008-10-06 10:25:06 EDT
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.
Comment 12 Need Real Name 2008-10-06 10:52:57 EDT
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.

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