Sorry, I can't reproduce your problem.

(In reply to Julio Entrena Perez from comment #0)
> Actual results:
> /boot/efi is not mounted

When I tried, /boot/efi was mounted during the upgrade process. I appended rd.upgrade.break=upgrade rd.upgrade.break=post to the upgrade kernel command line which drops me into a shell at appropriate points in the upgrade process. In the shell I did:

upgrade:/# cat /proc/mounts
(...)
/dev/mapper/VolGroup-lv_root /sysroot ext4 rw,relatime,data=ordered 0 0
(...)
/dev/vda2 /sysroot/boot ext4 rw,relatime,data=ordered 0 0
/dev/vda1 /sysroot/boot/efi vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro 0 0
(...)

> the bootloader configuration is stored there and
> it isn't updated thus. 

grub.conf at the end of the upgrade process seems to be updated:
upgrade-post:/# ls -lR /sysroot/boot/efi       
/sysroot/boot/efi:
total 4
drwx------ 3 root 0 4096 Feb 23 12:46 EFI

/sysroot/boot/efi/EFI:
total 4
drwx------ 2 root 0 4096 Feb 26 16:04 redhat

/sysroot/boot/efi/EFI/redhat:
total 256
-rwx------ 1 root 0   1459 Feb 26 16:04 grub.conf
-rwx------ 1 root 0 254317 Nov  9  2016 grub.efi

> System does not boot after upgrade.

For me the system boots after the upgrade. It is still using grub legacy, but that's expected (and I believe documented) - redhat-upgrade-tool does not install a new Grub. The old Grub seems to be able to boot the new system just fine. The old grub package is still there and owns the /boot/efi/EFI/redhat/grub.efi file:

# rpm -qf /boot/efi/EFI/redhat/grub.efi
grub-0.97-99.el6.x86_64

The grub configuration has been updated:

# ls -l /boot/efi/EFI/redhat/grub.conf 
-rwx------. 1 root root 1459 Feb 26 17:38 /boot/efi/EFI/redhat/grub.conf

and has the appropriate menu entries to boot into the new 7.4 system:
# cat /boot/efi/EFI/redhat/grub.conf
(...)
title Red Hat Enterprise Linux Server (3.10.0-693.el7.x86_64) 7.4 (Maipo)
        root (hd0,1)
        kernel /vmlinuz-3.10.0-693.el7.x86_64 root=/dev/mapper/VolGroup-lv_root (...)

I am wondering what may be different in your configuration - mine is a virtual machine.

Marian, I recall you had some problems with UEFI during an upgrade. Do you remember the details? Was there a test in the test suite for the redhat-upgrade-tool that would be exposing the issue?

bz1462672 has more information. I think that the problem may have been caused by the p-a module that attempted to upgrade Grub to Grub 2 and update the configuration and did it incorrectly. Since that module was replaced by a check which prevents the upgrade if UEFI is found, it seems to work if you override the check by a --force argument to r-u-t. The question is why there was a p-a UEFI module which attempted to do the Grub upgrade in the first place - in the non-UEFI case this is left to the user to be done manually after the upgrade is done.

(In reply to Pavel Cahyna from comment #5)
> bz1462672 has more information.

True. This is the cause or at least it has to be first step to ensure /boot/efi is mounted during upgrade phase (this is for redhat-upgrade-dracut? maybe already bug for that exists)

> it seems to work if you
> override the check by a --force argument to r-u-t.

Does this mean that 1) preuprade-assistant finished properly, 2) redhat-upgrade-tool did the job, 3) upgraded system started without issue?

I am bit doubtful. As far as I remember the fact that upgraded system was unable to boot was the reason of former effort (to upgrade grub)

(In reply to Marian Ganisin from comment #7)
> (In reply to Pavel Cahyna from comment #5)
> > bz1462672 has more information.
> 
> True. This is the cause or at least it has to be first step to ensure
> /boot/efi is mounted during upgrade phase (this is for
> redhat-upgrade-dracut? maybe already bug for that exists)

It is mounted. (under /sysroot/boot/efi)

> > it seems to work if you
> > override the check by a --force argument to r-u-t.
> 
> Does this mean that 1) preuprade-assistant finished properly

preupgrade-assistant forbids the upgrade (due to a change verified in https://bugzilla.redhat.com/show_bug.cgi?id=1462672#c2), that's why one needs to invoke redhat-upgrade-tool with --force

> 2) redhat-upgrade-tool did the job, 

yes, thanks to the change to preupgrade-assistant done in bz1462672 it does not touch grub during the upgrade, but otherwise the system gets upgraded fine.

> 3) upgraded system started without issue?

yes, the upgraded system just works with the old Grub.

> I am bit doubtful.

We sure would need more testing before declaring it supported.

> As far as I remember the fact that upgraded system was
> unable to boot was the reason of former effort (to upgrade grub)

Not sure, to me it rather seems that the effort to upgrade grub was breaking it.

Peter, could you please test this? What can be enough is to run the existing test suite on machine with UEFI. Is it possible to tell Beaker that you need machine with UEFI? For the upgrade to not be blocked by the Preupgrade Assistant UEFI module, there are a few options:
a) prepare special preupgrade-assistant-el6toel7 package which does not block upgrade on machines with UEFI
b) update the tests in the test suite to run with --force for redhat-upgrade tool. This option is probably not that wise.
c) update the tests in the test suite in a way that the Preupgrade Assistant UEFI module is not executed (hacking the preupgrade-assistant-el6toel7 package content a bit)

Hi Michal, sorry for the delay. I can test it manually with --force. And we will se how it goes. I'll let you know about the results.

(In reply to Michal Bocek from comment #9)
> Peter, could you please test this? What can be enough is to run the existing
> test suite on machine with UEFI. Is it possible to tell Beaker that you need
> machine with UEFI? For the upgrade to not be blocked by the Preupgrade
> Assistant UEFI module, there are a few options:
> a) prepare special preupgrade-assistant-el6toel7 package which does not
> block upgrade on machines with UEFI
> b) update the tests in the test suite to run with --force for redhat-upgrade
> tool. This option is probably not that wise.
> c) update the tests in the test suite in a way that the Preupgrade Assistant
> UEFI module is not executed (hacking the preupgrade-assistant-el6toel7
> package content a bit)

Hi Michal,

I was able to perform an upgrade from RHEL-6, Server, x86_64 with default package set to RHEL-7.5-20180228.1 without any major problem. I had to use --force as you mentioned before.

You worked with a virtual machine?

(In reply to shama_n1 from comment #12)
> You worked with a virtual machine?

No, I perfomed the upgrade on a regular hw.

Yes, I was using a VM.

Any news on this?

As internal tests fails for machines with UEFI, we do not plan any change until it will be investigated what's wrong. Nobody have time for that because of tasks with higher priority. I cannot estimate when this would be on the table again.

(In reply to pstodulk from comment #17)
> As internal tests fails for machines with UEFI, we do not plan any change
> until it will be investigated what's wrong. Nobody have time for that
> because of tasks with higher priority. I cannot estimate when this would be
> on the table again.

And what specific problems did you get?

(In reply to shama_n1 from comment #18)
> (In reply to pstodulk from comment #17)
> > As internal tests fails for machines with UEFI, we do not plan any change
> > until it will be investigated what's wrong. Nobody have time for that
> > because of tasks with higher priority. I cannot estimate when this would be
> > on the table again.
> 
> And what specific problems did you get?

That's question on QE guys.

When I was trying the upgrade on a UEFI system it worked. It was just a basic Server installation with a minimal package set. I don't remember I'd encounter any issue. But it was already a few months ago, so my memories are not exactly clear.

Closing this bug as all the further updates on this issue will continue under https://bugzilla.redhat.com/show_bug.cgi?id=1498186.
It may happen though that the issue won't be fixed since the RHEL 6 to RHEL 7 upgrade tooling is in a very low maintenance mode.

*** This bug has been marked as a duplicate of bug 1498186 ***