Installer Bug - has not been fixed since I reported it in Qubes 2.0 installer.

[Drew White]

Text based install.

This issue has not been fixed since I reported it in Qubes 2.0 installer.

INSTALLATION DESTINATION

(LVM, LVM Thin Partitioning)

ERROR AS FOLLOWS..

--------------------------------------------
storage configuration failed: autopart failed:

Encryption requested for LUKS device sda2 but no encryption key specified for this device.

--------------------------------------------

(Standard, Btrfs Partitioning)

--------------------------------------------
storage configuration failed: autopart failed:

Encryption requested for LUKS device sda2 but no encryption key specified for this device.

Encryption requested for LUKS device sda3 but no encryption key specified for this device.

--------------------------------------------

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks for the report. Tracking here:

https://github.com/QubesOS/qubes-issues/issues/2113

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXbd4XAAoJENtN07w5UDAwZ90P/18GXXkU7kRyKFZH5M2ucbHz
pIh5U0yITJLkdtg64bnIJDTMXstnUv00iD6l7onG+1zpcfMvR0Om8NDb+toXwuNl
ap8/Xh6B8s+kniIcrmPaKTqfj4//MEXhr5PCfzDDEbnxWp9+VE77X5nckOgiMV/4
4XSV4TWHkUd+28bSloXHFBTi/0OMTpnusnyxm/i1qkd8c3cHoFFhXaU8u8lcPB53
TJUs+SuO35EJUICvxYQx0aNhdF4UO3DINeN4Gw3uvHR9s/CJmsyKvAdU+F9jZ3Qv
6kNkxp1Y7YHEJ4lrDE1DfHrjtLnCWZ0HJCpDxmqasBhz9/rGol5Y/vNFpp9VSxiX
jgRDHNJpUEeNLj1qYipKPffGBdysBLAZWJswFA6R/gXJx73YY633cwMy3RKibweU
U2T8wqWVkQP93QIU0W9ANSXidFBAHc7fdyM1aqnIhMLs6DL0O/H45QXz+rRXJPXd
pa2zHg1Ob3ho4U7MESPE/KzcAQaTaaczOr7FFkFI2lVPCYT1pf4CdD1FM+bDXnsP
GOExk/1rlHJVzSKhV98Kl7uZ4+oJB82/t+ICjxS+cwb2hQhOHCfAPBQpy1BJItJX
T1F7UMq564VpeDIi2bCsevXlZyqCROaBRD4+19gb6oP1BohNdmJkXpu5cudgDjdL
nXR43c49/5CdaB0mkiME
=Ii5k
-----END PGP SIGNATURE-----

[Drew White]

Text based install

In the installer, when I don't get the LUKS bug, and it doesn't work right, I get the following error....

It creates "luks" on /dev/sda2, even though I have not selected LUKS, nor set a password for it.

then it comes up with...

--------------

(anaconda:957): Gdk-ERROR **: error: XDG_RUNTIME_DIR not set in the environment.

Pane is dead

--------------

There is no graphical interface, it's text based...

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks. Tracking here:

https://github.com/QubesOS/qubes-issues/issues/1623

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXcYCNAAoJENtN07w5UDAwi4gQAJBc8st6HVpmZDAaU2J9AXK5
A0uUmtxv412fGQMHjAM5CAm0kayEM3kDc0YFkw+A+jhDAc9dzCrShq28KVGdHdBV
qyjniQOUPzWlXSmFEhNqAjPupLm23t4uvlmSORRrZyVO8L8umpL59OHDNqU+jXLq
LAJDsozpRyL2RlXlbMCSHdKwilUi/ZSHcr5vNGeDRetWMWO5nD/oyBDk5wHHrkjh
3kOgL1Kqz+eM6UGUcnoGz1V+wZ43qiycSkbDQ8YnxsGRc7qhIFR4rs8WF2fCRvb6
4r+QlraAkJ/BIvCsAEUiezi0u7WLE8NlYEDZaZmD91VMUwbBiy271C/AULPIqka1
B3jPnMX2VWKqh9JvP2kQC/XPUrS65LgxnRvrDF0Hnq8tCkcE6YXrtwYaOCzcLPjN
eFg7ZHlHOm0uqPh8DOAIOHKZ+o5IaEIGVviJmPmKyCHPrUEC1UHox+d47atisdNt
gTVdWeQ0L+sBo7rg9QbrlEW84Yb+71zpJKM1ReVWEscceTahF0GGG5hCJ0E1wB/3
zICBCFVjSiUTTGZs9IAOrembB0TsoNCmPW1W5zqguOWFD6V8tg/LAE+sQiS4/keK
pb/vrXzaUrla0lCY7/64XK+5nv4E+5oZpXxLUoUUR9U+bxYL0PyQ35GhR6SupyKN
OTPEJoARk6nI9hsU4Vm5
=8moY
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

I think the XDG_RUNTIME_DIR message is unrelated, I've seen this also on
successful installation. Actual error message is probably in log file
in /tmp (?).
Anyway, it is probably still about passphrase not set. And it isn't set,
because anaconda in text mode does not have support for it.
Which is described here:
https://github.com/QubesOS/qubes-issues/issues/1161

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

iQEcBAEBCAAGBQJXcYbfAAoJENuP0xzK19csbJ8H/jviai7jiQoQuqcXbDLl585r
1Mr4Q1FyU6iQVDfupCLGiaJ5M+jc2GJ8We/1hhCihdk+PG9VsbOcFkkxC4nJzLcV
y0pObKBBdktesTn4zxLyd8GG9+JRHSK48tl3QP485sJ2yk2DSXOBOf+GdYiQeg2z
U7V26rBXa4ci8/s7XHeke+vOZYfD4CgDa120stIOpON0eMTkvX7JIUflzc+v2qSF
/EINN3VgQVSirR9xw3x/JSa8PTj4OPsRL/Huq84aVUL0nZwLuTiQJcc2Ec+qvzVh
RP2bcbc4CrYsq6zHmLnbl+Bf7eFsBhWoubzkHNADRpIHk+1cNW3jG9tUl14ymtk=
=pHkY
-----END PGP SIGNATURE-----

[Drew White]

On Tuesday, 28 June 2016 06:05:15 UTC+10, Marek Marczykowski-Górecki wrote:

I think the XDG_RUNTIME_DIR message is unrelated, I've seen this also on
successful installation.

 

 Interesting, I have not seen it on successful installs. Perhaps I missed it and it

went past too fast on the screen.

Actual error message is probably in log file in /tmp (?).

The error message in the log file is still the same. for the anaconda log file.

For the others, this is what happens around the same time...

---------- program.log

INFO program: Running... udevadm settle --timeout=300

DEBUG program: Return code: 0

INFO program: Running... udevadm settle --timeout=300

DEBUG program: Return code: 0

wipefs -f -a /dev/sda2

DEBUG program: Return code: 0

INFO program: Running... udevadm settle --timeout=300

DEBUG program: Return code: 0

INFO program: Running... udevadm settle --timeout=300

DEBUG program: Return code: 0

---------- storage.log

DEBUG blivet:            DiskLabel.commitToDisk: device: /dev/sda2 ; numparts: 2 ;

DEBUG blivet:            LUKS.create: device: /dev/sda2 ; status: False ; type: luks ;

---------- 

Is that what you were after?

Anyway, it is probably still about passphrase not set. And it isn't set,
because anaconda in text mode does not have support for it.
Which is described here:
https://github.com/QubesOS/qubes-issues/issues/1161

You may be correct, but it says that LUKS creation is false, does that mean it's not being used, or it's being used and not set when it wasn't set?

 

[jespernex...@gmail.com]

Hi all.

This it stilla an issue. Ive created a VM in Virtualbox - the graphical installer does not show up, and the text based installer fails. This has been a serious problem since 3.1.

I realise this is described in https://github.com/QubesOS/qubes-issues/issues/2113 - but this is not a solution - its a bad workaround.

When will anyone take this problem seriously?

[Alex]

On 08/22/2017 01:46 PM, jespernex...@gmail.com wrote:
> This it stilla an issue. Ive created a VM in Virtualbox - the graphical installer does not show up, and the text based installer fails. This has been a serious problem since 3.1.
>
> I realise this is described in https://github.com/QubesOS/qubes-issues/issues/2113 - but this is not a solution - its a bad workaround.
>
> When will anyone take this problem seriously?

Since it's not a problem in Qubes itself, but in anaconda (please see
https://bugzilla.redhat.com/show_bug.cgi?id=1020345 as linked by
https://github.com/QubesOS/qubes-issues/issues/1161) and since it has
been closed as wontfix with the dry statement "LUKS configuration is not
available in text mode", I see it highly unlikely that it will be ever
fixed.

The bug in Qubes tracker may itself be considered closed once the text
mode setup will be disabled and a feature request is opened for a text
mode setup, which will get a very low priority and hang on indefinitely
because of the impossibility of setting up LUKS in text mode. Some
project managers may prefer having a pending feature request than having
a pending bug.

As a side remark, please note that installing qubes in a VM is obviously
and clearly stated as unsupported and most likely will produce bug
chains like the one you are encountering, which should originate with
the inability to load the "vboxvideo" X driver (thus the text mode
install attempt, that fails on LUKS). Please test Qubes on a spare
physical PC: it also makes very little sense to try to use it as a
production OS in a virtualized environment. If you need a virtualization
host OS you can try the free ESXi, Proxmox or other alternatives to those.

--
Alex

[jespernex...@gmail.com]

Thanks for a quick reply Alex :-)

I think that most people would test Qubes OS (or any other new OS) in a VM before wiping a physical machine - and a lot of people probably dont even own spare physical machines, these days...so making it work within another hypervisor would make good sense. The docs does say that it is unsupported, but usually that doesnt mean "completely unusable" ;)

Perhaps just a meaningful error message would help people figure out why the installer seems to crash and/or behave like some buggy app. A project manager that disguises bugs like this as a low-prio feature req..well..hmm.. ;)

I guess the next step would be to see if VMWare will work with the graphical installer :)

Thanks for the explanation!

[Alex]

On 08/22/2017 02:15 PM, jespernex...@gmail.com wrote:
> I think that most people would test Qubes OS (or any other new OS) in
> a VM before wiping a physical machine - and a lot of people probably
> dont even own spare physical machines, these days...so making it work
> within another hypervisor would make good sense. The docs does say
> that it is unsupported, but usually that doesnt mean "completely
> unusable" ;)

It makes no sense in trying to make Xen work as a vm guest; Xen people
themselves said that they are not going to support that (sorry but I
don't have a link to that discussion at hand), and Qubes recently
(couple years at least) added the ability to be tested as a live distro
without touching the working OS installed.

Even if you manage to start anaconda/X, you'll probably encounter many
problems with Xen.

And yes, usually when you see "unsupported" it means "barely exists",
and it not only applies to Qubes but a lot of other things too - not
just software!

> Perhaps just a meaningful error message would help people figure out
> why the installer seems to crash and/or behave like some buggy app. A
> project manager that disguises bugs like this as a low-prio feature
> req..well..hmm.. ;)

Since it's actually not a bug in qubes the ticket could be just closed,
the text setup disabled, and that would be all. But not to lose the
detailed info about the issue, I think a nice thing to do to the users
that had experienced the problem would be reopening the issue as a
feature request. But I'm usually told that I'm too nice of a project
manager towards user requests.

Have a nice test (please consider the live cd / usb instead of virtual
machines!)

--
Alex

[Steve Coleman]

On 08/22/2017 08:15 AM, jespernex...@gmail.com wrote:

> I guess the next step would be to see if VMWare will work with the graphical installer :)

Qubes-OS is a HVM visualization system that works directly with the
hardware, and its use under another virtualization system is likely to
have many problems. The security that it provides depends on this being
the right hardware, and the virtualized hardware just isn't the same. In
short, don't test is under VirtualBox/VMWare and expect to see what it
will be like, because that is simply not a valid way to test it.

There used to be a Live DVD you could boot to test it, but that DVD is
ancient at this point. The better way to test (imho) is to instead
install it onto a fast bootable USB drive and then use grub or your BIOS
boot sequence to boot from that drive. Then Qubes will be running
natively on your real hardware, and the only difference is that the
locally installed system will likely run much faster, since the external
USB IO is likely much slower than your actual system drive.

best of luck,

Steve