RC1 impressions -- problems

[Stefan Boresch]

First, congratulations on RC1. Beta2 worked quite well for me, so
I skipped beta3 and only now decided to upgrade.

The installation worked smoothly and with the newer kernels / libs all
my hardware
was detected and works (based on limited testing so far). The only tinkering
needed was to attach the USB PCI device to which the 3G wireless
modem is connected to the netvm (once I figured out the device(s),
I could actually do it graphically)

For the HCL: Lenovo x220 8GB RAM, Intel graphics (core i5)
vt-d *is* working

However, not all is well:

(1) I have seen now two startups, where netvm and firewall-vm would
not start; when starting them manually, app-vms have no network
connectiviity. Note, this is not reproducible, so I'd be curious if others
have seen this as well.

(2) updating dom0 or installing stuff there (anti-evil-maid?) doesn't work.

Aside from http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateDom0 being outdated,

sudo qubes-dom0-update

fails with various 'connection' refused
messages. When I try to update dom0 from qubes-manager, a box
appears telling me that the update-tool will start shortly, but nothing
ever happens. In beta 2 updating dom0 from the command line
worked as described in the wiki (modulo the typo in the command name).
NB: given (1), I verified that networking in app VMs was up and working during
all those attempts!!

(3) I tried updating the fedora17 template VM (via the graphical interface),
but kernel-debug-3.4.xx
fails to install because 'installing package .. needs 99MB on the
/usr/lib/modules filesystem
???

Given that the VM
runs a 3.2.7 kernel, installing a 3.4.x debug kernel is probably not
a good idea to begin with, but this is what the graphical interface as
well as yum want to do ..

All other packages (about 23 or so) updated fine once I deselected this
one package.

(4) While it probably has nothing to do with (3), the strange error
reminded me of a question that bit me already with beta2. Can one increase
root.img of the fedora template VM *easily* (or of a cloned template
VM based on it)? In my devel domain I need lots of compilers, libs
etc. and the 10G tend to get 'narrow'. For /home there is the
neat qvm utiliity (to grow private?), but what to do about root.img ?

Thanks for all the hard work, and thanks for any advice / hints!

Stefan

[Marek Marczykowski]

On 25.07.2012 14:42, Stefan Boresch wrote:
> First, congratulations on RC1. Beta2 worked quite well for me, so
> I skipped beta3 and only now decided to upgrade.
>
> The installation worked smoothly and with the newer kernels / libs all
> my hardware
> was detected and works (based on limited testing so far). The only tinkering
> needed was to attach the USB PCI device to which the 3G wireless
> modem is connected to the netvm (once I figured out the device(s),
> I could actually do it graphically)
>
> For the HCL: Lenovo x220 8GB RAM, Intel graphics (core i5)
> vt-d *is* working

Added, thanks.

> However, not all is well:
>
> (1) I have seen now two startups, where netvm and firewall-vm would
> not start; when starting them manually, app-vms have no network
> connectiviity. Note, this is not reproducible, so I'd be curious if others
> have seen this as well.
>
> (2) updating dom0 or installing stuff there (anti-evil-maid?) doesn't work.
>
> Aside from http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateDom0 being outdated,
>
> sudo qubes-dom0-update
>
> fails with various 'connection' refused
> messages.

Looks like firewallvm not started properly...

> When I try to update dom0 from qubes-manager, a box
> appears telling me that the update-tool will start shortly, but nothing
> ever happens. In beta 2 updating dom0 from the command line
> worked as described in the wiki (modulo the typo in the command name).
> NB: given (1), I verified that networking in app VMs was up and working during
> all those attempts!!

This still can be related to problems with firewallvm/netvm. Dom0 updates are
downloaded by firewallvm, and then transferred to dom0. You can obtain some
debug info via qubes-manager: in context menu of VM (especially firewallvm)
there is "Logs" submenu.

> (3) I tried updating the fedora17 template VM (via the graphical interface),
> but kernel-debug-3.4.xx
> fails to install because 'installing package .. needs 99MB on the
> /usr/lib/modules filesystem
> ???

This is because of some packages in Fedora depends on kernel pkg, but in Qubes
it is managed by dom0, not VM itself. Basically it is bug in default template...
In our repo it is already fixed, but to apply this fix, you can:
sudo yum --enablerepo=qubes-vm-unstable install qubes-core-vm-kernel-placeholder
sudo yum remove kernel-debug

This should suppress further kernel-* pkg installation in VM.

> Given that the VM
> runs a 3.2.7 kernel, installing a 3.4.x debug kernel is probably not
> a good idea to begin with, but this is what the graphical interface as
> well as yum want to do ..
>
> All other packages (about 23 or so) updated fine once I deselected this
> one package.
>
> (4) While it probably has nothing to do with (3), the strange error
> reminded me of a question that bit me already with beta2. Can one increase
> root.img of the fedora template VM *easily* (or of a cloned template
> VM based on it)? In my devel domain I need lots of compilers, libs
> etc. and the 10G tend to get 'narrow'. For /home there is the
> neat qvm utiliity (to grow private?), but what to do about root.img ?

Not easily, but it is doable. The safest way is to do it for standalone VM
(qvm-create --standalone) - which have own root filesystem (copy of template,
instead of smart sharing). But should also work for normal template (as long
as changes in template between reboots didn't exceed 10G).

First of all make sure that root.img isn't used: for standalone VM, just make
sure it isn't running, for template - that none of template or VM based on it
is running. Then you can issue (in dom0):
truncate -s 20G /var/lib/qubes/vm-templates/fedora-17-x64/root.img
(replace desired size and path as you wish)
Then start template, issue:
sudo resize2fs /dev/mapper/dmroot
and shutdown template.

Then you should have extended root.img in your VM/template.

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[Marek Marczykowski]

On 26.07.2012 16:34, Stefan Boresch wrote:
> Hi Marek,
>
> thanks for the quick reply; mostly progress:
>
> 2012/7/25 Marek Marczykowski <marm...@invisiblethingslab.com>:

>> On 25.07.2012 14:42, Stefan Boresch wrote:
>
>>> (2) updating dom0 or installing stuff there (anti-evil-maid?) doesn't work.
>>>
>>> Aside from http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateDom0 being outdated,
>>>
>>> sudo qubes-dom0-update
>>>
>>> fails with various 'connection' refused
>>> messages.
>>
>> Looks like firewallvm not started properly...
>>
>

> today no connection refused messages, and I could not repoduce the
> issue. Could it be that the network/firewallvm
> gets confused if there is an ethernet (cable) and wlan connection
> simultaneously up? After the install
> I made sure that all my connectivities (lan, wlan and 3g wireless)
> work and switched back and forth.

Multiple active connections shouldn't cause any problem.

> It does not find updates (which may well be OK), but it still throws a
> bit strange messages:
>
> Checking for dom0 updates...
> Error: Cannot retrieve metalink for repository: fedora. Please verify
> its path and try again
> ...killed.
> No updates available
>
> The "Error" line does not always appear, but the ...killed is
> reproducible. So, is this a feature or
> is something still not quite right?

"...killed" message is the issue of Fedora systemd package. We have
workarounded it in some places, but as you see not all.

Error about metalink suggest that you have some network connectivity problem
in firewallvm. Do you have network access in any other VM?

Anyway there are no dom0 updates available for now. Every _dom0_ updates will
be announced on qubes-devel list.

>
>> This still can be related to problems with firewallvm/netvm. Dom0 updates are
>> downloaded by firewallvm, and then transferred to dom0. You can obtain some
>> debug info via qubes-manager: in context menu of VM (especially firewallvm)
>> there is "Logs" submenu.
>

> All the stuff in the logs looks harmless to me ..

>>> (4) While it probably has nothing to do with (3), the strange error
>>> reminded me of a question that bit me already with beta2. Can one increase
>>> root.img of the fedora template VM *easily* (or of a cloned template
>>> VM based on it)? In my devel domain I need lots of compilers, libs
>>> etc. and the 10G tend to get 'narrow'. For /home there is the
>>> neat qvm utiliity (to grow private?), but what to do about root.img ?
>>
>> Not easily, but it is doable. The safest way is to do it for standalone VM
>> (qvm-create --standalone) - which have own root filesystem (copy of template,
>> instead of smart sharing). But should also work for normal template (as long
>> as changes in template between reboots didn't exceed 10G).
>

> Again thanks! Worked very nicely and much more elegantly than what
> I did in the past ..
>
> Curious: what is 'volatile.img for? It's a 11G file.

http://wiki.qubes-os.org/trac/wiki/TemplateImplementation

BTW it is sparse file (use ls -ls) which actually holds much more disk space.

> I can't figure
> out what it does or if it is mounted in the running VM. Can having
> a 20G root.img with a 11G volatile.img cause trouble later on?
> (At the moment, there is only the standard stuff in /root, i.e., the additional
> storage (10->20G) is not used yet.

Short ansfer: yes, 11G volatile.img should work with 20G root.img.