RE: [qubes-users] UEFI installation issue

2017-04-24 Thread Wim Vervoorn 


-Original Message-
From: Marek Marczykowski-Górecki [mailto:marma...@invisiblethingslab.com] 
Sent: Monday, April 24, 2017 3:54 PM
To: Wim Vervoorn <wvervo...@eltan.com>
Cc: qubes-users <qubes-users@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Apr 24, 2017 at 01:44:35PM +, 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 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

iQEcBAEBCAAGBQJY/gOAAAoJENuP0xzK19cscQ8H/AvXmWEExm/OBstwLUoHb6tB
PQ23ylmv1OA52xtUpgUPFRaTNuQWWMK8cZlkAdi1eNzDQjiRvHjRxNMyUkUPjPLz
wQGpKIupqambM+WbxXo84soeyvI9mJ6waC4pElDv9Ku7R/I4qeYubdrcPnK669Nx
C/G/shrnSw93cAKboNYofufcNhLJUMiPhuTxakKoSgi4NsGUq0z+hITzZaHGu3cj
1ZUJIK9jK+LJrbvI5vEZW2K9meYUq9NpH2pqJ9FYps0zJsiX+UoqRvnYTgJtsuAG
jBI9Tn/Bo1eXtbSPXvyjtTlbrZurdfpKMDdrwi367YZ0m8e6Os8WE2j9zje86qM=
=rVn6
-END PGP SIGNATURE-

Hello Marek,

Thanks for the feedback.

This is my last line of the anaconda logging:

22:50:35,609 INFO anaconda: Running kickstart %%post script(s)

So my system seems to be stuck here:

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



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9b2e299a0b1e4515a8d45b5b02ba769f%40Eltsrv03.Eltan.local.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] UEFI installation issue

2017-04-24 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Apr 24, 2017 at 01:44:35PM +, 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
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

iQEcBAEBCAAGBQJY/gOAAAoJENuP0xzK19cscQ8H/AvXmWEExm/OBstwLUoHb6tB
PQ23ylmv1OA52xtUpgUPFRaTNuQWWMK8cZlkAdi1eNzDQjiRvHjRxNMyUkUPjPLz
wQGpKIupqambM+WbxXo84soeyvI9mJ6waC4pElDv9Ku7R/I4qeYubdrcPnK669Nx
C/G/shrnSw93cAKboNYofufcNhLJUMiPhuTxakKoSgi4NsGUq0z+hITzZaHGu3cj
1ZUJIK9jK+LJrbvI5vEZW2K9meYUq9NpH2pqJ9FYps0zJsiX+UoqRvnYTgJtsuAG
jBI9Tn/Bo1eXtbSPXvyjtTlbrZurdfpKMDdrwi367YZ0m8e6Os8WE2j9zje86qM=
=rVn6
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170424135407.GW1258%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

RE: [qubes-users] UEFI installation issue

2017-04-24 Thread Wim Vervoorn 
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

-Original Message-
From: Marek Marczykowski-Górecki [mailto:marma...@invisiblethingslab.com] 
Sent: Monday, April 24, 2017 2:05 PM
To: Wim Vervoorn <wvervo...@eltan.com>
Cc: qubes-users <qubes-users@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Apr 24, 2017 at 04:45:08AM -0700, wvervo...@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
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

iQEcBAEBCAAGBQJY/en3AAoJENuP0xzK19csPmoIAIt4ZJSffGxqH3rZH0WN5ysS
zID829cggBZcq2xBpBrgFUxmg6Zf7U0A8qcROWMq3tIkOTg8yLFAmMYm2thuE31c
cTWDdNN2HA2aCtSpJLnp5p+KktXi7CGwYFRzRFXc8rU3theaSprSTmVryno3QgvJ
XLANDrom7SA4Hw4J76kft35qK2K8ezCE13n8IqAjG57PsBF+Q9VVHUmDEqYlGusp
sSxA91kYtn1wN1HsHwguoJmSdvcEWmyEkqG5Bq1kqTQLrI0iC15Dnwdk2kiRowme
dZWTGI6ip9ODQa+QnOaCqjCRynJ7gnbxKaPWLPQw0mlPv1ARbUHDhTSec7/Ybio=
=zPGn
-END PGP SIGNATURE-


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8ee2061bbf74448ab3f2f2965c89f3e0%40Eltsrv03.Eltan.local.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] UEFI installation issue

2017-04-24 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Apr 24, 2017 at 04:45:08AM -0700, wvervo...@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
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

iQEcBAEBCAAGBQJY/en3AAoJENuP0xzK19csPmoIAIt4ZJSffGxqH3rZH0WN5ysS
zID829cggBZcq2xBpBrgFUxmg6Zf7U0A8qcROWMq3tIkOTg8yLFAmMYm2thuE31c
cTWDdNN2HA2aCtSpJLnp5p+KktXi7CGwYFRzRFXc8rU3theaSprSTmVryno3QgvJ
XLANDrom7SA4Hw4J76kft35qK2K8ezCE13n8IqAjG57PsBF+Q9VVHUmDEqYlGusp
sSxA91kYtn1wN1HsHwguoJmSdvcEWmyEkqG5Bq1kqTQLrI0iC15Dnwdk2kiRowme
dZWTGI6ip9ODQa+QnOaCqjCRynJ7gnbxKaPWLPQw0mlPv1ARbUHDhTSec7/Ybio=
=zPGn
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170424120511.GU1258%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] UEFI installation issue

2017-04-24 Thread wvervoorn 
On Thursday, April 20, 2017 at 11:57:44 AM UTC+2, wver...@eltan.com wrote:
> 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: 
> 
> 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 : wvervo...@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-users@googlegroups.com [mailto:qubes-users@googlegroups.com] On 
> Behalf Of Marek Marczykowski-Górecki
> Sent: Wednesday, April 19, 2017 9:39 PM
> To: Wim Vervoorn <wvervo...@eltan.com>
> Cc: qubes-users <qubes-users@googlegroups.com>
> Subject: Re: [qubes-users] UEFI installation issue
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Wed, Apr 19, 2017 at 09:06:48AM +, 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=8003
> 
> Hmm, this actually may be

Re: [qubes-users] UEFI installation issue

2017-04-24 Thread wvervoorn 
On Thursday, April 20, 2017 at 11:57:44 AM UTC+2, wver...@eltan.com wrote:
> 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: 
> 
> 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 : wvervo...@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-users@googlegroups.com [mailto:qubes-users@googlegroups.com] On 
> Behalf Of Marek Marczykowski-Górecki
> Sent: Wednesday, April 19, 2017 9:39 PM
> To: Wim Vervoorn <wvervo...@eltan.com>
> Cc: qubes-users <qubes-users@googlegroups.com>
> Subject: Re: [qubes-users] UEFI installation issue
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Wed, Apr 19, 2017 at 09:06:48AM +, 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=8003
> 
> Hmm, this actually may be

RE: [qubes-users] UEFI installation issue

2017-04-20 Thread Wim Vervoorn 
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 : wvervo...@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-users@googlegroups.com [mailto:qubes-users@googlegroups.com] On 
Behalf Of Wim Vervoorn
Sent: Thursday, April 20, 2017 11:57 AM
To: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>
Cc: qubes-users <qubes-users@googlegroups.com>
Subject: RE: [qubes-users] UEFI installation issue

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: 

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 : wvervo...@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-users@googlegroups.com [mailto:qubes-users@googlegroups.com] On 
Behalf Of Marek Marczykowski-Górecki
Sent: Wednesday, April 19, 2017 9:39 PM
To: Wim Vervoorn <wvervo...@eltan.com>
Cc: qubes-users <qubes-users@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Apr 19, 2017 at 09:06:48AM +, 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 co

RE: [qubes-users] UEFI installation issue

2017-04-20 Thread Wim Vervoorn 
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 : wvervo...@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:marma...@invisiblethingslab.com] 
Sent: Wednesday, April 19, 2017 9:26 PM
To: Wim Vervoorn <wvervo...@eltan.com>
Cc: qubes-users <qubes-users@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Apr 19, 2017 at 09:21:10PM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Apr 19, 2017 at 02:07:37PM +, 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 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).

Based on installation log (the other email), I actually can tell you 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

iQEbBAEBCAAGBQJY97neAAoJENuP0xzK19cssfAH+NQmb0JoDPL0qR/Y6J4is0aT
0lR04AynMNz+41pX0KilORAd02lob9my/rTrriiL2k6pgMC5rnpgMTFBG9Y/J0NF
rDuyvyhPIw6A524dhG2nRZbqRb91oyS8z/TNgHeDdviWzT7Wt+FX+qXbvDlcJkdE
7JIEfzoAgWEeOtu0NUowQ3D1gX0AWVdCxykh/fYw4sUZuV1DXhdXLSYbGSrJrevn
KODd5au6oe0EWw+MzOzMqVSXKTxDVS2CHs71HN4YEvygXjCiqk9IOrqN702tUwmV
4MkS/QDV/EOscUVFMKttSLXM6hz8bOT44vjiFCiqknLZ90qDpE90duzkNflsgg==
=+OLV
-END PGP SIGNATURE-


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5e14db6ef4b4445d8de03a3e393de4de%40Eltsrv03.Eltan.local.
For more options, visit https://groups.google.com/d/optout.

RE: [qubes-users] UEFI installation issue

2017-04-20 Thread Wim Vervoorn 
Hello Marek,

Please look at my comments below:

Wim 

-Original Message-
From: qubes-users@googlegroups.com [mailto:qubes-users@googlegroups.com] On 
Behalf Of Marek Marczykowski-Górecki
Sent: Wednesday, April 19, 2017 9:39 PM
To: Wim Vervoorn <wvervo...@eltan.com>
Cc: qubes-users <qubes-users@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Apr 19, 2017 at 09:06:48AM +, 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

> 
> 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=8003

Hmm, this actually may be a problem. I'm not sure what
status=8003 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 0x8003 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-

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170419193904.GE1486%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2e6b8dd062294a3fadfaf69a3e7c68a7%40Eltsrv03.Eltan.local.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] UEFI installation issue

2017-04-19 Thread Andrew David Wong 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-04-19 12:26, Marek Marczykowski-Górecki wrote:
> On Wed, Apr 19, 2017 at 09:21:10PM +0200, Marek Marczykowski-Górecki wrote:
>> On Wed, Apr 19, 2017 at 02:07:37PM +, 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
>> 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).
> 
> Based on installation log (the other email), I actually can tell you
> 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...).
> 

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-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b2945268-ef23-23bf-37b0-679d0c6841d5%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] UEFI installation issue

2017-04-19 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Apr 19, 2017 at 09:06:48AM +, 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=8003

Hmm, this actually may be a problem. I'm not sure what
status=8003 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

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 the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170419193904.GE1486%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] UEFI installation issue

2017-04-19 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Apr 19, 2017 at 09:21:10PM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Apr 19, 2017 at 02:07:37PM +, 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
> 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).

Based on installation log (the other email), I actually can tell you
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

iQEbBAEBCAAGBQJY97neAAoJENuP0xzK19cssfAH+NQmb0JoDPL0qR/Y6J4is0aT
0lR04AynMNz+41pX0KilORAd02lob9my/rTrriiL2k6pgMC5rnpgMTFBG9Y/J0NF
rDuyvyhPIw6A524dhG2nRZbqRb91oyS8z/TNgHeDdviWzT7Wt+FX+qXbvDlcJkdE
7JIEfzoAgWEeOtu0NUowQ3D1gX0AWVdCxykh/fYw4sUZuV1DXhdXLSYbGSrJrevn
KODd5au6oe0EWw+MzOzMqVSXKTxDVS2CHs71HN4YEvygXjCiqk9IOrqN702tUwmV
4MkS/QDV/EOscUVFMKttSLXM6hz8bOT44vjiFCiqknLZ90qDpE90duzkNflsgg==
=+OLV
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170419192621.GD1486%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] UEFI installation issue

2017-04-19 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Apr 19, 2017 at 02:07:37PM +, 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
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

iQEcBAEBCAAGBQJY97imAAoJENuP0xzK19csKu8H/1VIhuZf6xEY60C93VM4WGTI
yBhnZDhj6rDkDJWd/c6HfwuxiAtOCK/WcqLu5Tj9M0lUNwUNuqX90u5I2ID4GwFN
I+tYFz8FsYA3OsXBaHvjl8gGGtuuWW7GMg9wPG7gDoSlTRuDYKHDsdCqN4KuyPJu
Oxvg70W89Q/uTOeZ39YbMUDQDNb5K2ZG/ob9a7/4LdOGr4Pg1mNzWkvELCnm3moF
TfKBzrQE6Hrw+gl5wXzoyM2lQKQIU6tBT2hC3LfRDoTj4tklNwlvJW3J0PN51PDj
n0zWcNTOpsajwHSBBXtAlccjOkhZKaEa5xSzH9rOIWKTp285zjBs13b3Kq1gElA=
=R4F8
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170419192110.GD19207%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

RE: [qubes-users] UEFI installation issue

2017-04-19 Thread Wim Vervoorn 
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.


Best Regards,

Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : +31-(0)73-594 46 64
E : wvervo...@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: Wim Vervoorn 
Sent: Wednesday, April 19, 2017 11:07 AM
To: 'Marek Marczykowski-Górecki' <marma...@invisiblethingslab.com>
Cc: qubes-users <qubes-users@googlegroups.com>
Subject: RE: [qubes-users] UEFI installation issue

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 : wvervo...@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:marma...@invisiblethingslab.com]
Sent: Tuesday, April 18, 2017 9:30 PM
To: Wim Vervoorn <wvervo...@eltan.com>
Cc: qubes-users <qubes-users@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Apr 18, 2017 at 05:45:09AM -0700, wvervo...@eltan.com wrote:
> 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

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-


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ad1d2f3cf5ac408a933afe2a76b1b698%40Eltsrv03.Eltan.local.
For more options, visit https://groups.google.com/d/optout.
+ cat /lib/dracut/dracut-043-63.git20151211.fc23
dracut-043-63.git20151211.fc23
+ cat /proc/cmdl

RE: [qubes-users] UEFI installation issue

2017-04-19 Thread Wim Vervoorn 
Hello Marek,

When I looked at what happens when xen starts I also see this error message:

ConvertPages: failed to find range 82D08000 - 82D0811F

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.


Best Regards,

Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : +31-(0)73-594 46 64
E : wvervo...@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-users@googlegroups.com [mailto:qubes-users@googlegroups.com] On 
Behalf Of Wim Vervoorn
Sent: Wednesday, April 19, 2017 11:07 AM
To: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>
Cc: qubes-users <qubes-users@googlegroups.com>
Subject: RE: [qubes-users] UEFI installation issue

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 : wvervo...@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:marma...@invisiblethingslab.com]
Sent: Tuesday, April 18, 2017 9:30 PM
To: Wim Vervoorn <wvervo...@eltan.com>
Cc: qubes-users <qubes-users@googlegroups.com>
Subject: Re: [qubes-users] UEFI installation issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Apr 18, 2017 at 05:45:09AM -0700, wvervo...@eltan.com wrote:
> 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

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-


--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ab89ef80b1fa4a839fa986090b8090ef%40Eltsrv03.Eltan.local.
For mor

Re: [qubes-users] UEFI installation issue

2017-04-18 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Apr 18, 2017 at 05:45:09AM -0700, wvervo...@eltan.com wrote:
> 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

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-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170418192951.GC19207%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

RE: [qubes-users] UEFI installation issue

2017-04-18 Thread Wim Vervoorn 
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   8,192  .
  04/18/17  02:54a   8,192  ..
  04/18/17  03:25a0  xen.cfg
  07/26/16  11:56a2,126,535  xen-4.6.1.efi
  04/18/17  03:25a5,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 : wvervo...@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-users@googlegroups.com [mailto:qubes-users@googlegroups.com] On 
Behalf Of wvervo...@eltan.com
Sent: Tuesday, April 18, 2017 2:45 PM
To: qubes-users 
Subject: [qubes-users] UEFI installation issue

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@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.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/11b986ca836b409290ff7a313bada750%40Eltsrv03.Eltan.local.
For more options, visit https://groups.google.com/d/optout.