sys-firewall domain start failed

[para-vak]

Initial install with default template settings:

Upon concluding final configuration after 1st reboot, just after all VMs have been created for the first time, right before first booting into the system:

['/usr/bin/qvm-start: 'sys-firewall'] failed: stdout:""
stderr:"start failed: internal error: libxenlight failed to 
create new domain 'sys-firewall', see /var/log/libvert/libxl/libxl-driver.log

ISO file integrity has been verified. Media tests during a multiple re-install attempts with different media have passed, and yet the error is reproduced.

Following suggestion in error message, reveals log is nonexistent.

[awokd]

That is odd, ordinarily it would be sys-net or sys-usb with issues like
that. I think you might have to be su to see that log file. If you qvm-ls,
what is running? If sys-net fails to start, that might cause sys-firewall
to also fail. Also, do a qubes-hcl-report and check the last 5 lines about
HVM, IOMMU, etc.

[para-vak]

Indeed, yet I rarely input anything without 'sudo' behind it... anyway... Disregard! A fresh install has not reproduced the error! It seems that ensuring proper formatting of the disk is paramount! GParted + a manual partitioning in Qubes setup to be sure.

[niepo...@gmail.com]

you must run firewallVM in pv mode. then most possibe will start.

[apue...@gmail.com]

Hi please help! Same exact issue here, no matter what I do. Everything is halted except dom0. Nothing starts without being in PV mode, which doesn't seem to be due to hardware incompatibility.

Last 5 lines of qubes-hcl-report=

HVM: Active
I/0 MMU: Active
HAP/SLAT: YES
TPM: Device not found
Remapping: Yes

Just before the final "Setting up network" message of the configuration, the firewall isn't allowed to be created. /var/log/libvert/libxl/libxl-driver.log reveals:

2016-07-25 23:51:37.947+0000: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/1/console/tty': Resource temporarily unavailable
2016-07-25 23:54:01.037+0000: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/2/console/tty': Resource temporarily unavailable
2016-07-25 23:56:10.997+0000: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/3/console/tty': Resource temporarily unavailable
2016-07-25 23:58:15.459+0000: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/4/console/tty': Resource temporarily unavailable
2016-07-26 00:01:02.935+0000: libxl: libxl_device.c:1081:device_backend_callback: unable to add device with path /local/domain/5/backend/vif/7/0
2016-07-26 00:01:02.935+0000: libxl: libxl_create.c:1512:domcreate_attach_devices: unable to add nic devices
2016-07-26 00:01:02.953+0000: libxl: libxl_device.c:965:libxl__initiate_device_generic_remove: backend /local/domain/5/backend/vif/7/0 already removed, cleanup frontend only
2016-07-26 00:01:03.025+0000: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop0: No such device or address
2016-07-25 23:50:31.812+0000: libxl: libxl_device.c:1081:device_backend_callback: unable to add device with path /local/domain/1/backend/vif/3/0
2016-07-25 23:50:31.812+0000: libxl: libxl_create.c:1512:domcreate_attach_devices: unable to add nic devices
2016-07-25 23:50:31.834+0000: libxl: libxl_device.c:965:libxl__initiate_device_generic_remove: backend /local/domain/1/backend/vif/3/0 already removed, cleanup frontend only
2016-07-25 23:50:31.901+0000: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop0: No such device or address
2016-07-25 23:50:47.897+0000: libxl: libxl_device.c:1081:device_backend_callback: unable to add device with path /local/domain/4/backend/vif/6/0
2016-07-25 23:50:47.897+0000: libxl: libxl_create.c:1512:domcreate_attach_devices: unable to add nic devices
2016-07-25 23:50:47.914+0000: libxl: libxl_device.c:965:libxl__initiate_device_generic_remove: backend /local/domain/4/backend/vif/6/0 already removed, cleanup frontend only
2016-07-25 23:50:47.985+0000: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop0: No such device or address
2016-07-25 23:52:23.457+0000: libxl: libxl_device.c:1081:device_backend_callback: unable to add device with path /local/domain/7/backend/vif/9/0
2016-07-25 23:52:23.457+0000: libxl: libxl_create.c:1512:domcreate_attach_devices: unable to add nic devices
2016-07-25 23:52:23.473+0000: libxl: libxl_device.c:965:libxl__initiate_device_generic_remove: backend /local/domain/7/backend/vif/9/0 already removed, cleanup frontend only
2016-07-25 23:52:23.544+0000: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop0: No such device or address
2016-07-26 00:00:12.610+0000: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop0: No such device or address
2016-07-26 00:14:48.002+0000: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop0: No such device or address
2016-07-26 00:16:23.732+0000: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/16/console/tty': Resource temporarily unavailable
2016-07-26 00:17:30.891+0000: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/17/console/tty': Resource temporarily unavailable

[apue...@gmail.com]

On Monday, May 14, 2018 at 1:08:03 PM UTC-4, niepo...@gmail.com wrote:

> you must run firewallVM in pv mode. then most possibe will start.

Nothing starts without PV mode, but it shouldn't have to be this way.

[awokd]

On Sun, May 20, 2018 2:54 am, apue...@gmail.com wrote:

> 2016-07-26 00:01:02.935+0000: libxl:
> libxl_device.c:1081:device_backend_callback: unable to add device with
> path /local/domain/5/backend/vif/7/0
> 2016-07-26 00:01:02.935+0000: libxl:
> libxl_create.c:1512:domcreate_attach_devices: unable to add nic devices

I think the above is saying it can't start sys-firewall because sys-net is
down (and your date also seems pretty far off). Is sys-net running? If
not, note what devices are attached to sys-net, remove them, then see if
it starts. If it does, shut it back down, add your NIC back in, and again
see if it starts. If not, troubleshoot by trying the Debian template
instead of Fedora as well as the attach options described here
https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues.

[apue...@gmail.com]

Thanks for replying! Makes sense. But sys-net still won't start unless in PV mode, like all other VMs. NICs attached or detached is irrelevant. I've even tried not allowing the installer to create them, as in making sys-VMs from scratch with the same result.

Debian/Fedora templates make no difference.
Attach options make no difference. Sys-net attempts to start, pop-up notification states it has started, but never goes pass the yellow state. Refresh qube list reveals it goes back into off state.

Nothing starts without PV mode. :(

[apue...@gmail.com]

It seems that firewall being unable to start during the installation's final configuration makes Qubes believe there is some kind of incompatibility?

[apue...@gmail.com]

What are the default partitions created because I'm seeing a discrepancy now. At times I see /boot/efi - 200MB. At others, it is only /boot at 1024MB... ? Could this be the problem?

[awokd]

If you're booting in UEFI mode, you should always see /boot/efi. Is it
possible some other bootloader is running before Qubes'?. I've heard of
viruses that act that way too, but maybe it's just a bug in your UEFI.
Assuming there is nothing else on your hard drive you need to keep, try to
reinstall Qubes, select "I want to make space available", tell it to erase
everything, and let it auto partition.

[apue...@gmail.com]

It works! My BIOS automatically chooses UEFI for the thumb drive chosen to install. However, it has an option to directly boot any detected device. I chose the thumb drive with the direct boot option, without UEFI in its prefix.

This results in Automatic Partitioning creating a /boot partition for the bootloader, whereas when choosing to boot the thumb drive with UEFI prefixed, the installer creates /boot/efi.

The direct boot allows the installer to finish cleanly. The UEFI boot results in a failure to create sys-firewall domain for some reason.

[awokd]

On Sun, May 20, 2018 4:54 pm, apue...@gmail.com wrote:

>
> It works! My BIOS automatically chooses UEFI for the thumb drive chosen to
> install. However, it has an option to directly boot any detected device. I
> chose the thumb drive with the direct boot option, without UEFI in its
> prefix.
>
> This results in Automatic Partitioning creating a /boot partition for the
> bootloader, whereas when choosing to boot the thumb drive with UEFI
> prefixed, the installer creates /boot/efi.
>
> The direct boot allows the installer to finish cleanly. The UEFI boot
> results in a failure to create sys-firewall domain for some reason.

No more PV mode? Great! Nice catch on the /boot/efi appearing and
disappearing.

[Hugo Costa]

I have encountered this problem as well. Also had the error on the config post-install. My bios is Legacy-mode only, it worked perfectly on Q3.2. I'm inclined to just reinstall and hope for the best, as I cannot start neither sys-net nor sys-firewall.