F2 stoped working after last kernel update

[dimi]

We used to be able to switch to console when typing password or after to see messages, now just black screen.
Pressing F2 again shows GUI.

[awokd]

dimi:

> We used to be able to switch to console when typing password or after to
> see messages, now just black screen.
> Pressing F2 again shows GUI.
>

Check to make sure "rhgb quiet" didn't get added to your boot options.
Also, isn't it ctrl-alt-F2, or is that only once inside XFCE?

--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

[dimi]

Check to make sure "rhgb quiet" didn't get added to your boot options.
Also, isn't it ctrl-alt-F2, or is that only once inside XFCE?

There is no rhgb quiet in /boot/efi/EFI/qubes/xen.cfg
I have been pressing just F2 to unlock Kernel with passphrase for over a year now and i was being able to read dmesg messages until XFCE login prompt.
Already tried combinations of ctrl-alt-F2, alt-ctrl-Fx, alt-Fx and none shows the console.

Today's Kernel update showed some dmesg but way after kernel unlocking and right before XFCE Login.

My guess, it might be driver related. I do run qubes with a rx 480 since my mobo/cpu does not have intel grafix.

My xen.xfg,

options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off pci=noaer

(Since install, there have been countless pcieport 0000:00:01.1: AER: Corrected error received: 0000:00:01.1 messages with PCIe Bus Error: severity=Corrected from the rx 480 and tried to stop displaying them with pci=noaer but the option has not helped yet.)

Since i do not exactly remember where i added the pci=noaer, i cannot find /etc/default/grub to eddit options, could you be so kind and point as to where one modifies kernel options?

[awokd]

dimi:

> There is no rhgb quiet in /boot/efi/EFI/qubes/xen.cfg
> I have been pressing just F2 to unlock Kernel with passphrase for over a
> year now and i was being able to read dmesg messages until XFCE login
> prompt.
> Already tried combinations of ctrl-alt-F2, alt-ctrl-Fx, alt-Fx and none
> shows the console.

OK.

> My xen.xfg,
> options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode
> =scan smt=off pci=noaer

> Since i do not exactly remember where i added the pci=noaer, i cannot find
> /etc/default/grub to eddit options, could you be so kind and point as to
> where one modifies kernel options?

Looks like you're using UEFI boot instead of grub, so kernel options are
right next door to the Xen options in xen.cfg- look one line down for
"kernel=". :) This is where I see rhgb quiet.
Plymouth.ignore-serial-consoles is new; you might also try removing, but
it could be there for a reason.

[dimi]

Looks like you're using UEFI boot instead of grub, so kernel options are
right next door to the Xen options in xen.cfg- look one line down for
"kernel=". :) This is where I see rhgb quiet.
Plymouth.ignore-serial-consoles is new; you might also try removing, but
it could be there for a reason.

Contrary to my believe i did had not searched for rhgb and just assumed it would be in the "options=" line.
You were right, after deleting it from the kernel i see dmesg messages and slight different UI for password. ESC key switches back and forth.
Also adding pci=noaer in the kernel line finally removed the messages. Thanks.

Could not find a solution how, if even possible to pick which kernel to boot or/and modify kernel parameters before booting like i am used from grub by pressing 'e'.
Does UEFI Boot support this or/and how can i safely switch my setup to grub boot? I would like to see what happens when i remove the plymouth option (:

[awokd]

dimi:

> Could not find a solution how, if even possible to pick which kernel to
> boot or/and modify kernel parameters before booting like i am used from
> grub by pressing 'e'.
> Does UEFI Boot support this or/and how can i safely switch my setup to grub
> boot? I would like to see what happens when i remove the plymouth option (:
>

UEFI boot doesn't support on-the-fly modifications like grub. You can
edit that xen.cfg and change the default= to a different entry, but it
won't take effect until next boot. It might be possible to switch boot
to grub, but I wouldn't call it "safe". Some of the new systems only
support UEFI booting, for example, so switching to grub might break boot.

However, as long as you have a Live boot image of some type nearby, you
can try edits in your xen.cfg. If it breaks something, boot the Live
image, mount your drive, and edit xen.cfg back. Looks like
https://github.com/QubesOS/qubes-issues/issues/3849 is why it got added,
so doesn't seem like it would hurt to try removing (but don't think it
would gain you anything either).

[Claudia]

'awokd' via qubes-users:

> dimi:
>
>> Could not find a solution how, if even possible to pick which kernel to
>> boot or/and modify kernel parameters before booting like i am used from
>> grub by pressing 'e'.
>> Does UEFI Boot support this or/and how can i safely switch my setup to grub
>> boot? I would like to see what happens when i remove the plymouth option (:
>>
> UEFI boot doesn't support on-the-fly modifications like grub. You can
> edit that xen.cfg and change the default= to a different entry, but it
> won't take effect until next boot. It might be possible to switch boot
> to grub, but I wouldn't call it "safe". Some of the new systems only
> support UEFI booting, for example, so switching to grub might break boot.

Doesn't grub support UEFI? That is, can't the firmware's UEFI loader
load grub in UEFI mode (grub.efi), which can then boot other OSes just
like it does in legacy mode (with menu, command line, config editor
etc)? So grub should work fine on a UEFI-only machine, shouldn't it?

Actually, I found that if you install qubes on another partition on a
machine that already has qubes (or maybe any OS), (perhaps only if they
share a /boot), the qubes installer will enable grub (the UEFI entry
becomes grub.efi instead of xen.efi). And I'm pretty sure legacy boot
was disabled when I did it.

So I'm not sure why it would be unsafe. In fact I'm thinking about
manually enabling grub (in UEFI mode) just to ease troubleshooting in
the future should I ever run into any boot issues. Just my take, but I
could be wrong.

-------------------------------------------------
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!

[awokd]

Claudia:

> So I'm not sure why it would be unsafe. In fact I'm thinking about
> manually enabling grub (in UEFI mode) just to ease troubleshooting in
> the future should I ever run into any boot issues. Just my take, but I
> could be wrong.

It wasn't the boot sequence itself I thought might be unsafe, but the
process of converting a functioning UEFI Qubes install over to it could
pretty easily end up with a non-booting system. That could be painful to
recover from, depending on one's comfort level. Let's call it a sliding
scale of safety. :)

[Claudia]

'awokd' via qubes-users:

> Claudia:
>
>> So I'm not sure why it would be unsafe. In fact I'm thinking about
>> manually enabling grub (in UEFI mode) just to ease troubleshooting in
>> the future should I ever run into any boot issues. Just my take, but I
>> could be wrong.
>
> It wasn't the boot sequence itself I thought might be unsafe, but the
> process of converting a functioning UEFI Qubes install over to it could
> pretty easily end up with a non-booting system. That could be painful to
> recover from, depending on one's comfort level. Let's call it a sliding
> scale of safety. :)
>

Oh, I thought you were saying grub in general on UEFI systems was
unsafe. Makes sense now.

[dimi]

It wasn't the boot sequence itself I thought might be unsafe, but the
process of converting a functioning UEFI Qubes install over to it could
pretty easily end up with a non-booting system. That could be painful to
recover from, depending on one's comfort level. Let's call it a sliding
scale of safety. :)
 

Probably going to happen. Going to postpone this switch and thanks for clarifying.