How to show boot entries?

194 views
Skip to first unread message

coeu...@gmail.com

unread,
Mar 15, 2018, 2:08:25 AM3/15/18
to qubes-users
Hello, guys.

I want to show boot entries so that I can select certain kernel to boot, and I'm using EFI/qubes/xen.efi as boot binary. Currently, it will directly boot the default kernel. Could anyone give some advices?

BTW, here is the reason: I have multiple kernels installed and kernel-latest-4.15.6-1 may raise kernel panic errors on Raven Ridge platform, but kernel-4.14.18-1 works just fine.

Thanks!
D.F.

Yuraeitha

unread,
Mar 15, 2018, 6:13:49 AM3/15/18
to qubes-users

Two methods I know of, but there are probably other ways too, i.e. via the EFI Shell.

- Use a secure live boot, access dom0, unlock your encryption, then go here and use an editor to edit the file /boot/efi/EFI/qubes/xen.cfg (most straight forward between the two approaches here, but be careful you don't make dom0 less secure with the live boot access).

- Install Grub, and use Grub to boot EFI installs. This way you can have multiple EFI kernel boots.


I'm not familiar with the other EFI methods to switch the kernel, you may want to wait for more answers to see first. Careful you don't overwrite anything important if you choose to install Grub. Be mindful you may need to manually adjust Grub as well to make it work. Thereby, the first option is probably the most easy of the two.

CoeusITE

unread,
Mar 15, 2018, 6:23:59 AM3/15/18
to Yuraeitha, qubes-users
Thanks, Yuraeitha!

It seems xen.cfg is stored in the EFI partition, and I can modify it within dom0 or through Fedora Live without decryption. However I don’t know how to modify it.

I think I should add some parameters in [global] section of xen.cfg, but I fail to find any tips from Xen’s official documents.
--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/CZ5vMNL_c7k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7b3d2068-088c-4f77-88fb-97c82368c828%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Yuraeitha

unread,
Mar 15, 2018, 6:51:04 AM3/15/18
to qubes-users
np's :)

It's been a while since I modified one as I generally prefer legacyBIOS over EFI, but if memory serves, you only need to edit the top lines near the top of the file, the kernel preferences. No need to add or delete anything, you just need to change the kernel numbers. If you're unsure which kernel numbers you got, then you can perform a "ls" command inside the folder where the configuration file is located, it'll show the different kernels next to it. The top of the file is kind of like a default selector the the below listed kernels in the file, which will pick whichever kernel listed below it (should be 3 kernels by default).

Btw if you get frequent kernel issues, or expect more of them in the future after a failed kernel update, then you can increase the number of kernels the Linux (Qubes) system saves, thereby you have more redundancy in the future. Just be sure you got enough space on your partition where the boot device is located for multiple of kernels and files.

This can wait till you get it working again btw. You can edit this file in dom0 /etc/yum.conf and change "installonly_limit=3" i.e. set it to 5 or 7 instead. But be really careful if you got a limited drive space, it can cause your updates to fail, and result in a half finished update because it didn't have enough drive space to finish up. It will tell you when that happens, but you'll be unable to re-boot/re-start without fixing it. So take precaution against that when increasing the limit :)

Yuraeitha

unread,
Mar 15, 2018, 6:52:35 AM3/15/18
to qubes-users
On Thursday, March 15, 2018 at 11:23:59 AM UTC+1, CoeusITE wrote:
don't edit the listed kernels below the preference lines though, only edit the kernel preference, near the top of the file. That'll be the one that selects which kernel to boot.

Marcus Linsner

unread,
Sep 5, 2018, 12:17:46 AM9/5/18
to qubes-users
On Thursday, March 15, 2018 at 7:08:25 AM UTC+1, coeu...@gmail.com wrote:

I don't understand why there are multiple entries in xen.cfg if the only way to select any is by setting the default= to one of them.

So, I had to make a copy of the qubes/ folder where xen.cfg is located, then modify the copied xen.cfg to choose a different kernel. Then add a new boot entry (which I can only select to boot from by entering BIOS btw), which will be set as default when added by this command:

first see what we have:
$sudo efibootmgr -v
then add one more (BIOS-visible) entry:
$ sudo efibootmgr -v -c -u -L Mewbs -l /EFI/mewbs/xen.efi -d /dev/sda -p 1
then see what happened:
$ sudo efibootmgr -v

(I'd copy/paste but it's harder to do from dom0 and I'm currently lazy/tired. #notproud)

The above assumes /dev/sda1 is the efi partition. (the -p 1 is the partition number; `df /boot/efi` should show /dev/sda1 )
And that /boot/efi/EFI/qubes/ folder where xen.cfg, xen.efi, initramfs*, vmlinuz* files are, is copied as /boot/efi/EFI/mewbs/ with all the files. Then I edited mewbs/xen.cfg to change the default= to a different kernel.

Intructions are from here: https://www.qubes-os.org/doc/uefi-troubleshooting/

Now, the Mewbs entry is selected as default to boot from on next boot, but BIOS can select which to boot from, which means I have to enter BIOS via F2, then F7 to got to advanced then select Boot and there somewhere both Qubes and Mewbs entries can be seen and I can either perma-modify which one to boot from, or temp-override and straight boot on one directly from BIOS there. On an ASUS Z370-A PRIME motherboard.

Looks like the timeout(which is 1 second) cannot be changed:
$ sudo efibootmgr -v -t 10
Could not set Timeout: invalid argument

I don't know if BIOS has any such setting by the way.

Marcus Linsner

unread,
Sep 5, 2018, 7:37:51 AM9/5/18
to qubes-users
On Wednesday, September 5, 2018 at 6:17:46 AM UTC+2, Marcus Linsner wrote:
> On Thursday, March 15, 2018 at 7:08:25 AM UTC+1, coeu...@gmail.com wrote:
> > Hello, guys.
> >
> > I want to show boot entries so that I can select certain kernel to boot, and I'm using EFI/qubes/xen.efi as boot binary. Currently, it will directly boot the default kernel. Could anyone give some advices?
> >
> > BTW, here is the reason: I have multiple kernels installed and kernel-latest-4.15.6-1 may raise kernel panic errors on Raven Ridge platform, but kernel-4.14.18-1 works just fine.
> >
> > Thanks!
> > D.F.
>
> I don't understand why there are multiple entries in xen.cfg if the only way to select any is by setting the default= to one of them.
>
> So, I had to make a copy of the qubes/ folder where xen.cfg is located, then modify the copied xen.cfg to choose a different kernel. Then add a new boot entry (which I can only select to boot from by entering BIOS btw), which will be set as default when added by this command:
>
> first see what we have:
> $sudo efibootmgr -v
> then add one more (BIOS-visible) entry:
> $ sudo efibootmgr -v -c -u -L Mewbs -l /EFI/mewbs/xen.efi -d /dev/sda -p 1
> then see what happened:
> $ sudo efibootmgr -v
>
> (I'd copy/paste but it's harder to do from dom0 and I'm currently lazy/tired. #notproud)
Alright, it looks like it's easier than I thought, copy/pasting from dom0 (was previously using qvm-copy-to-vm), according to https://www.qubes-os.org/doc/copy-from-dom0/ , step 3 (for Qubes 4.0), to quote from there:
"In other versions, write the data you wish to copy into /var/run/qubes/qubes-clipboard.bin, then echo -n dom0 > /var/run/qubes/qubes-clipboard.bin.source. Then use Ctrl-Shift-V to paste the data to the desired VM."

There is another file /var/run/qubes/qubes-clipboard.bin.xevent which contains a number and it doesn't need to be modified or touched for the copy/pasting to work.

With that in mind, let's see how to add another UEFI entry (which, as a reminder, can only be selected from BIOS's Boot Menu - which in my case requires fully entering BIOS - there's no F12 key (but maybe it depends on settings, like secure boot must be disabled?)).
Let's add an entry which boots with smt=on to enable all cores, thus reducing security, according to: https://www.qubes-os.org/news/2018/09/02/qsb-43/

Quick help for reference:

[ctor@dom0 ~]$ sudo efibootmgr -h
efibootmgr version 14
usage: efibootmgr [options]
-a | --active sets bootnum active
-A | --inactive sets bootnum inactive
-b | --bootnum XXXX modify BootXXXX (hex)
-B | --delete-bootnum delete bootnum
-c | --create create new variable bootnum and add to bootorder
-C | --create-only create new variable bootnum and do not add to bootorder
-D | --remove-dups remove duplicate values from BootOrder
-d | --disk disk (defaults to /dev/sda) containing loader
-r | --driver Operate on Driver variables, not Boot Variables.
-e | --edd [1|3|-1] force EDD 1.0 or 3.0 creation variables, or guess
-E | --device num EDD 1.0 device number (defaults to 0x80)
-g | --gpt force disk with invalid PMBR to be treated as GPT
-i | --iface name create a netboot entry for the named interface
-l | --loader name (defaults to \EFI\redhat\grub.efi)
-L | --label label Boot manager display label (defaults to "Linux")
-m | --mirror-below-4G t|f mirror memory below 4GB
-M | --mirror-above-4G X percentage memory to mirror above 4GB
-n | --bootnext XXXX set BootNext to XXXX (hex)
-N | --delete-bootnext delete BootNext
-o | --bootorder XXXX,YYYY,ZZZZ,... explicitly set BootOrder (hex)
-O | --delete-bootorder delete BootOrder
-p | --part part (defaults to 1) containing loader
-q | --quiet be quiet
-t | --timeout seconds set boot manager timeout waiting for user input.
-T | --delete-timeout delete Timeout.
-u | --unicode | --UCS-2 pass extra args as UCS-2 (default is ASCII)
-v | --verbose print additional information
-V | --version return version and exit
-w | --write-signature write unique sig to MBR if needed
-y | --sysprep Operate on SysPrep variables, not Boot Variables.
-@ | --append-binary-args file append extra args from file (use "-" for stdin)
-h | --help show help/usage

Let's see what we have already:

[ctor@dom0 ~]$ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0000,0002
Boot0000* Qubes HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\qubes\xen.efi)
Boot0002* Mewbs HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\mewbs\xen.efi)

Find out which our efi partition:

[ctor@dom0 ~]$ mount|grep efi
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)

or another way:

[ctor@dom0 ~]$ df /boot/efi
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 817584 305036 512548 38% /boot/efi

So it's /dev/sda1 (mounted on /boot/efi)

That means I need to pass: -d /dev/sda -p 1


Let's make a copy of of /boot/efi/EFI/qubes/ dir for this new entry:

[ctor@dom0 ~]$ sudo cp -avr -- /boot/efi/EFI/qubes /boot/efi/EFI/qubes2
'/boot/efi/EFI/qubes' -> '/boot/efi/EFI/qubes2'
'/boot/efi/EFI/qubes/xen.cfg' -> '/boot/efi/EFI/qubes2/xen.cfg'
'/boot/efi/EFI/qubes/xen.efi' -> '/boot/efi/EFI/qubes2/xen.efi'
'/boot/efi/EFI/qubes/vmlinuz-4.14.57-2.pvops.qubes.x86_64' -> '/boot/efi/EFI/qubes2/vmlinuz-4.14.57-2.pvops.qubes.x86_64'
'/boot/efi/EFI/qubes/initramfs-4.14.57-2.pvops.qubes.x86_64.img' -> '/boot/efi/EFI/qubes2/initramfs-4.14.57-2.pvops.qubes.x86_64.img'
'/boot/efi/EFI/qubes/vmlinuz-4.14.67-1.pvops.qubes.x86_64' -> '/boot/efi/EFI/qubes2/vmlinuz-4.14.67-1.pvops.qubes.x86_64'
'/boot/efi/EFI/qubes/initramfs-4.14.67-1.pvops.qubes.x86_64.img' -> '/boot/efi/EFI/qubes2/initramfs-4.14.67-1.pvops.qubes.x86_64.img'
'/boot/efi/EFI/qubes/vmlinuz-4.18.5-7.pvops.qubes.x86_64' -> '/boot/efi/EFI/qubes2/vmlinuz-4.18.5-7.pvops.qubes.x86_64'
'/boot/efi/EFI/qubes/xen-4.8.4.efi' -> '/boot/efi/EFI/qubes2/xen-4.8.4.efi'
'/boot/efi/EFI/qubes/vmlinuz-4.14.57-1.pvops.qubes.x86_64' -> '/boot/efi/EFI/qubes2/vmlinuz-4.14.57-1.pvops.qubes.x86_64'
'/boot/efi/EFI/qubes/initramfs-4.14.57-1.pvops.qubes.x86_64.img' -> '/boot/efi/EFI/qubes2/initramfs-4.14.57-1.pvops.qubes.x86_64.img'
'/boot/efi/EFI/qubes/initramfs-4.18.5-7.pvops.qubes.x86_64.img' -> '/boot/efi/EFI/qubes2/initramfs-4.18.5-7.pvops.qubes.x86_64.img'

Now you must use your favorite editor to edit /boot/efi/EFI/qubes2/xen.cfg and set all smt=off to smt=on (there are 4 entries for me) Don't forget you must use sudo(or be root) to edit it.

[ctor@dom0 ~]$ sudo grep -nH smt /boot/efi/EFI/qubes2/xen.cfg
/boot/efi/EFI/qubes2/xen.cfg:6:options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
/boot/efi/EFI/qubes2/xen.cfg:12:options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
/boot/efi/EFI/qubes2/xen.cfg:18:options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
/boot/efi/EFI/qubes2/xen.cfg:25:options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off

If you want to ALSO use a different kernel(I don't know yet how I can make systemd-boot prompt you for one) then change the default= line under the [global] section to one of the other section names

For example:

[global]
default=4.14.57-1.pvops.qubes.x86_64
becomes:

[global]
default=4.18.5-7.pvops.qubes.x86_64

But note that even though this(with the comment) works:

[global]
#default=4.14.57-1.pvops.qubes.x86_64
default=4.18.5-7.pvops.qubes.x86_64

even the commented one will be replaced when you upgrade the kernels(eg. via: sudo qubes-dom0-update) like:

[global]
#default=4.18.5-7.pvops.qubes.x86_64
default=4.18.5-7.pvops.qubes.x86_64

but this only happens for the /boot/efi/EFI/qubes/xen.cfg so since we're in qubes2/xen.cfg it won't!

Now it's time to add the boot entry: (reminder: this entry is seen/selectable only from BIOS - at least, to my limited knowledge so far(which is noob-level, first time EFI-ing))

[ctor@dom0 ~]$ sudo efibootmgr -v -c -u -L Qubes2_SMT_on -l /EFI/qubes2/xen.efi -d /dev/sda -p 1
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0001,0000,0002
Boot0000* Qubes HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\qubes\xen.efi)
Boot0002* Mewbs HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\mewbs\xen.efi)
Boot0001* Qubes2_SMT_on HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\qubes2\xen.efi)

Looks like BootCurrent wasn't changed, I wonder if that's because I have just booted the Mewbs entry from BIOS Setup by selecting BIOS's Override Boot, which means it's temporary, and on the next boot it will have fallen back to its original BootCurrent which was 00000 ie. BIOS would usually boot Qubes, not Mewbs for me, it only booted Mewbs now because I choose Mewbs under the Boot Override section in BIOS.

To change the boot timeout, well, it won't work(for me):

[ctor@dom0 ~]$ sudo efibootmgr -v --timeout 10
Could not set Timeout: Invalid argument

That's all. Restart and enter BIOS to choose your boot entry whenever you need it.

Additions:
To remove an entry:

first, see what we have:
[ctor@dom0 ~]$ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0003,0001,0000,0002
Boot0000* Qubes HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\qubes\xen.efi)
Boot0001* Qubes2_SMT_on HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\qubes\xen.efi)
Boot0002* Mewbs HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\mewbs\xen.efi)
Boot0003* Qubes2_SMT_on HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\qubes2\xen.efi)

yeah I typoed the qubes folder on entry 0001, it should've been qubes2, so that's why I have to delete it now:

[ctor@dom0 ~]$ sudo efibootmgr -v -B -b 0001
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0003,0000,0002
Boot0000* Qubes HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\qubes\xen.efi)
Boot0002* Mewbs HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\mewbs\xen.efi)
Boot0003* Qubes2_SMT_on HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\qubes2\xen.efi)


To select different BootCurrent, I've no idea how to do that with efibootmgr yet. Frankly, I remember that it selects the newly added entry, so it should've been the number for the Qubes2_SMT_on entry.

Marcus Linsner

unread,
Sep 6, 2018, 6:12:30 AM9/6/18
to qubes-users
On Wednesday, September 5, 2018 at 1:37:51 PM UTC+2, Marcus Linsner wrote:
> With that in mind, let's see how to add another UEFI entry (which, as a reminder, can only be selected from BIOS's Boot Menu - which in my case requires fully entering BIOS - there's no F12 key (but maybe it depends on settings, like secure boot must be disabled?)).

A slight correction here, the boot key(for my mobo/BIOS) is F8 (not F12 as I wrongly assumed from experience with other PCs) and it doesn't require entering BIOS I found out, however it only shows the boot menu if the BIOS Admin(supervisor?) password(as opposed to BIOS User password) is entered when the PC is set to prompt for a password before boot. Perhaps this depends on some BIOS settings, so that it would otherwise work with the user password too.

Marcus Linsner

unread,
Sep 6, 2018, 8:50:51 AM9/6/18
to qubes-users

Ok, newsflash (for me):
Whichever UEFI entry is the BootCurrent one, that's the entry whose xen.cfg will be modified when installing a new dom0 kernel rpm.

So in the below example it modified /boot/efi/EFI/mewbs/xen.cfg (NOT /boot/efi/EFI/qubes/xen.cfg as I previously assumed it would do):

$ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds

BootOrder: 0000,0003,0001,0002


Boot0000* Qubes HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\qubes\xen.efi)

Boot0001* automenu HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\automenu\xen.efi)


Boot0002* Mewbs HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\mewbs\xen.efi)
Boot0003* Qubes2_SMT_on HD(1,GPT,a8c00c7c-aa3d-4418-8e1a-d3c5c158ac2d,0x800,0x190000)/File(\EFI\qubes2\xen.efi)

So, I guess, be careful which entry you're currently booted in when doing dom0 updates, because that's the one that will get the newest kernel. (the `default=` under `[global]` section is also modified to point to this new kernel, btw; actually now that I look at it, that's the ony thing that got modified, there's no new section for the new kernel that the default= now references, none of the other xen.cfg have it either, hmm... assuming fluke! maybe something got confused since the automenu entry doesn't have a default= which makes it auto boot the first entry - i was hoping for a prompt though)

awokd

unread,
Sep 6, 2018, 9:05:50 AM9/6/18
to Marcus Linsner, qubes-users
On Thu, September 6, 2018 12:50 pm, Marcus Linsner wrote:

> So, I guess, be careful which entry you're currently booted in when doing
> dom0 updates, because that's the one that will get the newest kernel.
> (the `default=` under `[global]` section is also modified to point to
> this new kernel, btw; actually now that I look at it, that's the ony
> thing that got modified, there's no new section for the new kernel that
> the default= now references, none of the other xen.cfg have it either,
> hmm... assuming fluke! maybe something got confused since the automenu
> entry doesn't have a default= which makes it auto boot the first entry -
> i was hoping for a prompt though)

Xen + UEFI = painful, unfortunately. I don't know why you can't easily
select one of the non-default entries either, or if there's some secret
key combination to do so.


Reply all
Reply to author
Forward
0 new messages