[ironic] IPA image does not want to boot with UEFI

Julia Kreger juliaashleykreger at gmail.com
Mon May 10 20:54:21 UTC 2021


My *guess* is that Secure Boot is being enforced and the asset being loaded
may not be signed, but I've never seen such issue a stacktrace. Just a hard
halt with a red screen on HPE gear.

Anyway, check the bios settings and try disabling secure boot enforcement.

-Julia

On Mon, May 10, 2021, 14:43 Vuk Gojnic <vuk.gojnic at gmail.com> wrote:

> I finally got some error messages. Mars Toktonaliev suggested following:
>
> "You could also change virtual serial port in BIOS to be COM1, and
> then try to SSH to iLO, run VSP command and monitor serial port
> output: chances are high that any errors will be dumped there."
>
> I did that and following happens:
> 1. I get to Grub
> 2. I load the kernel with "linux /vmlinuz nofb nomodeset vga=normal
> console=tty0 console=ttyS0,115200n8"
> 3. I try to load initrd. It blocks in the loop that throws following
> error in the loop (all in red letters - I suspect it is where red
> cursor is comming from :D ):
>
> X64 Exception Type 0x03 - Breakpoint Exception
>
> RCX=00000000454F9110 DX=0000000000000020 R8=000000006FA6E168
> R9=0000000000000000
> RSP=00000000454F92D8 BP=000000003D2E4B40 AX=00000000D176B0E2
> BX=000000003F3855C0
> R10=FFFFFFFFFFFFFFFF 11=000000003D2E5080 12=000000003D2E4FC0
> 13=000000003D2E4B00
> R14=0000000000020004 15=000000006FA677FE SI=00000000000000FF
> DI=000000003D2E4BE0
> CR2=0000000000000000 CR3=00000000454FA000 CR0=80000013 CR4=00000668
> CR8=00000000
> CS=00000038 DS=00000030 SS=00000030 ES=00000030 RFLAGS=00200297
> MSR: 0x1D9 = 00004801, 0x345=000033C5, 0x1C9=00000001
>
> LBRs From              To                From              To
> 01h  0000000000000006->0000000075B2406F  000000006FA6BB6B->000000006FA6BC88
> 03h  000000006FA6BF8D->000000006FA6BB42  000000006FA6BC8F->000000006FA6BF89
> 05h  000000006FA6BB6B->000000006FA6BC88  000000006FA6BF8D->000000006FA6BB42
> 07h  000000006FA6BC8F->000000006FA6BF89  000000006FA6BB6B->000000006FA6BC88
> 09h  000000006FA6BF8D->000000006FA6BB42  000000006FA6BC8F->000000006FA6BF89
> 0Bh  000000006FA6BB6B->000000006FA6BC88  000000006FA6BF8D->000000006FA6BB42
> 0Dh  000000006FA6BC8F->000000006FA6BF89  000000006FA6BB6B->000000006FA6BC88
> 0Fh  000000006FA6BF8D->000000006FA6BB42  0000000075B2407A->0000000078AB5660
>
> CALL ImageBase        ImageName+Offset
> 00h  0000000000000000 No Image Information
>
> CALL ImageBase        ImageName+Offset
>
>
>
>
> STACK   00h      04h      08h      0Ch      10h      14h      18h      1Ch
> RSP+00h 3F478E6D 3D2E4BE0 3D2E4FC0 00000001 3F37F208 6FA6A617 3F37F208
> 00000000
> RSP+20h 3F37F2C0 3F37F208 3F466A96 6FA6B52E 6FA67876 3F37F208 3F37F208
> 3F37F180
> RSP+40h 3F469F11 00000000 00000000 00000000 6FA6A2B7 3F44120B 6FA67851
> 3F441B6C
> RSP+60h 00000002 00000000 00000000 3F4354B2 6FA67851 3F43FAD4 2F89A000
> 3F440ACF
> RSP+80h 00000000 3F43FAD4 6FA67851 3F43EE6E 3F4337B7 3F37EDE0 6FA6AB8A
> 3F433814
> RSP+A0h 3F4338A6 6FA6CF13 3F380240 6FA6A0FD 6FA6C8F0 3F4FFFDA 3F3802C0
> 6FA6B149
> RSP+C0h 3F380540 74002D18 00000000 74012640 6FA63017 6FBEDDE8 453C4D9E
> 453C3380
> RSP+E0h 74006A18 73A51018 00000000 6F8FED98 6FA62000 00001000 798FE018
> 7400C398
>
>
> On Mon, May 10, 2021 at 2:28 PM Vuk Gojnic <vuk.gojnic at gmail.com> wrote:
> >
> > Hi Julia,hello everybody,
> >
> > I have finally got some time to test it further and found some
> interesting things (see below). I have also got some good tips and support
> in the IRC.
> >
> > I have changed the defaults and set both boot parameters to "uefi":
> > [deploy]
> > default_boot_mode = uefi
> >
> > [ilo]
> > default_boot_mode = uefi
> >
> > It is detecting the mode correctly and properly configures server to
> boot. See some latest extract from logs related to "openstack baremetal
> node provide" operation:
> >
> > 2021-05-10 08:45:28.233 561784 INFO ironic.conductor.task_manager
> [req-24fe55db-c252-471c-9639-9ad43a15137b - - - - -] Node
> ca718c74-77a6-46df-8b44-6a83db6a0ebe moved to provision state "cleaning"
> from state "manageable"; target provision state is "available"
> > 2021-05-10 08:45:32.235 561784 INFO ironic.drivers.modules.ilo.power
> [req-24fe55db-c252-471c-9639-9ad43a15137b - - - - -] The node
> ca718c74-77a6-46df-8b44-6a83db6a0ebe operation of 'power off' is completed
> in 2 seconds.
> > 2021-05-10 08:45:32.255 561784 INFO ironic.conductor.utils
> [req-24fe55db-c252-471c-9639-9ad43a15137b - - - - -] Successfully set node
> ca718c74-77a6-46df-8b44-6a83db6a0ebe power state to power off by power off.
> > 2021-05-10 08:45:34.056 561784 INFO ironic.drivers.modules.ilo.common
> [req-24fe55db-c252-471c-9639-9ad43a15137b - - - - -] Node
> ca718c74-77a6-46df-8b44-6a83db6a0ebe pending boot mode is uefi.
> > 2021-05-10 08:45:35.470 561784 INFO ironic.drivers.modules.ilo.common
> [req-24fe55db-c252-471c-9639-9ad43a15137b - - - - -] Set the node
> ca718c74-77a6-46df-8b44-6a83db6a0ebe to boot from URL
> https://10.23.137.234/tmp-images/ilo/boot-ca718c74-77a6-46df-8b44-6a83db6a0ebe.iso?filename=tmpi262v2zy.iso
> successfully.
> > 2021-05-10 08:45:43.485 561784 WARNING oslo.service.loopingcall [-]
> Function
> 'ironic.drivers.modules.ilo.power._wait_for_state_change.<locals>._wait'
> run outlasted interval by 1.32 sec
> > 2021-05-10 08:45:44.857 561784 INFO ironic.drivers.modules.ilo.power
> [req-24fe55db-c252-471c-9639-9ad43a15137b - - - - -] The node
> ca718c74-77a6-46df-8b44-6a83db6a0ebe operation of 'power on' is completed
> in 4 seconds.
> > 2021-05-10 08:45:44.872 561784 INFO ironic.conductor.utils
> [req-24fe55db-c252-471c-9639-9ad43a15137b - - - - -] Successfully set node
> ca718c74-77a6-46df-8b44-6a83db6a0ebe power state to power on by rebooting.
> > 2021-05-10 08:45:44.884 561784 INFO ironic.conductor.task_manager
> [req-24fe55db-c252-471c-9639-9ad43a15137b - - - - -] Node
> ca718c74-77a6-46df-8b44-6a83db6a0ebe moved to provision state "clean wait"
> from state "cleaning"; target provision state is "available"
> >
> > Everyhing goes ok and I come to Grub2.
> >
> > I can load the kernel with:
> > grub> linux /vmlinuz
> >
> > However when I try to load initrd with:
> > grub> initrd /initrd
> >
> > It first waits and goes to black screen with red cursor which is frozen.
> >
> > I have tried same procedure with standard ubuntu kernel and initrd  from
> http://archive.ubuntu.com/ubuntu/dists/bionic/main/installer-amd64/current/images/hd-media/
> and it works correctly and starts the installer.
> >
> > I went to try the combinations:
> > - kernel from Ubuntu server + initrd from custom IPA: this was failing
> the same way as described above
> > - kernel from IPA + initrd from Ubuntu server: this was working and
> starting the Ubuntu installer.
> > - kernel from Ubuntu servetr + initrd from IPA download server
> (ipa-centos8-stable-victoria.initramfs): failing same as above.
> >
> > I am pretty lost with what is going on :( Does anyone have more ideas?
> >
> > -Vuk
> >
> > On Thu, Apr 1, 2021 at 8:42 PM Julia Kreger <juliaashleykreger at gmail.com>
> wrote:
> >>
> >> Adding the list back and trimming the message. Replies in-band.
> >>
> >> Well, that is good that the server is not signed, nor other esp images
> >> are not working.
> >> On Thu, Apr 1, 2021 at 11:20 AM Vuk Gojnic <vuk.gojnic at gmail.com>
> wrote:
> >> >
> >> > Hey Julia,
> >> >
> >> > Thanks for asking. I have tried with several ESP image options with
> same effect (one taken from Ubuntu Live ISO that boots on that node,
> another downloaded and third made with grub tools). None of them was signed.
> >>
> >> Interesting. At least it is consistent! Have you tried to pull down
> >> the iso image and take it apart to verify it is UEFI bootable against
> >> a VM or another physical machine?
> >>
> >> I'm wondering if you need both uefi parameters set. You definitely
> >> don't have properties['capabilities']['boot_mode'] set which is used
> >> or... maybe a better word to use is drawn in for asserting defaults,
> >> but you do have the deploy_boot_mode setting set.
> >>
> >> I guess a quick manual sanity check of the actual resulting iso image
> >> is going to be critical. Debug logging may also be useful, and I'm
> >> only thinking that because there is no logging from the generation of
> >> the image.
> >>
> >> >
> >> > The server is not in UEFI secure boot mode.
> >>
> >> Interesting, sure sounds like it is based on your original message. :(
> >>
> >> > Btw. I will be on holidays for next week so I might not be able to
> follow up on this discussion before Apr 12th.
> >>
> >> No worries, just ping us on irc.freenode.net in #openstack-ironic if a
> >> reply on the mailing list doesn't grab our attention.
> >>
> >> >
> >> > Bests,
> >> > Vuk
> >> >
> >> > On Thu, Apr 1, 2021 at 4:20 PM Julia Kreger <
> juliaashleykreger at gmail.com> wrote:
> >> >>
> >> >> Greetings,
> >> >>
> >> >> Two questions:
> >> >> 1) Are the ESP image contents signed, or are they built using one of
> >> >> the grub commands?
> >> >> 2) Is the machine set to enforce secure boot at this time?
> >> >>
> >> >>
> >> [trim]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210510/5fd6bead/attachment-0001.html>


More information about the openstack-discuss mailing list