Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to get a log of fsck on boot partition when using systemd-sysv
89 views
Skip to first unread message
Jape Person
May 10, 2014, 6:20:02 PM5/10/14
to
Hi,
I just used
# apt-get install systemd-sysv
on several Debian testing systems (fully up-to-date).
It has been my habit to use
# touch /forcefsck
to force a file system check at reboot once per week on each system and
to keep track of the results by copying the contents of
/var/log/fsck/checkroot into a sort of diary I keep on system maintenance.
In various logs on these systems I see an indication that "touch
/forcefsck" doesn't work with systemd running the show, and that adding
fsck.mode=force
to the linux boot line in Grub is now the proper way to force fsck to
run at boot time.
However, though I see that fsck is running when I boot the system after
altering the boot process, there is still no output from the operation
written to the checkroot file. I presume this is part of the rhubarb
I've noticed on various lists concerning the logging of the boot process
when using systemd.
This is hardly a huge problem for me, but I'd like to keep practicing
this slightly OCD behavior if I can on a couple of the more critical
machines.
Would anyone have thoughts on how I can get a record of the file system
check on the boot drive when using systemd?
If there's something about this in the man pages, I'm certainly not
finding it.
Thanks for any pointers you can provide.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/536E9ED8...@comcast.net
I just used
# apt-get install systemd-sysv
on several Debian testing systems (fully up-to-date).
It has been my habit to use
# touch /forcefsck
to force a file system check at reboot once per week on each system and
to keep track of the results by copying the contents of
/var/log/fsck/checkroot into a sort of diary I keep on system maintenance.
In various logs on these systems I see an indication that "touch
/forcefsck" doesn't work with systemd running the show, and that adding
fsck.mode=force
to the linux boot line in Grub is now the proper way to force fsck to
run at boot time.
However, though I see that fsck is running when I boot the system after
altering the boot process, there is still no output from the operation
written to the checkroot file. I presume this is part of the rhubarb
I've noticed on various lists concerning the logging of the boot process
when using systemd.
This is hardly a huge problem for me, but I'd like to keep practicing
this slightly OCD behavior if I can on a couple of the more critical
machines.
Would anyone have thoughts on how I can get a record of the file system
check on the boot drive when using systemd?
If there's something about this in the man pages, I'm certainly not
finding it.
Thanks for any pointers you can provide.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/536E9ED8...@comcast.net
Brandon Vincent
May 10, 2014, 6:50:01 PM5/10/14
to
Jape,
It sounds like the fsck is being conducted while the initramfs is loaded and thus no log is being saved. Ideally, there would be a way to have the console dumped to dmesg.On Sat, May 10, 2014 at 2:49 PM, Jape Person <jap...@comcast.net> wrote:
Hi,
I just used
# apt-get install systemd-sysv
on several Debian testing systems (fully up-to-date).
It has been my habit to use
# touch /forcefsck
to force a file system check at reboot once per week on each system and to keep track of the results by copying the contents of /var/log/fsck/checkroot into a sort of diary I keep on system maintenance.
In various logs on these systems I see an indication that "touch /forcefsck" doesn't work with systemd running the show, and that adding
fsck.mode=force
to the linux boot line in Grub is now the proper way to force fsck to run at boot time.
However, though I see that fsck is running when I boot the system after altering the boot process, there is still no output from the operation written to the checkroot file. I presume this is part of the rhubarb I've noticed on various lists concerning the logging of the boot process when using systemd.
This is hardly a huge problem for me, but I'd like to keep practicing this slightly OCD behavior if I can on a couple of the more critical machines.
Would anyone have thoughts on how I can get a record of the file system check on the boot drive when using systemd?
If there's something about this in the man pages, I'm certainly not finding it.
Thanks for any pointers you can provide.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/536E9ED8...@comcast.net
Jape Person
May 10, 2014, 8:50:01 PM5/10/14
to
I hope you'll excuse me for moving your response to the bottom and then
replying to it there. I think this list prefers bottom posting or,
better yet, interleaved posting.
Thank you for your response.
Yes, I think you're right, though I wasn't bright enough to go in that
direction on my own -- perhaps because the previous system startup
method accomplished the file system check and then wrote the results
after the disk was mounted. Or maybe I'm taking too much for granted in
assuming how it accomplished that. I wonder if there's some reason why
systemd-sysv couldn't do the same thing?
This looks like an oversight to me, but maybe it's deliberate.
I suppose I could boot these systems with a live disc of some type, and
then perform a file system check on the systems' primary disks. That
would be a bit of trouble to go through on the systems that sit in front
of me, and not really practical at all on the remote systems.
I'll mull it over and see if I can figure it out.
Again, thank you for your insight.
Jape
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/536EC324...@comcast.net
Sven Joachim
May 11, 2014, 4:00:01 AM5/11/14
to
On 2014-05-10 23:49 +0200, Jape Person wrote:
> In various logs on these systems I see an indication that "touch
> /forcefsck" doesn't work with systemd running the show, and that
> adding
>
> fsck.mode=force
>
> to the linux boot line in Grub is now the proper way to force fsck to
> run at boot time.
It is true that fsck.mode=force is the recommended way, but the methods
> In various logs on these systems I see an indication that "touch
> /forcefsck" doesn't work with systemd running the show, and that
> adding
>
> fsck.mode=force
>
> to the linux boot line in Grub is now the proper way to force fsck to
> run at boot time.
used by the checkfs.sh initscript are still supported despite the
warning systemd-fsck prints when you use them.
> However, though I see that fsck is running when I boot the system
> after altering the boot process, there is still no output from the
> operation written to the checkroot file. I presume this is part of the
> rhubarb I've noticed on various lists concerning the logging of the
> boot process when using systemd.
logsave(8) which is a kludge to work around the problem that syslog is
not yet available when it runs.
> This is hardly a huge problem for me, but I'd like to keep practicing
> this slightly OCD behavior if I can on a couple of the more critical
> machines.
>
> Would anyone have thoughts on how I can get a record of the file
> system check on the boot drive when using systemd?
out how to get "journalctl -u" to work here.
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Biebl
May 11, 2014, 8:50:02 AM5/11/14
to
Am 11.05.2014 09:35, schrieb Sven Joachim:
> Something like "journalctl -b | grep systemd-fsck". I haven't figured
> out how to get "journalctl -u" to work here.
That, or something like
> Something like "journalctl -b | grep systemd-fsck". I haven't figured
> out how to get "journalctl -u" to work here.
systemctl status systemd-fsck-root.service
or
systemctl status systemd-fsck@<your device>.service
works for me as well.
If you use
systemctl status systemd-fsck@<TAB>
autocompeltion will help you with choosing the right device name, *but*
make sure to properly quote the string, if it contains \, ie. either put
it in "" or use \\ instead of single \.
HTH,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Jape Person
May 11, 2014, 12:40:02 PM5/11/14
to
On 05/11/2014 03:35 AM, Sven Joachim wrote:
> On 2014-05-10 23:49 +0200, Jape Person wrote:
>
>> In various logs on these systems I see an indication that "touch
>> /forcefsck" doesn't work with systemd running the show, and that
>> adding
>>
>> fsck.mode=force
>>
>> to the linux boot line in Grub is now the proper way to force fsck to
>> run at boot time.
>
> It is true that fsck.mode=force is the recommended way, but the methods
> used by the checkfs.sh initscript are still supported despite the
> warning systemd-fsck prints when you use them.
>
Thanks for this information, Sven. I was assuming that the warning
> On 2014-05-10 23:49 +0200, Jape Person wrote:
>
>> In various logs on these systems I see an indication that "touch
>> /forcefsck" doesn't work with systemd running the show, and that
>> adding
>>
>> fsck.mode=force
>>
>> to the linux boot line in Grub is now the proper way to force fsck to
>> run at boot time.
>
> It is true that fsck.mode=force is the recommended way, but the methods
> used by the checkfs.sh initscript are still supported despite the
> warning systemd-fsck prints when you use them.
>
message scrolling by on the screen meant that the file system check was
not actually being run. (More on this later.)
It's nice that it works, because that means I can still initiate the
fsck on remote systems. I'm not sure what I'm going to do if this bit of
backward compatibility gets eliminated before some other means besides
editing the Linux boot line to force the file system check is provided.
I suppose I could just update grub and have the check run every time the
systems are rebooted. It's not like it takes that long for fsck to run.
>> However, though I see that fsck is running when I boot the system
>> after altering the boot process, there is still no output from the
>> operation written to the checkroot file. I presume this is part of the
>> rhubarb I've noticed on various lists concerning the logging of the
>> boot process when using systemd.
>
> Those messages end up in the journal. The initscript captures them with
> logsave(8) which is a kludge to work around the problem that syslog is
> not yet available when it runs.
>
;-)
>> This is hardly a huge problem for me, but I'd like to keep practicing
>> this slightly OCD behavior if I can on a couple of the more critical
>> machines.
>>
>> Would anyone have thoughts on how I can get a record of the file
>> system check on the boot drive when using systemd?
>
> Something like "journalctl -b | grep systemd-fsck". I haven't figured
> out how to get "journalctl -u" to work here.
>
I really need to get into using the standard textual tools that are so
valuable to this operating system.
I'm a tinkerer/hobbyist with GNU/Linux. I use it a lot, but I don't
really work *on* it a lot.
What's funny is that I had examined the journal after using "touch
/forcefsck" by using cat to pipe it to a text file and just searching
with the find function of a text editor. I then stupidly quit looking as
soon as I found the warning message, assuming that the fsck hadn't
actually been run. Because I wasn't using a specific tool like grep
(which would have shown me only what I needed to see) to find what I was
looking for, I just quit.
Then when I tried to run the check by editing the Linux boot line I
(rather dumbly, I admit) just checked /var/log/fsck/checkroot again for
the results instead of going back to the journal.
All around not one of my brighter days.
If I had been a little less tired and a little more assiduous with the
text editor -- or if I'd used the proper tool for searching the journal
in the first place -- I'd have found what I was looking for.
You are an awfully useful person to have around because you help so much
with understanding the process. Many thanks.
> Cheers,
> Sven
Best regards,
Jape
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jape Person
May 11, 2014, 12:50:02 PM5/11/14
to
On 05/11/2014 08:29 AM, Michael Biebl wrote:
> Am 11.05.2014 09:35, schrieb Sven Joachim:
>
>> Something like "journalctl -b | grep systemd-fsck". I haven't figured
>> out how to get "journalctl -u" to work here.
>
> That, or something like
> systemctl status systemd-fsck-root.service
> or
> systemctl status systemd-fsck@<your device>.service
>
> works for me as well.
>
> If you use
> systemctl status systemd-fsck@<TAB>
> autocompeltion will help you with choosing the right device name, *but*
> make sure to properly quote the string, if it contains \, ie. either put
> it in "" or use \\ instead of single \.
>
Yes, indeed, the first of these two commands provided the information I
> Am 11.05.2014 09:35, schrieb Sven Joachim:
>
>> Something like "journalctl -b | grep systemd-fsck". I haven't figured
>> out how to get "journalctl -u" to work here.
>
> That, or something like
> systemctl status systemd-fsck-root.service
> or
> systemctl status systemd-fsck@<your device>.service
>
> works for me as well.
>
> If you use
> systemctl status systemd-fsck@<TAB>
> autocompeltion will help you with choosing the right device name, *but*
> make sure to properly quote the string, if it contains \, ie. either put
> it in "" or use \\ instead of single \.
>
was looking form. I'm going to have to read about systemctl.
The second command didn't seem to provide information about the fsck
output, but I may have been using it improperly.
And I learned something about my terminal emulator that I need to
correct. Apparently tab completion isn't operating on my system.
I'll do a little homework on that. It's obviously a useful tool.
> HTH,
> Michael
>
It does help, Michael. Thanks.
Best regards,
Jape
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jape Person
May 11, 2014, 7:10:01 PM5/11/14
to
"[SOLVED] " to the front of the thread title in case it might be helpful
to anyone scanning the archives for solutions to this problem.
Again, thank you all for your help.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages