Bug 1479960 - grub2 symlink handling causing FAH ISO installer failures
grub2 symlink handling causing FAH ISO installer failures
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2017-08-09 15:59 EDT by Jonathan Lebon
Modified: 2017-09-25 14:25 EDT (History)
4 users (show)

See Also:
Fixed In Version: grub2-2.02-8.fc27
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-09-25 14:25:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Handle relative symlink targets (1.21 KB, patch)
2017-08-14 14:40 EDT, Jonathan Lebon
no flags Details | Diff

  None (edit)
Description Jonathan Lebon 2017-08-09 15:59:30 EDT
Description of problem:

We're getting errors from grub2-install during anaconda installs of FAH Rawhide:


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


How reproducible:


Steps to Reproduce:
1. Download installer ISO
2. Install FAH

Actual results:

21:37:46,576 INF program: Running... grub2-install --no-floppy /dev/sda
21:37:49,008 INF program: Installing for i386-pc platform.
21:37:49,010 INF program: grub2-install: error: cannot rename the file /boot/grub2/grubenv.new to /boot/grub2/grubenv: No such file or directory.
21:37:49,010 DBG program: Return code: 1

Expected results:

No errors

Additional info:

I think this is caused by:


which changed /boot/grub2/grubenv to be a symlink to a
relative path rather than an absolute one.

Looking at the strace output, it seems like grub tries to
read the link first and rename directly to its target to
avoid clobbering the symlink itself, which leads to:

rename("/boot/grub2/grubenv.new", "../efi/EFI/fedora/grubenv") = -1 (ENOENT) (No such file or directory)

I.e. the rename(2) is now sensitive to what the cwd is at
the time it's invoked, which is most likely /.
Comment 1 Dusty Mabe 2017-08-11 15:42:24 EDT
some notes from IRC:

15:17:28   dustymabe | hey pjones - got a sec? 
15:17:53      pjones | dustymabe: how much of a second?
15:17:59      pjones | maybe, what's the issue?
15:18:08   dustymabe | https://bugzilla.redhat.com/show_bug.cgi?id=1479960   
15:18:16   dustymabe | have you seen that by chance? 
15:20:46      pjones | I hadn't, but I think I saw a patch that might fix it anyway
15:20:51           * | pjones looking now
15:20:55   dustymabe | thanks
15:21:24   dustymabe | if you want to make us a build we can get it tested 
15:22:34         <-- | wcohen (wcohen@nat/redhat/x-okwxpxsjftrqcgvs) has quit (Ping timeout: 255 seconds)
15:22:35         <-- | pwhalen (~pwhalen@unaffiliated/pwhalen) has quit (Ping timeout: 255 seconds)
15:25:09      pjones | Oh, the thing I saw actually fixes a different (tangentially related) problem :/
15:27:30   dustymabe | boo
15:30:03      pjones | dustymabe: so I don't really have time to hack on it right now, but if you want to give it a go, I suspect basically it's just
                     | needing rename_target be the directory portion of "name" + "/" + rename_target instead, at
                     | https://github.com/rhboot/grub2/blob/fedora-27/util/editenv.c#L95
15:30:55   dustymabe | pjones: quick question - do you think this affects just atomic host or other fedora types as well? 
15:31:21   dustymabe | and when you say 'don't really have time to hack on it right now' do you mean today, this week, this month?
15:31:31      pjones | "until I've landed my f27 features"
15:32:14      pjones | well, probably anything that runs grub2-editenv from is affected, but there's not a lot that does that.
15:32:36      pjones | ... and not quite everything, because it depends on what CWD is when you invoke it
15:32:47   dustymabe | ok

jlebon might be able to look at this on monday.
Comment 2 Jonathan Lebon 2017-08-14 14:40 EDT
Created attachment 1313303 [details]
Handle relative symlink targets
Comment 3 Jonathan Lebon 2017-08-14 14:42:29 EDT
Tested working at least in the Fedora Atomic flow.
Comment 4 Jan Kurik 2017-08-15 03:30:03 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.
Comment 5 Dusty Mabe 2017-08-15 22:56:01 EDT
@pjones, what's the verdict on the patch?
Comment 6 Dusty Mabe 2017-09-25 14:25:18 EDT
I believe this is resolved now.

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