Experimental upgrade notes 3.0 to 3.1rc2
125 views
Skip to first unread message
Chris Laprise
Jan 15, 2016, 10:51:23 AM1/15/16
to qubes-users
I performed an 'experimental' in-place upgrade to 3.1rc2 which was
successful overall. Here are some notes:
* Before starting, I could not update the fedora 21 template...
Apparently the qubes repository could not be reached. I use debian
instead of fedora templates so I skipped this step and removed the
fedora template after the upgrade completed.
* The debian template upgrade went smoothly, but now apt prints a
warning about a duplicate sources list; I'm not sure which one to
remove. Side-effect is that Qubes Manager now always shows that a debian
update is available even though the template is up to date.
* Pasting commands from a web page into the debian template made me
uneasy... I'd prefer an upgrade package that takes care of the fine
details, similar to the fedora upgrade process.
* AEM recovered automatically in the usual way after a boot partition
update.
System behavior:
* The system mostly works like 3.0 did.
* Net and firewall vms now startup completely instead of settling in the
'yellow' state.
* Bug: The drive attachment icon sometimes remains next to a vm in the
Manager list after shutting down a vm with an attached volume. Starting
the vm again does not clear the icon, and the 'Detach...' menu option is
visible in the context menu (but using it has no effect). The restarted
vm itself does not show any /dev/xvdi entries.
* System crash occurred while under moderate load: playing a video in
totem and starting another appvm. The video was 1080 HD reduced to about
1/8 display size; The started vm had all default properties (no pci
assignments or other config changes). The crash manifested as a full
system reset back to the BIOS screen. (IIRC, earlier in the session I
had tried to start an HVM with a USB controller pci assignment, which
failed.)
* I haven't measured it, but this version appears to use less power than
r3.0; it is more like r2.0 in this respect. I have less fan noise at idle.
* If I accidentally suspend a Mint HVM, Qubes is not aware of this fact
and is also unable to resume or shutdown the vm; it must be killed.
successful overall. Here are some notes:
* Before starting, I could not update the fedora 21 template...
Apparently the qubes repository could not be reached. I use debian
instead of fedora templates so I skipped this step and removed the
fedora template after the upgrade completed.
* The debian template upgrade went smoothly, but now apt prints a
warning about a duplicate sources list; I'm not sure which one to
remove. Side-effect is that Qubes Manager now always shows that a debian
update is available even though the template is up to date.
* Pasting commands from a web page into the debian template made me
uneasy... I'd prefer an upgrade package that takes care of the fine
details, similar to the fedora upgrade process.
* AEM recovered automatically in the usual way after a boot partition
update.
System behavior:
* The system mostly works like 3.0 did.
* Net and firewall vms now startup completely instead of settling in the
'yellow' state.
* Bug: The drive attachment icon sometimes remains next to a vm in the
Manager list after shutting down a vm with an attached volume. Starting
the vm again does not clear the icon, and the 'Detach...' menu option is
visible in the context menu (but using it has no effect). The restarted
vm itself does not show any /dev/xvdi entries.
* System crash occurred while under moderate load: playing a video in
totem and starting another appvm. The video was 1080 HD reduced to about
1/8 display size; The started vm had all default properties (no pci
assignments or other config changes). The crash manifested as a full
system reset back to the BIOS screen. (IIRC, earlier in the session I
had tried to start an HVM with a USB controller pci assignment, which
failed.)
* I haven't measured it, but this version appears to use less power than
r3.0; it is more like r2.0 in this respect. I have less fan noise at idle.
* If I accidentally suspend a Mint HVM, Qubes is not aware of this fact
and is also unable to resume or shutdown the vm; it must be killed.
Marek Marczykowski-Górecki
Jan 15, 2016, 7:49:37 PM1/15/16
to Chris Laprise, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Jan 15, 2016 at 10:51:19AM -0500, Chris Laprise wrote:
> I performed an 'experimental' in-place upgrade to 3.1rc2 which was
> successful overall. Here are some notes:
>
> * Before starting, I could not update the fedora 21 template... Apparently
> the qubes repository could not be reached. I use debian instead of fedora
> templates so I skipped this step and removed the fedora template after the
> upgrade completed.
Did you had similar problem before? Was it after installing
`qubes-upgrade-vm` package, or before?
> * The debian template upgrade went smoothly, but now apt prints a warning
> about a duplicate sources list; I'm not sure which one to remove.
> Side-effect is that Qubes Manager now always shows that a debian update is
> available even though the template is up to date.
You should remove /etc/apt/sources.list.d/qubes-r3-upgrade.list
Instruction updated.
> * Pasting commands from a web page into the debian template made me
> uneasy... I'd prefer an upgrade package that takes care of the fine details,
> similar to the fedora upgrade process.
Good idea.
https://github.com/QubesOS/qubes-issues/issues/1639
> * AEM recovered automatically in the usual way after a boot partition
> update.
Good :)
> System behavior:
>
>
> * The system mostly works like 3.0 did.
>
> * Net and firewall vms now startup completely instead of settling in the
> 'yellow' state.
>
> * Bug: The drive attachment icon sometimes remains next to a vm in the
> Manager list after shutting down a vm with an attached volume. Starting the
> vm again does not clear the icon, and the 'Detach...' menu option is visible
> in the context menu (but using it has no effect). The restarted vm itself
> does not show any /dev/xvdi entries.
Saved here:
https://github.com/QubesOS/qubes-issues/issues/1640
> * System crash occurred while under moderate load: playing a video in totem
> and starting another appvm. The video was 1080 HD reduced to about 1/8
> display size; The started vm had all default properties (no pci assignments
> or other config changes). The crash manifested as a full system reset back
> to the BIOS screen. (IIRC, earlier in the session I had tried to start an
> HVM with a USB controller pci assignment, which failed.)
Wasn't that simply overheat?
If not, I'm afraid debugging this without any logs (which in this case
are probably not written to the disk - probably available only on serial
console) and without reliable way to reproduce the issue, would be
extremely difficult.
> * I haven't measured it, but this version appears to use less power than
> r3.0; it is more like r2.0 in this respect. I have less fan noise at idle.
>
> * If I accidentally suspend a Mint HVM, Qubes is not aware of this fact and
> is also unable to resume or shutdown the vm; it must be killed.
You mean suspend from the inside of VM, right? Can you check VM state in
`xl list` and `virsh -c xen:/// list` in that case?
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWmZOaAAoJENuP0xzK19cseDwH/2mWQz0Z7X6OrI4SK+l44D84
9fs750Z5lCUv5nIGj9Nkvx115g3RlO+K+Fw/lfsal0op5jYS0zBjBUGVeDEdjjWg
dwbdccSQEK1HUJyUTsAWdGUxRa6dw+J5puD2p4oKeayjTr35rIEG4FkQNvrH5XNJ
05V/fBG5fjCVzyUV9tEMKHirYD8K2r/RcDWblzMDZYOvbkUPPAz0g+79aAwu2Jc2
FkIk2IuQdPAytpNjF9yw+hkl9fDenGxA+Ku6h42gmZ6yBzffjmNwniqbr29DRnz3
cn/Kzuex4hGa0qq5jyaNTG3WdsmliDLJ7C85b1hs75Xe2lbKzqxazJzegHB8Rwc=
=pxud
-----END PGP SIGNATURE-----
Hash: SHA256
On Fri, Jan 15, 2016 at 10:51:19AM -0500, Chris Laprise wrote:
> I performed an 'experimental' in-place upgrade to 3.1rc2 which was
> successful overall. Here are some notes:
>
> * Before starting, I could not update the fedora 21 template... Apparently
> the qubes repository could not be reached. I use debian instead of fedora
> templates so I skipped this step and removed the fedora template after the
> upgrade completed.
`qubes-upgrade-vm` package, or before?
> * The debian template upgrade went smoothly, but now apt prints a warning
> about a duplicate sources list; I'm not sure which one to remove.
> Side-effect is that Qubes Manager now always shows that a debian update is
> available even though the template is up to date.
Instruction updated.
> * Pasting commands from a web page into the debian template made me
> uneasy... I'd prefer an upgrade package that takes care of the fine details,
> similar to the fedora upgrade process.
https://github.com/QubesOS/qubes-issues/issues/1639
> * AEM recovered automatically in the usual way after a boot partition
> update.
> System behavior:
>
>
> * The system mostly works like 3.0 did.
>
> * Net and firewall vms now startup completely instead of settling in the
> 'yellow' state.
>
> * Bug: The drive attachment icon sometimes remains next to a vm in the
> Manager list after shutting down a vm with an attached volume. Starting the
> vm again does not clear the icon, and the 'Detach...' menu option is visible
> in the context menu (but using it has no effect). The restarted vm itself
> does not show any /dev/xvdi entries.
https://github.com/QubesOS/qubes-issues/issues/1640
> * System crash occurred while under moderate load: playing a video in totem
> and starting another appvm. The video was 1080 HD reduced to about 1/8
> display size; The started vm had all default properties (no pci assignments
> or other config changes). The crash manifested as a full system reset back
> to the BIOS screen. (IIRC, earlier in the session I had tried to start an
> HVM with a USB controller pci assignment, which failed.)
If not, I'm afraid debugging this without any logs (which in this case
are probably not written to the disk - probably available only on serial
console) and without reliable way to reproduce the issue, would be
extremely difficult.
> * I haven't measured it, but this version appears to use less power than
> r3.0; it is more like r2.0 in this respect. I have less fan noise at idle.
>
> * If I accidentally suspend a Mint HVM, Qubes is not aware of this fact and
> is also unable to resume or shutdown the vm; it must be killed.
`xl list` and `virsh -c xen:/// list` in that case?
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWmZOaAAoJENuP0xzK19cseDwH/2mWQz0Z7X6OrI4SK+l44D84
9fs750Z5lCUv5nIGj9Nkvx115g3RlO+K+Fw/lfsal0op5jYS0zBjBUGVeDEdjjWg
dwbdccSQEK1HUJyUTsAWdGUxRa6dw+J5puD2p4oKeayjTr35rIEG4FkQNvrH5XNJ
05V/fBG5fjCVzyUV9tEMKHirYD8K2r/RcDWblzMDZYOvbkUPPAz0g+79aAwu2Jc2
FkIk2IuQdPAytpNjF9yw+hkl9fDenGxA+Ku6h42gmZ6yBzffjmNwniqbr29DRnz3
cn/Kzuex4hGa0qq5jyaNTG3WdsmliDLJ7C85b1hs75Xe2lbKzqxazJzegHB8Rwc=
=pxud
-----END PGP SIGNATURE-----
Chris Laprise
Jan 17, 2016, 6:17:43 PM1/17/16
to Marek Marczykowski-Górecki, qubes-users
On 01/15/2016 07:49 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Fri, Jan 15, 2016 at 10:51:19AM -0500, Chris Laprise wrote:
>> I performed an 'experimental' in-place upgrade to 3.1rc2 which was
>> successful overall. Here are some notes:
>>
>> * Before starting, I could not update the fedora 21 template... Apparently
>> the qubes repository could not be reached. I use debian instead of fedora
>> templates so I skipped this step and removed the fedora template after the
>> upgrade completed.
> Did you had similar problem before? Was it after installing
> `qubes-upgrade-vm` package, or before?
some other network problem. I only updated fedora infrequently because
it wasn't in use, and the prior update was probably more than a month
ago. Yes, it was before the -upgrade package.
speed. The reset happened to me again: Better description of the
circumstances is that I was playing a youtube video (flash) while totem
was also playing while I was starting an appvm (I forgot the flash part
in my original description). Both times the audio buffer kept repeating
in a loop maybe 10-20x during the crash ...the timing during the first
crash was extremely comical :).
This sort of thing did happen a few times under 3.0, but I assumed that
some Xen or kernel update fixed the problem.
>> * I haven't measured it, but this version appears to use less power than
>> r3.0; it is more like r2.0 in this respect. I have less fan noise at idle.
>>
>> * If I accidentally suspend a Mint HVM, Qubes is not aware of this fact and
>> is also unable to resume or shutdown the vm; it must be killed.
> You mean suspend from the inside of VM, right? Can you check VM state in
> `xl list` and `virsh -c xen:/// list` in that case?
suspending, while the derivative -dm domain shows as "-b----". The virsh
command shows the domain as running but there is no -dm domain listed.
Chris
Marek Marczykowski-Górecki
Jan 17, 2016, 6:54:26 PM1/17/16
to Chris Laprise, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Sun, Jan 17, 2016 at 06:17:25PM -0500, Chris Laprise wrote:
> On 01/15/2016 07:49 PM, Marek Marczykowski-Górecki wrote:
> >On Fri, Jan 15, 2016 at 10:51:19AM -0500, Chris Laprise wrote:
(...)
> On 01/15/2016 07:49 PM, Marek Marczykowski-Górecki wrote:
> >On Fri, Jan 15, 2016 at 10:51:19AM -0500, Chris Laprise wrote:
> >>* System crash occurred while under moderate load: playing a video in totem
> >>and starting another appvm. The video was 1080 HD reduced to about 1/8
> >>display size; The started vm had all default properties (no pci assignments
> >>or other config changes). The crash manifested as a full system reset back
> >>to the BIOS screen. (IIRC, earlier in the session I had tried to start an
> >>HVM with a USB controller pci assignment, which failed.)
> >Wasn't that simply overheat?
> >If not, I'm afraid debugging this without any logs (which in this case
> >are probably not written to the disk - probably available only on serial
> >console) and without reliable way to reproduce the issue, would be
> >extremely difficult.
>
> Not overheating for sure, unless something was suppressing the fan speed.
> The reset happened to me again: Better description of the circumstances is
> that I was playing a youtube video (flash) while totem was also playing
> while I was starting an appvm (I forgot the flash part in my original
> description). Both times the audio buffer kept repeating in a loop maybe
> 10-20x during the crash ...the timing during the first crash was extremely
> comical :).
>
> This sort of thing did happen a few times under 3.0, but I assumed that some
> Xen or kernel update fixed the problem.
and log the output from some other machine. Otherwise, like I've said,
probably impossible to debug.
Details on serial console:
http://wiki.xenproject.org/wiki/Xen_Serial_Console
> >>* I haven't measured it, but this version appears to use less power than
> >>r3.0; it is more like r2.0 in this respect. I have less fan noise at idle.
> >>
> >>* If I accidentally suspend a Mint HVM, Qubes is not aware of this fact and
> >>is also unable to resume or shutdown the vm; it must be killed.
> >You mean suspend from the inside of VM, right? Can you check VM state in
> >`xl list` and `virsh -c xen:/// list` in that case?
>
> Yes, inside vm. The domain state shows as "------" in xl list after
> suspending, while the derivative -dm domain shows as "-b----". The virsh
> command shows the domain as running but there is no -dm domain listed.
during that operation. You can check VM console
(/var/log/xen/console/guest-VMNAME.log, or sudo xl console VMNAME). But
generally I would call it not supported operation...
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
LrWWx9yIncQwrL3vtH0lf8skfHY7rVs3Bcp9rzJ/1N0Exi42oK8UMfOS7Wdi7RdA
NJ06TVy0D3EpRIs7NpJvVGYXk25sWHVo+o1p3vbXt3yQjpORUImFIQsI8hHJNnXI
cOFg9WxeKIcKeX7pVO6BxnjAXIv85VzmA88kbPLx+SCN6wCtw9UkjfRLpuj9SPRL
jFWdLA867C93F+sMuIzlenonyC3jsPDPaZfX8KW3A0Ol3flwKVFfkX6XUaaqgIlE
Q5oabZGfdyMBulBy5rC770fNLZm+6hIQ9iAeHvf0PDrZ3dtUR5crgRD+kWHSYIs=
=m2iR
-----END PGP SIGNATURE-----
Chris Laprise
Jan 18, 2016, 5:52:40 AM1/18/16
to qubes...@googlegroups.com, Marek Marczykowski-Górecki
* Another issue I ran into: I decided it was a good idea to re-install
my whonix templates after the upgrade. But when I went to uninstall them
with 'autoremove' it said vm kernels 3.18.17-6, 3.18.17-7 and 4.1.13-8
would be removed.
So this made me wonder what is the intended set of kernels for r3.1? The
system is running on all 4.1 as a default, and I think the 3.x kernels
may be just leftovers from r3.0...
* Qubes templates never seem to update over VPN connections. I recall
some discussion in the past about changes that could facilitate this (I
think it was whonix related). So far, I still have to connect 'raw' to
get new installs and updates.
* The UEFI boot support in 3.1 does not appear to work. When I switch my
BIOS to UEFI-only, it displays a menu of drives and refuses to boot
(boot drive is USB stick).
Chris
Chris Laprise
Jan 25, 2016, 1:23:29 PM1/25/16
to Marek Marczykowski-Górecki, qubes-users
On 01/17/2016 06:54 PM, Marek Marczykowski-Górecki wrote:
system is handling my Logitech USB receiver. Filed an issue for this...
https://github.com/QubesOS/qubes-issues/issues/1689
I'm guessing the mouse was powering down when I was passively watching
longer videos, and when I moved the mouse and woke it up, that triggered
the crashes.
Reply all
Reply to author
Forward
0 new messages