Monday, March 6, 2017

(Lifted from Wordpress)

Car woes

This should not impact my work but it unfortunately does. My car would not unlock this morning again, so I had to get it picked up at my home and do a trip back and forth to the repair shop. They did a quick workaround, but a more complete fix requires a 2-days stop.

Installing new VM from NFS now fails

This is driving me nuts. I just needed a quick VM from scratch to do a comparison.

Unable to complete install: 'internal error: process exited while connecting to monitor: serialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5901,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on
2017-03-07T12:12:59.061498Z qemu-system-x86_64: -drive file=/data/systems/Rockstor-3.8-14.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on: Could not open '/data/systems/Rockstor-3.8-14.iso': Permission denied'

This is really a complicated message for what I suspect is my old SE Linux foe:

setsebool -P virt_use_nfs 1

Nope. Something else is at play. Now I get

Unable to complete install: 'internal error: process exited while connecting to monitor: 2017-03-07T12:36:59.962210Z qemu-system-x86_64: -drive file=/data/systems/Rockstor-3.8-14.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on: Could not open '/data/systems/Rockstor-3.8-14.iso': Permission denied'
Doing a file to read the ISO file shows that it’s readable both from root and from the regular user. Does the same problem exists with all my ISO files, which makes it a bit annoying. Doing an ls shows that user IDs are mapped correctly. In short, it’s none of the failure I learned to cope with in the past month.

Spice for Mac: fixing autoconf

Spent practically the whole day chasing the autoconf bug that made it hard to figure out what the root cause of my configuration problem was. After much sifting through Perl code (yuck), attempting to understand the multi-layered pile of m4 temporary files (re-yuck), and what the intent of all this processing was, I finally got to the bottom of it and found a one-line fix, which consists in filtering out m4trace output from m4.

Before, the message was:

Use of uninitialized value $msg in concatenation (.) or string at /usr/local/Cellar/autoconf/2.69/bin/autom4te line 1032.
  Use of uninitialized value $stacktrace in pattern match (m//) at /usr/local/Cellar/autoconf/2.69/bin/autom4te line 1032.
  unknown channel m4trace: -1- AS_VAR_APPEND(ac_configure_args, " '$ac_arg'")
   at /usr/local/Cellar/autoconf/2.69/share/autoconf/Autom4te/Channels.pm line 638.
      Autom4te::Channels::msg('m4trace: -1- AS_VAR_APPEND(ac_configure_args, " '$ac_arg'")x{a}', undef, 'warning: ', 'partial', 0) called at /usr/local/Cellar/autoconf/2.69/bin/autom4te line 1032

After the fix, the message turns to:

  common/Makefile.am:20: error: Libtool library used but 'LIBTOOL' is undefined
  common/Makefile.am:20:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
  common/Makefile.am:20:   to 'configure.ac' and run 'aclocal' and 'autoconf' again.
  common/Makefile.am:20:   If 'LT_INIT' is in 'configure.ac', make sure
  common/Makefile.am:20:   its definition is in aclocal's search path.
  autoreconf: automake failed with exit status: 1

Much better. Now I know what’s going on.