On Thursday 21 August 2014 at 01:03:20, Lennart Poettering wrote:
[...]
...missing sysroot's fsck, as well as any other x-initrd mounts and their
fsck instances.
Seems that sysroot.mount alone isn't sufficient.
...Anything on this?
Should we add yet another
On Thursday 21 August 2014 at 22:06:49, Ivan Shapovalov wrote:
On Thursday 21 August 2014 at 01:03:20, Lennart Poettering wrote:
[...]
...missing sysroot's fsck, as well as any other x-initrd mounts and
their fsck instances.
Seems that sysroot.mount alone isn't
On 21/08/14 19:12, Ivan Shapovalov wrote:
Actually, I don't pretty understand the reasoning behind skipping the default
dependencies on /usr mount
(Some of) the default dependencies require that /usr is mounted, so
mounting /usr cannot depend on them, to avoid a cycle.
(Or to put it the way
On Thursday 21 August 2014 at 19:32:01, Simon McVittie wrote:
On 21/08/14 19:12, Ivan Shapovalov wrote:
Actually, I don't pretty understand the reasoning behind skipping the
default
dependencies on /usr mount
(Some of) the default dependencies require that /usr is mounted, so
On Thursday 21 August 2014 at 01:03:20, Lennart Poettering wrote:
On Tue, 19.08.14 15:46, Ivan Shapovalov (intelfx...@gmail.com) wrote:
On Monday 18 August 2014 at 22:04:29, Ivan Shapovalov wrote:
[..]
Even if initramfs-only, ordering dependencies still need to be
On Tue, 19.08.14 15:46, Ivan Shapovalov (intelfx...@gmail.com) wrote:
On Monday 18 August 2014 at 22:04:29, Ivan Shapovalov wrote:
[..]
Even if initramfs-only, ordering dependencies still need to be worked
out.
Inside of initramfs, neither systemd-fsck-root.service nor
On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote:
That should be enough. (You don't need to individually order the
systemd-fsck@.service instances for the other devices after your
service, since they are already ordered after systemd-fsck-root.service,
and you order
On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote:
On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote:
That should be enough. (You don't need to individually order the
systemd-fsck@.service instances for the other devices after your
service, since they
On Mon, 18.08.14 18:00, Ivan Shapovalov (intelfx...@gmail.com) wrote:
On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote:
On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote:
That should be enough. (You don't need to individually order the
On Monday 18 August 2014 at 18:40:59, Lennart Poettering wrote:
On Mon, 18.08.14 18:00, Ivan Shapovalov (intelfx...@gmail.com) wrote:
On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote:
On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote:
That
On Friday 15 August 2014 at 15:35:06, Ivan Shapovalov wrote:
[...]
Ah, right. This is actually correct here. We want to make sure that the
root fs is remounted before we mount the other units, since this might
required creating additional directories to mount things on...
There
On Thursday 14 August 2014 at 12:56:10, Lennart Poettering wrote:
On Thu, 14.08.14 09:20, Ivan Shapovalov (intelfx...@gmail.com) wrote:
The udev rule should be possible (provided that udevd does not need rootfs
remounted read-write -- I'd like to preserve some decency towards
On Fri, 15.08.14 13:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
Ah, well, if the resume= switch is supposed to simply carry the finished
device node path, and nothing we still have to translate into one, then
of course the entire udev rules step is unnecessary, and you can just
write this
On Friday 15 August 2014 at 11:32:59, Lennart Poettering wrote:
On Fri, 15.08.14 13:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
Ah, well, if the resume= switch is supposed to simply carry the finished
device node path, and nothing we still have to translate into one, then
of course
On Fri, 15.08.14 13:54, Ivan Shapovalov (intelfx...@gmail.com) wrote:
On Friday 15 August 2014 at 11:32:59, Lennart Poettering wrote:
On Fri, 15.08.14 13:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
Ah, well, if the resume= switch is supposed to simply carry the finished
On Friday 15 August 2014 at 12:00:41, Lennart Poettering wrote:
[...]
So is Before=local-fs-pre.target a sufficient ordering for such
resume unit?
Again, the resume unit must be started before any filesystems are
(re)mounted
read-write, either from initrd or not.
On Fri, 15.08.14 14:07, Ivan Shapovalov (intelfx...@gmail.com) wrote:
On Friday 15 August 2014 at 12:00:41, Lennart Poettering wrote:
[...]
So is Before=local-fs-pre.target a sufficient ordering for such
resume unit?
Again, the resume unit must be started
On Friday 15 August 2014 at 12:19:50, Lennart Poettering wrote:
[...]
I'd like to make this work both with initramfs and without one
(provided that
the rootfs has been mounted read-only by using 'ro' kernel cmdline
parameter).
In this case, what are the needed
On Thu, 14.08.14 09:20, Ivan Shapovalov (intelfx...@gmail.com) wrote:
The udev rule should be possible (provided that udevd does not need rootfs
remounted read-write -- I'd like to preserve some decency towards initrd-less
systems), but udev is a framework for handling events, whereas we don't
On Mon, 28.07.14 14:06, Ivan Shapovalov (intelfx...@gmail.com) wrote:
Hello all,
I'm trying to implement resuming from hibernation with systemd-based
initramfs,
i. e. in terms of systemd unit files. That is, there should be a unit which
waits for the resume device and writes its
On Thursday 14 August 2014 at 03:10:30, Lennart Poettering wrote:
On Mon, 28.07.14 14:06, Ivan Shapovalov (intelfx...@gmail.com) wrote:
Hello all,
I'm trying to implement resuming from hibernation with systemd-based
initramfs,
i. e. in terms of systemd unit files. That is,
Hello all,
I'm trying to implement resuming from hibernation with systemd-based initramfs,
i. e. in terms of systemd unit files. That is, there should be a unit which
waits for the resume device and writes its major:minor into /sys/power/resume.
I've chosen to write a templated
22 matches
Mail list logo
