[arch-general] How do I _really_ fix the superblock?
Hi, I still need to comment out everything in fstab, excepted of / (it does include home) to boot Arch Linux, so at least I'm able to boot. Anyway, each time I boot, I get a message that the superblock's last write time was in the future, it always gets fixed and than always the / partition is checked. The Arch Linux partition is an ext3 FS, so I run fsck.ext3 -p from a live media and it pretended too, that the issue is fixe, but it isn't. JFTR the hardware clock does work correctly. I suspect it isn't related to the perl pain, that makes a lot of important software from AUR unusable on my machine. Could systemd be the culprit? [rocketmouse@archlinux ~]$ grep systemd /var/log/pacman.log | grep 2014-06-04 [2014-06-04 08:34] [PACMAN] upgraded libsystemd (212-3 -> 213-5) [2014-06-04 08:34] [PACMAN] upgraded systemd (212-3 -> 213-5) [2014-06-04 08:34] [PACMAN] upgraded systemd-sysvcompat (212-3 -> 213-5) I could restore my Arch from a backup to fix it, but than I wouldn't know what packages to upgrade and what package upgrades I need to ignore. JFTR after I booted Arch Linux I can remove the #'s from fstab and mount everything in fstab. Regards, Ralf
Sat, 07 Jun 2014 13:36:08 +0200 Ralf Mardorf <ralf.mardorf@rocketmail.com>:
Could systemd be the culprit?
Yes. https://bugs.archlinux.org/task/40706 --byte
On Sat, 2014-06-07 at 13:50 +0200, Jens Adam wrote:
Sat, 07 Jun 2014 13:36:08 +0200 Ralf Mardorf <ralf.mardorf@rocketmail.com>:
Could systemd be the culprit?
Thank you and my apologize that I didn't check the bugs myself. "I had the same problem. Simply reverting RTC to UTC helped as workaround." Not a workaround for my taste. I want to have the choice what time to use. Regards, Ralf
On 2014-06-07 06:57, Ralf Mardorf wrote:
On Sat, 2014-06-07 at 13:50 +0200, Jens Adam wrote:
Sat, 07 Jun 2014 13:36:08 +0200 Ralf Mardorf <ralf.mardorf@rocketmail.com>:
Could systemd be the culprit?
Thank you
and my apologize that I didn't check the bugs myself.
"I had the same problem. Simply reverting RTC to UTC helped as workaround."
Not a workaround for my taste. I want to have the choice what time to use.
Regards, Ralf
The Beginner's Guide says: Warning: Using localtime may lead to several known and unfixable bugs. If you're going to do something non-standard that's known to cause problems, you have to expect things like this from time to time.
On Sat, 2014-06-07 at 09:59 -0500, Doug Newgard wrote:
The Beginner's Guide says: Warning: Using localtime may lead to several known and unfixable bugs.
If you're going to do something non-standard that's known to cause problems, you have to expect things like this from time to time.
"systemd, libsystemd and systemd-sysvcompat 213-6 from testing only solve the fstab issue, but they don't solve the superblock issue." - https://bugs.archlinux.org/task/40706 I never run into trouble before, because I use the local time when using Linux and FreeBSD, while I'm using Linux for around 11 years each day now. I chose local time because I want the correct time, when I use the BIOS, e.g. to backup BIOS settings, it's not related to a Windows install. I suspect it's just the evil policy of those systemd folks, who want to teach everybody to follow there ways, as the only right ways. IMO there's no valid reason not to chose local time.
On 2014-06-07 17:46, Ralf Mardorf wrote: [--snip--]
I suspect it's just the evil policy of those systemd folks, who want to teach everybody to follow there ways, as the only right ways.
Please don't insinuate conspiracies without good evidence.
IMO there's no valid reason not to chose local time.
Here's a reason: A time zone is for *DISPLAY PURPOSES ONLY*. UTC is well-defined for machine time (which is a continuum), but local time may not be continuous -- there are holes and overlaps in a local time depending on daylight saving time. Always use UTC unless you have absolutely no other choice. Regards,
On Sat, 2014-06-07 at 17:54 +0200, Bardur Arantsson wrote:
On 2014-06-07 17:46, Ralf Mardorf wrote: [--snip--]
I suspect it's just the evil policy of those systemd folks, who want to teach everybody to follow there ways, as the only right ways.
Please don't insinuate conspiracies without good evidence.
It's not a bug, nothing needs to be fixed [1]. So what is the reason for this decision, when it's not a bug? It worked with _all_ systemd versions until now, it still works with sysvinit and upstart. It _never_ cause trouble to use localtime the last 11 years on my machines, just the current systemd upgrade for my Arch Linux, for the first time ever in 11 years does cause trouble. Perhaps we shouldn't spoil the list, you perhaps could explain me the reason for this decision off-list. Maybe I simply miss something. Regards, Ralf [1] -------- Forwarded Message -------- From: Arch Linux <bugs@archlinux.org> Reply-to: bugs@archlinux.org To: bugs@archlinux.org Subject: FS#40706: [systemd] cannot boot with 213-5 Date: Sat, 07 Jun 2014 15:55:34 +0000 Mailer: Flyspray THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#40706 - [systemd] cannot boot with 213-5 User who did this - Dave Reisner (falconindy) ---------- Your "superblock issue" is solved by not using localtime. Nothing to be fixed in systemd. ---------- More information can be found at the following URL: https://bugs.archlinux.org/task/40706#comment124000 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
On 2014-06-07 11:05, Ralf Mardorf wrote:
On Sat, 2014-06-07 at 17:54 +0200, Bardur Arantsson wrote:
On 2014-06-07 17:46, Ralf Mardorf wrote: [--snip--]
I suspect it's just the evil policy of those systemd folks, who want to teach everybody to follow there ways, as the only right ways.
Please don't insinuate conspiracies without good evidence.
It's not a bug, nothing needs to be fixed [1]. So what is the reason for this decision, when it's not a bug? It worked with _all_ systemd versions until now, it still works with sysvinit and upstart. It _never_ cause trouble to use localtime the last 11 years on my machines, just the current systemd upgrade for my Arch Linux, for the first time ever in 11 years does cause trouble.
It's not a bug because using a time that warps forward and backward as your internal yardstick is simply not sane. The bug linked to above happened because nobody tested systemd with a RTC in localtime. That's not surprising, since people who actually know what's happening behind the scenes know that using localtime makes no sense and wouldn't run it. And nobody cares that you've been using Linux for 11 years. Really, get off of it. (I say this as a Linux user of > 15 years.)
On Sat, 2014-06-07 at 11:14 -0500, Doug Newgard wrote:
On 2014-06-07 11:05, Ralf Mardorf wrote:
On Sat, 2014-06-07 at 17:54 +0200, Bardur Arantsson wrote:
On 2014-06-07 17:46, Ralf Mardorf wrote: [--snip--]
I suspect it's just the evil policy of those systemd folks, who want to teach everybody to follow there ways, as the only right ways.
Please don't insinuate conspiracies without good evidence.
It's not a bug, nothing needs to be fixed [1]. So what is the reason for this decision, when it's not a bug? It worked with _all_ systemd versions until now, it still works with sysvinit and upstart. It _never_ cause trouble to use localtime the last 11 years on my machines, just the current systemd upgrade for my Arch Linux, for the first time ever in 11 years does cause trouble.
It's not a bug because using a time that warps forward and backward as your internal yardstick is simply not sane. The bug linked to above happened because nobody tested systemd with a RTC in localtime. That's not surprising, since people who actually know what's happening behind the scenes know that using localtime makes no sense and wouldn't run it.
And nobody cares that you've been using Linux for 11 years. Really, get off of it. (I say this as a Linux user of > 15 years.)
There was a choice until now, at least for the last 11 years, perhaps longer and now there's no choice anymore. Using UTC has got advantages, but for some needs localtime is the better choice, so why not providing a choice anymore?
On Sat, 2014-06-07 at 18:34 +0200, Ralf Mardorf wrote:
On Sat, 2014-06-07 at 11:14 -0500, Doug Newgard wrote:
On 2014-06-07 11:05, Ralf Mardorf wrote:
On Sat, 2014-06-07 at 17:54 +0200, Bardur Arantsson wrote:
On 2014-06-07 17:46, Ralf Mardorf wrote: [--snip--]
I suspect it's just the evil policy of those systemd folks, who want to teach everybody to follow there ways, as the only right ways.
Please don't insinuate conspiracies without good evidence.
It's not a bug, nothing needs to be fixed [1]. So what is the reason for this decision, when it's not a bug? It worked with _all_ systemd versions until now, it still works with sysvinit and upstart. It _never_ cause trouble to use localtime the last 11 years on my machines, just the current systemd upgrade for my Arch Linux, for the first time ever in 11 years does cause trouble.
It's not a bug because using a time that warps forward and backward as your internal yardstick is simply not sane. The bug linked to above happened because nobody tested systemd with a RTC in localtime. That's not surprising, since people who actually know what's happening behind the scenes know that using localtime makes no sense and wouldn't run it.
And nobody cares that you've been using Linux for 11 years. Really, get off of it. (I say this as a Linux user of > 15 years.)
There was a choice until now, at least for the last 11 years, perhaps longer and now there's no choice anymore. Using UTC has got advantages, but for some needs localtime is the better choice, so why not providing a choice anymore?
PS: Perhaps the time when backing up a BIOS any way is encoded in UTC, but at least I can see the correct time when using the BIOS (when taking a look at the BIOS time) or when experimenting with the hardware, without using an OS. However, I will close this thread, a discussion it will lead to nothing.
On Sat, Jun 07, 2014 at 05:46:48PM +0200, Ralf Mardorf wrote:
Date: Sat, 07 Jun 2014 17:46:48 +0200 From: Ralf Mardorf <ralf.mardorf@rocketmail.com> To: arch-general@archlinux.org Subject: Re: [arch-general] How do I _really_ fix the superblock? X-Mailer: Evolution 3.12.2
On Sat, 2014-06-07 at 09:59 -0500, Doug Newgard wrote:
The Beginner's Guide says: Warning: Using localtime may lead to several known and unfixable bugs.
If you're going to do something non-standard that's known to cause problems, you have to expect things like this from time to time.
"systemd, libsystemd and systemd-sysvcompat 213-6 from testing only solve the fstab issue, but they don't solve the superblock issue." - https://bugs.archlinux.org/task/40706
There has never been a "superblock" issue. There is something wrong with your RTC/system clock. Depending on the filesystem this may be a problem or not. For instance, ext{3,4} cares about superblock modification time, while ntfs does not (iirc).
now. I chose local time because I want the correct time, when I use the BIOS, e.g. to backup BIOS settingstamps.
And... your clock is not correct apparently. Besides, what does BIOS backup have to do with a way your clock keep time? -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 2014-06-07 at 12:12 -0400, Leonid Isaev wrote:
your clock is not correct apparently.
The clock provides the correct localtime. There's no issue caused by the clock. The issue only appears for Arch Linux with systemd from the repositories > version 212-3. It worked before: [rocketmouse@archlinux ~]$ grep systemd /var/log/pacman.log [snip] [2013-02-17 02:59] installed systemd (197-4) [snip] [2014-06-04 08:34] [PACMAN] upgraded libsystemd (212-3 -> 213-5) [2014-06-04 08:34] [PACMAN] upgraded systemd (212-3 -> 213-5) [2014-06-04 08:34] [PACMAN] upgraded systemd-sysvcompat (212-3 -> 213-5) [snip] [2014-06-07 17:19] [PACMAN] Running 'pacman -U systemd-213-6-x86_64.pkg.tar.xz libsystemd-213-6-x86_64.pkg.tar.xz systemd-sysvcompat-213-6-x86_64.pkg.tar.xz' [2014-06-07 17:19] [PACMAN] upgraded libsystemd (213-5 -> 213-6) [2014-06-07 17:19] [PACMAN] upgraded systemd (213-5 -> 213-6) [2014-06-07 17:19] [PACMAN] upgraded systemd-sysvcompat (213-5 -> 213-6) And it always worked without a problem for all other Linux and FreeBSD installs on my machines. If it's a new policy, then there's no reason to discuss this on the mailing list.
On Sat, Jun 07, 2014 at 06:23:49PM +0200, Ralf Mardorf wrote:
Date: Sat, 07 Jun 2014 18:23:49 +0200 From: Ralf Mardorf <ralf.mardorf@rocketmail.com> To: arch-general@archlinux.org Subject: Re: [arch-general] How do I _really_ fix the superblock? X-Mailer: Evolution 3.12.2
On Sat, 2014-06-07 at 12:12 -0400, Leonid Isaev wrote:
your clock is not correct apparently.
The clock provides the correct localtime. There's no issue caused by the clock. The issue only appears for Arch Linux with systemd from the repositories > version 212-3. It worked before:
[rocketmouse@archlinux ~]$ grep systemd /var/log/pacman.log [snip] [2013-02-17 02:59] installed systemd (197-4) [snip] [2014-06-04 08:34] [PACMAN] upgraded libsystemd (212-3 -> 213-5) [2014-06-04 08:34] [PACMAN] upgraded systemd (212-3 -> 213-5) [2014-06-04 08:34] [PACMAN] upgraded systemd-sysvcompat (212-3 -> 213-5) [snip] [2014-06-07 17:19] [PACMAN] Running 'pacman -U systemd-213-6-x86_64.pkg.tar.xz libsystemd-213-6-x86_64.pkg.tar.xz systemd-sysvcompat-213-6-x86_64.pkg.tar.xz' [2014-06-07 17:19] [PACMAN] upgraded libsystemd (213-5 -> 213-6) [2014-06-07 17:19] [PACMAN] upgraded systemd (213-5 -> 213-6) [2014-06-07 17:19] [PACMAN] upgraded systemd-sysvcompat (213-5 -> 213-6)
And it always worked without a problem for all other Linux and FreeBSD installs on my machines.
Just out of curiosity, when exactly do you see the fsck warning: at each reboot, or when booting after some downtime? Also, how do you syncronize time: ntpd/chrony/timesyncd?
If it's a new policy, then there's no reason to discuss this on the mailing list.
There is no policy, just common sense... -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 2014-06-07 at 12:43 -0400, Leonid Isaev wrote:
Just out of curiosity, when exactly do you see the fsck warning: at each reboot, or when booting after some downtime? Also, how do you syncronize time: ntpd/chrony/timesyncd?
I see the warning with each startup, it doesn't matter if I reboot or if I boot after a long downtime. The clock is ok. I sync manually [rocketmouse@archlinux ~]$ cat /usr/local/bin/tool #!/bin/bash # /usr/local/bin/tool case $1 in [snip] ntp) ntpdate ntp.favey.ch hwclock --set --date "$(date)";; [snip] The warning about the wrong superblock time isn't an issue, the problem is that with each startup the / partition is checked. I thought this is caused by the wrong superblock time, but IIUC it's another bug.
On Sat, Jun 07, 2014 at 06:49:58PM +0200, Ralf Mardorf wrote:
Date: Sat, 07 Jun 2014 18:49:58 +0200 From: Ralf Mardorf <ralf.mardorf@rocketmail.com> To: arch-general@archlinux.org Subject: Re: [arch-general] How do I _really_ fix the superblock? X-Mailer: Evolution 3.12.2
On Sat, 2014-06-07 at 12:43 -0400, Leonid Isaev wrote:
Just out of curiosity, when exactly do you see the fsck warning: at each reboot, or when booting after some downtime? Also, how do you syncronize time: ntpd/chrony/timesyncd?
I see the warning with each startup, it doesn't matter if I reboot or if I boot after a long downtime. The clock is ok. I sync manually
[rocketmouse@archlinux ~]$ cat /usr/local/bin/tool #!/bin/bash
# /usr/local/bin/tool
case $1 in [snip] ntp) ntpdate ntp.favey.ch hwclock --set --date "$(date)";; [snip]
Just an advice: replace this with a continuously tunning ntpd or at least with ntpd -q.
The warning about the wrong superblock time isn't an issue, the problem is that with each startup the / partition is checked. I thought this is caused by the wrong superblock time, but IIUC it's another bug.
That's actually interesting. Whether / will be fsck'ed or not depends on your mkinitcpio hooks (fsck) and kernel cmdline. What are them? Do you have "ro" in the cmdline? -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 2014-06-07 at 13:23 -0400, Leonid Isaev wrote:
That's actually interesting. Whether / will be fsck'ed or not depends on your mkinitcpio hooks (fsck) and kernel cmdline. What are them? Do you have "ro" in the cmdline?
The GRUB lines for my kernels all include 'ro'. [rocketmouse@archlinux ~]$ grep HOOKS /etc/mkinitcpio.conf | grep -v "#" HOOKS="base udev autodetect modconf block filesystems keyboard fsck vboxhost" "1) Use the 'fsck' hook, use 'rw' on the kernel commandline. 2) Don't use the 'fsck' hook, use 'ro' on the kernel commandline." - https://bbs.archlinux.org/viewtopic.php?pid=1307895#p1307895 So I should remove fsck from the hooks? If so, why didn't it cause the issue before the systemd update? Regards, Ralf Off-topic PS:
Just an advice: replace this with a continuously tunning ntpd or at least with ntpd -q.
Is this useful for a DAW? Part of the audio tuning could be turning off Internet connections, but at least I will run as less services as possible. Ok, the -q "ntpd will not daemonize and will exit after the clock is first synchronized" seems to be something I could use.
On Sat, Jun 07, 2014 at 10:34:12PM +0200, Ralf Mardorf wrote:
Date: Sat, 07 Jun 2014 22:34:12 +0200 From: Ralf Mardorf <ralf.mardorf@rocketmail.com> To: arch-general@archlinux.org Subject: Re: [arch-general] Unwanted forced fsck at each startup - Was: How do I _really_ fix the superblock? X-Mailer: Evolution 3.12.2
On Sat, 2014-06-07 at 13:23 -0400, Leonid Isaev wrote:
That's actually interesting. Whether / will be fsck'ed or not depends on your mkinitcpio hooks (fsck) and kernel cmdline. What are them? Do you have "ro" in the cmdline?
The GRUB lines for my kernels all include 'ro'.
[rocketmouse@archlinux ~]$ grep HOOKS /etc/mkinitcpio.conf | grep -v "#" HOOKS="base udev autodetect modconf block filesystems keyboard fsck vboxhost"
So, your / is being checked twice on boot...
"1) Use the 'fsck' hook, use 'rw' on the kernel commandline. 2) Don't use the 'fsck' hook, use 'ro' on the kernel commandline." - https://bbs.archlinux.org/viewtopic.php?pid=1307895#p1307895
So I should remove fsck from the hooks?
Since you are seeing the fsck warning even after an extended downtime, I can think of two possibilities: 1. The superblock mod time is _really_ wrong (like in 2020), that is OS does something strange. You can check this by running "tune2fs -l" or dumpe2fs from a live environment, possibly disabling your timesync tool for this one experiment. 2. Something happens in between the two runs of fsck. I'd remove the fsck hook to let systemd check the filesystems and see if that helps.
If so, why didn't it cause the issue before the systemd update?
I don't know.
Regards, Ralf
Off-topic PS:
Just an advice: replace this with a continuously tunning ntpd or at least with ntpd -q.
Is this useful for a DAW? Part of the audio tuning could be turning off Internet connections, but at least I will run as less services as possible. Ok, the -q "ntpd will not daemonize and will exit after the clock is first synchronized" seems to be something I could use.
I meant "running", not "tunning". Also, I can only suspect what you mean by DAW. Anyway, ntpd daemon can handle intermittent network access just fine... Unless you have an extremely CPU/memory-constrained system, you really should use the daemon IMHO because it offers continuous time synchronization, etc. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 2014-06-07 at 17:13 -0400, Leonid Isaev wrote:
I'd remove the fsck hook to let systemd check the filesystems and see if that helps.
Done, but I won't reboot now. I will report back next time I (re)boot Arch Linux.
Off-topic PS: I meant "running", not "tunning". Also, I can only suspect what you mean by DAW. Anyway, ntpd daemon can handle intermittent network access just fine... Unless you have an extremely CPU/memory-constrained system, you really should use the daemon IMHO because it offers continuous time synchronization, etc.
"DAW" is for "digital audio workstation", it is an extremely CPU/memory-strained real-time task system.
On Sat, 2014-06-07 at 23:24 +0200, Ralf Mardorf wrote:
On Sat, 2014-06-07 at 17:13 -0400, Leonid Isaev wrote:
I'd remove the fsck hook to let systemd check the filesystems and see if that helps.
Done, but I won't reboot now. I will report back next time I (re)boot Arch Linux.
fsck still is forced to run :(
On Sat, Jun 07, 2014 at 05:46:48PM +0200, Ralf Mardorf wrote:
"systemd, libsystemd and systemd-sysvcompat 213-6 from testing only solve the fstab issue, but they don't solve the superblock issue." - https://bugs.archlinux.org/task/40706
I never run into trouble before, because I use the local time when using Linux and FreeBSD, while I'm using Linux for around 11 years each day now. I chose local time because I want the correct time, when I use the BIOS, e.g. to backup BIOS settings, it's not related to a Windows install.
It's a warning, not a trouble. fsck is warning you, not systemd. $ LANG=C grep "last write time is in the future" $(pacman -Qlq e2fsprogs|grep /bin/.) Binary file /usr/bin/e2fsck matches Binary file /usr/bin/fsck.ext2 matches Binary file /usr/bin/fsck.ext3 matches Binary file /usr/bin/fsck.ext4 matches Binary file /usr/bin/fsck.ext4dev matches It's not a new "issue", maybe you're seeing it for the first time (localtime here), in coincidence with the forced fsck bug.
On Sat, 2014-06-07 at 18:36 +0200, Alessandro Doro wrote:
It's not a new "issue", maybe you're seeing it for the first time (localtime here), in coincidence with the forced fsck bug.
Oops, sorry, not closed, I indeed missed something. My impression was, that the superblock issue does cause the fsck. IOW fsck runs each time, even if I would switch to UTC? I don't care about a message/warning about the time, it's annoying that it takes that long, when fsck checks / each time I boot Arch.
On Sat, Jun 07, 2014 at 06:44:21PM +0200, Ralf Mardorf wrote:
On Sat, 2014-06-07 at 18:36 +0200, Alessandro Doro wrote:
It's not a new "issue", maybe you're seeing it for the first time (localtime here), in coincidence with the forced fsck bug.
Oops, sorry, not closed, I indeed missed something.
My impression was, that the superblock issue does cause the fsck. IOW fsck runs each time, even if I would switch to UTC?
I don't think so, the whole message should be: Superblock last write time is in the future. (by less than a day, probably due to the hardware clock being incorrectly set). FIXED. The fsck issue comes (AFAICT) from https://bugs.freedesktop.org/show_bug.cgi?id=79576 Systemd 213-6 is now in testing with a patch to remove the recently added "-l" option to fsck in systemd-fsck. Did you try that?
On Sat, 2014-06-07 at 19:46 +0200, Alessandro Doro wrote:
The fsck issue comes (AFAICT) from https://bugs.freedesktop.org/show_bug.cgi?id=79576
Systemd 213-6 is now in testing with a patch to remove the recently added "-l" option to fsck in systemd-fsck. Did you try that?
Yes, it doesn't solve the fsck issue, it only solved the issue that I needed to command out fstab entries, now there isn't the need to comment out those entries. "[rocketmouse at archlinux ~]$ grep systemd /var/log/pacman.log [snip] [2014-06-07 17:19] [PACMAN] Running 'pacman -U systemd-213-6-x86_64.pkg.tar.xz libsystemd-213-6-x86_64.pkg.tar.xz systemd-sysvcompat-213-6-x86_64.pkg.tar.xz' [2014-06-07 17:19] [PACMAN] upgraded libsystemd (213-5 -> 213-6) [2014-06-07 17:19] [PACMAN] upgraded systemd (213-5 -> 213-6) [2014-06-07 17:19] [PACMAN] upgraded systemd-sysvcompat (213-5 -> 213-6)" - https://mailman.archlinux.org/pipermail/arch-general/2014-June/036497.html
participants (6)
-
Alessandro Doro
-
Bardur Arantsson
-
Doug Newgard
-
Jens Adam
-
Leonid Isaev
-
Ralf Mardorf