Toshiba Satellite Z30-B-10W - Qubes
Hardware info on main page.
Hints:
dom0 to clipboard trick:
$ xrandr > /var/run/qubes/qubes-clipboard.bin $ echo "dom0" > /var/run/qubes/qubes-clipboard.bin.source
then use ctrl-shift-V to copy it into the desired VMs clipboard.
Links
History
2015-12-11: HCL report:
[user@dom0 ~]$ qubes-hcl-report personal Qubes release 3.1 (R3.1) Brand: TOSHIBA Model: SATELLITE Z30-B BIOS: Version 3.20 Xen: 4.6.0 Kernel: 3.19.8-100 RAM: 16295 Mb CPU: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz Chipset: Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09) VGA: Intel Corporation Broadwell-U Integrated Graphics [8086:1616] (rev 09) (prog-if 00 [VGA controller]) Net: Intel Corporation Ethernet Connection (3) I218-V (rev 03) Intel Corporation Wireless 3160 (rev cb) SCSI: TOSHIBA THNSNJ12 Rev: 0101 DataTraveler 3.0 Rev: PMAP HVM: Active I/O MMU: Not active TPM: Device not found Qubes HCL Files are copied to: 'personal' Qubes-HCL-TOSHIBA-SATELLITE_Z30-B-20151211-111006.yml - HCL Info
ok
2015-12-11: Next I start terminal for the personal VM and verify that I can ping DNS names - ok. Next I start Firefox in the personal VM. Yes - browsing works.
2015-12-11: I'm still missing all menu items for several VMs, so I try:
$ qvm-sync-appmenus fedora-23
since the fedora-23 VM is running, this completes quickly, and I have my appmenus for 'personal' and other VMs. cool.
2015-12-11: the installation was finished, I rebooted the machine and created my "user" user, set date and time, create VMs. It took some time, but qubes-configuration completed quicker now. I got an error message: "Setting up networking failure! ['/usr/bin/service','qubes-netvm','start'] failed: Redirecting to /bin/systemctl start qubes-netvm.service job for qubes-netvm.service failed. See 'systemctl status qubes-netvm.service' and 'journalctl -xn' for details." and then setup was completed, I pressed "finish" and could log in. At first, menus and stuff was very slow (not the mouse, and not commands, once I got a shell running) but that improved within some minutes. I connected to my wireless network (had to do it twice, the first try failed).
Let me try
$ sudo qubesctl state.highstate
and it worked (changed=1) but sys-firewall is not running. I start it via Qubes VM manager, it starts up normally.
2015-12-10: reinstall Qubes R3.1-rc1 to a usb stick (the same 16 GB stick). This time with "user" user.
2015-12-10: after a restart, VMs sys-net, sys-firewall and sys-whonix start automatically. I connect to my wireless network (for some reason, this requires two tries). I have no appVM menus, looks like menus from the fedora-23 TemplateVM didn't show up. Trying to start the fedora-23 TemplateVM I get this:
$ qvm-start fedora-23 --> Loading the VM (type = TemplateVM)... --> Starting Qubes DB... --> Setting Qubes DB info for the VM... --> Updating firewall rules... --> Starting the VM... --> Starting the qrexec daemon... Waiting for VM's qrexec agent.......................Cannot connect to 'fedora-23' qrexec agent for 60 seconds, giving up ERROR: Cannot execute qrexec-daemon!
but ps ax | grep qr
reveals that it is running as /usr/lib/qubes/qrexec-daemon 6 fedora-23 user
Hmm, what now?
$ xl list
and fedora-23 shows up there too, with state 'b' (blocked).
On a whim, I tried to start the work vm (it worked) and after that I can update the fedora-23 vm too. Updating requires the TemplateVM to be running. Strange that it suddenly works. Except that the update didn't complete and all kinds of stuff starts to fail afterwards. Tired of this, I decide to redo the install, this time with user "user".
2015-12-10: later (after sleep and a workday) I have figured out that the user "user" also must be a member of the qubes group, so fix that: before
$ id user uid=1001(user) gid=1002(user) groups=1002(user) $ id tingo uid=1000(tingo) gid=1001(tingo) groups=1001(tingo), 10(wheel), 18(dialout), 1000(qubes) $ sudo usermod -a -G qubes user
after
$ id user uid=1001(user) gid=1002(user) groups=1002(user), 1000(qubes)
ok. Now let's see if the qubesctl command succeds:
$ sudo qubesctl state.highstate [...] Succeeded: 28 (changed=5) Failed: 0 Total states run: 28
It appears to have worked. Nice. I assigned the wireless network card to the sys-net firewall. Now, what happens if I run a restart of Qubes?
2015-12-10: after a reboot, qubes comes up, but only with dom0. No other VMs sighted.
2015-12-10: after finishing the install, I booted into Qubes R3.1-rc1, created a user, date and time, selected the default VMs for system, application, Whonix & Workstation. "qubes-configuration" took a long time. Ok, I got a dialog box with an error message: "Executing qubes configuration failure! Qubes initial configuration failed. Login to the system and check /var/log/salt/minion for details. You can retry configuration by calling 'sudo qubesctl state.highstate in dom0 (you will get detailed state there).". Login is slow, and afterwards I have only the mouse pointer on the grey Qubes background. Using Ctrl-Alt-F2 gets me tty2, and I can do a console login there, that works. Let me try that command:
[tingo@dom0 ~]$ sudo qubesctl state.highstate
ok, it fails with lots of "Problem running salt function in Jinja template: User 'user' is not available". And refers to a file /var/cache/salt/minion/files/dom0/qvm/template.jinja. Several other on the malinglist had the same error. The "fix" is to add a user named "user" and rerun the qubesctl command.
[tingo@dom0 ~]$ sudo useradd user
it completes after a bit. I set a password with sudo passwd user, then retry
$ sudo qubesctl state.highstate
which still takes its sweet time. Getting tired, I just shutdown the whole Qubes.
2015-12-09: I started to install Qubes R3.1-rc1 onto another usb stick, a 16 GB usb 3.0 stick, the install takes a long time.
2015-12-09: I booted Qubes R3.1-rc1 (install image) from a usb stick. Network card and everything seems to work.