Bug 1203641

Here comes the serial console logs:
 https://openqa.suse.de/tests/9525060/logfile?filename=serial0.txt

And from https://openqa.suse.de/tests/9525060#step/first_boot/1, we can see it enters into emergency mode.

In the video, from 3:18 on the console says:

  You are in emergency mode. After logging in, type 
  "journalctl -xb" to view system logs, "systemctl reboot"
  to reboot, "systemctl default" or "exit" to boot into
  default mode.

  Give root password for maintenance
  (or press Control-D to continue):


This isjust after a (crude) Plymouth screen with 3 green dots, the last of them highlighted.

IIRC that means that the kernel did boot, but systemd got stuck during initializing the newly booted system.

I also see some dozen of those messages in serial0.txt (however significant they may be):

  Lockdown: init: /dev/mem,kmem,port is restricted;
  see man kernel_lockdown.7

Unfortunately, there are no y2logs yet at this stage, so I guess you will have to do some manual debugging to find out what exactly went wrong.

Maybe more logs like the y2logs or the journal can be salvaged by logging in in that systemd emergency mode. At least finding out what filesystems are already mounted will probably be helpful ("mount", "df", "lsblk" or whatever is actually available in that state).

(In reply to Stefan Hundhammer from comment #3)
> I also see some dozen of those messages in serial0.txt (however significant
> they may be):
> 
>   Lockdown: init: /dev/mem,kmem,port is restricted;
>   see man kernel_lockdown.7
> 
> Unfortunately, there are no y2logs yet at this stage, so I guess you will
> have to do some manual debugging to find out what exactly went wrong.
> 
> Maybe more logs like the y2logs or the journal can be salvaged by logging in
> in that systemd emergency mode. At least finding out what filesystems are
> already mounted will probably be helpful ("mount", "df", "lsblk" or whatever
> is actually available in that state).

I will try to collect the y2logs

The issue was gone when I tried to re-run the test
https://openqa.suse.de/tests/9602611#

Let me run more times to see if it can be reproduced stably.
# for i in {1..5};do openqa-clone-job  --from http://openqa.suse.de --host http://openqa.suse.de 9602611 _GROUP_ID=0 -skip-download --skip-chained-deps BUILD=rfan1_uefi_hyperv TEST=rfan1_uefi_hyperv RETRY=0;done
Created job #9603519: sle-15-SP5-Online-x86_64-Build24.1-default@svirt-hyperv-uefi -> http://openqa.suse.de/t9603519
Created job #9603520: sle-15-SP5-Online-x86_64-Build24.1-default@svirt-hyperv-uefi -> http://openqa.suse.de/t9603520
Created job #9603521: sle-15-SP5-Online-x86_64-Build24.1-default@svirt-hyperv-uefi -> http://openqa.suse.de/t9603521
Created job #9603522: sle-15-SP5-Online-x86_64-Build24.1-default@svirt-hyperv-uefi -> http://openqa.suse.de/t9603522
Created job #9603523: sle-15-SP5-Online-x86_64-Build24.1-default@svirt-hyperv-uefi -> http://openqa.suse.de/t9603523

https://openqa.suse.de/tests/9621050#

I can see some systemd service failed there.

https://openqa.suse.de/tests/9621050#step/first_boot/10

Created attachment 861792 [details]
y2logs for hyperv

BTW, not sure if the issue has something to do with  
https://bugzilla.suse.com/show_bug.cgi?id=1202731

@kernel team:
There is number of 

Lockdown: init: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7

recods at the end of serial0.txt. Can it somehow be a consequence of an issue in the bootstrap? Can we find what it is caused by?