Bug 978649 - Fedora 19Beta, install to USB, boot fails because grub points to hd0 when should be hd1, easy fix
Fedora 19Beta, install to USB, boot fails because grub points to hd0 when sho...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-26 22:45 EDT by sj
Modified: 2013-07-10 12:42 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-10 12:42:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description sj 2013-06-26 22:45:00 EDT
Description of problem:
I installed Fedora 19 Beta net install 64bit to a USB drive (/dev/sdb).  On reboot, I see the grub menu, but the boot fails.

Version-Release number of selected component (if applicable):
Fedora-19-Beta-x86_64-netinst.iso 328,204,288 bytes

How reproducible:
Install to USB2 external device that is not the first hard drive (/dev/sdb)

Steps to Reproduce:
1. Install Fedora 19Beta to a USB drive in a USB2 port
2. After completing the install, reboot
3. Select any item in the grub menu and hit enter

Actual results:
The screen clears, then starts booting from my other hard drive.

Expected results:
Boot from USB (which does work now that i fixed grub settings)

Additional info:
The grub menu (/boot/grub2/grub.conf) listed "hd0" in several places--I just changed it to "hd1" and it boots fine. The install process should detect the drive number and should have coded "hd1" during the installation process.
Comment 1 sj 2013-06-30 15:52:19 EDT
I want to modify this... i have reformatted that disk, but i installed another version of F19beta and noticed that /boot/grub/device.map pointed both (hd0) and (hd1) to /dev/sdb.  In other words, the grub config file could say (hd0) and perhaps is could point to any device on the machine.  I might not like that trick with the device map, but it might be a "feature" rather than a bug.  I'm not sure why I have had seemingly random trouble booting from my USB drive.
Comment 2 Brian Lane 2013-07-08 20:26:20 EDT
Please attach the logs from /var/log/anaconda/* as individual text/plain files.
Comment 3 sj 2013-07-09 21:44:08 EDT
In response to Brian Lane, I have since reformatted that disk and suspect that there is/was an unrelated problem related to booting from the USB drive.  Note that I posted a comment above describing why the hd0 thing might not have been the problem.  I'll copy that here:

"I want to modify this... i have reformatted that disk, but i installed another version of F19beta and noticed that /boot/grub/device.map pointed both (hd0) and (hd1) to /dev/sdb.  In other words, the grub config file could say (hd0) and perhaps is could point to any device on the machine.  I might not like that trick with the device map, but it might be a "feature" rather than a bug.  I'm not sure why I have had seemingly random trouble booting from my USB drive."

As for the boot problems now (after reformatting and using the F19Beta 64bit x86 live DVD),  I typically need to boot around three times before it works, but it does consistently work after a few tries!  The problem occurs before the kernel can load.  Note that I used LUKS to encrypt the disk and the new problem (which might be the same as the old problem) happens before I decrypt the disk.  I found no log file in my /boot partition (and the rest of my disk is still encrypted when the problem occurs), but I can reboot and make some notes with a pencil and transcribe them here...
Comment 4 sj 2013-07-09 22:34:31 EDT
(In reply to Brian C. Lane from comment #2)
> Please attach the logs from /var/log/anaconda/* as individual text/plain
> files.

i couldn't attach the files here, i posted them here:
https://mega.co.nz/#F!FpQykCqS!A2x-sX7G9qZ5SVckPfw_qA

Here are some error messages that I transcribed from the screen in the past hour when I tested the boot problem.  Note that I reformatted it since the last post here, and I typically need to boot several times before it works, then I can use my computer without any problems.  I do not know if the problem is related to anaconda or if the (hd0) thing had any impact (because sometimes the computer boots and sometimes it doesn't).

Note that all of this happens before the system partition is decrypted, so nothing could possibly be written to /var/log.

1) I get to the GRUB menu and select 3.9.9-301.fc19.x86_64

The message says "loading initial ramdisk"

Initramfs unpackgin failed: no cpio magic
systemd[1] Cannot open /etc/machine-id: no such file.
systemd[1] Failed to load default target: no such file or directory
systemd-cgroups-agent[62]: Failed to get D-Bus connetion: Failed to connect to socket /org/freedesktop/systemd1/private: connection refused

2) after a few successful boots, I got this one after selected 3.9.9-301.fc19.x86_64 from the GRUB menu:
Initramfs unpackgin failed: no cpio magic
Kernal panic-not syncing: VFS: Unable to mount root fs on unknown block(0,0)
	Pid: 1, comm: swapper/0 Not tainted 3.9.9-301.fc19.x86_64
	[some dump info]

3) after a few successful boots, I got this one
Grub loading
Welcome to GRUB!
error: invaldi arch-indpendent ELF magic
Entering rescue mode

4) and after a few successful boots, I got this one
Grub loading
Welcome to GRUB!
error: symbol '_strlen' not found
Comment 5 Brian Lane 2013-07-10 12:42:53 EDT
I'm not sure what's going on, but it seems pretty clear that you have some flaky hardware. Not much we can do about that.

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