End of week

Friday, March 24, 2017

Another week where I have a feeling I did a lot of side stuff that slowed me down on my primary objectives.

Bug filing

  • Filed Red Hat Bugzilla 1435567 regarding the btrfsck core dump.
  • Filed rhnz1435580 regarding another issue where I'm locked out of my

    Gnome sessions. Happens semi-regularly on Big.

Added these to the Bugs page.

Bridging

I'm still not done seting up bridging for user sessions. It's important for my Win10 session, which I'd like to keep in a user session to be able to use 3D acceleration, but to be able to access remotely using not just Spice, but also its native protocol (Microsoft Remote Desktop, RDP).

Yesterday, I followed the instructions on bridging, with a minor adjustment (had to dnf install iptables-services, and replace eth0 with the actual name on my system, which is enp4s0). But the br0 bridge still does not show up. Not sure why not.

If I try to manually ifup br0, I get:

[root@muse ddd]# ifup br0
Determining IP information for br0... failed.

So it looks like it's not getting the DHCP response from my server.

Great, now I lost network access to Muse. Fiddling locally to get it back up.

First, I get SELinux warnings when trying to do service network restart:

The source process: systemd attempted to access: create on this unix_stream_socket: 

You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 'systemd' --raw | audit2allow -M my-systemd # semodule -X 300 -i my-systemd.pp

And Another one:

The source process: dhclient-script Attempted to access: write On this directory: NetworkManager


You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 'dhclient-script' --raw | audit2allow -M my-dhclientscript # semodule -X 300 -i my-dhclientscript.pp

If I bring the br0 interface manually with ifup br0, I still get the failed message, but something shows up in ifconfig -a:

br0: flags=4163  mtu 1500
        inet6 fe80::3c6d:a5ff:fe8c:4252  prefixlen 64  scopeid 0x20
        ether 3e:6d:a5:8c:42:52  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 86  bytes 17290 (16.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp4s0: flags=4163 mtu 9000 inet 192.168.77.45 netmask 255.255.255.0 broadcast 192.168.77.255 inet6 fe80::83b4:5047:b30:24a0 prefixlen 64 scopeid 0x20 inet6 fd00::1:a3cf:9509:4f5b:1bc4 prefixlen 64 scopeid 0x0 ether 50:e5:49:53:03:87 txqueuelen 1000 (Ethernet) RX packets 1519007 bytes 2082144658 (1.9 GiB) RX errors 0 dropped 17 overruns 0 frame 0 TX packets 400419 bytes 76062012 (72.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1 (Local Loopback) RX packets 621843 bytes 72912030 (69.5 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 621843 bytes 72912030 (69.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

macvtap0: flags=4163 mtu 1500 inet6 fe80::5054:ff:feaf:9fbb prefixlen 64 scopeid 0x20 ether 52:54:00:af:9f:bb txqueuelen 500 (Ethernet) RX packets 530057 bytes 2013261526 (1.8 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 395956 bytes 75515985 (72.0 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr0: flags=4099 mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether 52:54:00:ff:43:f0 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr0-nic: flags=4098 mtu 1500 ether 52:54:00:ff:43:f0 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

However, if I try to start my Windows 10 guest after connecting to br0, I have yet another failure, this time on access control lists???

Error starting domain: internal error: /usr/libexec/qemu-bridge-helper --br=br0 --fd=24: failed to communicate with bridge helper: Transport endpoint is not connected

stderr=access denied by acl file

Mar 24 11:35:09 muse.dinechin.org systemd-sysctl[3470]: Couldn't write '0' to 'net/bridge/bridge-nf-call-arptables', ignoring: No such file Mar 24 11:35:09 muse.dinechin.org systemd-sysctl[3470]: Couldn't write '0' to 'net/bridge/bridge-nf-call-iptables', ignoring: No such file Mar 24 11:35:09 muse.dinechin.org systemd-sysctl[3470]: Couldn't write '0' to 'net/bridge/bridge-nf-call-ip6tables', ignoring: No such file

So clearly, the documentation is very incomplete for a Fedora 25 system with SELinux active.

Now, I can ssh into Muse, not VNC into it. Tried to restart the Vino server, no luck. Tried to log out and back in, still no luck. How annoying. I checked that I can run remote-viewer vnc://localhost:5900, and it works. But if I do that from Big as remote-viewer vnc://muse:5900, then remote-viewer tells me it can't access the file.

The Firewall application is not installed. Tried to look at iptables -L, that looked OK. Tried to restart iptables service, got an error, and then iptables -L shows nothing.

Save my VMs to disk, restart. Now it works. I hate it when I have to reboot a Linux machine like a poor Windows 95, just because systemctl can't figure out how to restart things nicely.

Someone on IRC suggested I go to the libvirt wiki. But maybe the answer to my last issue can be found via Google. The trick is this:

QEMU has a neat bridge-helper utility which allows a non-root user to easily connect a virtual machine to a bridged interface. In Fedora at least, qemu-bridge-helper runs as setuid (any user can run as root) and privileges are immediately dropped to cap_net_admin. It also has a simple white/blacklist ACL mechanism in place which limits connections to virbr0, libvirt’s local area network.

So the solution is to edit /etc/qemu/bridge.conf and add the line:

allow br0

Still no luck, though. Now I get a different message:

rror starting domain: internal error: /usr/libexec/qemu-bridge-helper --br=br0 --fd=24: failed to communicate with bridge helper: Transport endpoint is not connected
stderr=failed to get mtu of bridge `br0': No such device

And indeed, after rebooting, br0 is gone now. Trying ifup br0 without much hope. Nope:

[root@muse qemu]# ifup br0

Determining IP information for br0... failed.

VM disk corruption bug

Running the suggestions in Red Hat Bugzilla 1435315. First qemu-img check, which indeed finds a number of issues:

Leaked cluster 163766 refcount=1 reference=0
Leaked cluster 163767 refcount=1 reference=0
Leaked cluster 163768 refcount=1 reference=0
Leaked cluster 163769 refcount=1 reference=0
Leaked cluster 163770 refcount=1 reference=0
Leaked cluster 163771 refcount=1 reference=0
Leaked cluster 163772 refcount=1 reference=0
Leaked cluster 163773 refcount=1 reference=0
Leaked cluster 163774 refcount=1 reference=0
Leaked cluster 163775 refcount=1 reference=0
Leaked cluster 163776 refcount=1 reference=0
Leaked cluster 163777 refcount=1 reference=0
Leaked cluster 163778 refcount=1 reference=0
Leaked cluster 163779 refcount=1 reference=0
Leaked cluster 163780 refcount=1 reference=0
Leaked cluster 163781 refcount=1 reference=0
Leaked cluster 163782 refcount=1 reference=0
Leaked cluster 163783 refcount=1 reference=0
Leaked cluster 163784 refcount=1 reference=0
Leaked cluster 163785 refcount=1 reference=0
Leaked cluster 163786 refcount=1 reference=0
Leaked cluster 163787 refcount=1 reference=0
Leaked cluster 163788 refcount=1 reference=0
Leaked cluster 163789 refcount=1 reference=0
Leaked cluster 163790 refcount=1 reference=0
Leaked cluster 163791 refcount=1 reference=0
Leaked cluster 163792 refcount=1 reference=0
Leaked cluster 163793 refcount=1 reference=0
Leaked cluster 163794 refcount=1 reference=0
Leaked cluster 163795 refcount=1 reference=0
Leaked cluster 163796 refcount=1 reference=0
Leaked cluster 163797 refcount=1 reference=0
Leaked cluster 163798 refcount=1 reference=0
Leaked cluster 163799 refcount=1 reference=0
Leaked cluster 163800 refcount=1 reference=0
Leaked cluster 163801 refcount=1 reference=0
Leaked cluster 163802 refcount=1 reference=0
Leaked cluster 163803 refcount=1 reference=0
Leaked cluster 163804 refcount=1 reference=0
Leaked cluster 163805 refcount=1 reference=0
Leaked cluster 163806 refcount=1 reference=0
Leaked cluster 163807 refcount=1 reference=0
Leaked cluster 163808 refcount=1 reference=0
Leaked cluster 163809 refcount=1 reference=0
Leaked cluster 163810 refcount=1 reference=0
Leaked cluster 163811 refcount=1 reference=0
Leaked cluster 163812 refcount=1 reference=0
Leaked cluster 163813 refcount=1 reference=0
Leaked cluster 163814 refcount=1 reference=0
Leaked cluster 163815 refcount=1 reference=0
Leaked cluster 163816 refcount=1 reference=0
Leaked cluster 163817 refcount=1 reference=0
Leaked cluster 163818 refcount=1 reference=0
Leaked cluster 163819 refcount=1 reference=0
Leaked cluster 163820 refcount=1 reference=0
Leaked cluster 163821 refcount=1 reference=0
Leaked cluster 163822 refcount=1 reference=0
Leaked cluster 163823 refcount=1 reference=0
Leaked cluster 163824 refcount=1 reference=0
Leaked cluster 163825 refcount=1 reference=0
Leaked cluster 163826 refcount=1 reference=0
Leaked cluster 163827 refcount=1 reference=0
Leaked cluster 163828 refcount=1 reference=0
Leaked cluster 163829 refcount=1 reference=0
Leaked cluster 163830 refcount=1 reference=0
Leaked cluster 163831 refcount=1 reference=0
Leaked cluster 163832 refcount=1 reference=0
Leaked cluster 163833 refcount=1 reference=0
Leaked cluster 163834 refcount=1 reference=0
Leaked cluster 163835 refcount=1 reference=0
Leaked cluster 163836 refcount=1 reference=0
Leaked cluster 163837 refcount=1 reference=0
Leaked cluster 163838 refcount=1 reference=0
Leaked cluster 163839 refcount=1 reference=0
ERROR cluster 163868 refcount=0 reference=1
ERROR cluster 163869 refcount=0 reference=1
ERROR cluster 172062 refcount=0 reference=1
ERROR cluster 180255 refcount=0 reference=1
ERROR cluster 188448 refcount=0 reference=1
ERROR cluster 196641 refcount=0 reference=1
ERROR cluster 196642 refcount=0 reference=1
ERROR cluster 204835 refcount=0 reference=1
ERROR cluster 213028 refcount=0 reference=1
ERROR cluster 221221 refcount=0 reference=1
ERROR cluster 229414 refcount=0 reference=1
ERROR cluster 229415 refcount=0 reference=1
ERROR cluster 237608 refcount=0 reference=1
ERROR cluster 245801 refcount=0 reference=1
ERROR cluster 253994 refcount=0 reference=1
ERROR cluster 262187 refcount=0 reference=1
ERROR cluster 262188 refcount=0 reference=1
ERROR cluster 270381 refcount=0 reference=1
ERROR cluster 278574 refcount=0 reference=1
ERROR cluster 286767 refcount=0 reference=1
ERROR cluster 294960 refcount=0 reference=1
ERROR cluster 294961 refcount=0 reference=1
ERROR cluster 303154 refcount=0 reference=1
ERROR cluster 311347 refcount=0 reference=1
ERROR cluster 319540 refcount=0 reference=1
ERROR cluster 327733 refcount=0 reference=1
ERROR OFLAG_COPIED L2 cluster: l1_index=20 l1_entry=80000002801d0000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=21 l1_entry=80000002a01e0000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=22 l1_entry=80000002c01f0000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=23 l1_entry=80000002e0200000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=24 l1_entry=8000000300220000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=25 l1_entry=8000000320230000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=26 l1_entry=8000000340240000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=27 l1_entry=8000000360250000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=28 l1_entry=8000000380270000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=29 l1_entry=80000003a0280000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=30 l1_entry=80000003c0290000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=31 l1_entry=80000003e02a0000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=32 l1_entry=80000004002c0000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=33 l1_entry=80000004202d0000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=34 l1_entry=80000004402e0000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=35 l1_entry=80000004602f0000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=36 l1_entry=8000000480310000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=37 l1_entry=80000004a0320000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=38 l1_entry=80000004c0330000 refcount=0
ERROR OFLAG_COPIED L2 cluster: l1_index=39 l1_entry=80000004e0340000 refcount=0

46 errors were found on the image. Data may be corrupted, or further writes to the image may corrupt it.

16356 leaked clusters were found on the image. This means waste of disk space, but no harm to data. 147456/327680 = 45.00% allocated, 0.00% fragmented, 0.00% compressed clusters Image end offset: 21478375424

The second suggestion from Rick Jones, to convert the file, works without reporting any error:

ddd@muse images> qemu-img convert -f qcow2 fedora25-qxl.qcow2 -O raw fedora25-qxl.raw
ddd@muse images> ls -lh  fedora25-qxl.raw fedora25-qxl.qcow2 
-rw-------. 1 ddd ddd 21G Mar 24 15:21 fedora25-qxl.qcow2
-rw-r--r--. 1 ddd ddd 20G Mar 24 15:53 fedora25-qxl.raw

So this is interesting, as it allows me to boot that guest. In that case, the qcow2 file is larger than the raw file anyway... Which I find a bit suspect in itself, since I have very little in that guest (it's a relatively fresh install, and there's 12.7G free).