[Q4-rc5] Blank screen on boot after installation on Lenovo

[glu...@gmail.com]

I saw some other similar posts, but they didn't have resolutions or were for different systems.

Any suggests/help would be appreciated! -Thanks!

Issue:
After a successful installation of Q4 rc5 from USB the machine booted, and is displayed the following 4 lines:
Xen 4.0.3 (c/s ) EFI loader
Using configuration file 'xen.cfg'
vmlinuz-4.14.18-1.pvops.qubes.x86_64: 0x00(details removed)
initramfs-4.14.18-1.pvops.qubes.x86_64.log: 0x00(details removed)

Then the screen goes blank (it's still on, but is just black)

Additional information:
I've been working on Linux since it was first created, but this is my first Qubes install. If you don't have an idea based on the info here, can you point me to any good technical documentation on the boot sequence/process? -Thanks!

If I hit the power button right away it turns off immediately, but if I wait a little, I need to hold the button down for 10 seconds to turn it off.

System config:
Lenovo Flex 3-1570
CPU: Intel® Core™ i7-5500U CPU @ 2.40GHz × 4
Ram: 8GB
Graphics: Intel® HD Graphics 5500 (Broadwell GT2)
Graphics2: nVidia GeForce 920M
BIOS updated last week to latest and Virtualization enabled

Installed both with and without encryption and encountered the same issue.

Pulled the following using a live Debian:
xen.cfg:
[global]
default=4.14.18-1.pvops.qubes.x86_64

[4.14.18-1.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx
kernel=vmlinuz-4.14.18-1.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rhgb quiet
ramdisk=initramfs-4.14.18-1.pvops.qubes.x86_64.img

[4.14.18-1.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx
kernel=vmlinuz-4.14.18-1.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rhgb quiet
ramdisk=initramfs-4.14.18-1.pvops.qubes.x86_64.img


/loader/entries/01642511d1574586af89ff95c3051e06-4.14.18-1.pvops.qubes.x86_64.conf:
title Qubes 4.0 (R4.0)
version 4.14.18-1.pvops.qubes.x86_64
machine-id 01642511d1574586af89ff95c3051e06
options inst.stage2=hd:LABEL=Qubes-R4.0-rc5-x86_64 i915.alpha_support=1
linux /01642511d1574586af89ff95c3051e06/4.14.18-1.pvops.qubes.x86_64/linux
initrd /01642511d1574586af89ff95c3051e06/4.14.18-1.pvops.qubes.x86_64/initrd

[anon]

If it helps same problem here, after using the Thinkpad Troubleshooting
docs link, went through the whole thing, then there is *No xen.cfg  to
change to BOOT only a efi.cfg (which I saw in another post in the
usergroup someone also saw) ;  I changed the efi.cfg  references to BOOT
and was able to install, but after install  in EFI mode,   I get display
problems with the boot up penguins and loading then the blank screen.  
This is a T520 series...

So, I went back to the legacy install and all is well for now

[berto0...@gmail.com]

I'm having the same issue on a Thinkpad X230 with the latest Lenovo BIOS (2.71). Installation went fine, XEN is booting and throwing many lines without any obvious errors (please let me know how to obtain that log as text if possible, else I have an actual photo of the screen), the the screen is going black.

This is my XEN.cfg:

[global]
default=4.14.18-1.pvops.qubes.x86_64

[4.14.18-1.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx

kernel=vmlinuz-4.14.18-1.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-8dd628c2-8acf-4452-8935-b580856aeed6 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rhgb quiet
ramdisk=initramfs-4.14.18-1.pvops.qubes.x86_64.img

[4.14.18-1.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx

kernel=vmlinuz-4.14.18-1.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-8dd628c2-8acf-4452-8935-b580856aeed6 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rhgb quiet
ramdisk=initramfs-4.14.18-1.pvops.qubes.x86_64.img

Any help is appreciated.

[awokd]

Did you try step #11 under
https://www.qubes-os.org/doc/uefi-troubleshooting/#cannot-start-installation-installation-completes-successfully-but-then-bios-loops-at-boot-device-selection-hangs-at-four-penguins-after-choosing-test-media-and-install-qubes-os-in-grub-menu
? If it didn't help, you could also try to reinstall in legacy mode.

[glu...@gmail.com]

After setting UEFI/Legacy Boot to "Legacy Only" and Boot Priority to "Legacy First", I was able to complete the installation and setup process. Qubes is now running, although with a bunch of errors.

I'm going to experiment to see if I can get it working with UEFI. I'll try @awokd's advice and post my results.

Also, in case it's relevant, the system is using a Samsung 860EVO 500GB SSD.

[glu...@gmail.com]

On Sunday, March 25, 2018 at 4:29:40 AM UTC-7, awokd wrote:
> Did you try step #11 under
> https://www.qubes-os.org/doc/uefi-troubleshooting/#cannot-start-installation-installation-completes-successfully-but-then-bios-loops-at-boot-device-selection-hangs-at-four-penguins-after-choosing-test-media-and-install-qubes-os-in-grub-menu
> ? If it didn't help, you could also try to reinstall in legacy mode.

Thanks @awokd! That also worked! Now UEFI also works. :)

[awokd]

On Sun, March 25, 2018 10:24 pm, glu...@gmail.com wrote:
> On Sunday, March 25, 2018 at 4:29:40 AM UTC-7, awokd wrote:
>
>> Did you try step #11 under
>> https://www.qubes-os.org/doc/uefi-troubleshooting/#cannot-start-installa
>> tion-installation-completes-successfully-but-then-bios-loops-at-boot-de
>> vice-selection-hangs-at-four-penguins-after-choosing-test-media-and-ins

>> tall-qubes-os-in-grub-menu ? If it didn't help, you could also try to

>> reinstall in legacy mode.
>
> Thanks @awokd! That also worked! Now UEFI also works. :)

Thanks for reporting back! Unfortunately, there are a lot of buggy UEFI
implementations out there so it's good to know this work-around can still
help in some cases under 4.0.

[berto0...@gmail.com]

> Did you try step #11 under
> https://www.qubes-os.org/doc/uefi-troubleshooting/#cannot-start-installation-installation-completes-successfully-but-then-bios-loops-at-boot-device-selection-hangs-at-four-penguins-after-choosing-test-media-and-install-qubes-os-in-grub-menu

This also fixed it for me. I am getting to the luks password page now.

My disk password is never accepted, though. I have tried to login on the console instead and did a complete reinstall with another disk password and the same result.

Can adding kernel parameters mess with Luks/EFI in any way? The laptop also has a TPM chip built-in.

[awokd]

Are you using a non-default keyboard layout? You might have to regenerate
initramfs with the host only option.

dracut -H -f /boot/efi/EFI/qubes/initramfs-$(uname -r).img $(uname -r)

Might be best to do this at the end of the install by switching to the
terminal before the reboot, or else I'm not sure how you can get back in.

[berto0...@gmail.com]

> Are you using a non-default keyboard layout? You might have to regenerate
> initramfs with the host only option.

Thanks. It turned out that Qubes always assumes an US keyboard layout for the LUKS unlock, even if a different keyboard was specified in the installation. I had an ASCII character in my password that is on a different key; I had never noticed that before.

Is the fixed keyboard layout by design or should it be considered a bug?

[awokd]

It's in a bit of an indeterminate state right now:
https://github.com/QubesOS/qubes-issues/issues/2971. Did regenerating
initramfs with host only fix it for you, or did you just leave the
keyboard setting on US on the reinstall?

[berto0...@gmail.com]

> It's in a bit of an indeterminate state right now:
> https://github.com/QubesOS/qubes-issues/issues/2971. Did regenerating
> initramfs with host only fix it for you, or did you just leave the
> keyboard setting on US on the reinstall?

Actually, I just pressed the keys as on an imaginary US keyboard after realizing one key was in a different position. That's a quite common method for non-US users -- you just need to be aware that you are dealing with a moved key in the first place. And there is no feedback when typing a password as first task on a new OS, obviously.

[awokd]

Sounds like that linked issue's not resolved. If you have a Github
account, mind commenting on it with your experience and pinging
@andrewdavidwong? I can do it later too, if you don't. If you get a chance
to regenerate with -H, I'm curious if that fixes it too. Shouldn't (TM)
hurt anything.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Have you tried final 4.0 image? There were some fixes that didn't
managed to get included in rc5.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlq3FxMACgkQ24/THMrX
1yyY2gf/aMKU0Z5QePTIlSvlCv+w5Q+izB8ROYhVB2u924BN+cdJOpeucLV9BCJD
XjpxhT9jcmPa92VB8Y9ZYuuh0xHD2+2961/Gi84cgtyUhAeqPNwzixkQDFkQNDCk
LwjauR3+qR/ESQQjrnwEQj9wUSWdNaAeU3CKBbl2xyu7R1/mNQbiEKpN0hbaZ0S9
ByZ3DzL5s2TC5Eulc134mCLba7W1Na6cUYeh4pC2caUztJOOIFWuqB8Jqyu0vEvp
l+SidbOeHoMdlTZEBx9VZzab/Xk1DqbuLHqkDU09XaSLlBzEahC/AW5Oz0Z1TJry
K/ZJNK6aVK74WDN/oBvfeswxas3UOg==
=uk26
-----END PGP SIGNATURE-----

[qubes-us...@ralphdouglass.com]

On Sunday, April 1, 2018 at 2:02:15 PM UTC-4, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Wed, Mar 28, 2018 at 11:25:18AM -0000, 'awokd' via qubes-users wrote:

> > On Wed, March 28, 2018 2:09 am, berto00000001 wrote:
> > >> It's in a bit of an indeterminate state right now:
> > >> https://github.com/QubesOS/qubes-issues/issues/2971. Did regenerating
> > >> initramfs with host only fix it for you, or did you just leave the
> > >> keyboard setting on US on the reinstall?
> > >
> > > Actually, I just pressed the keys as on an imaginary US keyboard after
> > > realizing one key was in a different position. That's a quite common
> > > method for non-US users -- you just need to be aware that you are dealing
> > > with a moved key in the first place. And there is no feedback when typing
> > > a password as first task on a new OS, obviously.
> >
> > Sounds like that linked issue's not resolved. If you have a Github
> > account, mind commenting on it with your experience and pinging
> > @andrewdavidwong? I can do it later too, if you don't. If you get a chance
> > to regenerate with -H, I'm curious if that fixes it too. Shouldn't (TM)
> > hurt anything.
>
> Have you tried final 4.0 image? There were some fixes that didn't
> managed to get included in rc5.

The issue appears to still present in the final 4.0 release based on the results of my reinstall this weekend.

(I don't know if this is the source of the problem, but I watched the installer switch the the keyboard layout listed in the upper right hand corner from my chosen preference back to 'us' while installing packages. I think maybe somewhere between package number 700 and 800. By the end of the install the keyboard listed in the upper right hand corner was switched back to what I had previously selected. Post install rpm script doing this or something?!?)