On Thu, Dec 22, 2022, at 11:00 AM, Lennart Poettering wrote:
> On Do, 22.12.22 10:56, Chris Murphy (li...@colorremedies.com) wrote:
>> Still another idea, we could add a new setting MinRetentionSec=90day
>> which would translate into "not less than 90 days" and wou
or if less, the 10% of
file system size rule) still applies. So in no case would any use case end up
using more space for logs.
Any thoughts?
--
Chris Murphy
/73168
>
> This *may* be related to the use of ZFS, although I've got a
> half-dozen systems using ZFS and only two of them have this issue.
Are the two with the problem multiple device ZFS? And the rest are single
device ZFS?
--
Chris Murphy
ries outside of which
if the kernel code estimates it's going to fall short of, could trigger a
cancel of the shrink. This could be size or time based. e.g.
BTRFS_IOC_RESIZE_BEST (effort).
--
Chris Murphy
time.
On shutdown, homed resizes until it gets killed
https://github.com/systemd/systemd/issues/22901
Getting "New partition doesn't fit into backing storage, refusing"
https://github.com/systemd/systemd/issues/22255
fails to resize
https://github.com/systemd/systemd/issues/22124
[1]
Branch from Rawhide August 9, the earliest release date would be October 18.
--
Chris Murphy
nervous about fs shrink at logout (also implying restart and shutdown) time.
On shutdown, homed resizes until it gets killed
https://github.com/systemd/systemd/issues/22901
Getting "New partition doesn't fit into backing storage, refusing"
https://github.com/systemd/systemd/issues/22255
fails to resize
https://github.com/systemd/systemd/issues/22124
[1]
Branch from Rawhide August 9, the earliest release date would be October 18.
--
Chris Murphy
sed blocks to the underlying filesystem? And then do an
fs resize (shrink or grow) as needed on login, so that the user home
shows ~80% of the free space in the underlying file system?
homework-luks.c:3407:/* Before we
shrink, let's trim the file system, so that we need less space on disk
during the shrinking */
--
Chris Murphy
retty
broken right now.
https://github.com/kdave/btrfs-progs/issues/271
I'm not sure if systemd folks would use libbtrfsutil facility to
determine the minimum device shrink size? But also even the kernel
doesn't have a very good idea of how small a file system can be
shrunk. Right now it basically has to just start trying, and does it
one block group at a time.
Adding systemd-devel@
--
Chris Murphy
On Thu, Dec 30, 2021 at 3:59 PM Chris Murphy wrote:
>
> ZFS uses volume and user properties which we could probably mimic with
> xattr. I thought I asked about xattr instead of subvolume names at one
> point in the thread but I don't see it. So instead of using subvolume
&g
instead of using subvolume
names, what about stuffing this information in xattr? My gut instinct
is this is less transparent and user friendly, it requires more tools
to know how to user to troubleshoot and fix, etc.
--
Chris Murphy
mechanism
to match /boot and /usr together, so that the user doesn't get stuck
choosing a kernel version for which the modules don't exist in an
older generation /usr. And then does this imply some additional
functionality in the bootloader to achieve it, or should this
information be fully encapsulated in Boot Loader Spec compliant
snippets?
--
Chris Murphy
On Tue, Dec 21, 2021 at 6:57 AM Ludwig Nussel wrote:
>
> Chris Murphy wrote:
> > The part I'm having a hard time separating is the implicit case (use
> > some logic to assemble the correct objects), versus explicit (the
> > bootloader snippet points to a root a
ounting
'@auto/varlibvirtimages-x86-64:fedora.35 at /var/lib/libvirt/images...
Dec 10 10:45:11 fovo.local systemd[1]: Mounting
'@auto/varlog-x86-64:fedora.35' at /var/log...
Dec 10 10:45:11 fovo.local systemd[1]: Mounting '@auto/swap' at /var/swap...
--
Chris Murphy
apply to any
image? Let's say it's a Btrfs image. And in the context of this
thread, the GPT partition type GUID would be the "super-root" GUID?
--
Chris Murphy
d keep this reasonably independent of btrfs where its
> easy, plain dirs otherwise are fine too after all. Which reminds me,
> recent util-linux implements the X-mount.subdir= mount option, which
> means one could also use 'rootflags=X-mount.subdir=@auto/fedora_36.2'
> as non-btrfs-specific way to express the btrfs-specific
> 'rootflags=subvol=@auto/fedora_36.2')
Neat.
--
Chris Murphy
e of this for btrfs for some sort of rescue/emergency boot
subvolume however... where it doesn't contain the parameter
"rootflags=subvol=$root" (which acts as an override for the default
subvolume set in the fs itself) then the btrfs default subvolume would
be used. I'm struggling with its role in all of this though.
--
Chris Murphy
On Fri, Nov 19, 2021 at 4:17 AM Lennart Poettering
wrote:
>
> On Do, 18.11.21 14:51, Chris Murphy (li...@colorremedies.com) wrote:
>
> > How to do swapfiles?
>
> Is this really a concept that deserves too much attention?
*shrug* Only insofar as I like order, and like th
On Mon, Nov 22, 2021 at 3:02 AM Ulrich Windl
wrote:
>
> >>> Lennart Poettering schrieb am 19.11.2021 um 10:17
> in
> Nachricht :
> > On Do, 18.11.21 14:51, Chris Murphy (li...@colorremedies.com) wrote:
> >
> >> How to do swapfiles?
> >
>
On Thu, Nov 18, 2021 at 2:51 PM Chris Murphy wrote:
>
> How to do swapfiles?
>
> Currently I'm creating a "swap" subvolume in the top-level of the file
> system and /etc/fstab looks like this
>
> UUID=$FSUUID/var/swap btrfs noatime,subvol
d still ZFS uses @ for their (read-only) snapshots.
--
Chris Murphy
aproject.org/message/VBVFQOG5EYI73CGFVCLMGX72IZUCQEYG/
--
Chris Murphy
al
set out in the discoverable partition spec, which is to obviate the
need for /etc/fstab.
--
Chris Murphy
On Tue, Feb 9, 2021 at 8:02 AM Phillip Susi wrote:
>
>
> Chris Murphy writes:
>
> > Basically correct. It will merge random writes such that they become
> > sequential writes. But it means inserts/appends/overwrites for a file
> > won't be located with the or
On Mon, Feb 8, 2021 at 8:20 AM Phillip Susi wrote:
>
>
> Chris Murphy writes:
>
> > I showed that the archived journals have way more fragmentation than
> > active journals. And the fragments in active journals are
> > insignificant, and can even be reduced b
On Mon, Feb 8, 2021 at 7:56 AM Phillip Susi wrote:
>
>
> Chris Murphy writes:
>
> >> It sounds like you are arguing that it is better to do the wrong thing
> >> on all SSDs rather than do the right thing on ones that aren't broken.
> >
> > No I'
some cases if the intent is to
use nodatacow. Snapshots results in nodatacow files being subject to
cow.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fri, Feb 5, 2021 at 8:23 AM Phillip Susi wrote:
> Chris Murphy writes:
>
> > But it gets worse. The way systemd-journald is submitting the journals
> > for defragmentation is making them more fragmented than just leaving
> > them alone.
>
> Wait, doesn't i
ntended to be used together, and combining them
seems accidental.
Defragmenting datacow files makes some sense on rotating media. But
that's the exception, not the rule.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.
y more fragmented than fallocated
files on ext4 or XFS.
2-17 fragments on ext4:
https://pastebin.com/jiPhrDzG
https://pastebin.com/UggEiH2J
That behavior is no different for nodatacow fallocated journals on
Btrfs. There's no point in defragmenting these no matter the file
system. I d
On Thu, Feb 4, 2021 at 6:28 AM Lennart Poettering
wrote:
>
> On Mi, 03.02.21 22:32, Chris Murphy (li...@colorremedies.com) wrote:
> > It doesn't. It waits indefinitely.
> >
> > [* ] A start job is running for
> > /dev/disk/by-uuid/cf9c9518-45d4-43d6-8a0a-294
h other. They
are independent ways of dealing with the same problem, where only one
of them is needed. And the best of the two is fallocate+nodatacow
which makes the journals behave the same as on ext4 where you also
don't do defragmentation.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Wed, Feb 3, 2021 at 10:32 PM Chris Murphy wrote:
>
> On Thu, Jan 28, 2021 at 7:18 AM Lennart Poettering
> wrote:
> >
> > On Mi, 27.01.21 17:19, Chris Murphy (li...@colorremedies.com) wrote:
> >
> > > Is it possible for a udev rule to have a timeout? For exa
ession is enabled.
But the write hit has already happened by writing journal data into
this journal file during its lifetime. Just rename it on rotate.
That's the least IO impact possible at this point. Defragmenting it
means even more writes, and not much of a gain if any, unless
On Wed, Feb 3, 2021 at 9:41 AM Lennart Poettering
wrote:
>
> On Di, 05.01.21 10:04, Chris Murphy (li...@colorremedies.com) wrote:
>
> > f27a386430cc7a27ebd06899d93310fb3bd4cee7
> > journald: whenever we rotate a file, btrfs defrag it
> >
> > Since systemd-jo
On Thu, Jan 28, 2021 at 7:18 AM Lennart Poettering
wrote:
>
> On Mi, 27.01.21 17:19, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Is it possible for a udev rule to have a timeout? For example:
> > /usr/lib/udev/rules.d/64-btrfs.rules
> >
> > This udev
On Thu, Jan 28, 2021 at 1:03 AM Greg KH wrote:
>
> On Wed, Jan 27, 2021 at 05:19:38PM -0700, Chris Murphy wrote:
> >
> > Next, is it possible to enhance udev so that it can report the number
> > of devices expected for a Btrfs file system? This information is
> > cur
on is
currently in the Btrfs superblock found on each device in the
num_devices field.
https://github.com/storaged-project/udisks/pull/838#issuecomment-768372627
Thanks,
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freede
On Tue, Jan 5, 2021 at 10:04 AM Chris Murphy wrote:
>
> f27a386430cc7a27ebd06899d93310fb3bd4cee7
> journald: whenever we rotate a file, btrfs defrag it
>
> Since systemd-journald sets nodatacow on /var/log/journal the journals
> don't really fragment much. I typically
n atomic
freeze+thaw ioctl, i.e. one that is guaranteed to return to thaw. But
this has been rebuffed so far. While thaw seems superfluous for the
use case under discussion, it's possible poweroff command will be
blocked by the freeze. And the thaw itself can be blocked by the
tacow files submitted for decompression were compressed. So we no
longer get that unintended benefit. This strengthens the case to just
drop the defragment step upon rotation, no other changes.
What do you think?
--
Chris Murphy
___
systemd-devel m
On Mon, Oct 12, 2020 at 1:33 AM Lennart Poettering
wrote:
>
> On So, 11.10.20 14:57, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Hi,
> >
> > A Fedora 32 (systemd-245.8-2.fc32) user has a 10-drive Btrfs raid1 set
> > to mount in /etc/fstab:
> >
>
On Sun, Oct 11, 2020 at 11:56 PM Andrei Borzenkov wrote:
>
> 11.10.2020 23:57, Chris Murphy пишет:
> > Hi,
> >
> > A Fedora 32 (systemd-245.8-2.fc32) user has a 10-drive Btrfs raid1 set
> > to mount in /etc/fstab:
> >
> > UUID=f89f0a16- /srv btrfs de
rder
to know to mount this file system at /srv
Anyway I'm mainly confused why the btrfs udev rule is seemingly not
applied in this case.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.
this is a temporary situation, we need to find a long term
solution because it's definitely not intended that the user babysit
the two file systems like this. There should be built-in logic to make
sure It Just Works.
But also in your case you should try to find out why ther
rkaround until
this is figured out why the fallocate fails (I suspect shared extents,
there's evidence this home file has been snapshot and I don't know
what effect that has on fallocating the file) is to use
--luks-discard=true ? That should avoid the need to fallocate when
opening. And t
On Thu, Jun 4, 2020 at 5:30 AM Michal Koutný wrote:
>
> Hi.
>
> On Mon, Jun 01, 2020 at 07:11:15PM -0600, Chris Murphy
> wrote:
> > But journalctl does not show it at all. Seems like it might be a bug,
> > I expect it to be recorded in the journal, not only found i
/user-1000.journal on
a btrfs file system, and copy-on-write is e
But journalctl does not show it at all. Seems like it might be a bug,
I expect it to be recorded in the journal, not only found in dmesg.
systemd-245.4-1.fc32.x86_64
Thanks,
--
Chris Murphy
and encrypt /home.
Or add in zram-generator configuration if the generator is available,
and not worry about creating a persistent device.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Hi,
I'm wondering if user journals are better being located in ~/.var by
default? In particular in a systemd-homed context when ~/ is
encrypted.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
re's no difference in the error between wrong passphrase (this user
is not authentic) and encoding failure due to keyboard change, or
keymapping change, or whatever else can affect encoding.
Small problem? :D
--
Chris Murphy
___
systemd-devel mai
://www.saout.de/pipermail/dm-crypt/2019-December/006283.html
[2]
modhex
https://www.saout.de/pipermail/dm-crypt/2019-December/006285.html
ASCII, although actually personally excludes upper case
https://www.saout.de/pipermail/dm-crypt/2019-December/006287.html
--
Chris Murphy
___
On Wed, Nov 20, 2019, 11:58 PM Belisko Marek
wrote:
> On Thu, Nov 21, 2019 at 7:25 AM Chris Murphy
> wrote:
> >
> > On Tue, Nov 12, 2019 at 3:52 AM Belisko Marek
> wrote:
> > >
> > > On Mon, Nov 11, 2019 at 4:47 PM Lennart Poettering
> > > wrote
al. Your effort should be on finding out why this
problem is happening in the first place. This doesn't strike me as the
(somewhat) ordinary case of unclean unmount, which results in journal
replay at next mount attempt. But something considerably more serious.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
so far the effort has been to try and
make the initramfs smaller, and more generic.
I have no idea how either Apple or Microsoft solve this problem.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.fre
arate var volume, mounted
at /var, with /var/home bind mounted to /home.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
8.709s in userspace
[root@localhost-live ~]#
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
/listinfo/anaconda-devel-list
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
illa.redhat.com/show_bug.cgi?id=1748145
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mon, Sep 2, 2019 at 1:56 AM Hans de Goede wrote:
>
> Hi,
>
> On 02-09-19 07:17, Mantas Mikulėnas wrote:
> > On Mon, Sep 2, 2019 at 7:34 AM Chris Murphy > <mailto:li...@colorremedies.com>> wrote:
> >
> > systemd-243~rc2-2.fc31.x86_64
>
s
/sys/module/acpiphp
/sys/module/libata/parameters/noacpi
/sys/module/libata/parameters/acpi_gtf_filter
/sys/module/acpi
/sys/module/acpi/parameters/acpica_version
OK so maybe no expected hook to discover the brightness to save it or
load it is all? *shrug*
--
Chris Murphy
___
ccessfully" type of behavior. In any case, it's
up to the distro to decide the policy, with a way for the user to opt
out of that by setting the applicable timeout value to something like
0, to indicate they really want an indefinite wait.
Thanks,
--
Chris Murphy
__
] fmac.local audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=systemd-random-seed comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
[chris@fmac ~]$
---
Chris Murphy
_
arly-debug shell and start typing, it almost
immediately clears up and boot proceeds.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Thu, Aug 1, 2019 at 12:43 AM Stefan Tatschner wrote:
>
> On Wed, 2019-07-31 at 16:27 -0600, Chris Murphy wrote:
> > The Obi Wan quote seems to apply here. "Who's the more foolish, the
> > fool, or the fool who follows him?"
> >
> > You're invit
ol who follows him?"
You're invited to stop following me.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mon, Jul 29, 2019 at 1:26 AM Lennart Poettering
wrote:
>
> On So, 28.07.19 22:11, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Using either of the following:
> >
> > systemd.log_level=debug systemd.journald.forward_to_kmsg log_buf_len=8M
>
subset of messages to kmsg but then they get
dropped? I don't know how to debug this...
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Sun, Jul 21, 2019 at 11:48 PM Ulrich Windl
wrote:
>
> >>> Chris Murphy schrieb am 18.07.2019 um 17:55 in
> Nachricht
> :
> > On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala wrote:
> >>
> >> On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote:
>
On Fri, Jul 19, 2019 at 8:45 AM Uoti Urpala wrote:
>
> On Thu, 2019-07-18 at 21:52 -0600, Chris Murphy wrote:
> > # df -h
> > ...
> > /dev/mapper/live-rw 6.4G 5.7G 648M 91% /
> >
> > And in the log:
> > 47,19636,16754831,-;systemd-journald[905]: Fixe
to kmsg.
https://bugzilla.redhat.com/show_bug.cgi?id=1715699#c17
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
1 0.0 0.1 171444 14696 ?Ss 12:05 0:09
/usr/lib/systemd/systemd --switched-root --system --deserialize 18
Live system (Rawhide):
root 1 0.8 0.4 171516 14708 ?Ss 19:57 0:07
/usr/lib/systemd/systemd --switched-root --system --deserialize 32
--
C
On Thu, Jul 18, 2019 at 4:02 PM Chris Murphy wrote:
>
> On Thu, Jul 18, 2019 at 10:18 AM Dave Howorth wrote:
> >
> > On Thu, 18 Jul 2019 09:55:51 -0600
> > Chris Murphy wrote:
> > > On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala
> > > wrote:
> &g
On Thu, Jul 18, 2019 at 10:18 AM Dave Howorth wrote:
>
> On Thu, 18 Jul 2019 09:55:51 -0600
> Chris Murphy wrote:
> > On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala
> > wrote:
> > >
> > > On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote:
> > &g
On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala wrote:
>
> On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote:
> > So far nothing I've tried gets me access to information that would
> > give a hint why systemd-journald thinks there's no free space and yet
> > i
cific cause + solution it's
questionable to block.
---
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mon, Jul 15, 2019 at 2:32 PM Chris Murphy wrote:
>
> This is still a problem with systemd-242-5.git7a6d834.fc31.x86_64
>
> If I boot using 'systemd.journald.forward_to_console=1
> console=ttyS0,38400 console=tty1 systemd.log_level=debug rd.debug
> rd.udev.debug'
On Mon, Jul 15, 2019 at 2:32 PM Chris Murphy wrote:
>
> If I boot using 'systemd.log_level=debug rd.debug rd.udev.debug
> systemd.log_target=kmsg log_buf_len=64M printk.devkmsg=on'
Another data point. Is kmsg dumped into a file is 5MiB, after the
point in time when journald ha
eed 8.0M
of archived journals from
/var/log/journal/05d0a9c86a0e4bbcb36c5e0082b987ee.
<47>[ 24.390015] systemd-journald[905]: Journal effective settings
seal=no compress=yes compress_threshold_bytes=512B
<47>[ 24.390126] systemd-journald[905]: Retrying write.
Retrying what write a
use cases dictate.
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
x27;s
like a RAM cache for swap. It'll swap to memory first, and then
overflow to a swap partition or file. It also lacks all the weird
interfaces of zram.)
https://wiki.archlinux.org/index.php/Improving_performance#Zram_or_zswap
> > zswap is different: we k
at
reboot time?
I'd like to allow a user to 'systemctl stop zram' which does swapoff
and removes the zram device. But is there something that could go into
the unit file that says "don't wait for swapoff, if everything else is
rea
7b9f602709b7897eb2?branch=devel
I figure it's plausible at shutdown time that something is swapped
out, and a umount before swapoff could hang (briefly or indefinitely I
don't know), and therefore it's probably better to cause swapoff to
happen befo
On Wed, Jun 19, 2019 at 6:15 AM Lennart Poettering
wrote:
>
> On Di, 18.06.19 20:34, Chris Murphy (li...@colorremedies.com) wrote:
>
> > When I boot Fedora 30/Rawhide Workstation (LiveOS install media) in a
> > VM with ~2GiB memory, using any combination of systemd, dracut,
ly
dropping the first 30s just because I've got debug options set is a
big problem for troubleshooting other problems with early startup of
install images.
Thanks,
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
ht
[ 23.310765] flap.local systemd[1]: Found device /dev/mapper/cryptswap.
In the non-working case, that never happens. systemd just doesn't see
the swap device appear. But in early debug shell, 'blkid' sees it.
Chris Murphy
___
syste
01 R09: 55d0300e8160
[7.887550] fmac.local kernel: R10: 7ffc79f6a080 R11:
35fc R12: 7ffc79ed78c8
[7.887551] fmac.local kernel: R13: 7ffc79ed78c0 R14:
55d0300efa60 R15: 00c3d9ef
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Wed, May 8, 2019 at 3:52 AM Lennart Poettering
wrote:
>
> eOn Mo, 06.05.19 10:26, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Waiting for device (parent + 2 partitions) to appear...
> > Found writable 'root' partition (UUID
> > 87d5a92987174be9
On Mon, May 6, 2019 at 10:26 AM Chris Murphy wrote:
> Looks like it wants to mount root, but it's already mounted and hence
> busy. Btrfs lets you do that, ext4 and XFS don't, they need to be bind
> mounted instead. Just a guess.
Nope, that's not correct. I can mount /de
gdb) quit
Looks like it wants to mount root, but it's already mounted and hence
busy. Btrfs lets you do that, ext4 and XFS don't, they need to be bind
mounted instead. Just a guess.
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel
On Fri, May 3, 2019 at 2:23 AM Lennart Poettering
wrote:
>
> On Fr, 03.05.19 00:37, Chris Murphy (li...@colorremedies.com) wrote:
>
> > systemd-242-3.git7a6d834.fc31.x86_64
> >
> > With the Fedora /etc/fstab entry for /boot/efi commented out, systemd
> > isn'
EC93B (EFI System)
Partition unique GUID: 0E3A48C0-3F1B-4CA7-99F4-32FD1D831CDC
First sector: 2048 (at 1024.0 KiB)
Last sector: 411647 (at 201.0 MiB)
Partition size: 409600 sectors (200.0 MiB)
Attribute flags:
Partition name: 'EFI System Partition'
5] flap.local systemd[582]: systemd-random-seed.service:
Executing: /usr/lib/systemd/systemd-random-seed load
The first one seems late in startup; and then it's not for ~10s later
that it's really executed.
--
Chris Murphy
___
systemd-devel mailing list
OK the only thing running is `dev-mapper-eswap.device` everything else
is waiting. But even looking at its status, it doesn't reveal why it's
waiting.
I've updated the bug.
--
Chris Murphy
___
systemd-devel mailing lis
On Mon, Mar 25, 2019 at 3:18 AM Lennart Poettering
wrote:
>
> On Do, 21.03.19 19:36, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Hi,
> >
> > Problem Summary (which I forgot to put in the bug):
> > /etc/crypttab configured to use /dev/urandom to gen
https://bugzilla.redhat.com/show_bug.cgi?id=1691589
But it's not a great bug report yet because I don't have enough
information why it's hanging. Ordinarily I'd use
`systemd.log_level=debug` but the problem never happens so far if I
use it. So I'm looking for advice on getting more informati
On Wed, Jul 18, 2018, 1:12 PM Lennart Poettering
wrote:
> On Mi, 18.07.18 13:08, Chris Murphy (li...@colorremedies.com) wrote:
>
> > My original expectation was that SystemMaxUse=2G which is the same
> > size as the file system, would be limited by the default behavior of
On Thu, Jul 12, 2018 at 8:28 AM, Michal Koutný wrote:
> Hi Chris.
>
> On 07/11/2018 09:44 PM, Chris Murphy wrote:
>> Somehow journald would not
>> delete its own files until I had deleted a few manually.
> Indeed, see man page update [1] added recently for more details. I
83.7M free.
Not much to go on.
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
e up space.
Anyway the main thing that has me confused is the max 1.3G statement,
which has been the same since the file system was 5% full upon
creation, and then journals increased all the way to enospc without
any of them being deleted.
--
Chris Murphy
___
On Thu, Jun 7, 2018 at 10:32 AM, Mantas Mikulėnas wrote:
> On Thu, Jun 7, 2018 at 4:21 AM Chris Murphy wrote:
>>
>> [chris@f28h ~]$ sudo journalctl --verify
>> 15f1c8: Data object references invalid entry at 4855f8
>> File corruption dete
1 - 100 of 253 matches
Mail list logo
