Bug 835663

Summary: f17 anaconda fails to install boot loader
Product: [Fedora] Fedora Reporter: Jim Bean <jimbean2633>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 17CC: anaconda-maint-list, bcl, collura, dennis, g.kaviyarasu, jonathan, mads, pjones, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-01 08:57:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Partition table (fdisk -l)
none
Log files archive
none
stracelog
none
stracelog #2
none
stracelog #3 none

Description Jim Bean 2012-06-26 18:33:15 UTC
Created attachment 594566 [details]
Partition table (fdisk -l)

Description of problem:
After normal install anaconda reports problem installing the bootloader and that the system may be unbootable, and it is. The master boot goes to bootmagic which gives selection of windows, F16 and now F17. The bootloader is to be installed in the front of a normal partition which previousely held the / of F15 (sdb1). This partition is on a different physical disk from the MBR.
Tried the install twice with the same result. The install medium is a bootable DVD + download. The F16 still bootss normally on sdb3. This machine has run every Fedora since 6 in the same configuration. The partition table is attached.

Version-Release number of selected component (if applicable):


How reproducible:
Normal install from DVD

Steps to Reproduce:
1.
2.
3.
  
Actual results:
system is unbootable

Expected results:


Additional info:

Comment 1 Brian Lane 2012-06-26 22:50:26 UTC
Please attach the logs from /tmp/*log (or /var/log/anaconda/ in the installed partition) to this bug as individual text/plain files.

Comment 2 Jim Bean 2012-06-27 02:32:44 UTC
Created attachment 594645 [details]
Log files archive

Comment 3 Mads Kiilerich 2012-06-27 12:03:05 UTC
18:41:55,789 INFO program: Running... grub2-install --force --no-floppy /dev/sdb1
18:41:58,201 ERR program: /usr/share/grub/grub-mkconfig_lib: line 53: 14836 Aborted                 "${grub_probe}" -t fs "$path" > /dev/null 2>&1
18:41:58,221 ERR program: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting.

There is a good chance that this crash is a problem that has been fixed since grub 2.0beta4. Please try with something like the unofficial snapshot at
http://koji.fedoraproject.org/koji/taskinfo?taskID=4152623 . A more official rc1 build might be available soon.

Comment 4 Brian Lane 2012-06-27 15:54:09 UTC
Please, no archive attachments, bugzilla can't search them. Individual text/plain files only.

Comment 5 Jim Bean 2012-06-28 00:07:30 UTC
For Mads,
I would like to test this but am over my head.
The reference above seems to be for RH insiders and I am an outsider.
I can mount the new partition from F16 and copy into it but:
what do I copy and
how do I get it.
I install using the basic and updates repositories.
Would re-installing after adding the test repository pick up the beta version?
Jim

Comment 6 Jim Bean 2012-07-19 23:07:29 UTC
Noting that the build above was accomplished on Jul-17 and may have picked up the beta grub2 I attempted the install again. The install log shows:
12:03:25 Installing grub2-2.0-0.37.beta6.fc17.x86_64
was installed. This seems to be the fixed grub2 but the same error is displayed and the system is again unbootable.
Jim

Comment 7 Jim Bean 2012-07-21 03:32:33 UTC
Prowling around the grub scripts I seem to have found something.
The file /boot/grub2/device.map, which is generated by anaconda, is being flagged as having an invalid entry. On F16 the file is:
# this device map was generated by anaconda
(hd0)      /dev/sda
(hd1)      /dev/sdb
while on F17 it is:
# this device map was generated by anaconda
(hd0)      /dev/sda
(hd1)      /dev/sdb
(hd1,3)      /dev/sdb3
where the last line is being flagged as invalid by /usr/sbin/grub2-probe.
The probe then returns "ext2" while the file system is actually ext3.
I hope this means something. :)
Jim

Comment 8 Vladimir Serbinenko 2012-07-21 09:45:46 UTC
What is the "same message"? I don't see any exact error message in your description

Comment 9 Vladimir Serbinenko 2012-07-21 09:46:45 UTC
GRUB doesn't distinguish between ext2 and ext3. As for invalid entry, it's ignored but it doesn't harm to remove device.map altogether.

Comment 10 Jim Bean 2012-07-21 23:34:59 UTC
(In reply to comment #8)
> What is the "same message"? I don't see any exact error message in your
> description

18:41:58,221 ERR program: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting.

Comment 11 Jim Bean 2012-07-21 23:51:32 UTC
(In reply to comment #9)
> GRUB doesn't distinguish between ext2 and ext3. As for invalid entry, it's
> ignored but it doesn't harm to remove device.map altogether.

Program grub2-probe messages that it ignores the error. It is however a fact that the return from grub2-probe is what triggers the message above and the abort. grub2-probe is flagging the partition as unreadable. I can mount the partition and read it so it is readable.

I could remove device.map but the installer would just put it back.

These scripts are complex and difficult for an amature to read so I may be all wet but I really think grub2-probe is the key here. Or not :)
Jim Bean

Comment 12 Mads Kiilerich 2012-07-23 14:39:01 UTC
(In reply to comment #6)
> Noting that the build above was accomplished on Jul-17 and may have picked
> up the beta grub2 I attempted the install again. The install log shows:
> 12:03:25 Installing grub2-2.0-0.37.beta6.fc17.x86_64
> was installed. This seems to be the fixed grub2 but the same error is
> displayed and the system is again unbootable.
> Jim

It is not sufficiently clear what you did and what you got.

If you reinstalled the system then please describe how you did it and attach the new log files.

Comment 13 Jim Bean 2012-07-23 20:26:25 UTC
(In reply to comment #12)
> (In reply to comment #6)
> > Noting that the build above was accomplished on Jul-17 and may have picked
> > up the beta grub2 I attempted the install again. The install log shows:
> > 12:03:25 Installing grub2-2.0-0.37.beta6.fc17.x86_64
> > was installed. This seems to be the fixed grub2 but the same error is
> > displayed and the system is again unbootable.
> > Jim
> 
> It is not sufficiently clear what you did and what you got.
> 
> If you reinstalled the system then please describe how you did it and attach
> the new log files.

I normally install using a bootable DVD and 2 repositories. This time I added the test repository to try to get the latest grub2. The install proceeds normally up to the boot install where it fails and aborts. Since the partition is complete except for the boot I can mount it from F16. Doing that the logs:

/mnt/root17/boot/install.log  the relevent portion
> > 12:03:25 Installing grub2-2.0-0.37.beta6.fc17.x86_64

/mnt/root17/var/log/anaconda/anaconda.program.log    grepping for grub
12:16:39,489 INFO program: Running... grub2-install --force --no-floppy /dev/sdb1
12:16:41,806 ERR program: /usr/share/grub/grub-mkconfig_lib: line 53: 15145 Aborted                 "${grub_probe}" -t fs "$path" > /dev/null 2>&1
12:16:41,820 ERR program: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting.

In comment 3 above grub2 at beta6 is mentioned as a possible solution but it seems to have been picked up this time, and didn't fix the problem

in /mnt/root17/usr/share/grub/grub-mkconfig_lib
procedure is_path_readable_by_grub ()
{
  path="$1"

  # abort if path doesn't exist
  if test -e "$path" ; then : ;else
    return 1
  fi

  # abort if file is in a filesystem we can't read
  if "${grub_probe}" -t fs "$path" > /dev/null 2>&1 ; then : ; else
    return 1
  fi
...

where $(grub_probe) is /mnt/root17/sbin/grub2-probe

This seems to be the point of failure since in
/mnt/root17/usr/sbin/grub2-install has

if ! is_path_readable_by_grub "${grubdir}"; then
    gettext_printf "Path \`%s' is not readable by GRUB on boot. Installation is impossible. Aborting.\n" "${grubdir}" 1>&2
    exit 1
fi

As in my comment 11 above it looks like grub2-probe is reporting the partition unreadable when it is in fact readable.
Hope my amature script snooping is of help. Jim Bean

Comment 14 Vladimir Serbinenko 2012-07-29 16:15:32 UTC
What triggers the problem is that grub-probe crashes, not the warning. Please take care to look which grub-probe was launched and exact arguments and whether it segfaults when you launch it manually. Then could you run it under gdb? It looks like you launch a newer grub-probe manually since it doesn't seem that you get a crash this way. Your analysis was going wrong way and you paraphrasing output made it only more difficult to understand. Please put exact messages and not speculation.

Comment 15 Jim Bean 2012-07-30 20:06:00 UTC
(In reply to comment #14)
> What triggers the problem is that grub-probe crashes, not the warning.
> Please take care to look which grub-probe was launched and exact arguments
> and whether it segfaults when you launch it manually. Then could you run it
> under gdb? It looks like you launch a newer grub-probe manually since it
> doesn't seem that you get a crash this way. Your analysis was going wrong
> way and you paraphrasing output made it only more difficult to understand.
> Please put exact messages and not speculation.

The last grub installed, according to /boot/install.log

> > 12:03:25 Installing grub2-2.0-0.37.beta6.fc17.x86_64

I regret that I cannot run grub2-probe for you since my F17 remains unbootable.
My attempt to run it from F16 was probably bogus since the F16 kernel dosn't match the F17 grub.
I can only usefully run grub2-probe by running anaconda.
When run by anaconda grub2-probe does not seem to crash.
Anaconda gives a sensible log message and offers to reboot, which of course fails. From /var/log/anaconda/anaconda.program.log

12:16:39,489 INFO program: Running... grub2-install --force --no-floppy /dev/sdb1
12:16:41,806 ERR program: /usr/share/grub/grub-mkconfig_lib: line 53: 15145 Aborted                 "${grub_probe}" -t fs "$path" > /dev/null 2>&1
12:16:41,820 ERR program: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting.

Looking at the install scripts below, grub2-probe must return to procedure
is_path_readable_by_grub, which returns to script grub2_install in order for that message to come out.

in /usr/share/grub/grub-mkconfig_lib is procedure
is_path_readable_by_grub ()
{
  path="$1"

  # abort if path doesn't exist
  if test -e "$path" ; then : ;else
    return 1
  fi

  # abort if file is in a filesystem we can't read
  if "${grub_probe}" -t fs "$path" > /dev/null 2>&1 ; then : ; else
    return 1
  fi
...

where $(grub_probe) is /sbin/grub2-probe

/usr/sbin/grub2-install has

if ! is_path_readable_by_grub "${grubdir}"; then
    gettext_printf "Path \`%s' is not readable by GRUB on boot. Installation is impossible. Aborting.\n" "${grubdir}" 1>&2
    exit 1
fi

So grub2-probe may crash but it returns rather than segfaulting.
Jim Bean

Comment 16 Jim Bean 2012-07-31 00:49:16 UTC
As an experiment I inserted a return 0 in grub-mkconfig_lib:

is_path_readable_by_grub ()
{
  path="$1"

  # abort if path doesn't exist
  if test -e "$path" ; then : ;else
    return 1
  fi

return 0

  # abort if file is in a filesystem we can't read
  if "${grub_probe}" -t fs "$path" > /dev/null 2>&1 ; then : ; else
    return 1
  fi
...

and ran anaconda in update mode. It attempted to install the bootloader and failed but the log is now different.
20:34:42,090 INFO program: Running... grub2-install --force --no-floppy /dev/sdb1
20:34:46,374 ERR program: xargs: /usr/sbin/grub2-probe: terminated by signal 6
20:34:46,623 ERR program: xargs: /usr/sbin/grub2-probe: terminated by signal 6

It looks like grub2-probe is now crashing on a call later in the process.

Jim Bean

Comment 17 Mads Kiilerich 2012-07-31 01:01:58 UTC
While booted on the installer media you can also launch a terminal and run
  bash -x grub2-install --force --no-floppy /dev/sdb1 2> log

In the log file you can see exactly which grub2-probe invocation failed. If in doubt attach the log file here.

Try to run grub2-probe with these parameters manually but add a --verbose and show us the output.

You can also try
  yum install strace
  strace -o stracelog grub2-probe ...
using the same parameters and attach stracelog here.

Comment 18 Jim Bean 2012-07-31 19:51:17 UTC
Created attachment 601572 [details]
stracelog

Comment 19 Jim Bean 2012-07-31 20:00:34 UTC
Typen in my comment but then added the attachment, which wiped the comment
running from the troubleshooting option of the installer
bash -x grub2-install --force --no-floppy --verbose /dev/sdb1 2>log  gave;

Install GRUB on your device

INSTALL_DEVICE must be system device filename

Report bugs ....

and nomal termination

tail var/log/anaconda/anaconda.program.log gives
00:33:55,834 INFO program: Running... /bin/mount -n -t ext2 -o defaults,bind /run/initramfs/live/ /mnt/install/source
20:34:09,836 INFO program: Running... /sbin/rsyslogd -c 4 -f /tmp/rsyslog_backend.conf -i /var/run/rsyslog_backend.pid
20:34:35,565 INFO program: Running... yum clean all
20:34:41,580 INFO program: Loaded plugins: langpacks, presto, refresh-packagekit
20:34:41,685 INFO program: Cleaning repos: fedora updates
20:34:41,685 INFO program: Cleaning up Everything
20:34:41,723 INFO program: No delta-package files removed by presto
20:34:42,090 INFO program: Running... grub2-install --force --no-floppy /dev/sdb1
20:34:46,374 ERR program: xargs: /usr/sbin/grub2-probe: terminated by signal 6
20:34:46,623 ERR program: xargs: /usr/sbin/grub2-probe: terminated by signal 6

strace -o stracelog grub2-install --force --no-floppy /dev/sdb1 2>log
gave normal termination.
stracelog attachment already up.
Hope this is what you wanted. Jim Bean

Comment 20 Mads Kiilerich 2012-08-03 11:47:59 UTC
No, that was not what I wanted.

But I think we must realize that it isn't feasible to debug this remotely.

I recommend getting involved early in fedora 18 testing. That will confirm if the issue has been resolved.

Comment 21 Jim Bean 2012-08-04 00:40:27 UTC
(In reply to comment #20)
> No, that was not what I wanted.
> 
> But I think we must realize that it isn't feasible to debug this remotely.
> 
> I recommend getting involved early in fedora 18 testing. That will confirm
> if the issue has been resolved.
Maybe this is what was wanted.

strace -o stracelog usr/sbin/grub2-probe --device-map=/boot/grub/device,map --target=fs /boot/grub

strace log attached

Comment 22 Jim Bean 2012-08-04 00:41:42 UTC
Created attachment 602210 [details]
stracelog #2

Comment 23 Mads Kiilerich 2012-08-04 23:03:55 UTC
(In reply to comment #21)
> Maybe this is what was wanted.
> 
> strace -o stracelog usr/sbin/grub2-probe --device-map=/boot/grub/device,map
> --target=fs /boot/grub

It could have been if that grub2-probe was what bash -x had shown was crashing.

(By the way: It might also be necessary to do a chroot first when running from a live / installer media. I can't explain in details how to do that.)

Comment 24 Jim Bean 2012-08-07 18:57:23 UTC
One more try. I put a log print after every probe call to identify exactly which ones are failing and did an anaconda update.

tail /mnt/root17/var/log/anaconda/anaconda.program.log
16:07:20,251 INFO program: Cleaning repos: fedora updates
16:07:20,252 INFO program: Cleaning up Everything
16:07:20,281 INFO program: No delta-package files removed by presto
16:07:20,544 INFO program: Running... grub2-install --force --no-floppy /dev/sdb1
16:07:24,637 ERR program: grub_device = /dev/sdb1.
16:07:25,156 ERR program: xargs: /usr/sbin/grub2-probe: terminated by signal 6
16:07:25,158 ERR program: fs_module = ext2.
16:07:25,385 ERR program: partmap_module =  part_msdos.
16:07:25,438 ERR program: xargs: /usr/sbin/grub2-probe: terminated by signal 6
16:07:25,440 ERR program: devabstraction_module = .
so the failing statements are:

fs_module="`echo "${grub_device}" | xargs "$grub_probe" --device-map="${device_map}" --target=fs --device `"
and

devabstraction_module="`echo "${grub_device}" | xargs "$grub_probe" --device-map="${device_map}" --target=abstraction --device`"

using the troubleshooting option of anaconda and chroot to /mnt/sysimage I ran;
strace -o stracelog2.1 "echo /dev/sdb1" | xargs "/usr/sbin/grub2-probe" --device-map=/boot/grub2/device.map --target=fs --device 
and it terminated signal 6

then
strace -o stracelog2.2 "echo /dev/sdb1" | xargs "/usr/sbin/grub2-probe" --device-map=/boot/grub2/device.map --target=abstraction --device 
and it also terminated signal 6

the two strace logs are attached as stracelog #3

Comment 25 Jim Bean 2012-08-07 18:58:26 UTC
Created attachment 602832 [details]
stracelog #3

Comment 26 Jim Bean 2012-08-28 00:32:22 UTC
One additional data point
I re-partitioned the disk so that /boot is in a separate partition.
The anaconda install now succeeds.

tail /var/log/anaconda/anaconda.program.log
16:55:32,562 INFO program: Running... grub2-install --force --no-floppy /dev/sdb6
16:55:37,227 ERR program: /usr/sbin/grub2-bios-setup: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
16:55:37,342 ERR program: Installation finished. No error reported.
16:55:37,548 INFO program: Running... grub2-set-default Fedora Linux, with Linux 3.5.2-1.fc17.x86_64
16:55:37,780 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg
16:55:38,639 ERR program: Generating grub.cfg ...
16:55:39,470 ERR program: Found linux image: /boot/vmlinuz-3.5.2-1.fc17.x86_64
16:55:39,525 ERR program: Found initrd image: /boot/initramfs-3.5.2-1.fc17.x86_64.img
16:55:45,365 ERR program: Found Microsoft Windows XP Professional on /dev/sda1
16:55:47,071 ERR program: Found Fedora release 16 (Verne) on /dev/sdb1

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63    37174409    18587173+  83  Linux          F16 /
/dev/sdb2        37174410    78124094    20474842+  fd  Linux raid     F16 /home
/dev/sdb3   *    78125056    78534655      204800   83  Linux          F17 /
/dev/sdb4        78534656   156301487    38883416    5  Extended
/dev/sdb5       119851008   155895807    18022400   83  Linux reserved F18 /boot
/dev/sdb6       155897856   156301311      201728   83  Linux          F17 /boot
/dev/sdb7        78538752   119851007    20656128   fd  Linux raid     F17 /home

Comment 27 Fedora End Of Life 2013-07-04 02:38:36 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 28 Fedora End Of Life 2013-08-01 08:57:14 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.