UEFI installation issue
595 views
Skip to first unread message
wver...@eltan.com
Apr 18, 2017, 8:45:09 AM4/18/17
to qubes-users
Hello,
I am trying to install Qubes on a UEFI only system (no CSM).
Everything seems to work fine but after the install I have 2 problems:
1) The boot option isn't added
2) The efi\qubes directory doesn't contain xen.efi (just the one with the version in it) and the xen.cfg file is created but is 0 bytes in length so not very usefull.
Do you have any suggestion of what could be the problem? Or how this can be located?
If I run qubes repair I can use efibootmgr and I can also use the efivars file system so it doesn't look related to that.
When I tried to verify my boot media this failed but from the other posts it looks to me as this is standard for boot media created from Windows
Best regards,
Wim Vervoorn
Wim Vervoorn
Apr 18, 2017, 9:11:51 AM4/18/17
to Wim Vervoorn, qubes-users
Hello,
In the mean time I tried this one:
efi=no-rs (xen command line) - disable EFI runtime services at all - this would make installer unable to setup EFI boot, but at least may make your system bootable (once you setup xen.efi path in your EFI BIOS manually)
To eliminate any issues with the Efi runtime variables but this doesn't make any difference.
I still get this:
fs0:\EFI> cd qubes
fs0:\EFI\qubes> ls
Directory of: fs0:\EFI\qubes
04/18/17 02:54a <DIR> 8,192 .
04/18/17 02:54a <DIR> 8,192 ..
04/18/17 03:25a 0 xen.cfg
07/26/16 11:56a 2,126,535 xen-4.6.1.efi
04/18/17 03:25a 5,970,752 vmlinuz-4.4.14-11.pvops.qubes.x86_64
04/18/17 03:26a 20,973,576 initramfs-4.4.14-11.pvops.qubes.x86_64.img
4 File(s) 29,070,863 bytes
2 Dir(s)
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
--
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/WLAf7nOh9Qg/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/a9192c25-8279-4688-b2de-990692371403%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
In the mean time I tried this one:
efi=no-rs (xen command line) - disable EFI runtime services at all - this would make installer unable to setup EFI boot, but at least may make your system bootable (once you setup xen.efi path in your EFI BIOS manually)
To eliminate any issues with the Efi runtime variables but this doesn't make any difference.
I still get this:
fs0:\EFI> cd qubes
fs0:\EFI\qubes> ls
Directory of: fs0:\EFI\qubes
04/18/17 02:54a <DIR> 8,192 .
04/18/17 02:54a <DIR> 8,192 ..
04/18/17 03:25a 0 xen.cfg
07/26/16 11:56a 2,126,535 xen-4.6.1.efi
04/18/17 03:25a 5,970,752 vmlinuz-4.4.14-11.pvops.qubes.x86_64
04/18/17 03:26a 20,973,576 initramfs-4.4.14-11.pvops.qubes.x86_64.img
4 File(s) 29,070,863 bytes
2 Dir(s)
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
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/WLAf7nOh9Qg/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/a9192c25-8279-4688-b2de-990692371403%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marek Marczykowski-Górecki
Apr 18, 2017, 3:29:57 PM4/18/17
to wver...@eltan.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Logs from installation would be useful, you can find them in
/var/log/anaconda in installed system (mounted in /mnt/sysimage if you
boot in "Rescue a Qubes system" mode). I suspect some problem with
detecting that you're using UEFI and installer simply skipped that part.
Anyway, I've just added instruction what to do now:
https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-finished-but-qubes-boot-option-is-missing-and-xencfg-is-empty
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJY9mkxAAoJENuP0xzK19csnWAH+wVviEzfnXpbtA+HPwUgcgWG
0eDz74hKDLR+WPxLBSTa2tiXmRrpqKDON7GVrxB6bFqhmhI+7JD3e8HtKmJsmxdw
GuLdMp/3RoDM/Rw4IXxiamB0Ez6m0b3+ClAagjPEVvtUlf25NGNzwqjU8+N6yypz
29+sUKC4Qq4rLgcgaYYcGU2iMFBkzBszq6JKJWRlsqsfWlT/3Og/bJE4rvToaDcF
8LxSMzH052x7pMcHTUJ+fDJ4r4JI4TGxTJh1/rlYjv7eSXyIJfssO65tEfytBfmu
rO1ezSogPzxbmI/Hpa4Hk6OR5N6ATgPMASmKW2lGX5fQ/Af837IFgOIrW7pSvzs=
=idr1
-----END PGP SIGNATURE-----
Hash: SHA256
/var/log/anaconda in installed system (mounted in /mnt/sysimage if you
boot in "Rescue a Qubes system" mode). I suspect some problem with
detecting that you're using UEFI and installer simply skipped that part.
Anyway, I've just added instruction what to do now:
https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-finished-but-qubes-boot-option-is-missing-and-xencfg-is-empty
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJY9mkxAAoJENuP0xzK19csnWAH+wVviEzfnXpbtA+HPwUgcgWG
0eDz74hKDLR+WPxLBSTa2tiXmRrpqKDON7GVrxB6bFqhmhI+7JD3e8HtKmJsmxdw
GuLdMp/3RoDM/Rw4IXxiamB0Ez6m0b3+ClAagjPEVvtUlf25NGNzwqjU8+N6yypz
29+sUKC4Qq4rLgcgaYYcGU2iMFBkzBszq6JKJWRlsqsfWlT/3Og/bJE4rvToaDcF
8LxSMzH052x7pMcHTUJ+fDJ4r4JI4TGxTJh1/rlYjv7eSXyIJfssO65tEfytBfmu
rO1ezSogPzxbmI/Hpa4Hk6OR5N6ATgPMASmKW2lGX5fQ/Af837IFgOIrW7pSvzs=
=idr1
-----END PGP SIGNATURE-----
Wim Vervoorn
Apr 19, 2017, 5:07:29 AM4/19/17
to Marek Marczykowski-Górecki, qubes-users
Hello Marek,
Thanks for getting back to me.
I obtained the logs and had a look at them.
I couldn't find anything obvious. Can you have a look at them.
Please be aware this isn't a standard UEFI BIOS but coreboot with a TianoCore payload on top of it. This implementation is UEFI only and doesn't support a CSM in any way.
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
-----Original Message-----
Thanks for getting back to me.
I obtained the logs and had a look at them.
I couldn't find anything obvious. Can you have a look at them.
Please be aware this isn't a standard UEFI BIOS but coreboot with a TianoCore payload on top of it. This implementation is UEFI only and doesn't support a CSM in any way.
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
-----Original Message-----
Wim Vervoorn
Apr 19, 2017, 9:07:04 AM4/19/17
to Wim Vervoorn, Marek Marczykowski-Górecki, qubes-users
Hello Marek,
When I looked at what happens when xen starts I also see this error message:
ConvertPages: failed to find range FFFF82D080000000 - FFFF82D0811FFFFF
As far as I can see this the area used by the xen file itself, is that correct? Could this be causing problems as well?
Normally we only see these calls to het e.g. the virtual address of an mmio or other reserved area.
When I looked at what happens when xen starts I also see this error message:
ConvertPages: failed to find range FFFF82D080000000 - FFFF82D0811FFFFF
As far as I can see this the area used by the xen file itself, is that correct? Could this be causing problems as well?
Normally we only see these calls to het e.g. the virtual address of an mmio or other reserved area.
--
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/WLAf7nOh9Qg/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/ab89ef80b1fa4a839fa986090b8090ef%40Eltsrv03.Eltan.local.
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/WLAf7nOh9Qg/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.
Wim Vervoorn
Apr 19, 2017, 10:08:27 AM4/19/17
to Marek Marczykowski-Górecki, qubes-users
Hello Marek,
I also tried booting using the xen.cfg file.
As far as I can see the cfg file is OK but the qubes os still fails.
The there is no request for the password and so the volumes are not unlocked.
I added both the xen.cfg I am using and the log file.
FYI /dev/sda1 is the ESP, /dev/sda2 is /boot and /dev/sda3 is the LVM partition
When I am using the rescue mode the password is asked and all seems to be fine.
I also tried booting using the xen.cfg file.
As far as I can see the cfg file is OK but the qubes os still fails.
The there is no request for the password and so the volumes are not unlocked.
I added both the xen.cfg I am using and the log file.
FYI /dev/sda1 is the ESP, /dev/sda2 is /boot and /dev/sda3 is the LVM partition
When I am using the rescue mode the password is asked and all seems to be fine.
Marek Marczykowski-Górecki
Apr 19, 2017, 3:21:15 PM4/19/17
to Wim Vervoorn, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Wed, Apr 19, 2017 at 02:07:37PM +0000, Wim Vervoorn wrote:
> Hello Marek,
>
> I also tried booting using the xen.cfg file.
>
> As far as I can see the cfg file is OK but the qubes os still fails.
>
> The there is no request for the password and so the volumes are not unlocked.
>
> I added both the xen.cfg I am using and the log file.
>
> FYI /dev/sda1 is the ESP, /dev/sda2 is /boot and /dev/sda3 is the LVM partition
>
> When I am using the rescue mode the password is asked and all seems to be fine.
Looks like your system use different LV names and also have LUKS applied
> Hello Marek,
>
> I also tried booting using the xen.cfg file.
>
> As far as I can see the cfg file is OK but the qubes os still fails.
>
> The there is no request for the password and so the volumes are not unlocked.
>
> I added both the xen.cfg I am using and the log file.
>
> FYI /dev/sda1 is the ESP, /dev/sda2 is /boot and /dev/sda3 is the LVM partition
>
> When I am using the rescue mode the password is asked and all seems to be fine.
to individual LVM volumes, not the whole LVM volume group.
[ 2.548486] dom0 dracut-initqueue[362]: inactive '/dev/qubes_dom0/00' [20.00 GiB] inherit
[ 2.548886] dom0 dracut-initqueue[362]: inactive '/dev/qubes_dom0/01' [10.00 GiB] inherit
[ 2.556716] dom0 dracut-initqueue[362]: File descriptor 98 (socket:[9738]) leaked on lvm
invocation. Parent PID 489: /bin/sh
[ 2.557017] dom0 dracut-initqueue[362]: File descriptor 99 (socket:[9739]) leaked on lvm
invocation. Parent PID 489: /bin/sh
[ 2.564504] dom0 dracut-initqueue[362]: Failed to find logical volume "qubes_dom0/root"
[ 2.572468] dom0 dracut-initqueue[362]: File descriptor 98 (socket:[9738]) leaked on lvm
invocation. Parent PID 489: /bin/sh
[ 2.572874] dom0 dracut-initqueue[362]: File descriptor 99 (socket:[9739]) leaked on lvm
invocation. Parent PID 489: /bin/sh
[ 2.580150] dom0 dracut-initqueue[362]: Failed to find logical volume "qubes_dom0/swap"
Try using qubes_dom0/00 instead of qubes_dom0/root and qubes_dom0/01
instead of qubes_dom0/swap. Or the other way around. And also adjust
root= accordingly (may require using UUID=... notation, but I cannot
tell based on the above info, before decrypting it).
- --
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-----
Version: GnuPG v2
yBhnZDhj6rDkDJWd/c6HfwuxiAtOCK/WcqLu5Tj9M0lUNwUNuqX90u5I2ID4GwFN
I+tYFz8FsYA3OsXBaHvjl8gGGtuuWW7GMg9wPG7gDoSlTRuDYKHDsdCqN4KuyPJu
Oxvg70W89Q/uTOeZ39YbMUDQDNb5K2ZG/ob9a7/4LdOGr4Pg1mNzWkvELCnm3moF
TfKBzrQE6Hrw+gl5wXzoyM2lQKQIU6tBT2hC3LfRDoTj4tklNwlvJW3J0PN51PDj
n0zWcNTOpsajwHSBBXtAlccjOkhZKaEa5xSzH9rOIWKTp285zjBs13b3Kq1gElA=
=R4F8
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Apr 19, 2017, 3:26:28 PM4/19/17
to Wim Vervoorn, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
what to put in root= option: /dev/mapper/luks-298b7206-1b82-46c0-8c1a-2b27a02f2384
Anyway, this layout (LUKS over LVM, instead of LVM over LUKS) isn't the
best idea. I suggest you reinstall and make sure to have the other one
(which should be the default...).
- --
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-----
Version: GnuPG v2
0lR04AynMNz+41pX0KilORAd02lob9my/rTrriiL2k6pgMC5rnpgMTFBG9Y/J0NF
rDuyvyhPIw6A524dhG2nRZbqRb91oyS8z/TNgHeDdviWzT7Wt+FX+qXbvDlcJkdE
7JIEfzoAgWEeOtu0NUowQ3D1gX0AWVdCxykh/fYw4sUZuV1DXhdXLSYbGSrJrevn
KODd5au6oe0EWw+MzOzMqVSXKTxDVS2CHs71HN4YEvygXjCiqk9IOrqN702tUwmV
4MkS/QDV/EOscUVFMKttSLXM6hz8bOT44vjiFCiqknLZ90qDpE90duzkNflsgg==
=+OLV
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Apr 19, 2017, 3:39:12 PM4/19/17
to Wim Vervoorn, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Wed, Apr 19, 2017 at 09:06:48AM +0000, Wim Vervoorn wrote:
> Hello Marek,
>
> Thanks for getting back to me.
>
> I obtained the logs and had a look at them.
>
> I couldn't find anything obvious. Can you have a look at them.
Hmm, I found this in anaconda.log:
> Hello Marek,
>
> Thanks for getting back to me.
>
> I obtained the logs and had a look at them.
>
> I couldn't find anything obvious. Can you have a look at them.
23:19:35,474 INFO anaconda: skipping boot loader install per user request
Do you remember some question about it, or changing such option?
>
> Please be aware this isn't a standard UEFI BIOS but coreboot with a TianoCore payload on top of it. This implementation is UEFI only and doesn't support a CSM in any way.
specifically coreboot, but then assuming grub payload there...
But it shouldn't disable installing UEFI entries, only allow to have
encrypted /boot (since grub in coreboot can handle it).
Some relevant log entries:
anaconda.log:
01:50:16,997 INFO anaconda: bootloader XenEFI on EFI platform
01:50:17,067 INFO anaconda: dmidecode -s bios-vendor returns coreboot
syslog:
01:49:52,515 WARNING kernel:[ 223.240750] efivars: get_next_variable: status=8000000000000003
Hmm, this actually may be a problem. I'm not sure what
status=8000000000000003 is, but if accessing efivars does not work,
efibootmgr would not work, so can't add Qubes entry. Does `efibootmgr
- -v` show anything?
Other than that, I also can't see anything interesting.
- --
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-----
Version: GnuPG v2
/kXqiO8mHfcCTWsu1knqVT2WJ8KmjJm8ERNDg3pVxor1paZBZ+BKkCzrp20zBJ/d
prhv9j3M9wHNJF+4BSJKUse7gy1RBJrKFnz85gvLBT55PH/k9BGGVk/+eXylmTuM
0yJXkYBqAik84XFRGXWrdm/Rn40h4Gjj1MlXicewKctu8oymqdzOxsIlTxeNYXZa
ZiVen8cFlc4Nsh1LvDfKi61JHrhj/0I623Pacyf/xvsSgynBK5ymRHUY3NlAGHSs
otU9IzsfCUTE6SSaQwKibWRt7P2+MSR4gW6OOgviHr5Ei0bXSQRCf0uCvVyXyQw=
=tbyJ
-----END PGP SIGNATURE-----
Andrew David Wong
Apr 19, 2017, 3:46:36 PM4/19/17
to Marek Marczykowski-Górecki, Wim Vervoorn, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
For reference, we have the installer defaults (LVM inside LUKS)
documented here:
https://www.qubes-os.org/doc/custom-install/#installer-defaults-r32
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY976EAAoJENtN07w5UDAwb8YP/0Mh7qbyC81RUwNNkusYqgqb
HH1qAdR1XwUIbBZp5gym7Da6FBTGqYLEcRSDAEIpq/RnkWzLIQ2Zmi+//kchWLP1
vJOt90w7QJtQC7hPJAPUC2ienwR6+g6Quva5K3P4fozWGocl3z9uIJ+kzXmHbmar
0m2gjsgB3+wE/vRXte2uIhfoALI4/ILtzcu0hQMlF8xj3HaOyUUXO3Pf66acnlgd
gMYvvW3FCzrm5W64DiYmtpiC/EQaL4PJ76dQIH16OSOz0hnwNitT7BzdWxZAAnjS
zc7Jsv6PhcjfdYOYUXqFCA3BEuq3V8pvrrnHFqdXvNPAZ90puOhsGLD7LW9RVbGe
gTOMVvqk0KE7rb4TEbtuu5UqOUYIpAfOn6W9F16KRSHTVRwB1u+8B3kxbgoj0Uyq
kI37K82sbRtNcjtfkHpfimFX+UpQXIUY2NshKmzC918agvcHWtOq9vwZFEmjd8Lq
wACV6T3YLaHuw9zvDXc15vcc2ceJa5k+IzqMcQDPYv49iklqIgFA4FkgKxXCIWmy
b85Kp/EEtjZKa3eZ4EFcOP7G0j1w10+6irwqFNEwEfI0mcAqXf6+4OdP2CTgzuZY
rUWb/3NYuSYmqn5z83fSoz8Ul/90OhblLBcRxRSenaYtoIHaKZ5LNPd0n9WW0pfz
sNjzxCv4Lj61eQADA9z7
=Rcdc
-----END PGP SIGNATURE-----
Hash: SHA512
documented here:
https://www.qubes-os.org/doc/custom-install/#installer-defaults-r32
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY976EAAoJENtN07w5UDAwb8YP/0Mh7qbyC81RUwNNkusYqgqb
HH1qAdR1XwUIbBZp5gym7Da6FBTGqYLEcRSDAEIpq/RnkWzLIQ2Zmi+//kchWLP1
vJOt90w7QJtQC7hPJAPUC2ienwR6+g6Quva5K3P4fozWGocl3z9uIJ+kzXmHbmar
0m2gjsgB3+wE/vRXte2uIhfoALI4/ILtzcu0hQMlF8xj3HaOyUUXO3Pf66acnlgd
gMYvvW3FCzrm5W64DiYmtpiC/EQaL4PJ76dQIH16OSOz0hnwNitT7BzdWxZAAnjS
zc7Jsv6PhcjfdYOYUXqFCA3BEuq3V8pvrrnHFqdXvNPAZ90puOhsGLD7LW9RVbGe
gTOMVvqk0KE7rb4TEbtuu5UqOUYIpAfOn6W9F16KRSHTVRwB1u+8B3kxbgoj0Uyq
kI37K82sbRtNcjtfkHpfimFX+UpQXIUY2NshKmzC918agvcHWtOq9vwZFEmjd8Lq
wACV6T3YLaHuw9zvDXc15vcc2ceJa5k+IzqMcQDPYv49iklqIgFA4FkgKxXCIWmy
b85Kp/EEtjZKa3eZ4EFcOP7G0j1w10+6irwqFNEwEfI0mcAqXf6+4OdP2CTgzuZY
rUWb/3NYuSYmqn5z83fSoz8Ul/90OhblLBcRxRSenaYtoIHaKZ5LNPd0n9WW0pfz
sNjzxCv4Lj61eQADA9z7
=Rcdc
-----END PGP SIGNATURE-----
hft.h...@gmail.com
Apr 19, 2017, 5:10:57 PM4/19/17
to qubes-users
Op dinsdag 18 april 2017 14:45:09 UTC+2 schreef wver...@eltan.com:
Yup, my bootable usb couldn't verify itself. But then within the installer, I chose different install medium and selected the same downloaded iso file from my Windows data partition. Verification of this file was success.
No problems installing this way. :)
Have you tried this? This is more like a workaround, not a solution to the failed verification.
Otherwise I'm not of any help to you hehe sorry.
Wim Vervoorn
Apr 20, 2017, 4:09:36 AM4/20/17
to Marek Marczykowski-Górecki, qubes-users
Hello Marek,
Please look at my comments below:
Wim
-----Original Message-----
From: qubes...@googlegroups.com [mailto:qubes...@googlegroups.com] On Behalf Of Marek Marczykowski-Górecki
Sent: Wednesday, April 19, 2017 9:39 PM
To: Wim Vervoorn <wver...@eltan.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue
>
> Please be aware this isn't a standard UEFI BIOS but coreboot with a TianoCore payload on top of it. This implementation is UEFI only and doesn't support a CSM in any way.
This may be important details. We have some code targeting specifically coreboot, but then assuming grub payload there...
But it shouldn't disable installing UEFI entries, only allow to have encrypted /boot (since grub in coreboot can handle it).
Some relevant log entries:
anaconda.log:
01:50:16,997 INFO anaconda: bootloader XenEFI on EFI platform
01:50:17,067 INFO anaconda: dmidecode -s bios-vendor returns coreboot
syslog:
01:49:52,515 WARNING kernel:[ 223.240750] efivars: get_next_variable: status=8000000000000003
Hmm, this actually may be a problem. I'm not sure what
status=8000000000000003 is, but if accessing efivars does not work, efibootmgr would not work, so can't add Qubes entry. Does `efibootmgr
- -v` show anything?
Other than that, I also can't see anything interesting.
** WIM : the efivars filesystem is populated and the efibootmgr -v is reporting the options I am expecting so that seems to be fine. The 0x8000000000000003 is EFI_UNSUPPORTED
This could be because the request has been made with attributes that aren't supported by the system, without know the call parameters I can't tell if this is the case.
if ((Attributes & EFI_VARIABLE_ATTRIBUTES_MASK) == 0) {
//
// Make sure the Attributes combination is supported by the platform.
//
return EFI_UNSUPPORTED;
#define EFI_VARIABLE_ATTRIBUTES_MASK (EFI_VARIABLE_NON_VOLATILE | \
EFI_VARIABLE_BOOTSERVICE_ACCESS | \
EFI_VARIABLE_RUNTIME_ACCESS | \
EFI_VARIABLE_HARDWARE_ERROR_RECORD | \
EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS | \
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS | \
EFI_VARIABLE_APPEND_WRITE)
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJY97zYAAoJENuP0xzK19cszh4H/2uGpcbGXvUsflXZvyo5A08Y
/kXqiO8mHfcCTWsu1knqVT2WJ8KmjJm8ERNDg3pVxor1paZBZ+BKkCzrp20zBJ/d
prhv9j3M9wHNJF+4BSJKUse7gy1RBJrKFnz85gvLBT55PH/k9BGGVk/+eXylmTuM
0yJXkYBqAik84XFRGXWrdm/Rn40h4Gjj1MlXicewKctu8oymqdzOxsIlTxeNYXZa
ZiVen8cFlc4Nsh1LvDfKi61JHrhj/0I623Pacyf/xvsSgynBK5ymRHUY3NlAGHSs
otU9IzsfCUTE6SSaQwKibWRt7P2+MSR4gW6OOgviHr5Ei0bXSQRCf0uCvVyXyQw=
=tbyJ
-----END PGP SIGNATURE-----
Please look at my comments below:
Wim
-----Original Message-----
From: qubes...@googlegroups.com [mailto:qubes...@googlegroups.com] On Behalf Of Marek Marczykowski-Górecki
Sent: Wednesday, April 19, 2017 9:39 PM
To: Wim Vervoorn <wver...@eltan.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, Apr 19, 2017 at 09:06:48AM +0000, Wim Vervoorn wrote:
> Hello Marek,
>
> Thanks for getting back to me.
>
> I obtained the logs and had a look at them.
>
> I couldn't find anything obvious. Can you have a look at them.
Hmm, I found this in anaconda.log:
23:19:35,474 INFO anaconda: skipping boot loader install per user request
Do you remember some question about it, or changing such option?
* WIM: No I have not seen anything like this
Hash: SHA256
On Wed, Apr 19, 2017 at 09:06:48AM +0000, Wim Vervoorn wrote:
> Hello Marek,
>
> Thanks for getting back to me.
>
> I obtained the logs and had a look at them.
>
> I couldn't find anything obvious. Can you have a look at them.
Hmm, I found this in anaconda.log:
23:19:35,474 INFO anaconda: skipping boot loader install per user request
Do you remember some question about it, or changing such option?
>
> Please be aware this isn't a standard UEFI BIOS but coreboot with a TianoCore payload on top of it. This implementation is UEFI only and doesn't support a CSM in any way.
This may be important details. We have some code targeting specifically coreboot, but then assuming grub payload there...
But it shouldn't disable installing UEFI entries, only allow to have encrypted /boot (since grub in coreboot can handle it).
Some relevant log entries:
anaconda.log:
01:50:16,997 INFO anaconda: bootloader XenEFI on EFI platform
01:50:17,067 INFO anaconda: dmidecode -s bios-vendor returns coreboot
syslog:
01:49:52,515 WARNING kernel:[ 223.240750] efivars: get_next_variable: status=8000000000000003
Hmm, this actually may be a problem. I'm not sure what
status=8000000000000003 is, but if accessing efivars does not work, efibootmgr would not work, so can't add Qubes entry. Does `efibootmgr
- -v` show anything?
Other than that, I also can't see anything interesting.
This could be because the request has been made with attributes that aren't supported by the system, without know the call parameters I can't tell if this is the case.
if ((Attributes & EFI_VARIABLE_ATTRIBUTES_MASK) == 0) {
//
// Make sure the Attributes combination is supported by the platform.
//
return EFI_UNSUPPORTED;
#define EFI_VARIABLE_ATTRIBUTES_MASK (EFI_VARIABLE_NON_VOLATILE | \
EFI_VARIABLE_BOOTSERVICE_ACCESS | \
EFI_VARIABLE_RUNTIME_ACCESS | \
EFI_VARIABLE_HARDWARE_ERROR_RECORD | \
EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS | \
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS | \
EFI_VARIABLE_APPEND_WRITE)
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJY97zYAAoJENuP0xzK19cszh4H/2uGpcbGXvUsflXZvyo5A08Y
/kXqiO8mHfcCTWsu1knqVT2WJ8KmjJm8ERNDg3pVxor1paZBZ+BKkCzrp20zBJ/d
prhv9j3M9wHNJF+4BSJKUse7gy1RBJrKFnz85gvLBT55PH/k9BGGVk/+eXylmTuM
0yJXkYBqAik84XFRGXWrdm/Rn40h4Gjj1MlXicewKctu8oymqdzOxsIlTxeNYXZa
ZiVen8cFlc4Nsh1LvDfKi61JHrhj/0I623Pacyf/xvsSgynBK5ymRHUY3NlAGHSs
otU9IzsfCUTE6SSaQwKibWRt7P2+MSR4gW6OOgviHr5Ei0bXSQRCf0uCvVyXyQw=
=tbyJ
-----END PGP SIGNATURE-----
--
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/WLAf7nOh9Qg/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/20170419193904.GE1486%40mail-itl.
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/WLAf7nOh9Qg/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.
Wim Vervoorn
Apr 20, 2017, 4:18:46 AM4/20/17
to Marek Marczykowski-Górecki, qubes-users
Hello Marek,
I reformatted the disk and now the system is working after copying the correct xen.cfg file.
The issue that is left is now the correct setting of the boot option by the install process.
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
-----Original Message-----
From: Marek Marczykowski-Górecki [mailto:marm...@invisiblethingslab.com]
I reformatted the disk and now the system is working after copying the correct xen.cfg file.
The issue that is left is now the correct setting of the boot option by the install process.
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
-----Original Message-----
From: Marek Marczykowski-Górecki [mailto:marm...@invisiblethingslab.com]
Sent: Wednesday, April 19, 2017 9:26 PM
To: Wim Vervoorn <wver...@eltan.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue
To: Wim Vervoorn <wver...@eltan.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue
Wim Vervoorn
Apr 20, 2017, 4:26:30 AM4/20/17
to hft.h...@gmail.com, qubes-users
Thanks,
The failure of the verification is not a real issue. It's basically an error in the verification mechanism triggered by the fact that Windows creates an additional folder with some volume information on the fat partition of the disk.
Wim
-----Original Message-----
From: qubes...@googlegroups.com [mailto:qubes...@googlegroups.com] On Behalf Of hft.h...@gmail.com
Sent: Wednesday, April 19, 2017 11:11 PM
To: qubes-users <qubes...@googlegroups.com>
The failure of the verification is not a real issue. It's basically an error in the verification mechanism triggered by the fact that Windows creates an additional folder with some volume information on the fat partition of the disk.
Wim
-----Original Message-----
From: qubes...@googlegroups.com [mailto:qubes...@googlegroups.com] On Behalf Of hft.h...@gmail.com
Sent: Wednesday, April 19, 2017 11:11 PM
To: qubes-users <qubes...@googlegroups.com>
--
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/WLAf7nOh9Qg/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/5727811d-4a35-45fd-ba1a-5e7a366f5127%40googlegroups.com.
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/WLAf7nOh9Qg/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.
Wim Vervoorn
Apr 20, 2017, 5:57:44 AM4/20/17
to Marek Marczykowski-Górecki, qubes-users
Hello Marek,
The previous logging was with a debug version of the UEFI code.
I now tried a release version as well.
The good thing is that the EFI_UNSUPPORTED response from efivars: get_next_variable doesn't show up any longer.
The bad news is that I still see the "INFO anaconda: skipping boot loader install per user request" message so somehow anaconda is concluding the bootloader install should be skipped.
This is the final part of the anaconda log:
22:39:12,715 INFO anaconda: Installing boot loader
22:39:14,663 DEBUG anaconda: new default image: <pyanaconda.bootloader.LinuxBootLoaderImage object at 0x7fc4f24ffb70>
22:39:14,737 INFO anaconda: skipping boot loader install per user request
22:39:14,738 INFO anaconda: Installing boot loader
22:39:14,739 INFO anaconda: Performing post-installation setup tasks
22:39:14,760 INFO anaconda: Performing post-installation setup tasks
22:39:14,763 INFO anaconda: Thread Done: AnaInstallThread (140483890104064)
22:39:46,558 DEBUG anaconda: Entered spoke: UserSpoke
22:40:08,695 DEBUG anaconda: Left spoke: UserSpoke
22:40:20,756 INFO anaconda: Running Thread: AnaConfigurationThread (140483890104064)
22:40:20,759 INFO anaconda: Configuring installed system
22:40:22,320 INFO anaconda: Configuring installed system
22:40:22,321 INFO anaconda: Writing network configuration
22:40:22,330 INFO anaconda: setting installation environment host name to dom0
22:40:22,661 INFO anaconda: Writing network configuration
22:40:22,662 INFO anaconda: Creating users
22:40:22,664 INFO anaconda: user account root setup with no password
22:40:22,664 INFO anaconda: user account root locked
22:40:23,215 ERR anaconda: User eltan already exists, not creating.
22:40:23,217 INFO anaconda: Creating users
22:40:23,218 INFO anaconda: Configuring addons
22:40:23,219 INFO anaconda: Configuring addons
22:40:23,220 INFO anaconda: Generating initramfs
22:50:35,588 INFO anaconda: Generating initramfs
22:50:35,607 INFO anaconda: Running post-installation scripts
22:50:35,609 INFO anaconda: Running kickstart %%post script(s)
The OS is booting fine after creating the boot option manually (and performing the other steps like copying a correct xen.cfg file)
So at this point the main item to tackle is the reason why anaconda skips the bootloader install.
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
The previous logging was with a debug version of the UEFI code.
I now tried a release version as well.
The good thing is that the EFI_UNSUPPORTED response from efivars: get_next_variable doesn't show up any longer.
The bad news is that I still see the "INFO anaconda: skipping boot loader install per user request" message so somehow anaconda is concluding the bootloader install should be skipped.
This is the final part of the anaconda log:
22:39:12,715 INFO anaconda: Installing boot loader
22:39:14,663 DEBUG anaconda: new default image: <pyanaconda.bootloader.LinuxBootLoaderImage object at 0x7fc4f24ffb70>
22:39:14,737 INFO anaconda: skipping boot loader install per user request
22:39:14,738 INFO anaconda: Installing boot loader
22:39:14,739 INFO anaconda: Performing post-installation setup tasks
22:39:14,760 INFO anaconda: Performing post-installation setup tasks
22:39:14,763 INFO anaconda: Thread Done: AnaInstallThread (140483890104064)
22:39:46,558 DEBUG anaconda: Entered spoke: UserSpoke
22:40:08,695 DEBUG anaconda: Left spoke: UserSpoke
22:40:20,756 INFO anaconda: Running Thread: AnaConfigurationThread (140483890104064)
22:40:20,759 INFO anaconda: Configuring installed system
22:40:22,320 INFO anaconda: Configuring installed system
22:40:22,321 INFO anaconda: Writing network configuration
22:40:22,330 INFO anaconda: setting installation environment host name to dom0
22:40:22,661 INFO anaconda: Writing network configuration
22:40:22,662 INFO anaconda: Creating users
22:40:22,664 INFO anaconda: user account root setup with no password
22:40:22,664 INFO anaconda: user account root locked
22:40:23,215 ERR anaconda: User eltan already exists, not creating.
22:40:23,217 INFO anaconda: Creating users
22:40:23,218 INFO anaconda: Configuring addons
22:40:23,219 INFO anaconda: Configuring addons
22:40:23,220 INFO anaconda: Generating initramfs
22:50:35,588 INFO anaconda: Generating initramfs
22:50:35,607 INFO anaconda: Running post-installation scripts
22:50:35,609 INFO anaconda: Running kickstart %%post script(s)
The OS is booting fine after creating the boot option manually (and performing the other steps like copying a correct xen.cfg file)
So at this point the main item to tackle is the reason why anaconda skips the bootloader install.
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
-----Original Message-----
From: qubes...@googlegroups.com [mailto:qubes...@googlegroups.com] On Behalf Of Marek Marczykowski-Górecki
Sent: Wednesday, April 19, 2017 9:39 PM
To: Wim Vervoorn <wver...@eltan.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue
From: qubes...@googlegroups.com [mailto:qubes...@googlegroups.com] On Behalf Of Marek Marczykowski-Górecki
Sent: Wednesday, April 19, 2017 9:39 PM
To: Wim Vervoorn <wver...@eltan.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue
--
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/WLAf7nOh9Qg/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/20170419193904.GE1486%40mail-itl.
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/WLAf7nOh9Qg/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.
Wim Vervoorn
Apr 20, 2017, 9:33:44 AM4/20/17
to Marek Marczykowski-Górecki, qubes-users
Hello Marek,
One other item came to mind thinking about this.
When I install Qubes and indicate I want the default partitions to be created it does create the three partitions mentioned on the website but it doesn't create the UEFI ESP partition which of course is also required on a UEFI system.
Is this expected behavior or is this a sign that the installer doesn't completely recognize this system as being a UEFI system? Perhaps the installer doesn't complete properly because of this?
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
-----Original Message-----
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a2a108ee3204467599f7960c0eeda67d%40Eltsrv03.Eltan.local.
One other item came to mind thinking about this.
When I install Qubes and indicate I want the default partitions to be created it does create the three partitions mentioned on the website but it doesn't create the UEFI ESP partition which of course is also required on a UEFI system.
Is this expected behavior or is this a sign that the installer doesn't completely recognize this system as being a UEFI system? Perhaps the installer doesn't complete properly because of this?
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wver...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
-----Original Message-----
From: qubes...@googlegroups.com [mailto:qubes...@googlegroups.com] On Behalf Of Wim Vervoorn
Sent: Thursday, April 20, 2017 11:57 AM
To: Marek Marczykowski-Górecki <marm...@invisiblethingslab.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: RE: [qubes-users] UEFI installation issue
Sent: Thursday, April 20, 2017 11:57 AM
To: Marek Marczykowski-Górecki <marm...@invisiblethingslab.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: RE: [qubes-users] UEFI installation issue
wver...@eltan.com
Apr 24, 2017, 3:32:23 AM4/24/17
to qubes-users
Hello,
Is this still at the right list? Or should this issue be moved to another one?
Anyhow, is there any possibility to direct me to the location this installation is handled so I can have a look myself if needed?
Best regards,
Wim
wver...@eltan.com
Apr 24, 2017, 6:25:32 AM4/24/17
to qubes-users, marm...@invisiblethingslab.com
I have been looking at this a bit further and found a part in the log that looks suspicious to me:
At some point the log returns:
22:06:43,197 INFO anaconda: skipping unneeded stage1 efi request
I haven't been able to located where this comes from, could this be the cause of problems or is this expected?
Furthermore, if I look in qubes-install/anaconda/pyanaconda/bootloader.py it looks like add_image() is executed correctly while Add_efi_boot_tartget() is not as the expected result is not there and no error is reported.
22:06:43,173 DEBUG anaconda: autoPartitionRequests:
PartSpec instance (0x7fc4f1ac72e8) --
mountpoint = / lv = True thin = True btrfs = True
weight = 0 fstype = ext4 encrypted = True
size = 1 GiB maxSize = None grow = True
PartSpec instance (0x7fc4f1ac7320) --
mountpoint = /boot/efi lv = False thin = False btrfs = False
weight = 5000 fstype = efi encrypted = False
size = 20 MiB maxSize = 200 MiB grow = True
PartSpec instance (0x7fc4f1ac7358) --
mountpoint = /boot lv = False thin = False btrfs = False
weight = 2000 fstype = ext4 encrypted = False
size = 500 MiB maxSize = None grow = False
PartSpec instance (0x7fc4f1ac7390) --
mountpoint = None lv = True thin = False btrfs = False
weight = 0 fstype = swap encrypted = True
size = 7.5 GiB maxSize = None grow = False
22:06:43,173 DEBUG anaconda: storage.disks: ['sda']
22:06:43,174 DEBUG anaconda: storage.partitioned: ['sda']
22:06:43,174 DEBUG anaconda: all names: ['/LiveOS/rootfs.img', '/overlay (deleted)', '/run/install/repo/LiveOS/squashfs.img', 'live-base', 'live-rw', 'loop0', 'loop1', 'loop2', 'sda']
22:06:43,179 DEBUG anaconda: boot disk: sda
22:06:43,193 DEBUG anaconda: candidate disks: [DiskDevice instance (0x7fc4f1acf438) --
name = sda status = True kids = 0 id = 227
parents = []
uuid = None size = 111.79 GiB
format = existing gpt disklabel
major = 8 minor = 0 exists = True protected = False
sysfs path = /sys/devices/pci0000:00/0000:00:17.0/ata2/host1/target1:0:0/1:0:0:0/block/sda
target size = 111.79 GiB path = /dev/sda
format args = [] originalFormat = disklabel removable = False]
22:06:43,195 DEBUG anaconda: devs: [PartitionDevice instance (0x7fc4f1abeeb8) --
name = req10 status = False kids = 0 id = 2596
parents = []
uuid = None size = 500 MiB
format = non-existent luks
major = 0 minor = 0 exists = False protected = False
sysfs path =
target size = 500 MiB path = /dev/req10
format args = [] originalFormat = luks grow = True max size = 0 B bootable = None
part type = None primary = False start sector = None end sector = None
partedPartition = None
disk = None
]
22:06:43,197 INFO anaconda: skipping unneeded stage1 efi request **** WIV SUSPICIOUS ???
22:06:43,197 DEBUG anaconda: PartSpec instance (0x7fc4f1ac7320) --
mountpoint = /boot/efi lv = False thin = False btrfs = False
weight = 5000 fstype = efi encrypted = False
size = 20 MiB maxSize = 200 MiB grow = True
22:06:43,198 DEBUG anaconda: None
22:06:43,454 DEBUG anaconda: finished automatic partitioning
wver...@eltan.com
Apr 24, 2017, 7:45:08 AM4/24/17
to qubes-users, marm...@invisiblethingslab.com
On Thursday, April 20, 2017 at 11:57:44 AM UTC+2, wver...@eltan.com wrote:
I think this is the culprit:
This code is in bootloader.py line 1422:
if subprocess.check_output(
['dmidecode', '-s', 'bios-vendor'],
universal_newlines=True) == "coreboot\n":
log.info("dmidecode -s bios-vendor returns coreboot")
self.encryption_support = True
self.skip_bootloader = True
self.stage2_format_types += ["lvmlv"]
This indicates the bootloader can be skipped for coreboot, which may be correct for coreboot with a grub payload integrated but not when the UEFI payload is used as it is in our case.
Best regards,
Wim Vervoorn
Marek Marczykowski-Górecki
Apr 24, 2017, 8:05:17 AM4/24/17
to wver...@eltan.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Mon, Apr 24, 2017 at 04:45:08AM -0700, wver...@eltan.com wrote:
> Hello,
>
> I think this is the culprit:
>
> This code is in bootloader.py line 1422:
>
> if subprocess.check_output(
> ['dmidecode', '-s', 'bios-vendor'],
> universal_newlines=True) == "coreboot\n":
> log.info("dmidecode -s bios-vendor returns coreboot")
> self.encryption_support = True
> self.skip_bootloader = True
> self.stage2_format_types += ["lvmlv"]
>
> This indicates the bootloader can be skipped for coreboot, which may be correct for coreboot with a grub payload integrated but not when the UEFI payload is used as it is in our case.
Yes, this is probably the case. There is very similar issue with
> Hello,
>
> I think this is the culprit:
>
> This code is in bootloader.py line 1422:
>
> if subprocess.check_output(
> ['dmidecode', '-s', 'bios-vendor'],
> universal_newlines=True) == "coreboot\n":
> log.info("dmidecode -s bios-vendor returns coreboot")
> self.encryption_support = True
> self.skip_bootloader = True
> self.stage2_format_types += ["lvmlv"]
>
> This indicates the bootloader can be skipped for coreboot, which may be correct for coreboot with a grub payload integrated but not when the UEFI payload is used as it is in our case.
Coreboot+SeaBIOS[1].
The problem is exactly what you've identified - the above should really
check for coreboot+grub2, but it checks only for coreboot.
[1] https://github.com/QubesOS/qubes-issues/issues/2553
- --
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-----
Version: GnuPG v2
zID829cggBZcq2xBpBrgFUxmg6Zf7U0A8qcROWMq3tIkOTg8yLFAmMYm2thuE31c
cTWDdNN2HA2aCtSpJLnp5p+KktXi7CGwYFRzRFXc8rU3theaSprSTmVryno3QgvJ
XLANDrom7SA4Hw4J76kft35qK2K8ezCE13n8IqAjG57PsBF+Q9VVHUmDEqYlGusp
sSxA91kYtn1wN1HsHwguoJmSdvcEWmyEkqG5Bq1kqTQLrI0iC15Dnwdk2kiRowme
dZWTGI6ip9ODQa+QnOaCqjCRynJ7gnbxKaPWLPQw0mlPv1ARbUHDhTSec7/Ybio=
=zPGn
-----END PGP SIGNATURE-----
Wim Vervoorn
Apr 24, 2017, 9:44:53 AM4/24/17
to Marek Marczykowski-Górecki, qubes-users
Hello Marek,
I tried this by changing the "coreboot" name in my coreboot version.
After that I performed a re-install.
After doing so this issue is solved. The xen.cfg is generated correct and the bootoptions are set correctly as well.
After this the system boots correctly without manual interactions.
I did run into another issue however but this is not related to writing the boot options I assume. After finalizing the setup the system is stuck with a cursor in the top left corner. I need to turn the system off to proceed. I try to gather some more information about this and post this as well.
Besides that I am wondering how you will deal with this issue. Will this be included in a new 3.2 release at some point in time or do I need to create a custom version to include this fix?
Best regards,
Wim
I tried this by changing the "coreboot" name in my coreboot version.
After that I performed a re-install.
After doing so this issue is solved. The xen.cfg is generated correct and the bootoptions are set correctly as well.
After this the system boots correctly without manual interactions.
I did run into another issue however but this is not related to writing the boot options I assume. After finalizing the setup the system is stuck with a cursor in the top left corner. I need to turn the system off to proceed. I try to gather some more information about this and post this as well.
Besides that I am wondering how you will deal with this issue. Will this be included in a new 3.2 release at some point in time or do I need to create a custom version to include this fix?
Best regards,
Wim
Sent: Monday, April 24, 2017 2:05 PM
To: Wim Vervoorn <wver...@eltan.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue
To: Wim Vervoorn <wver...@eltan.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue
Marek Marczykowski-Górecki
Apr 24, 2017, 9:54:14 AM4/24/17
to Wim Vervoorn, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Mon, Apr 24, 2017 at 01:44:35PM +0000, Wim Vervoorn wrote:
> Hello Marek,
>
> I tried this by changing the "coreboot" name in my coreboot version.
>
> After that I performed a re-install.
>
> After doing so this issue is solved. The xen.cfg is generated correct and the bootoptions are set correctly as well.
>
> After this the system boots correctly without manual interactions.
>
> I did run into another issue however but this is not related to writing the boot options I assume. After finalizing the setup the system is stuck with a cursor in the top left corner. I need to turn the system off to proceed. I try to gather some more information about this and post this as well.
>
> Besides that I am wondering how you will deal with this issue. Will this be included in a new 3.2 release at some point in time or do I need to create a custom version to include this fix?
See the issue I linked before[1]. There will updated 3.2 installation
> Hello Marek,
>
> I tried this by changing the "coreboot" name in my coreboot version.
>
> After that I performed a re-install.
>
> After doing so this issue is solved. The xen.cfg is generated correct and the bootoptions are set correctly as well.
>
> After this the system boots correctly without manual interactions.
>
> I did run into another issue however but this is not related to writing the boot options I assume. After finalizing the setup the system is stuck with a cursor in the top left corner. I need to turn the system off to proceed. I try to gather some more information about this and post this as well.
>
> Besides that I am wondering how you will deal with this issue. Will this be included in a new 3.2 release at some point in time or do I need to create a custom version to include this fix?
image ("3.2.1") in some not-so-distant future.
[1] https://github.com/QubesOS/qubes-issues/issues/2553
- --
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-----
Version: GnuPG v2
PQ23ylmv1OA52xtUpgUPFRaTNuQWWMK8cZlkAdi1eNzDQjiRvHjRxNMyUkUPjPLz
wQGpKIupqambM+WbxXo84soeyvI9mJ6waC4pElDv9Ku7R/I4qeYubdrcPnK669Nx
C/G/shrnSw93cAKboNYofufcNhLJUMiPhuTxakKoSgi4NsGUq0z+hITzZaHGu3cj
1ZUJIK9jK+LJrbvI5vEZW2K9meYUq9NpH2pqJ9FYps0zJsiX+UoqRvnYTgJtsuAG
jBI9Tn/Bo1eXtbSPXvyjtTlbrZurdfpKMDdrwi367YZ0m8e6Os8WE2j9zje86qM=
=rVn6
-----END PGP SIGNATURE-----
Wim Vervoorn
Apr 24, 2017, 11:24:19 AM4/24/17
to Marek Marczykowski-Górecki, qubes-users
-----Original Message-----
From: Marek Marczykowski-Górecki [mailto:marm...@invisiblethingslab.com]
Sent: Monday, April 24, 2017 3:54 PM
To: Wim Vervoorn <wver...@eltan.com>
Cc: qubes-users <qubes...@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue
Thanks for the feedback.
This is my last line of the anaconda logging:
22:50:35,609 INFO anaconda: Running kickstart %%post script(s)
def runPostScripts(scripts):
postScripts = [s for s in scripts if s.type == KS_SCRIPT_POST]
if len(postScripts) == 0:
return
log.info("Running kickstart %%post script(s)")
for script in postScripts:
script.run(iutil.getSysroot())
** STUCK BEFORE THIS
log.info("All kickstart %%post script(s) have been run")
Problem is that I don't know the process well enough to figure out which scripts are executed here.
Do you have some suggestions?
Best regards,
Wim Vervoorn
Reply all
Reply to author
Forward
0 new messages