HCL report / some problems

[Marc de Bruin]

Lo,

Please find attached the HCL report for my machine:

Model Name:    Dell_Inc. XPS_L521X
Kernel:        3.12.23-1
Xen:        4.1.6.1

RAM:        16266 Mb

CPU:        Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz
Chipset:    00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09)
VGA:        00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
        01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK107M [GeForce GT 640M] [10de:0fd2] (rev a1) (prog-if 00 [VGA controller])

Net:        07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)
        08:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01)

SCSI:        LITEONIT LCT-512 Rev: VSDC
        DVDRWBD UJ167    Rev: 1.01

BIOS:        A16
VT-x:        Active
VT-d:        Active

I did run into some small glitches.

1. Although the installation went fine, it seemed it hanged after the reboot, immediately after GRUB. The screen showed exactly one line: "[   8.686029] usb 2-1.5: string descriptor 0 read error: -22". However, before installing it natively on my machine, I managed to install Qubes in a VMware VM and based from that experience, I knew I had to punch down the password for the encrypted partition at that stage during the boot process. So typing in the password (no feedback at all!) and pressing enter continues the startup and allows me to login. Strange behavior. Nice security by obscurity though! :-)
   
2. I did not manage to successfully enable TRIM for my SSD. I followed the instructions on https://qubes-os.org/wiki/DiskTRIM very closely, but in the end, sudo dmsetup table doesn't show it is enabled. I guess the problem is related to this kernel message: "systemd-cryptsetup-generator[92]: Unknown kernel switch rd.luks.allow-discards=1. Ignoring." Any ideas about this?
   
3. Sometimes, shutting down a PV takes a lot of time. Occasionally up to 60 seconds. Haven't got a clue yet.
   
4. I installed the Debian template but as already mentioned, opening a terminal shows black text on a black background. Yet, how can I still do something useful with it? I'm more familiar with Debian and less with Fedora, so I'd rather use Debian.
   

I didn't bother to install the Nvidia stuff, although my machine might support it. Also have not test sleep/resume yet, I'm a bit nervous to try it, it's not a Mac, you know, it's a Dell!

I'm also having problems getting an original physical Windows installation working in a HVM, as in doing a P2V. I used dd to image the entire disk and performed the restore using dd within a HVM, using SystemRescueCD. Booting the HVM results in the notorious STOP 0x7B BSOD however. I tried some of the obvious things but it didn't work. It is probably missing drivers which I didn't add to the Windows installed upfront. Are there any drivers I could/should have added, specifically for the virtual IO stuff?

Greetz,

Marc.

[Marek Marczykowski-Górecki]

> 1. Although the installation went fine, it seemed it hanged after the

> reboot, immediately after GRUB. The screen showed exactly one line: "[
> 8.686029] usb 2-1.5: string descriptor 0 read error: -22". However, before
> installing it natively on my machine, I managed to install Qubes in a
> VMware VM and based from that experience, I knew I had to punch down the
> password for the encrypted partition at that stage during the boot process.
> So typing in the password (no feedback at all!) and pressing enter
> continues the startup and allows me to login. Strange behavior. Nice
> security by obscurity though! :-)

> 2. I did not manage to successfully enable TRIM for my SSD. I followed

> the instructions on https://qubes-os.org/wiki/DiskTRIM very closely, but in
> the end, sudo dmsetup table doesn't show it is enabled. I guess the problem
> is related to this kernel message: "systemd-cryptsetup-generator[92]:
> Unknown kernel switch rd.luks.allow-discards=1. Ignoring." Any ideas about
> this?

Try adding "rd.luks.options=discard" instead of
"rd.luks.allow-discards=1" to /etc/default/grub. Let us know if that
works for you, so we can update the instructions.

> 3. Sometimes, shutting down a PV takes a lot of time. Occasionally up to

> 60 seconds. Haven't got a clue yet.

Take a look at "sudo xl console VMNAME" output (exit with Ctrl+] ).
There should be info what that VM is doing.

> 4. I installed the Debian template but as already mentioned, opening a

> terminal shows black text on a black background. Yet, how can I still do
> something useful with it? I'm more familiar with Debian and less with
> Fedora, so I'd rather use Debian.

Of course you can change the colors in terminal settings :)
Although I would wait a week or two - we will release new template
version with a lot of improvements.

> I didn't bother to install the Nvidia stuff, although my machine might
> support it. Also have not test sleep/resume yet, I'm a bit nervous to try
> it, it's not a Mac, you know, it's a Dell!
>
> I'm also having problems getting an original physical Windows installation
> working in a HVM, as in doing a P2V. I used dd to image the entire disk and
> performed the restore using dd within a HVM, using SystemRescueCD. Booting
> the HVM results in the notorious STOP 0x7B BSOD however. I tried some of
> the obvious things but it didn't work. It is probably missing drivers which
> I didn't add to the Windows installed upfront. Are there any drivers I
> could/should have added, specifically for the virtual IO stuff?

Try safe mode, there you can try to install missing drivers.

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

[cprise]

Marek, the password prompt seems to be a recurring problem at boot time. Is there an option, such as omitting Plymouth, that could avert this bug?

[Oleg Artemiev]

Hello.

> So typing in the password (no feedback at all!) and pressing enter
> continues the startup and allows me to login. Strange behavior. Nice
> security by obscurity though! :-)
> Marek, the password prompt seems to be a recurring problem at boot time. Is
> there an option, such as omitting Plymouth, that could avert this bug?

BTW: When the team will fix this minor bug - please leave an option to
hide the password prompt.
Some times the host looking like hanged is okay to fool the layman check. :)

Especially on mine asus n56vz the boot process is talking about some
non-critical error right before waiting for password (cpu or acpi -
don't remember) - okay to tell
that machine is un-bootable - "something has broken, I donno". =)
Thouhg this wouldn't help for a long time - AFAIR, after a very long
timeout this will boot to emergency mode
with a lot of errors. I'd prefer this be an option - nice to have
possibility to wait for password forever.


--
Bye.Olli.
gpg --search-keys grey_olli
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (mostly in russian): http://grey-olli.livejournal.com/tag/

[Marc de Bruin]

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

On 29/01/15 00:04, Marek Marczykowski-Górecki wrote:
>> 2. I did not manage to successfully enable TRIM for my SSD. I
>> followed the instructions on https://qubes-os.org/wiki/DiskTRIM
>> very closely, but in the end, sudo dmsetup table doesn't show it
>> is enabled. I guess the problem is related to this kernel
>> message: "systemd-cryptsetup-generator[92]: Unknown kernel switch
>> rd.luks.allow-discards=1. Ignoring." Any ideas about this?
>
> Try adding "rd.luks.options=discard" instead of
> "rd.luks.allow-discards=1" to /etc/default/grub. Let us know if
> that works for you, so we can update the instructions.

With this change, the kernel message disappears, yet still 'sudo
dmsetup table' doesn't show TRIM enabled.

'sudo fstrim -v /' says: "fstrim: /: discard operation not supported."

Maybe my SSD doesn't support TRIM? Is that even possible?

Greetz,
Marc
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUy+N5AAoJEG7SigwLJqZsaY0P/2ezvH1Zst855FoGrU7GUSa/
triWIMJEmp+sldAasnjGT3dTj37T7agsZSl1Soa3iEa19UeGjuxJc31STPC1Hqf5
0RW7GFrmmuzUV6dHjkINx7Cam0as3r3dmu0uej1I8cEuh48prJccJ/AXqg8QWUm4
O/Lwv+byjMAmL+n1/XRd5DvfBcSyEHiwR2wcQNY24mGP/7X2xI/83LdIJa9/qNam
arlyY2Z2a+pgNn/na3rINqvlZC/vmvL5T946sH4nMfS23rk7B+SQsGzNJpfQVHum
zah19+b/cbULkyVFMz6YaZRzFpKipAF/laZOzgFyT5iJv/eOJ15SHw+JcSERHhZ0
eoE5O4nZG4jizV50R+7MY2PCKVgacdt3DLz2K/U9N5hJuK/t1a4a0UL25JvOHC8+
8KU+enD77DNmXRrUfdb6LGli4h67NLQ44793YhTfbJnCYY8IkxVMXstxoTl9fksn
KOtjy9+xoJb+6dk4gCigRGsPZ+kshnGCiKK+pYfJTKQpccvheRk9fPZrx0KkEZIh
n0QJqQDiDcMZP1yv/XatEr70L8hfIm0R5xZC/6Q4iPF0aG8XDEbbx5J3We14b5xB
vDsCPxoe3NUGojo+3X/5JyDxuVpoSAWR4b4EUx47V7aNPT+J7WueLmJX1ZaBsSDM
1bAm10KZ26i0H+sPUjFE
=jYjH
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On Fri, Jan 30, 2015 at 09:03:05PM +0100, Marc de Bruin wrote:
> On 29/01/15 00:04, Marek Marczykowski-Górecki wrote:
> >> 2. I did not manage to successfully enable TRIM for my SSD. I
> >> followed the instructions on https://qubes-os.org/wiki/DiskTRIM
> >> very closely, but in the end, sudo dmsetup table doesn't show it
> >> is enabled. I guess the problem is related to this kernel
> >> message: "systemd-cryptsetup-generator[92]: Unknown kernel switch
> >> rd.luks.allow-discards=1. Ignoring." Any ideas about this?
> >
> > Try adding "rd.luks.options=discard" instead of
> > "rd.luks.allow-discards=1" to /etc/default/grub. Let us know if
> > that works for you, so we can update the instructions.
>
> With this change, the kernel message disappears, yet still 'sudo
> dmsetup table' doesn't show TRIM enabled.

Check if initramfs contains /etc/crypttab file - you can list initramfs
files with lsinitrd command.

> 'sudo fstrim -v /' says: "fstrim: /: discard operation not supported."
>
> Maybe my SSD doesn't support TRIM? Is that even possible?

It is possible, but very unlikely. Also there still should be
"allow_discards" in "dmsetup table" output.

[Marc de Bruin]

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

On 30/01/15 21:44, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 30, 2015 at 09:03:05PM +0100, Marc de Bruin wrote:
>> On 29/01/15 00:04, Marek Marczykowski-Górecki wrote:
>>>> 2. I did not manage to successfully enable TRIM for my SSD.
>>>> I followed the instructions on
>>>> https://qubes-os.org/wiki/DiskTRIM very closely, but in the
>>>> end, sudo dmsetup table doesn't show it is enabled. I guess
>>>> the problem is related to this kernel message:
>>>> "systemd-cryptsetup-generator[92]: Unknown kernel switch
>>>> rd.luks.allow-discards=1. Ignoring." Any ideas about this?
>>>
>>> Try adding "rd.luks.options=discard" instead of
>>> "rd.luks.allow-discards=1" to /etc/default/grub. Let us know
>>> if that works for you, so we can update the instructions.
>>
>> With this change, the kernel message disappears, yet still 'sudo
>> dmsetup table' doesn't show TRIM enabled.
>
> Check if initramfs contains /etc/crypttab file - you can list
> initramfs files with lsinitrd command.

Already checked that, yep, /etc/crypttab is in the initramfs.

man 5 crypttab shows the option to be 'discard' and not
'allow-discards'. So I tried 'allow-discards', 'discard',
'luks,discard' and finally 'allow_discards'. None seem to work.

Shouldn't 'sudo lsblk --discard' show some indication of
discard-support on some levels? I only see '0':

DISC-ZERO
sda 0
sda1 0
[...]
sda5 0
luks-* 0
qubes_dom0-swap 0
qubes_dom0-root 0
sr0 0
loop0 1
snapshot-* 1

> It is possible, but very unlikely. Also there still should be
> "allow_discards" in "dmsetup table" output.

"allow_discards" or "allow-discards"?

Greetz,
Marc

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUy/QhAAoJEG7SigwLJqZszZAP/3a8vOYv7r27XC9swbxOBl8D
RFTzflxsAoAiBuM02wqlaFZ1P1GihenCh0LztQvUKQXj1mmDnzMkN4KUYJjJeczK
cS5voKAYXBQwQSoh9B8UmlqmYrJlYwzVBkQMgwSn1aM9+03fU6zOGdAqgoi9JOB/
eNTqAOxW/UfEQiziQpdV0H1ITNLaQel02ENZuhqBJySic4pdtzOA0o4uxa7vfcyG
TOJCEV8ZaeKHWhlweesl8lZIJwbhnQpr15oAM0z1Cun3NK32wH8s4yC5OuCcTyML
uSHiW/anI2R+PvHgYOaLQpTrU8eA4mDNfzGDu0k8sgsX4cIjMMZaoZavbroyIG+9
w8TQ/S7/TF65EIAyYEj8oqB1JvMxT9j/zUpZl+mJKtC1YzHlWIsZJQ5ivFzYys7T
0z/kWmj92pPZ9RPpij/PN9cgVH+qmoXmVWSCYR1154RgD05L1g+nG8Ed0SQ/11er
ppHwYkYS3JibuX6fhUQBjb9C/79riOnIb7tRSFZ8mT8d4bKlIJLe2Prgm/0/8aQh
kBqIdbbd4ENliC8apVgruO68ccMaBH1jb3iC65JBupHw84UdloPz3DAb2EvSMljH
GBmcU+XCvFfx3n3Wp58HeuEfNwZRAJjv0hBk4BXXCVwS6KWiobNzMojFUb5r61UZ
vHTkg+vgVYcq362fitkU
=EEif
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On Fri, Jan 30, 2015 at 10:14:09PM +0100, Marc de Bruin wrote:
> On 30/01/15 21:44, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 30, 2015 at 09:03:05PM +0100, Marc de Bruin wrote:
> >> On 29/01/15 00:04, Marek Marczykowski-Górecki wrote:
> >>>> 2. I did not manage to successfully enable TRIM for my SSD.
> >>>> I followed the instructions on
> >>>> https://qubes-os.org/wiki/DiskTRIM very closely, but in the
> >>>> end, sudo dmsetup table doesn't show it is enabled. I guess
> >>>> the problem is related to this kernel message:
> >>>> "systemd-cryptsetup-generator[92]: Unknown kernel switch
> >>>> rd.luks.allow-discards=1. Ignoring." Any ideas about this?
> >>>
> >>> Try adding "rd.luks.options=discard" instead of
> >>> "rd.luks.allow-discards=1" to /etc/default/grub. Let us know
> >>> if that works for you, so we can update the instructions.
> >>
> >> With this change, the kernel message disappears, yet still 'sudo
> >> dmsetup table' doesn't show TRIM enabled.
> >
> > Check if initramfs contains /etc/crypttab file - you can list
> > initramfs files with lsinitrd command.
>
> Already checked that, yep, /etc/crypttab is in the initramfs.
>
> man 5 crypttab shows the option to be 'discard' and not
> 'allow-discards'. So I tried 'allow-discards', 'discard',
> 'luks,discard' and finally 'allow_discards'. None seem to work.

Did you regenerated initamfs each time? I have 'allow-discards' in
crypttab and it works. I have also rd.luks.uuid=UUID-of-my-disk in
kernel command line.

> Shouldn't 'sudo lsblk --discard' show some indication of
> discard-support on some levels? I only see '0':
>
> DISC-ZERO
> sda 0
> sda1 0
> [...]
> sda5 0
> luks-* 0
> qubes_dom0-swap 0
> qubes_dom0-root 0
> sr0 0
> loop0 1
> snapshot-* 1

Mine lsblk also print only 0's, but fstrim succeeds.

>
> > It is possible, but very unlikely. Also there still should be
> > "allow_discards" in "dmsetup table" output.
>
> "allow_discards" or "allow-discards"?

In dmsetup table output it is "allow_discards".

[Marc de Bruin]

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

On 30/01/15 23:08, Marek Marczykowski-Górecki wrote:
>>>>>> 2. I did not manage to successfully enable TRIM for my
>>>>>> SSD. I followed the instructions on
>>>>>> https://qubes-os.org/wiki/DiskTRIM very closely, but in
>>>>>> the end, sudo dmsetup table doesn't show it is enabled. I
>>>>>> guess the problem is related to this kernel message:
>>>>>> "systemd-cryptsetup-generator[92]: Unknown kernel switch
>>>>>> rd.luks.allow-discards=1. Ignoring." Any ideas about
>>>>>> this?
>>>>>
>>>>> Try adding "rd.luks.options=discard" instead of
>>>>> "rd.luks.allow-discards=1" to /etc/default/grub. Let us
>>>>> know if that works for you, so we can update the
>>>>> instructions.
>>>>
>>>> With this change, the kernel message disappears, yet still
>>>> 'sudo dmsetup table' doesn't show TRIM enabled.
>>>
>>> Check if initramfs contains /etc/crypttab file - you can list
>>> initramfs files with lsinitrd command.
>>
>> Already checked that, yep, /etc/crypttab is in the initramfs.
>>
>> man 5 crypttab shows the option to be 'discard' and not
>> 'allow-discards'. So I tried 'allow-discards', 'discard',
>> 'luks,discard' and finally 'allow_discards'. None seem to work.
>
> Did you regenerated initamfs each time? I have 'allow-discards' in
> crypttab and it works. I have also rd.luks.uuid=UUID-of-my-disk in
> kernel command line.

Yes, each time I change the config, I rerun both grub2-mkconfig and
dracut as mentioned on the Wiki-page.

Regarding the kernel command line, I also have rd.luks.uuid in there,
but the UUID mentioned is the UUID for /dev/sda5, not for
/dev/mapper/qubes_dom0-root, correct? Or do you have them both on the
kernel command line?

Are you using rd.luks.allow-discards=1 or rd.luks.options=discard?

Any way to increase logging somewhere to get more insight in this matter?

> In dmsetup table output it is "allow_discards".

Tnx, I will keep that in mind.

Marc.

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUzH3LAAoJEG7SigwLJqZsGbQQAIbRNAxbmfzAcyFMU8PfbSIJ
BiiLT7bQs5TNYWSz5BEocdFJd+Jr1No0k/2Et8K0xUvQD3pfXQh6i+7XhqBjo2e/
lPWyYRERV+pG3APcN5/dCkp+qTDeMgONfuFJqkqQPMhzBgrkDiSAOM3b9lK6arPa
j2WhTO9SWvlMOSilgarE2+HMT03INohEw5UreUY2S1DjZ8geUMubgca2IqLTIWXz
Jo+VMBh3auMwwokn0dEsaItL5vd28z4LMiil0EnSu1sWWsBlqCw2wbGomonSOXpP
KmkTRjyxGZ5wOT+dIcHdU0V2PuWsWRwLE9Nhl3K1iHvhluADSB/kJoP8FeZYfwNa
94cNv/5Uiz9sTboBB3NyA/LlcgLxaWliFKgdih9eWwfwx1WkFH0y5M0KBofXC70j
zPQgMOqEcNqVlTv2QvrCQfRPwDdkGYZHZd5zAJtbof/X6uihXUSW5Mcsv0IPl3S2
N67v9Y/NGqXvz6jRS7p2AnN9qmR15UHh4h3HuAjxhiQhx7JIL7tq84E2p1UVo61j
YMFwfUGKbFAGkfnOLDf4mtEzxaICDqdKs148AoOUbpftt3CTrM6JFQ13+R60xxNw
hiHXMaCzu2QHM9s1/FXwzLbGWkzgbvGb8LXiTyuoY0YTmrN+Jcyp7I8A1gR8UAJa
R3zrErOyzr4zPc4MIs8X
=4BtR
-----END PGP SIGNATURE-----

[Marc de Bruin]

On 01/30/15 23:08, Marek Marczykowski-Górecki wrote:
> Did you regenerated initamfs each time? I have 'allow-discards' in
> crypttab and it works. I have also rd.luks.uuid=UUID-of-my-disk in
> kernel command line.

All relevant config I believe I have at this moment. These are the
files/commands mentioned at the Wiki. I tossed out all the long UUIDs,
leaving only the first part visible.

blkid:
/dev/loop0: UUID="705e6ae3-*-*-*-*" TYPE="ext4"
/dev/loop1: TYPE="DM_snapshot_cow"
/dev/loop2: UUID="f1b31824-*-*-*-*" TYPE="ext4"
/dev/loop4: UUID="e7ffe06f-*-*-*-*" SEC_TYPE="ext2" TYPE="ext3"
/dev/loop5: UUID="f1b31824-*-*-*-*" TYPE="ext4"
/dev/sda1: LABEL="System" UUID="*" TYPE="ntfs" PARTUUID="bf8940d8-01"
/dev/sda2: LABEL="OSDisk" UUID="*" TYPE="ntfs" PARTUUID="bf8940d8-02"
/dev/sda3: UUID="eda1e1bf-*-*-*-*" TYPE="ext4" PARTUUID="bf8940d8-03"
/dev/sda5: UUID="825bac45-*-*-*-*" TYPE="crypto_LUKS"
PARTUUID="bf8940d8-05"
/dev/mapper/luks-825bac45-*-*-*-*: UUID="uFTgbG-*-*-*-*-*-*"
TYPE="LVM2_member"
/dev/mapper/qubes_dom0-swap: UUID="4a9aaf4c-*-*-*-*" TYPE="swap"
/dev/mapper/qubes_dom0-root: UUID="ce2fa9a0-*-*-*-*" TYPE="ext4"
/dev/mapper/snapshot-fd02:15206142-fd02:15206272:
UUID="705e6ae3-*-*-*-*" TYPE="ext4"
/dev/loop3: PTUUID="73179486" PTTYPE="dos"
/dev/loop6: PTUUID="73179486" PTTYPE="dos"
/dev/loop7: UUID="f1b31824-*-*-*-*" TYPE="ext4"
/dev/loop8: PTUUID="73179486" PTTYPE="dos"

crypttab:
luks-825bac45-*-*-*-* UUID=825bac45-*-*-*-* none
luks-ce2fa9a0-*-*-*-* UUID=ce2fa9a0-*-*-*-* none allow-discards

grub:
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="gfxterm"
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-825bac45-*-*-*-*
rd.lvm.lv=qubes_dom0/root vconsole.font=latarcyrheb-sun16
rd.lvm.lv=qubes_dom0/swap rd.luks.options=discard $([ -x
/usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :)
rhgb quiet"
GRUB_CMDLINE_XEN_DEFAULT="console=none"
GRUB_DISABLE_RECOVERY="true"
GRUB_THEME="/boot/grub2/themes/system/theme.txt"

fstab:
#
# /etc/fstab
# Created by anaconda on Sat Jan 24 01:31:56 2015
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/qubes_dom0-root / ext4
defaults,x-systemd.device-timeout=0,discard 1 1
UUID=eda1e1bf-*-*-*-* /boot ext4 defaults 1 2
/dev/mapper/qubes_dom0-swap swap swap
defaults,x-systemd.device-timeout=0 0 0

[Marc de Bruin]

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

On 29/01/15 00:04, Marek Marczykowski-Górecki wrote:

>> I'm also having problems getting an original physical Windows
>> installation working in a HVM, as in doing a P2V. I used dd to
>> image the entire disk and performed the restore using dd within a
>> HVM, using SystemRescueCD. Booting the HVM results in the
>> notorious STOP 0x7B BSOD however. I tried some of the obvious
>> things but it didn't work. It is probably missing drivers which I
>> didn't add to the Windows installed upfront. Are there any
>> drivers I could/should have added, specifically for the virtual
>> IO stuff?
>
> Try safe mode, there you can try to install missing drivers.
>

Tried safe mode but still ran into the same BSOD.

Anything I should/could do to the physical partition before "dd",
e.g., what drivers do I need to add to have maximum compatibility with
the HVM on top of Qubes?

Is HVM on top of Qubes related to Qemu?

Greetz,

Marc.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUzLN4AAoJEG7SigwLJqZs4PgP/0kAyxcJ3GIvO5EeZG9+jDg3
t10VPENTIFED+JXjUpVdMs8scpEPDHA+6bgTX0dv83bulOpAYC3+mezKifiFJkEx
wZ/1iu5CMmyubkJuphGfjillMUI90hRlaseLdGctumjKhbEDWg5UyR2BUSDFZbFY
xOf7QdrCIes7x7feUZNF8EIlTRv2eLZnhkZppkIxBh1nBkLGUZE5HvzniusY1YOW
tHjw9SlhSubDPva5/jacvgGwE+0N90KFlkpJh/Y2WWOoJLb3pqq1TXr80otNHS8O
NG+jdDX7xb/zDy1GWJHUnYopgx6YB6BR1GvwG9tvijAoiHVBbwvSVA51R5wL07OW
t50tZn75MrcHbaL+2Ak0gH8VJSMqQANppqNnajyirkgwACESClZ6/rPAXrwZVuNT
Im4OO0CDrR6Xu/5LZBfqJrWHF1rHnga0GfMFJPgx9siHmGqn4e+qIA2pp65yXJmQ
iT2redow/bl/VuLnz72W/jp2yvzaBu6waJYnJqjjacX5ynPSPMQrT+tmLBDov18X
eaYzz5fDmidzJWRwL1UsD8wTwguAWuJ9T1fBy4gBQr3nTiBy8EZxBsz1XDvuRFl1
M/2iQdh9gjW47Vy9LDMwHPVyBYC1Lx65gWfsljtH6ypWmHmE0A83SF9m9FcT7hLY
dNaYAJyht3RNnnoSTIZ/
=qhqq
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

UUID of luks device (sda5), not root partition.

> Are you using rd.luks.allow-discards=1 or rd.luks.options=discard?

The former one.

> Any way to increase logging somewhere to get more insight in this matter?
>
> > In dmsetup table output it is "allow_discards".
>
> Tnx, I will keep that in mind.
>
> Marc.

On Sat, Jan 31, 2015 at 08:28:29AM +0100, Marc de Bruin wrote:
> On 01/30/15 23:08, Marek Marczykowski-Górecki wrote:
> >Did you regenerated initamfs each time? I have 'allow-discards' in
> >crypttab and it works. I have also rd.luks.uuid=UUID-of-my-disk in
> >kernel command line.
>

Ok, here is the problem - you should have allow-discards on the first
line. The second line does nothing as /dev/mapper/qubes_dom0-root is not
LUKS device (it is *placed on* LUKS device).

[Marc de Bruin]

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

Success! :-)

You might want to update the Wiki with this information, because the
first instruction "sudo blkid /dev/mapper/*root" returns the
luks-ce2fa9a0-*-*-*-* UUID (the wrong one) and not the
luks-825bac45-*-*-*-* UUID (the right one). And the second instruction
instructs you to reuse that UUID, at least, that is how I read it.

Maybe the first instruction in the Wiki ought to be "sudo dmsetup
table | grep crypt"? Or "sudo lsblk" and watch for the parent of
qubes_dom0-root?

Thank you very much for your patience with me! :-)

Greetz,
Marc.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUzPyOAAoJEG7SigwLJqZsAoUQALHsfj1bty8wRkmGfEbd1kzq
Vd+pNJfH3KJLktJRalI1V6SW15RTqh4HBu8DFlgg2it0TUw/mhc01rKlz4MfT2Sc
R5S2cRA7QBCaSuUatNLFW0fo92Pzm1LqwqxFHp1dcCPxfNUKFRzTXr8u5t7ytdcr
p1SNVG7GLLjwPdIu69H/l+dH9HBEvGt7UPY62BLmUUzjjIBeFgA3G5Hd2OOSCBwl
37hhe5gAcbvvM+FiJSGKIqWwfmF4CIJs1MwOxeVWcsjG+RaLc6rcWk/L72ZuQrrS
GL2W28fPq9igL56Ek5kVE43of47CqZTEuzjTQ31B/fHZBbksXhCr5NiRzqf8PuTD
L6JIrJDj2EMQhPWxOUvRB4Es3bTRYndtdQ++Vxsnp5nBb1CHKJhwAxmtZGXQMXMX
5TXUMWMOHmRrydNM8aUCwgCrrjWSHVp9HtqP6oLMVp6ZFGKTtIzgW5F5JvdbAL4y
v8dvy8ZV65tpU98T1azMXYe6zUeWvt3gqLC8maIDed4yP9xZOIAtDSu8E7+1bHt8
nb0NlWhmB8gDhDHViB/qETYNjVz1RHBIOrOEx3pJPtzo6ceJAkmx9gMSfjZx/eIL
XVOkCEslYnRPDxSbPsbXNOtJnkvXO0pTlz6/5vQTPL0T/+JlXaW0CrqDx6rCZ7ai
hWSmtOfDyBd3MJL0MdlZ
=31Ij
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

Updated.

[Marc de Bruin]

On 01/30/2015 12:02 AM, Oleg Artemiev wrote:
> Hello.
>
>> So typing in the password (no feedback at all!) and pressing enter
>> continues the startup and allows me to login. Strange behavior. Nice
>> security by obscurity though! :-)
>> Marek, the password prompt seems to be a recurring problem at boot time. Is
>> there an option, such as omitting Plymouth, that could avert this bug?
> BTW: When the team will fix this minor bug - please leave an option to
> hide the password prompt.
> Some times the host looking like hanged is okay to fool the layman check. :)
>
> Especially on mine asus n56vz the boot process is talking about some
> non-critical error right before waiting for password (cpu or acpi -
> don't remember) - okay to tell
> that machine is un-bootable - "something has broken, I donno". =)
> Thouhg this wouldn't help for a long time - AFAIR, after a very long
> timeout this will boot to emergency mode
> with a lot of errors. I'd prefer this be an option - nice to have
> possibility to wait for password forever.
>
>

Replying on this very old thread which I once started, I just wanted to
say that with R3.1 I still don't get a disk-password-prompt on this Dell
XPS 15 hardware. But entering the right password on a black screen
without any feedback indeed does work.

I might upload a new HCL report.

Greetz,
Marc.