Where is fsck run?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
6
down vote

favorite
2












enter image description hereI was reading through all the things that are run during bootup and have seen that after mounting the rootfs, /sbin/fsck.ext4 is run and after that systemd is run. I was wondering where or how fsck is run, because I was searching for it in the kernel source code and couldn't find it and its not part of the init scripts. So what runs fsck? The distro I am using is mint.



EDIT: In this image it is shown that fsck is run after mounting the root file sytem







share|improve this question





















  • Possibly related: unix.stackexchange.com/a/400927/126755
    – Vlastimil
    Jun 28 at 4:25










  • Note that van Smoorenburg rc scripts are not the places to look for an fsck run after systemd. unix.stackexchange.com/a/236968/5132
    – JdeBP
    Jun 28 at 14:59














up vote
6
down vote

favorite
2












enter image description hereI was reading through all the things that are run during bootup and have seen that after mounting the rootfs, /sbin/fsck.ext4 is run and after that systemd is run. I was wondering where or how fsck is run, because I was searching for it in the kernel source code and couldn't find it and its not part of the init scripts. So what runs fsck? The distro I am using is mint.



EDIT: In this image it is shown that fsck is run after mounting the root file sytem







share|improve this question





















  • Possibly related: unix.stackexchange.com/a/400927/126755
    – Vlastimil
    Jun 28 at 4:25










  • Note that van Smoorenburg rc scripts are not the places to look for an fsck run after systemd. unix.stackexchange.com/a/236968/5132
    – JdeBP
    Jun 28 at 14:59












up vote
6
down vote

favorite
2









up vote
6
down vote

favorite
2






2





enter image description hereI was reading through all the things that are run during bootup and have seen that after mounting the rootfs, /sbin/fsck.ext4 is run and after that systemd is run. I was wondering where or how fsck is run, because I was searching for it in the kernel source code and couldn't find it and its not part of the init scripts. So what runs fsck? The distro I am using is mint.



EDIT: In this image it is shown that fsck is run after mounting the root file sytem







share|improve this question













enter image description hereI was reading through all the things that are run during bootup and have seen that after mounting the rootfs, /sbin/fsck.ext4 is run and after that systemd is run. I was wondering where or how fsck is run, because I was searching for it in the kernel source code and couldn't find it and its not part of the init scripts. So what runs fsck? The distro I am using is mint.



EDIT: In this image it is shown that fsck is run after mounting the root file sytem









share|improve this question












share|improve this question




share|improve this question








edited Jun 28 at 17:14
























asked Jun 27 at 23:37









systolicDrake

505




505











  • Possibly related: unix.stackexchange.com/a/400927/126755
    – Vlastimil
    Jun 28 at 4:25










  • Note that van Smoorenburg rc scripts are not the places to look for an fsck run after systemd. unix.stackexchange.com/a/236968/5132
    – JdeBP
    Jun 28 at 14:59
















  • Possibly related: unix.stackexchange.com/a/400927/126755
    – Vlastimil
    Jun 28 at 4:25










  • Note that van Smoorenburg rc scripts are not the places to look for an fsck run after systemd. unix.stackexchange.com/a/236968/5132
    – JdeBP
    Jun 28 at 14:59















Possibly related: unix.stackexchange.com/a/400927/126755
– Vlastimil
Jun 28 at 4:25




Possibly related: unix.stackexchange.com/a/400927/126755
– Vlastimil
Jun 28 at 4:25












Note that van Smoorenburg rc scripts are not the places to look for an fsck run after systemd. unix.stackexchange.com/a/236968/5132
– JdeBP
Jun 28 at 14:59




Note that van Smoorenburg rc scripts are not the places to look for an fsck run after systemd. unix.stackexchange.com/a/236968/5132
– JdeBP
Jun 28 at 14:59










2 Answers
2






active

oldest

votes

















up vote
5
down vote



accepted










Edit 2: checked sources



I've found the ubuntu initramfs-tools sources. Here you can see clearly, the Begin: "Mounting root file system" message is printed first, but in the mount_root function fsck is run before the actual mounting. I have ommited some non-relevant code, just to indicate the order. (If you would inspect the linked sources you will find also the other reported scripts from the screenshot).



/init line 256



log_begin_msg "Mounting root file system"
# Always load local and nfs (since these might be needed for /etc or
# /usr, irrespective of the boot script used to mount the rootfs).
. /scripts/local
. /scripts/nfs
. /scripts/$BOOT
parse_numeric $ROOT
maybe_break mountroot
mount_top
mount_premount
mountroot
log_end_msg


/scripts/local @line 244



mountroot()

local_mount_root



/scripts/local @line 131



local_mount_root()




Original answer, retained for historical reasons



Two options:



  1. Root is mounted read-only during boot and the init implementation is running fsck. Systemd is the init implementation on mint, and since you already checked if it exists there, this option does not apply.


  2. /sbin/fsck.ext4 is run in the "early user space", set up by an initramfs. Which is most probably the case in your system.

Systemd



Even if you noticed that /sbin/fsck.ext4 was run before systemd, I want tot elaborate a bit. Systemd is perfectly capable of running fsck itself, on a read-only mounted filesystem. See systemd-fsck@.service documentation. Most probably this service is not enabled by default in mint, since it will be redundant with the early user space one.



Initramfs



I don't know which implementation of an initramfs mint is running, but I will use dracut as an example. (used in Debian, openSuse and more) It states the following in its mount preperation documentation:




When the root file system finally becomes visible:




  • Any maintenance tasks which cannot run on a mounted root file system are done.

  • The root file system is mounted read-only.

  • Any processes which must continue running (such as the rd.splash screen helper and its command FIFO) are hoisted into the newly-mounted
    root file system.



And maintenance tasks includes fsck. Further evidence, there is a possibility in dracut cmdline options to switch off fsck:




rd.skipfsck



skip fsck for rootfs and /usr. If you’re mounting /usr read-only and the init system performs fsck before remount, you might
want to use this option to avoid duplication




Implementations of initramfs



An dynamic (udev based) and flexible initramfs can be implemented using the systemd infrastructure. Dracut is such an implementation and probably there are distro's out there that want to write their own.



Another option would be a script based initramfs. In such a case busybox ash is used as a scripting shell and maybe even replacing udev with mdev, or maybe just completely static. I found some people being dropped to a busybox shell due to some fsck error int mint, so this implementation could apply to mint.



If you really want to know for sure, try to decompress the initramfs file in /boot and see what's in there. It might also be possible to see it mounted under /initramfs.






share|improve this answer























  • dracut is available in Debian, but it isn’t used by default; Debian uses initramfs-tools. The general principle is the same.
    – Stephen Kitt
    Jul 1 at 20:54

















up vote
1
down vote














systemd-fsck@.service and systemd-fsck-root.service are services responsible for file system checks. They are instantiated for each device that is configured for file system checking. systemd-fsck-root.service is responsible for file system checks on the root file system, but only if the root filesystem was not checked in the initramfs. systemd-fsck@.service is used for all other file systems and for the root file system in the initramfs.




https://www.freedesktop.org/software/systemd/man/systemd-fsck@.service.html



It sounds like you also might be interested in this:



https://www.freedesktop.org/software/systemd/man/bootup.html






share|improve this answer





















  • The question is talking about the fsck on the root filesystem that is run from the initramfs before executing /sbin/init//lib/sytemd/systemd.
    – JdeBP
    Jun 28 at 7:47






  • 2




    The bootup link does contain some additional background info. dracut (mentioned in my asnwer) is in fact an implementation of a systemd based initramfs
    – Tim
    Jun 28 at 7:54











  • The question is both under & over constrained. It asks where fsck is run, not specifically fsck of the rootfs. And it says that the root is fscked after being mounted - however, if you use e.g. dracut to mount the root filesystem, the fsck will happen before the root is mounted. It is fair to say that not everyone uses dracut though and they may use initramfs implementations which do not use systemd. (Also that most people do use an initramfs, I think I had not explicitly considered this, as i say because it conflicted with the question).
    – sourcejedi
    Jun 28 at 8:39










  • You're overthinking the question. The questioner knows that fsck is run. On many systems one can see that happen, after all. Xe does not necessarily know when it is run relative to the mount, since that is part of what xe is asking about, so allow for that to be wrong. But xe is looking in the kernel code and in the rc scripts, and thus we can deduce that xe doesn't know to also look at the initramfs, or realize that there is early filesystem checking done there.
    – JdeBP
    Jun 28 at 15:03










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f452321%2fwhere-is-fsck-run%23new-answer', 'question_page');

);

Post as a guest






























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
5
down vote



accepted










Edit 2: checked sources



I've found the ubuntu initramfs-tools sources. Here you can see clearly, the Begin: "Mounting root file system" message is printed first, but in the mount_root function fsck is run before the actual mounting. I have ommited some non-relevant code, just to indicate the order. (If you would inspect the linked sources you will find also the other reported scripts from the screenshot).



/init line 256



log_begin_msg "Mounting root file system"
# Always load local and nfs (since these might be needed for /etc or
# /usr, irrespective of the boot script used to mount the rootfs).
. /scripts/local
. /scripts/nfs
. /scripts/$BOOT
parse_numeric $ROOT
maybe_break mountroot
mount_top
mount_premount
mountroot
log_end_msg


/scripts/local @line 244



mountroot()

local_mount_root



/scripts/local @line 131



local_mount_root()




Original answer, retained for historical reasons



Two options:



  1. Root is mounted read-only during boot and the init implementation is running fsck. Systemd is the init implementation on mint, and since you already checked if it exists there, this option does not apply.


  2. /sbin/fsck.ext4 is run in the "early user space", set up by an initramfs. Which is most probably the case in your system.

Systemd



Even if you noticed that /sbin/fsck.ext4 was run before systemd, I want tot elaborate a bit. Systemd is perfectly capable of running fsck itself, on a read-only mounted filesystem. See systemd-fsck@.service documentation. Most probably this service is not enabled by default in mint, since it will be redundant with the early user space one.



Initramfs



I don't know which implementation of an initramfs mint is running, but I will use dracut as an example. (used in Debian, openSuse and more) It states the following in its mount preperation documentation:




When the root file system finally becomes visible:




  • Any maintenance tasks which cannot run on a mounted root file system are done.

  • The root file system is mounted read-only.

  • Any processes which must continue running (such as the rd.splash screen helper and its command FIFO) are hoisted into the newly-mounted
    root file system.



And maintenance tasks includes fsck. Further evidence, there is a possibility in dracut cmdline options to switch off fsck:




rd.skipfsck



skip fsck for rootfs and /usr. If you’re mounting /usr read-only and the init system performs fsck before remount, you might
want to use this option to avoid duplication




Implementations of initramfs



An dynamic (udev based) and flexible initramfs can be implemented using the systemd infrastructure. Dracut is such an implementation and probably there are distro's out there that want to write their own.



Another option would be a script based initramfs. In such a case busybox ash is used as a scripting shell and maybe even replacing udev with mdev, or maybe just completely static. I found some people being dropped to a busybox shell due to some fsck error int mint, so this implementation could apply to mint.



If you really want to know for sure, try to decompress the initramfs file in /boot and see what's in there. It might also be possible to see it mounted under /initramfs.






share|improve this answer























  • dracut is available in Debian, but it isn’t used by default; Debian uses initramfs-tools. The general principle is the same.
    – Stephen Kitt
    Jul 1 at 20:54














up vote
5
down vote



accepted










Edit 2: checked sources



I've found the ubuntu initramfs-tools sources. Here you can see clearly, the Begin: "Mounting root file system" message is printed first, but in the mount_root function fsck is run before the actual mounting. I have ommited some non-relevant code, just to indicate the order. (If you would inspect the linked sources you will find also the other reported scripts from the screenshot).



/init line 256



log_begin_msg "Mounting root file system"
# Always load local and nfs (since these might be needed for /etc or
# /usr, irrespective of the boot script used to mount the rootfs).
. /scripts/local
. /scripts/nfs
. /scripts/$BOOT
parse_numeric $ROOT
maybe_break mountroot
mount_top
mount_premount
mountroot
log_end_msg


/scripts/local @line 244



mountroot()

local_mount_root



/scripts/local @line 131



local_mount_root()




Original answer, retained for historical reasons



Two options:



  1. Root is mounted read-only during boot and the init implementation is running fsck. Systemd is the init implementation on mint, and since you already checked if it exists there, this option does not apply.


  2. /sbin/fsck.ext4 is run in the "early user space", set up by an initramfs. Which is most probably the case in your system.

Systemd



Even if you noticed that /sbin/fsck.ext4 was run before systemd, I want tot elaborate a bit. Systemd is perfectly capable of running fsck itself, on a read-only mounted filesystem. See systemd-fsck@.service documentation. Most probably this service is not enabled by default in mint, since it will be redundant with the early user space one.



Initramfs



I don't know which implementation of an initramfs mint is running, but I will use dracut as an example. (used in Debian, openSuse and more) It states the following in its mount preperation documentation:




When the root file system finally becomes visible:




  • Any maintenance tasks which cannot run on a mounted root file system are done.

  • The root file system is mounted read-only.

  • Any processes which must continue running (such as the rd.splash screen helper and its command FIFO) are hoisted into the newly-mounted
    root file system.



And maintenance tasks includes fsck. Further evidence, there is a possibility in dracut cmdline options to switch off fsck:




rd.skipfsck



skip fsck for rootfs and /usr. If you’re mounting /usr read-only and the init system performs fsck before remount, you might
want to use this option to avoid duplication




Implementations of initramfs



An dynamic (udev based) and flexible initramfs can be implemented using the systemd infrastructure. Dracut is such an implementation and probably there are distro's out there that want to write their own.



Another option would be a script based initramfs. In such a case busybox ash is used as a scripting shell and maybe even replacing udev with mdev, or maybe just completely static. I found some people being dropped to a busybox shell due to some fsck error int mint, so this implementation could apply to mint.



If you really want to know for sure, try to decompress the initramfs file in /boot and see what's in there. It might also be possible to see it mounted under /initramfs.






share|improve this answer























  • dracut is available in Debian, but it isn’t used by default; Debian uses initramfs-tools. The general principle is the same.
    – Stephen Kitt
    Jul 1 at 20:54












up vote
5
down vote



accepted







up vote
5
down vote



accepted






Edit 2: checked sources



I've found the ubuntu initramfs-tools sources. Here you can see clearly, the Begin: "Mounting root file system" message is printed first, but in the mount_root function fsck is run before the actual mounting. I have ommited some non-relevant code, just to indicate the order. (If you would inspect the linked sources you will find also the other reported scripts from the screenshot).



/init line 256



log_begin_msg "Mounting root file system"
# Always load local and nfs (since these might be needed for /etc or
# /usr, irrespective of the boot script used to mount the rootfs).
. /scripts/local
. /scripts/nfs
. /scripts/$BOOT
parse_numeric $ROOT
maybe_break mountroot
mount_top
mount_premount
mountroot
log_end_msg


/scripts/local @line 244



mountroot()

local_mount_root



/scripts/local @line 131



local_mount_root()




Original answer, retained for historical reasons



Two options:



  1. Root is mounted read-only during boot and the init implementation is running fsck. Systemd is the init implementation on mint, and since you already checked if it exists there, this option does not apply.


  2. /sbin/fsck.ext4 is run in the "early user space", set up by an initramfs. Which is most probably the case in your system.

Systemd



Even if you noticed that /sbin/fsck.ext4 was run before systemd, I want tot elaborate a bit. Systemd is perfectly capable of running fsck itself, on a read-only mounted filesystem. See systemd-fsck@.service documentation. Most probably this service is not enabled by default in mint, since it will be redundant with the early user space one.



Initramfs



I don't know which implementation of an initramfs mint is running, but I will use dracut as an example. (used in Debian, openSuse and more) It states the following in its mount preperation documentation:




When the root file system finally becomes visible:




  • Any maintenance tasks which cannot run on a mounted root file system are done.

  • The root file system is mounted read-only.

  • Any processes which must continue running (such as the rd.splash screen helper and its command FIFO) are hoisted into the newly-mounted
    root file system.



And maintenance tasks includes fsck. Further evidence, there is a possibility in dracut cmdline options to switch off fsck:




rd.skipfsck



skip fsck for rootfs and /usr. If you’re mounting /usr read-only and the init system performs fsck before remount, you might
want to use this option to avoid duplication




Implementations of initramfs



An dynamic (udev based) and flexible initramfs can be implemented using the systemd infrastructure. Dracut is such an implementation and probably there are distro's out there that want to write their own.



Another option would be a script based initramfs. In such a case busybox ash is used as a scripting shell and maybe even replacing udev with mdev, or maybe just completely static. I found some people being dropped to a busybox shell due to some fsck error int mint, so this implementation could apply to mint.



If you really want to know for sure, try to decompress the initramfs file in /boot and see what's in there. It might also be possible to see it mounted under /initramfs.






share|improve this answer















Edit 2: checked sources



I've found the ubuntu initramfs-tools sources. Here you can see clearly, the Begin: "Mounting root file system" message is printed first, but in the mount_root function fsck is run before the actual mounting. I have ommited some non-relevant code, just to indicate the order. (If you would inspect the linked sources you will find also the other reported scripts from the screenshot).



/init line 256



log_begin_msg "Mounting root file system"
# Always load local and nfs (since these might be needed for /etc or
# /usr, irrespective of the boot script used to mount the rootfs).
. /scripts/local
. /scripts/nfs
. /scripts/$BOOT
parse_numeric $ROOT
maybe_break mountroot
mount_top
mount_premount
mountroot
log_end_msg


/scripts/local @line 244



mountroot()

local_mount_root



/scripts/local @line 131



local_mount_root()




Original answer, retained for historical reasons



Two options:



  1. Root is mounted read-only during boot and the init implementation is running fsck. Systemd is the init implementation on mint, and since you already checked if it exists there, this option does not apply.


  2. /sbin/fsck.ext4 is run in the "early user space", set up by an initramfs. Which is most probably the case in your system.

Systemd



Even if you noticed that /sbin/fsck.ext4 was run before systemd, I want tot elaborate a bit. Systemd is perfectly capable of running fsck itself, on a read-only mounted filesystem. See systemd-fsck@.service documentation. Most probably this service is not enabled by default in mint, since it will be redundant with the early user space one.



Initramfs



I don't know which implementation of an initramfs mint is running, but I will use dracut as an example. (used in Debian, openSuse and more) It states the following in its mount preperation documentation:




When the root file system finally becomes visible:




  • Any maintenance tasks which cannot run on a mounted root file system are done.

  • The root file system is mounted read-only.

  • Any processes which must continue running (such as the rd.splash screen helper and its command FIFO) are hoisted into the newly-mounted
    root file system.



And maintenance tasks includes fsck. Further evidence, there is a possibility in dracut cmdline options to switch off fsck:




rd.skipfsck



skip fsck for rootfs and /usr. If you’re mounting /usr read-only and the init system performs fsck before remount, you might
want to use this option to avoid duplication




Implementations of initramfs



An dynamic (udev based) and flexible initramfs can be implemented using the systemd infrastructure. Dracut is such an implementation and probably there are distro's out there that want to write their own.



Another option would be a script based initramfs. In such a case busybox ash is used as a scripting shell and maybe even replacing udev with mdev, or maybe just completely static. I found some people being dropped to a busybox shell due to some fsck error int mint, so this implementation could apply to mint.



If you really want to know for sure, try to decompress the initramfs file in /boot and see what's in there. It might also be possible to see it mounted under /initramfs.







share|improve this answer















share|improve this answer



share|improve this answer








edited Jun 29 at 6:26


























answered Jun 28 at 5:03









Tim

463211




463211











  • dracut is available in Debian, but it isn’t used by default; Debian uses initramfs-tools. The general principle is the same.
    – Stephen Kitt
    Jul 1 at 20:54
















  • dracut is available in Debian, but it isn’t used by default; Debian uses initramfs-tools. The general principle is the same.
    – Stephen Kitt
    Jul 1 at 20:54















dracut is available in Debian, but it isn’t used by default; Debian uses initramfs-tools. The general principle is the same.
– Stephen Kitt
Jul 1 at 20:54




dracut is available in Debian, but it isn’t used by default; Debian uses initramfs-tools. The general principle is the same.
– Stephen Kitt
Jul 1 at 20:54












up vote
1
down vote














systemd-fsck@.service and systemd-fsck-root.service are services responsible for file system checks. They are instantiated for each device that is configured for file system checking. systemd-fsck-root.service is responsible for file system checks on the root file system, but only if the root filesystem was not checked in the initramfs. systemd-fsck@.service is used for all other file systems and for the root file system in the initramfs.




https://www.freedesktop.org/software/systemd/man/systemd-fsck@.service.html



It sounds like you also might be interested in this:



https://www.freedesktop.org/software/systemd/man/bootup.html






share|improve this answer





















  • The question is talking about the fsck on the root filesystem that is run from the initramfs before executing /sbin/init//lib/sytemd/systemd.
    – JdeBP
    Jun 28 at 7:47






  • 2




    The bootup link does contain some additional background info. dracut (mentioned in my asnwer) is in fact an implementation of a systemd based initramfs
    – Tim
    Jun 28 at 7:54











  • The question is both under & over constrained. It asks where fsck is run, not specifically fsck of the rootfs. And it says that the root is fscked after being mounted - however, if you use e.g. dracut to mount the root filesystem, the fsck will happen before the root is mounted. It is fair to say that not everyone uses dracut though and they may use initramfs implementations which do not use systemd. (Also that most people do use an initramfs, I think I had not explicitly considered this, as i say because it conflicted with the question).
    – sourcejedi
    Jun 28 at 8:39










  • You're overthinking the question. The questioner knows that fsck is run. On many systems one can see that happen, after all. Xe does not necessarily know when it is run relative to the mount, since that is part of what xe is asking about, so allow for that to be wrong. But xe is looking in the kernel code and in the rc scripts, and thus we can deduce that xe doesn't know to also look at the initramfs, or realize that there is early filesystem checking done there.
    – JdeBP
    Jun 28 at 15:03














up vote
1
down vote














systemd-fsck@.service and systemd-fsck-root.service are services responsible for file system checks. They are instantiated for each device that is configured for file system checking. systemd-fsck-root.service is responsible for file system checks on the root file system, but only if the root filesystem was not checked in the initramfs. systemd-fsck@.service is used for all other file systems and for the root file system in the initramfs.




https://www.freedesktop.org/software/systemd/man/systemd-fsck@.service.html



It sounds like you also might be interested in this:



https://www.freedesktop.org/software/systemd/man/bootup.html






share|improve this answer





















  • The question is talking about the fsck on the root filesystem that is run from the initramfs before executing /sbin/init//lib/sytemd/systemd.
    – JdeBP
    Jun 28 at 7:47






  • 2




    The bootup link does contain some additional background info. dracut (mentioned in my asnwer) is in fact an implementation of a systemd based initramfs
    – Tim
    Jun 28 at 7:54











  • The question is both under & over constrained. It asks where fsck is run, not specifically fsck of the rootfs. And it says that the root is fscked after being mounted - however, if you use e.g. dracut to mount the root filesystem, the fsck will happen before the root is mounted. It is fair to say that not everyone uses dracut though and they may use initramfs implementations which do not use systemd. (Also that most people do use an initramfs, I think I had not explicitly considered this, as i say because it conflicted with the question).
    – sourcejedi
    Jun 28 at 8:39










  • You're overthinking the question. The questioner knows that fsck is run. On many systems one can see that happen, after all. Xe does not necessarily know when it is run relative to the mount, since that is part of what xe is asking about, so allow for that to be wrong. But xe is looking in the kernel code and in the rc scripts, and thus we can deduce that xe doesn't know to also look at the initramfs, or realize that there is early filesystem checking done there.
    – JdeBP
    Jun 28 at 15:03












up vote
1
down vote










up vote
1
down vote










systemd-fsck@.service and systemd-fsck-root.service are services responsible for file system checks. They are instantiated for each device that is configured for file system checking. systemd-fsck-root.service is responsible for file system checks on the root file system, but only if the root filesystem was not checked in the initramfs. systemd-fsck@.service is used for all other file systems and for the root file system in the initramfs.




https://www.freedesktop.org/software/systemd/man/systemd-fsck@.service.html



It sounds like you also might be interested in this:



https://www.freedesktop.org/software/systemd/man/bootup.html






share|improve this answer














systemd-fsck@.service and systemd-fsck-root.service are services responsible for file system checks. They are instantiated for each device that is configured for file system checking. systemd-fsck-root.service is responsible for file system checks on the root file system, but only if the root filesystem was not checked in the initramfs. systemd-fsck@.service is used for all other file systems and for the root file system in the initramfs.




https://www.freedesktop.org/software/systemd/man/systemd-fsck@.service.html



It sounds like you also might be interested in this:



https://www.freedesktop.org/software/systemd/man/bootup.html







share|improve this answer













share|improve this answer



share|improve this answer











answered Jun 28 at 7:09









sourcejedi

18k22375




18k22375











  • The question is talking about the fsck on the root filesystem that is run from the initramfs before executing /sbin/init//lib/sytemd/systemd.
    – JdeBP
    Jun 28 at 7:47






  • 2




    The bootup link does contain some additional background info. dracut (mentioned in my asnwer) is in fact an implementation of a systemd based initramfs
    – Tim
    Jun 28 at 7:54











  • The question is both under & over constrained. It asks where fsck is run, not specifically fsck of the rootfs. And it says that the root is fscked after being mounted - however, if you use e.g. dracut to mount the root filesystem, the fsck will happen before the root is mounted. It is fair to say that not everyone uses dracut though and they may use initramfs implementations which do not use systemd. (Also that most people do use an initramfs, I think I had not explicitly considered this, as i say because it conflicted with the question).
    – sourcejedi
    Jun 28 at 8:39










  • You're overthinking the question. The questioner knows that fsck is run. On many systems one can see that happen, after all. Xe does not necessarily know when it is run relative to the mount, since that is part of what xe is asking about, so allow for that to be wrong. But xe is looking in the kernel code and in the rc scripts, and thus we can deduce that xe doesn't know to also look at the initramfs, or realize that there is early filesystem checking done there.
    – JdeBP
    Jun 28 at 15:03
















  • The question is talking about the fsck on the root filesystem that is run from the initramfs before executing /sbin/init//lib/sytemd/systemd.
    – JdeBP
    Jun 28 at 7:47






  • 2




    The bootup link does contain some additional background info. dracut (mentioned in my asnwer) is in fact an implementation of a systemd based initramfs
    – Tim
    Jun 28 at 7:54











  • The question is both under & over constrained. It asks where fsck is run, not specifically fsck of the rootfs. And it says that the root is fscked after being mounted - however, if you use e.g. dracut to mount the root filesystem, the fsck will happen before the root is mounted. It is fair to say that not everyone uses dracut though and they may use initramfs implementations which do not use systemd. (Also that most people do use an initramfs, I think I had not explicitly considered this, as i say because it conflicted with the question).
    – sourcejedi
    Jun 28 at 8:39










  • You're overthinking the question. The questioner knows that fsck is run. On many systems one can see that happen, after all. Xe does not necessarily know when it is run relative to the mount, since that is part of what xe is asking about, so allow for that to be wrong. But xe is looking in the kernel code and in the rc scripts, and thus we can deduce that xe doesn't know to also look at the initramfs, or realize that there is early filesystem checking done there.
    – JdeBP
    Jun 28 at 15:03















The question is talking about the fsck on the root filesystem that is run from the initramfs before executing /sbin/init//lib/sytemd/systemd.
– JdeBP
Jun 28 at 7:47




The question is talking about the fsck on the root filesystem that is run from the initramfs before executing /sbin/init//lib/sytemd/systemd.
– JdeBP
Jun 28 at 7:47




2




2




The bootup link does contain some additional background info. dracut (mentioned in my asnwer) is in fact an implementation of a systemd based initramfs
– Tim
Jun 28 at 7:54





The bootup link does contain some additional background info. dracut (mentioned in my asnwer) is in fact an implementation of a systemd based initramfs
– Tim
Jun 28 at 7:54













The question is both under & over constrained. It asks where fsck is run, not specifically fsck of the rootfs. And it says that the root is fscked after being mounted - however, if you use e.g. dracut to mount the root filesystem, the fsck will happen before the root is mounted. It is fair to say that not everyone uses dracut though and they may use initramfs implementations which do not use systemd. (Also that most people do use an initramfs, I think I had not explicitly considered this, as i say because it conflicted with the question).
– sourcejedi
Jun 28 at 8:39




The question is both under & over constrained. It asks where fsck is run, not specifically fsck of the rootfs. And it says that the root is fscked after being mounted - however, if you use e.g. dracut to mount the root filesystem, the fsck will happen before the root is mounted. It is fair to say that not everyone uses dracut though and they may use initramfs implementations which do not use systemd. (Also that most people do use an initramfs, I think I had not explicitly considered this, as i say because it conflicted with the question).
– sourcejedi
Jun 28 at 8:39












You're overthinking the question. The questioner knows that fsck is run. On many systems one can see that happen, after all. Xe does not necessarily know when it is run relative to the mount, since that is part of what xe is asking about, so allow for that to be wrong. But xe is looking in the kernel code and in the rc scripts, and thus we can deduce that xe doesn't know to also look at the initramfs, or realize that there is early filesystem checking done there.
– JdeBP
Jun 28 at 15:03




You're overthinking the question. The questioner knows that fsck is run. On many systems one can see that happen, after all. Xe does not necessarily know when it is run relative to the mount, since that is part of what xe is asking about, so allow for that to be wrong. But xe is looking in the kernel code and in the rc scripts, and thus we can deduce that xe doesn't know to also look at the initramfs, or realize that there is early filesystem checking done there.
– JdeBP
Jun 28 at 15:03












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f452321%2fwhere-is-fsck-run%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

Peggy Mitchell

Palaiologos

The Forum (Inglewood, California)