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