Installation issue (bootloader install failed)

[Dylan M.]

I am attempting to install Qubes R2 from DVD installer disc, specifying USB flash drive as the destination. I have tried with several different flash drives and SD Cards, all larger than 32GB, and each time the result is the same.

The installer starts fine, allows me to pick the USB drive as destination, and proceeds through installation steps. At around step 763 of 929, installer aborts and reports an unknown error. Specific debug message everytime is:

/../../../bootloader.py line 1552 raised BootloaderError ("bootloader install failed")

Trying with multiple different destination media produces the same outcome, so a faulty device isn't likely the cause.

Any advice on how to proceed would be greatly appreciated. I am using a Samsung laptop as host machine, which raises no other problems during install prior to this bootloader install error.

Thanks very much!

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 25, 2015 at 10:59:04PM -0400, Dylan M. wrote:
> I am attempting to install Qubes R2 from DVD installer disc, specifying USB flash drive as the destination. I have tried with several different flash drives and SD Cards, all larger than 32GB, and each time the result is the same.
>
> The installer starts fine, allows me to pick the USB drive as destination, and proceeds through installation steps. At around step 763 of 929, installer aborts and reports an unknown error. Specific debug message everytime is:
>
> /../../../bootloader.py line 1552 raised BootloaderError ("bootloader install failed")

This means that grub2-install failed. If you switch to tty5
(Alt-ctrl-F5), you should see some details. Also some useful messages
can be available on other consoles:
tty1: installer runs from here, there is tmux, you can switch to other
"windows" with Ctrl-b n
tty2: shell
tty3: anaconda log
tty4: storage configuration log
tty5: anaconda subprograms log

You can also try to manually install grub and see what happens. Switch
to tty2 and execute sth like this:
chroot /mnt/sysimage grub2-install /dev/sdX
Where /dev/sdX should be your installation target (check blkid output
for available devices).

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

iQEcBAEBAgAGBQJVPWJcAAoJENuP0xzK19csXNMH/3Y405ueecgAjbN13Kr853wU
OeGvVR7n/elAw1FbY1TPDHQ8pwV0APMBfgBh3A1TH7so9n7poFVteCEeAVOCOBWS
XMhFTbKvwezU0JSSgetv0G7f1IKSzkHe85+f8EKF1EGoGrk+Hs+sNf7FapamT9nd
+mqZqKaGXMaDfUyBJ3vnY5w3d5ituDHTfLdFOjfJC/tioLHtMLO/niBkpsxkgYAb
DYRCc8B5xxOVUai910gdt5PtH414J7cXvJ+NgbsNHJuX5l72XJH2vQk98AkgIfcI
kACzKZqzGXubb8fHiTbQBJjGzIcsfzycfVvS+Glkb6nBOKvJSFpSXOU2359Wzuc=
=5uZo
-----END PGP SIGNATURE-----

[Dylan Maccarone]

On Sun, Apr 26, 2015 at 6:10 PM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:

This means that grub2-install failed. If you switch to tty5
(Alt-ctrl-F5), you should see some details. Also some useful messages
can be available on other consoles:
tty1: installer runs from here, there is tmux, you can switch to other
"windows" with Ctrl-b n
tty2: shell
tty3: anaconda log
tty4: storage configuration log
tty5: anaconda subprograms log

You can also try to manually install grub and see what happens. Switch
to tty2 and execute sth like this:
chroot /mnt/sysimage grub2-install /dev/sdX
Where /dev/sdX should be your installation target (check blkid output
for available devices).

Thanks for the advice. I happened to try burning the ISO onto a different fresh DVD, and this time got an error at a completely different part of the install, whereupon I surmised that I had a bad batch of DVDs, and decided to burn to a small flash drive first, and install from there to the original larger destination flash drive. This time it worked without a hitch.

However, I am now encountering the issue described here:

https://groups.google.com/forum/#!topic/qubes-users/X5Iomlu_oo4

...where during the initial configuration (Welcome to Qubes R2 screen) it completely freezes and locks up at the part where it states "Starting Qubes Networking", after I've left the default "create all app and service VMs" checked and said Continue.

From there the only solution is to power the computer off and restart. Unfortunately it seems that once this glitch has occurred, the configuration is permanently corrupted and cannot even be started again in order to choose different options. Any subsequent boots following this freeze-glitch, cause the config screen to lock up immediately upon initial loading of the "Welcome" screen, without allowing the user to even move the mouse long enough to select anything before freezing.

I am going to try the solutions mentioned in the other thread, specifically disabling my networking card from BIOS, and also disabling "vt-d" if my slightly older CPU even has such an option to be toggled.

Are there any other suggestions likely to help in resolving this initial config issue? Thanks..

[Jason M]

On Monday, 27 April 2015 12:50:13 UTC-4, Dylan Maccarone wrote:

On Sun, Apr 26, 2015 at 6:10 PM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:

This means that grub2-install failed. If you switch to tty5
(Alt-ctrl-F5), you should see some details. Also some useful messages
can be available on other consoles:
tty1: installer runs from here, there is tmux, you can switch to other
"windows" with Ctrl-b n
tty2: shell
tty3: anaconda log
tty4: storage configuration log
tty5: anaconda subprograms log

You can also try to manually install grub and see what happens. Switch
to tty2 and execute sth like this:
chroot /mnt/sysimage grub2-install /dev/sdX
Where /dev/sdX should be your installation target (check blkid output
for available devices).

Thanks for the advice. I happened to try burning the ISO onto a different fresh DVD, and this time got an error at a completely different part of the install, whereupon I surmised that I had a bad batch of DVDs, and decided to burn to a small flash drive first, and install from there to the original larger destination flash drive. This time it worked without a hitch.

However, I am now encountering the issue described here:

https://groups.google.com/forum/#!topic/qubes-users/X5Iomlu_oo4

...where during the initial configuration (Welcome to Qubes R2 screen) it completely freezes and locks up at the part where it states "Starting Qubes Networking", after I've left the default "create all app and service VMs" checked and said Continue.

From there the only solution is to power the computer off and restart. Unfortunately it seems that once this glitch has occurred, the configuration is permanently corrupted and cannot even be started again in order to choose different options. Any subsequent boots following this freeze-glitch, cause the config screen to lock up immediately upon initial loading of the "Welcome" screen, without allowing the user to even move the mouse long enough to select anything before freezing.

Could this be related to swiotlb?  I patch core-admin with a hard coded value of 8192 over 4096 to prevent such issues, or I install Qubes with no virtual machines or netvm initially and add them manually, then change the kernelopts in dom0:

qvm-prefs sys-net -s kernelopts "nopat iommu=soft swiotlb=8192"

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This problem should not hard hang the machine, at wost network adapted
would be unavailable.

> > I am going to try the solutions mentioned in the other thread,
> > specifically disabling my networking card from BIOS, and also disabling
> > "vt-d" if my slightly older CPU even has such an option to be toggled.
> >
> > Are there any other suggestions likely to help in resolving this initial
> > config issue? Thanks..

I guess buggy BIOS support for VT-d, unfortunately this is quite
common...

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

iQEcBAEBAgAGBQJVPsFcAAoJENuP0xzK19csdZoH/jeia9U7NMVFhEzV5Q1N3iv7
yLO9kDLuVjKyubiG9OHF+6HQoHSAVC4MVVQ/+hMHNrkiJyRPK+cb1NGF4yX8NH3W
d2eOluwjh2KnAmdKvCAkeTNrYISQGVcrvr8MmHw9E4/8+LhW4cLZzmrfULGgzCZb
q7h1uQKjN7m2Z3yFNEUsJ7TfVxSdwSkYG7qoCxEf3Vse3nOxZKRFnMfdgF1TzsC9
y36yDEWv1E3pM/vWIVO7BvM1H4bU5seKgmUiz4ViH5Y4N4oNot7efDxmfcuEFKjw
KO68DouMARe2tEYeXexeSYKs9neqtPDfUspx/KLYWXmbD2QlDTdu89RLroorC20=
=wfE9
-----END PGP SIGNATURE-----

[Dylan M.]

I ended up having an earlier opportunity to install and configure Qubes R2 on a different, newer computer using the same flash drive, and everything worked fine. The initial config screen completed as designed and all the default VMs were created, including netVM which started successfully and connected to a local wifi network.

I then took the flash drive with this installation and booted it on my original problematic computer, and it was able to boot correctly into dom0 with all VMs appearing in the list as expected. However when I tried to start netVM it reported failure due to inability to locate the pci network card from the original install machine.

Using VM Manager under Devices for netVM, I attempted to add my local network card from that problematic machine, and instantly upon doing so and clicking OK, the system crashed and forced a shutdown of the computer in order to recover. From that point, Qubes would not boot any longer, and crashed producing a black screen each time immediately after the LUKS password screen.

I went into my computer's BIOS and disabled the ethernet and wireless adapters in settings and tried to boot again, but even with those devices disabled Qubes would still not boot past the password screen. Simply having the network card added in the configuration for netVM was enough to prevent proper startup, even with the device disabled through CMOS.

I was still able to boot Qubes on the original install machine, and although it initially complained that netVM could not be started due to the absence of the problematic network card, I was able to overcome this by removing all devices (<<) under VM Manager, and then manually re-adding the currently present network adapters to netVM, which then started correctly and restored network connectivity.

So, it seems that Qubes does not like my network card in the other machine, to the severe extent of reaching for its hat and coat the moment any attempt is made to introduce that card into the operating environment. I don't know whether a BIOS update of some sort might solve this, or whether it is a fundamental incompatibility that cannot be reconciled.

I will likely continue experimenting to discover the best option.

[Jason M]

On Wednesday, 29 April 2015 10:24:56 UTC-4, Dylan M. wrote:

I ended up having an earlier opportunity to install and configure Qubes R2 on a different, newer computer using the same flash drive, and everything worked fine. The initial config screen completed as designed and all the default VMs were created, including netVM which started successfully and connected to a local wifi network.

I then took the flash drive with this installation and booted it on my original problematic computer, and it was able to boot correctly into dom0 with all VMs appearing in the list as expected. However when I tried to start netVM it reported failure due to inability to locate the pci network card from the original install machine.

Using VM Manager under Devices for netVM, I attempted to add my local network card from that problematic machine, and instantly upon doing so and clicking OK, the system crashed and forced a shutdown of the computer in order to recover. From that point, Qubes would not boot any longer, and crashed producing a black screen each time immediately after the LUKS password screen.

After or before entering your password you can <ALT>+<TAB> to 'console' mode (you can enter your password there as well).  So, if you enter you password and switch to console mode does it time out 5 minutes later giving you an emergency prompt?

If so, are you using BTRFS file system.  Again, if so, you are experiencing 2 issues.  The BTRFS filesystem has a bug in most recent kernels that prevent mounting after a crash. I discuss how to fix that issue here: https://groups.google.com/forum/#!topic/qubes-users/RuBU4S_f00s.

Now again not knowing your setup, but if you fix your boot, try the `kernelopts` I listed in post a few above.  If I don't run with a patched version of qubes, I have to install qubes with no netvm or it will lock up my computer as well during the network installation stage... complete freeze, no access to switch tty, etc.

So if you in the mood to experiment, give these a shot and good luck!

[ceno...@gmail.com]

On Wednesday, April 29, 2015 at 10:45:34 AM UTC-4, Jason M wrote:

Now again not knowing your setup, but if you fix your boot, try the `kernelopts` I listed in post a few above.  If I don't run with a patched version of qubes, I have to install qubes with no netvm or it will lock up my computer as well during the network installation stage... complete freeze, no access to switch tty, etc.

qvm-prefs sys-net -s kernelopts "nopat iommu=soft swiotlb=8192"

Here is what I attempted: On the machine where Qubes runs correctly with full network support, I activated a dom0 Konsole and entered the command as typed above. dom0 responded by saying there was no VM registered to the sytem named "sys-net", so I inferred that it was a placeholder for whatever the name is of the current default netVM, specifically "netVM" on the default auto-configured version of Qubes R2. Entering the command above with the name of the netVM changed (but still from dom0) seemed to work and produced no error message.

I then booted Qubes on the problematic machine, and it ran correctly since I had already previously removed the troublesome network card from netVM using the other machine. Within VM Manager I now re-added the ethernet and wireless adapters and clicked OK to save the configuration. Upon starting the netVM however, the system once again hard froze and required a forced power-down to resolve.

I tried rebooting Qubes again and viewing the startup from the terminal option using Alt-Tab. The boot proceeded correctly, and I could enter my disk/LUKS password. However at the GUI user-login prompt to the main Qubes desktop, the system hard froze and would not accept any input.

If I am doing anything incorrectly or in the wrong order, let me know and I'll re-attempt. Otherwise it seems the problem is unrelated to swiotlb, and Qubes simply does not like my network card. Ironically I could theoretically bypass this whole issue by leaving the network card disabled and using a USB 3G modem/phone to connect, but as I understand it Qubes does not suppport such devices for various security/technical reasons.

[Jason M]

On Thursday, 30 April 2015 20:49:26 UTC-4, ceno...@gmail.com wrote:

On Wednesday, April 29, 2015 at 10:45:34 AM UTC-4, Jason M wrote:

Now again not knowing your setup, but if you fix your boot, try the `kernelopts` I listed in post a few above.  If I don't run with a patched version of qubes, I have to install qubes with no netvm or it will lock up my computer as well during the network installation stage... complete freeze, no access to switch tty, etc.

qvm-prefs sys-net -s kernelopts "nopat iommu=soft swiotlb=8192"

Here is what I attempted: On the machine where Qubes runs correctly with full network support, I activated a dom0 Konsole and entered the command as typed above. dom0 responded by saying there was no VM registered to the sytem named "sys-net", so I inferred that it was a placeholder for whatever the name is of the current default netVM, specifically "netVM" on the default auto-configured version of Qubes R2. Entering the command above with the name of the netVM changed (but still from dom0) seemed to work and produced no error message.

Yes, netvm is correct on Qubes Release 2.  Release 3 uses sys-net.
 

I then booted Qubes on the problematic machine, and it ran correctly since I had already previously removed the troublesome network card from netVM using the other machine. Within VM Manager I now re-added the ethernet and wireless adapters and clicked OK to save the configuration. Upon starting the netVM however, the system once again hard froze and required a forced power-down to resolve.

Before starting the netvm on the problematic machine, did you confirm the kernel-opts I supplied took?

qvm-prefs netvm

Should display info about the netvm including the 'kernelopts' line which would have the following:

nopat iommu=soft swiotlb=8192

Sometimes booting with a different kernel will work as well (if you have additional kernels installed), you can use arrow keys right away to stop auto start of Xex, then select the entry that allows you to use custom options in XEN boot screen, then press enter and enter again to select kernel to boot with (Sorry about the vague description, I am providing it from memory as I do not usually need to boot with another kernel)

Wondering what network card you have as well.  Mine is listed below and requres the kernelopt as indicated...
lspci
...
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)
04:00.0 Network controller: Intel Corporation Wireless 3160 (rev 83)
...

I tried rebooting Qubes again and viewing the startup from the terminal option using Alt-Tab. The boot proceeded correctly, and I could enter my disk/LUKS password. However at the GUI user-login prompt to the main Qubes desktop, the system hard froze and would not accept any input.

If I am doing anything incorrectly or in the wrong order, let me know and I'll re-attempt. Otherwise it seems the problem is unrelated to swiotlb, and Qubes simply does not like my network card. Ironically I could theoretically bypass this whole issue by leaving the network card disabled and using a USB 3G modem/phone to connect, but as I understand it Qubes does not suppport such devices for various security/technical reasons.

I agree that the problem may be unrelated to 'swiotlb', but those are the exact same symptoms I have had.  If this is the issue, it is important that you check the kerelopts are set before starting the netvm and after adding your network interfaces, so they should be set in dom0 on the problem machine.

So, on problem computer, in Konsole in dom0:
Assumes you do not have netvm appvm setup and your default template is named fedora-20-x64

# Skip is already netvm already created
qvm-create --label=red --net --template=fefora-20-x64 netvm

# List pci devices attached to netvm
qvm-pci -l netvm

# Add network device if needed (lspci to find device ID; look at my example above)
qvm-pci -a netvm '02:00.0'

# Check then set kernel opts
qvm-prefs netvm
qvm-prefs netvm -s kernelopts "nopat iommu=soft swiotlb=8192"

# Confirm kernelopts set (look for kernelopts line)
qvm-prefs netvm

qvm-start netvm





 

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 30, 2015 at 05:49:26PM -0700, ceno...@gmail.com wrote:
>
>
> On Wednesday, April 29, 2015 at 10:45:34 AM UTC-4, Jason M wrote:
> >
> >
> > Now again not knowing your setup, but if you fix your boot, try the
> > `kernelopts` I listed in post a few above. If I don't run with a patched
> > version of qubes, I have to install qubes with no netvm or it will lock up
> > my computer as well during the network installation stage... complete
> > freeze, no access to switch tty, etc.
> >
> > qvm-prefs sys-net -s kernelopts "nopat iommu=soft swiotlb=8192"
> >
> >
> >
> Here is what I attempted: On the machine where Qubes runs correctly with
> full network support, I activated a dom0 Konsole and entered the command as
> typed above. dom0 responded by saying there was no VM registered to the
> sytem named "sys-net", so I inferred that it was a placeholder for whatever
> the name is of the current default netVM, specifically "netVM" on the
> default auto-configured version of Qubes R2. Entering the command above
> with the name of the netVM changed (but still from dom0) seemed to work and
> produced no error message.
>
> I then booted Qubes on the problematic machine, and it ran correctly since
> I had already previously removed the troublesome network card from netVM
> using the other machine. Within VM Manager I now re-added the ethernet and
> wireless adapters and clicked OK to save the configuration. Upon starting
> the netVM however, the system once again hard froze and required a forced
> power-down to resolve.

This can be a bug in BIOS in regard to support vitalization, especially
VT-d. Did you tried to enable this network card, while keeping VT-d
disabled?

> I tried rebooting Qubes again and viewing the startup from the terminal
> option using Alt-Tab. The boot proceeded correctly, and I could enter my
> disk/LUKS password. However at the GUI user-login prompt to the main Qubes
> desktop, the system hard froze and would not accept any input.
>
> If I am doing anything incorrectly or in the wrong order, let me know and
> I'll re-attempt. Otherwise it seems the problem is unrelated to swiotlb,
> and Qubes simply does not like my network card. Ironically I could
> theoretically bypass this whole issue by leaving the network card disabled
> and using a USB 3G modem/phone to connect, but as I understand it Qubes
> does not suppport such devices for various security/technical reasons.

Actually you can use USB 3G modem, unless you're using USB keyboard
connected to the same USB controller (which I guess is not the case).
You just need to assign the right USB controller to the netvm. Take a
look here:
https://www.qubes-os.org/doc/AssigningDevices/

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

iQEcBAEBAgAGBQJVQ1HmAAoJENuP0xzK19csB1gIAIqGyzHYnnrJ3ZqU9nIZCbjZ
FdH8QColWJ13KTm8GOg3v6XKfTXQDk/gCF7m+2NZOg5Tn7ceXzPGikr4tvpj3qhQ
12OE04taYuJ3bT29qKLFxdrW3eqLtltYqkU4hY+ASObg40JssAC1XJunhOyu79SF
VWPW6r+W/HR5V6QqAsg5k59E3MuEyekiBuxyXnFdJqrzGNOh7ir/s6u8u6wiC9uO
dxRAg/JoxVxvUOtGmMfTNYJqhjzC7mLNJjNa/sfy7Uy6st5ppIZ3FBy7k9rSlGeD
2Ilc1X/TPdacwNS6cV5u8WaIOBbDY1CWpky1aacN+V3pwNxaQP5urSiffEo2bSY=
=Ux2U
-----END PGP SIGNATURE-----

[ceno...@gmail.com]

Thanks Marek and Jason for your ongoing support and assistance, it's greatly appreciated.

Of the three suggestions I currently have to work with (try kernelopts fix, disable VT-d, enable usb modem by adding controller to netvm) I decided to try the last one first, since the fully working non-problematic laptop I've been testing on is temporarily unavailable for the next few days, and I won't have an easy convenient recovery option if something gets messed up and the netvm freezes. Once I have it back I will resume experimenting with the swiotlb setting instructions provided above.

In the meantime, assigning the USB controller with the 3G modem attached to netvm does seem to have worked successfully and achieved network connectivity (I'm posting this from Qubes). I was a little concerned about trying it since although my USB keyboard/mouse are plugged into a port on a different controller, the bus where the modem is connected also seemed to be hosting a couple of other devices alongside it:

Linux Foundation 2.0 root hub
Intel Corp. Integrated Rate Matching Hub

I wasn't sure if assigning these to netvm would cause undesirable consequences, but so far I haven't noticed any. If there's a known issue I should look out for as a result of this multi-device assignment to netvm, I'd wouldn't mind knowing about it.

I also took a look in my BIOS settings for one controlling VT-d, but didn't see any likely contenders. My mainboard is from several years ago and may not have any such toggle available. But I will try the kernelopts/swiotlb fix and re-enabling the standard network adapters once I can do so safely, and report results back once I've had the chance.

Thanks again...