3.2 Install: Error unpacking qubes-template-fedora-23

[m...@evanwillms.com]

I'm trying to install Qubes 3.2 on a Thinkpad T450s (i7), which is listed on the hardware compatibility list as being generally successful with both releases 3.1 and 3.2.

I have had to use the UEFI Lenovo workaround documented at https://www.qubes-os.org/doc/uefi-troubleshooting/ so my install process has been as follows:

- dd write a checksum and signature verified Qubes-R3.2-x86_64.iso to a 32GB USB drive
- Enable legacy boot in the Thinkpad BIOS
- Boot from the USB drive
- Select "Troubleshooting" > "Boot from local disk" to enter secondary GRUB menu
- Highlight the "Verify and Install" option and press 'e'
- Add '/mapbs /noexitboot' to the 'chainloader' GRUB line
- Press ctrl-x to boot with modified config
- See successful verification of the USB drive contents and launch of Qubes 3.2 installer
- Secondarily verify the install media from the "Installation Source" GUI panel
- Configure install destination to "reclaim all space" by deleting the existing partitions and use the automatic paritioning
- Begin the install

About halfway through the progress bar, the status reads:
"Installing qubes-template-fedora-23.noarch (800/930)"

Switching to tty-1 with ctrl-alt-f1 shows the error message:
"Error unpacking rpm package qubes-fedora-23-3.0.6-201608081228.noarch"

If left along for long enough, this rpm task seems to error out completely and get skipped over to finish the rest of the installation. I then add the documented UEFI workaround to /mnt/sysimage/boot/efi/EFI/qubes/xen.cfg.

After rebooting into the Qubes install, asking the Configuration helper to set up the default system qubes (sys-net, sys-firewall) fails with an alert message:

[Dom0] Error
['/usr/bin/qubes-prefs'. '--set', 'default-template', 'fedora-23'] failed:
stdout: ""
stderr: "A VM with the name 'fedora-23' does not exist in the system."

I'm confused about why such a specific package would consistently fail to install from good installation media over multiple install runs on my laptop. I've now tried with two different USB drives and ISO files from different sources.

When running the installed Qubes, manually adding the package to dom0 with:

sudo yum install /run/media/<user>/Qubes-R3.2-x86_64/Packages/q/qubes-template-fedora-23-3.0.6-201608081228.noarch.rpm

installs successfully and provides the fedora-23 vm template in the VM Manager, from which I'm able to create a new NetVM and connect to a wired network. So that's all working, once it's in place.

I would very much like to have the default sys-net and sys-firewall qubes. The way I see it, there are two semi-automated ways to get them:

1) Re-run the firstboot qubes-anaconda-addon now that the fedora-23 vm template is installed.

2) Re-install again, manually adding the qubes-template-fedora-23 package before the reboot so that it's available for the normal firstboot process.

[Implicit option 3) Figure out and manually type the sys-net and sys-firewall creation commands by picking through the qubes-anaconda-addon source.]

Any helpful hints come to mind?

Thanks,
Evan

[Fabian Wloch]

I can confirm that error under certain circumstances.
If I write the ISO (checked via Sha256+GPG) with Rufus from Windows 10, I
get the exact same error under multiple computers with totally different
hardware.
If I write it on my USB drive with dd under Fedora 24, it works without any
errors.

Used the same hardware to write the same iso onto the same usb drive, just
once with Win10 and once with Fedora.

Maybe you try it this way aswell if you didnt already found another solution.

-Fabian

[evan....@bluemesahealth.com]

On Friday, October 28, 2016 at 5:24:07 AM UTC-7, Fabian Wloch wrote:
> I can confirm that error under certain circumstances.
> If I write the ISO (checked via Sha256+GPG) with Rufus from Windows 10, I
> get the exact same error under multiple computers with totally different
> hardware.
> If I write it on my USB drive with dd under Fedora 24, it works without any
> errors.

Thanks Fabian, that pattern held true for me as well.

Writing Qubes-R3.2-x86_64.iso with Rufus from Windows 10 had the error.
Writing Qubes-R3.2-x86_64.iso with dd from macOS to if=/dev/disk2 and if=/dev/rdisk2 had the error

Writing Qubes-R3.2-x86_64.iso with dd from the fedora-23 qube resulted in install media that worked completely.

-Evan

[Marek Marczykowski-Górecki]

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

Any chance to check what is different between such created USBs? For
start, I'd run `diff -Nrb` on them. If that yields no difference, then
compare hexdumps, like this (works on bash):

diff <(hexdump -n 4246732800 -C /dev/sdb) <(hexdump -n 4246732800 -C /dev/sdc)

where /dev/sdb and /dev/sdc are two device created using different
methods. The -n parameter to hexdump is installation image size, to not
compare the whole device.

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

iQEcBAEBCAAGBQJYE7nDAAoJENuP0xzK19csSo0H/3XCgRTQlrJxkftyk3qo63FF
qPiZ19s+PouAbNPHHH3t4ulvzupsO8S6XxLyo+b97fwF9sEWEgCRViQJ5mlNu3M0
wmB7qYMHHurhXfSV2DljHGvvN871WnY7ZkliMGcvpu646zv5zT1d4a+CghHn2dcc
IMzYYKDIN4HcmWhSS5NPezhwXjw6KjCLXMwxJW3dIwSz/jOcSM9CTAwcTXlhfZDu
E4fZaUbTEPiCZPptDywnwdPlB71Ea9YKsXVj+Alq2a7g4t3AaBkujQICd0qaW9lL
IXSZFGEsLr03KbPYcQDIW8XfCUfn5hCYV4o0lXCVwIuETtN3u9IKjF04nXht52k=
=wIE1
-----END PGP SIGNATURE-----

[Fabian Wloch]

I just tried to do so, it says these files are different:
On sdX1:
images/efiboot.img
Packages/q/qubes-template-fedora-23-3.06-201608081228.noarch.rpm
On sdX2:
System Volume Information/WPSettings.dat

Didn't got any further informations, and I'm quite unexperienced with diff,
so I hope it helps.
Also, I just checked that Rufus is the newest version (Checked it because I
had the binary on my computer for a couple weeks, but its still up2date).

I'll take a closer look at them tomorrow evening.

[ma...@ibiblio.org]

> About halfway through the progress bar, the status reads:
> "Installing qubes-template-fedora-23.noarch (800/930)"
>
> Switching to tty-1 with ctrl-alt-f1 shows the error message:
> "Error unpacking rpm package qubes-fedora-23-3.0.6-201608081228.noarch"

+1, getting the same issue installing the 3.2 ISO. My system is locked up and unresponsive so debugging doesn't appear possible.

It's installing using UEFI, will try a legacy boot instead.

I did try to md5sum /dev/<usbkey> to verify the (checked) ISO on the USB I'd just written, it didn't match but I wasn't sure if it was meant to as new partitions seemed to be created by the ISO dd.

host:/var/tmp/qubes root# md5sum -c Qubes-R3.2-x86_64.iso.DIGESTS
Qubes-R3.2-x86_64.iso: OK
md5sum: WARNING: 23 lines are improperly formatted

host:/var/tmp/qubes root# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 14.9G 0 disk
└─sda1 8:1 1 14.9G 0 part

host:/var/tmp/qubes root# dd if=Qubes-R3.2-x86_64.iso of=/dev/sda
8294400+0 records in
8294400+0 records out
4246732800 bytes (4.2 GB) copied, 1095.08 s, 3.9 MB/s

host:/var/tmp/qubes root# md5sum /dev/sda
3c3669f4f633bf1adb9f9fe9142fb15d /dev/sda

host:/var/tmp/qubes root# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 14.9G 0 disk
├─sda1 8:1 1 4G 0 part
└─sda2 8:2 1 30.8M 0 part

The USB key did have the original SanDisk vendor default "tools" on it, I'll try deleting all data first as well.

[plo...@gmail.com]

I found the same problem on a fresh 3.2 install. One data point of something that looked odd to me is that the sha1/sha256 sums are different between the RPM that's distributed as part of the installer and the supposedly same RPM available via the repo online...

The Qubes 3.2 installer iso has:

.../Qubes-R3.2-x86_64/Packages/q
$ sha256sum qubes-template-fedora-23-3.0.6-201608081228.noarch.rpm
c070ecb75b2580aec594d67afc833579c52ccb20e4acf5bc1797bbc93cefde26 qubes-template-fedora-23-3.0.6-201608081228.noarch.rpm
$ sha1sum qubes-template-fedora-23-3.0.6-201608081228.noarch.rpm
cef6ddb660d0c9cb3fbee54230899ddeb2df64a6 qubes-template-fedora-23-3.0.6-201608081228.noarch.rpm

Trying to install this fails.

But the package I downloaded (from https://yum.qubes-os.org/r3.2/templates-itl/rpm/) has:

$ sha256sum qubes-template-fedora-23-3.0.6-201608081228.noarch.rpm
0b751ae1c94747f026b33767437b25f5bf0d09857430bd7c080992b61a9ca244 qubes-template-fedora-23-3.0.6-201608081228.noarch.rpm
$ sha1sum qubes-template-fedora-23-3.0.6-201608081228.noarch.rpm
5e1186e6fcd08e5b99432418655d49fa7fadf796 qubes-template-fedora-23-3.0.6-201608081228.noarch.rpm

I haven't yet tried to install this one so I'm not sure that explains anything yet, but it may be indicative of some problem.

[ma...@ibiblio.org]

My freezes for me are pretty random on dozens of different places during the Legacy and UEFI installs, something more than one RPM is broken. I'm blaming my Gigabyte Z97X Gaming mobo, F7 BIOS. I've ordered an ASRock Z97 Extreme6 mobo as that is known to work. I think it's the Gigabyte BIOS that isn't so hot.

[ma...@ibiblio.org]

On Thursday, December 29, 2016 at 3:04:53 PM UTC+11, ma...@ibiblio.org wrote:
> My freezes for me are pretty random on dozens of different places during the Legacy and UEFI installs, something more than one RPM is broken. I'm blaming my Gigabyte Z97X Gaming mobo, F7 BIOS. I've ordered an ASRock Z97 Extreme6 mobo as that is known to work. I think it's the Gigabyte BIOS that isn't so hot.

Update: I tried installing Qubes 3.2 on my newly installed ASRock Extreme6 this morning, using a physical DVD ISO. It froze again during the Anaconda process, similar to what occurred on the Gigabyte board. The ISO passed md5sum checking so it's very odd. I'll check BIOS revs and try again.