On Fri, 13.03.15 17:59, Will Woods (wwo...@redhat.com) wrote:
(Warming up this rally old thread again, sorry for not responding more timely)
> > http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
> >
> > systemd has been implementing this for quite a while, at least for all
> > syst
On Sat, Mar 14, 2015 at 12:07 AM, Andrei Borzenkov wrote:
> В Fri, 13 Mar 2015 16:38:33 -0600
> Chris Murphy пишет:
>
>> On Fri, Mar 13, 2015 at 3:59 PM, Will Woods wrote:
>> > I don't really like the new->old->new switchroot stuff, but I haven't
>> > got a better solution at the moment.
>> >
>>
В Fri, 13 Mar 2015 16:38:33 -0600
Chris Murphy пишет:
> On Fri, Mar 13, 2015 at 3:59 PM, Will Woods wrote:
> > I don't really like the new->old->new switchroot stuff, but I haven't
> > got a better solution at the moment.
> >
> > But: if we could use something like "systemd-nspawn" to:
> >
> > 1
On Fri, Mar 13, 2015 at 3:59 PM, Will Woods wrote:
> I don't really like the new->old->new switchroot stuff, but I haven't
> got a better solution at the moment.
>
> But: if we could use something like "systemd-nspawn" to:
>
> 1) start your old system in a container,
> 2) let it mount its disks,
>
On Tue, 2015-03-10 at 17:21 +0100, Lennart Poettering wrote:
> My recommendation would be to use the offline updates logic we have in
> systemd already:
>
> http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
>
> systemd has been implementing this for quite a while, at least for all
>
On Mon, 09.03.15 08:10, James Hogarth (james.hoga...@gmail.com) wrote:
> >> The reason for this is to simplify finding out where mount points are
> >> for a clean upgrade - it's been felt the easiest way is to just 'ask'
> >> the actual system to do this.
> >>
> >> After the mount points are all u
On 8 March 2015 at 22:32, Lennart Poettering wrote:
> On Thu, 05.03.15 22:07, James Hogarth (james.hoga...@gmail.com) wrote:
>
>> > Tried to put together a reduced testcase via a yum installroot style
>> > container to switch-root into to see what that behaviour is like and
>> > do see a segfault
On Sun, Mar 8, 2015 at 4:32 PM, Lennart Poettering
wrote:
> On Thu, 05.03.15 22:07, James Hogarth (james.hoga...@gmail.com) wrote:
>> This naturally means that the serialization/deserialization needs to
>> be forwards *and* backwards compatible between 216 and 219 for this to
>> work.
>
> Yeah, b
On Thu, 05.03.15 22:07, James Hogarth (james.hoga...@gmail.com) wrote:
> > Tried to put together a reduced testcase via a yum installroot style
> > container to switch-root into to see what that behaviour is like and
> > do see a segfault - not certain if this is the same being seen during
> > the
On 5 March 2015 at 17:07, James Hogarth wrote:
> On 5 March 2015 at 15:10, Lennart Poettering wrote:
>>
>>
>> Right before switch rooting systemd will kill all remaining processes
>> of the initrd, including the strace, hence the strace logs aren't that
>> useful either, they end before the trans
On 5 March 2015 at 15:10, Lennart Poettering wrote:
>
>
> Right before switch rooting systemd will kill all remaining processes
> of the initrd, including the strace, hence the strace logs aren't that
> useful either, they end before the transition.
>
> Please boot with "systemd.log_level=debug sy
On Thu, 05.03.15 13:52, James Hogarth (james.hoga...@gmail.com) wrote:
> Hi,
>
> I spent some time last night trying to track down the issue preventing
> fedup from fedora 21 to 22:
>
> https://bugzilla.redhat.org/show_bug.cgi?id=1185604
>
> I'm pretty sure I've tracked it down to when switch-r
Hi,
I spent some time last night trying to track down the issue preventing
fedup from fedora 21 to 22:
https://bugzilla.redhat.org/show_bug.cgi?id=1185604
I'm pretty sure I've tracked it down to when switch-root is called and
systemd-219 gets executed being passed the serialised state of systemd
13 matches
Mail list logo
