On 10/28/2016 01:56 AM, Marek Marczykowski-Górecki wrote:
> On Thu, Oct 27, 2016 at 03:31:46PM +0200, Marek Marczykowski-Górecki
> wrote:
> > On Thu, Oct 27, 2016 at 09:50:56AM +0200, Zrubi wrote:
> >> On 09/06/2016 01:24 AM, Marek Marczykowski-Górecki wrote:
> >>
> >>> I've just tried this and successfully upgraded Fedora 23 to Fedora 24
> >>> template.
> >>>
> >>> TL;DR version:
> >>> 1. Clone fedora-23 to fedora-24-test.
> >>> 2. Open terminal in fedora-24-test.
> >>> 3. Run "dnf upgrade --releasever=24".
> >>> 4. Shutdown the template.
> >>> 5. Switch (some of?) VMs to this template.
> >>>
> >>
> >> Just tried to upgrade my templates and got this error:
> >>
> >>
> >> Error: Transaction check error:
> >> file /usr/lib64/libpython3.so from install of
> >> system-python-libs-3.5.1-17.fc24.x86_64 conflicts with file from
> package
> >> python3-libs-3.4.3-12.fc23.x86_64
> >>
> >>
> >> Was not able to workaround it, because(?) those libs are used by dnf
> >> itself :o
> >>
> >> The official fedora upgrade way:
> >> https://fedoraproject.org/wiki/DNF_system_upgrade
> >> seems not compatible with Qubes
> >>
> >>
> >> any hints how to solve this?
>
> > I haven't tried recently, but it worked before. Maybe a workaround would
> > be to disable "updates" repository for the upgrade time? Just add
> > --disablerepo=updates.
>
> Or another idea: use `dnf distro-sync --releasever=24`, instead of `dnf
> upgrade`. Not sure if that helps.
>
> > I think it may be possible to use "official" upgrade method, by
> > switching to pvgrub first:
> >
> https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm
> > But in practice probably it will be more complex than just following
> > that instructions... Maybe worth a try?
>
> Actually, it looks like it almost works this way, even without switching
> to pvgrub. The only problem is that we put "3" on kernel cmdline, which
> forces systemd going into multi-user.target (instead of
> system-update.target). This can be worked around by putting
> "systemd.unit=system-update.target" on the template kernel command line
> ("kernelopts" property) before starting second phase of the upgrade.
We should not be putting 3 in the kernel command line, and we should not
be modifying the default target in qubes-core-vm-systemd either. What
we should do is do the necessary work to get the default system
configuration to work when we boot a VM into graphical.target (the
default). That way we avoid these integration issues.
I believe the correct thing to do is to create the necessary
configuration for the default display manager to start qubes-guid with
autologin. This will also give us a complete desktop session inside the
VM, and XDG autostart as well, as opposed to just a tiny stub that
doesn't have e.g. password manager environment or GPG agent.
This area is ripe for research, and it's time we matured in that
direction. Also noteworthy is that, with the move to Wayland, this sort
of work is very apropos.
--
Rudd-O
http://rudd-o.com/
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/822d780c-e039-f80b-3808-c6c8e740ffa7%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.
