Where is fsck run?

Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
I 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
kernel systemd init fsck sysvinit
add a comment |Â
up vote
6
down vote
favorite
I 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
kernel systemd init fsck sysvinit
Possibly related: unix.stackexchange.com/a/400927/126755
â Vlastimil
Jun 28 at 4:25
Note that van Smoorenburgrcscripts are not the places to look for anfsckrun after systemd. unix.stackexchange.com/a/236968/5132
â JdeBP
Jun 28 at 14:59
add a comment |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I 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
kernel systemd init fsck sysvinit
I 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
kernel systemd init fsck sysvinit
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 Smoorenburgrcscripts are not the places to look for anfsckrun after systemd. unix.stackexchange.com/a/236968/5132
â JdeBP
Jun 28 at 14:59
add a comment |Â
Possibly related: unix.stackexchange.com/a/400927/126755
â Vlastimil
Jun 28 at 4:25
Note that van Smoorenburgrcscripts are not the places to look for anfsckrun 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
add a comment |Â
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:
- 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. /sbin/fsck.ext4is 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.
dracutis available in Debian, but it isnâÂÂt used by default; Debian usesinitramfs-tools. The general principle is the same.
â Stephen Kitt
Jul 1 at 20:54
add a comment |Â
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
The question is talking about thefsckon 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 thatfsckis 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 thercscripts, 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
add a comment |Â
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:
- 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. /sbin/fsck.ext4is 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.
dracutis available in Debian, but it isnâÂÂt used by default; Debian usesinitramfs-tools. The general principle is the same.
â Stephen Kitt
Jul 1 at 20:54
add a comment |Â
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:
- 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. /sbin/fsck.ext4is 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.
dracutis available in Debian, but it isnâÂÂt used by default; Debian usesinitramfs-tools. The general principle is the same.
â Stephen Kitt
Jul 1 at 20:54
add a comment |Â
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:
- 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. /sbin/fsck.ext4is 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.
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:
- 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. /sbin/fsck.ext4is 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.
edited Jun 29 at 6:26
answered Jun 28 at 5:03
Tim
463211
463211
dracutis available in Debian, but it isnâÂÂt used by default; Debian usesinitramfs-tools. The general principle is the same.
â Stephen Kitt
Jul 1 at 20:54
add a comment |Â
dracutis available in Debian, but it isnâÂÂt used by default; Debian usesinitramfs-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
add a comment |Â
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
The question is talking about thefsckon 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 thatfsckis 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 thercscripts, 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
add a comment |Â
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
The question is talking about thefsckon 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 thatfsckis 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 thercscripts, 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
add a comment |Â
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
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
answered Jun 28 at 7:09
sourcejedi
18k22375
18k22375
The question is talking about thefsckon 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 thatfsckis 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 thercscripts, 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
add a comment |Â
The question is talking about thefsckon 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 thatfsckis 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 thercscripts, 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
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Possibly related: unix.stackexchange.com/a/400927/126755
â Vlastimil
Jun 28 at 4:25
Note that van Smoorenburg
rcscripts are not the places to look for anfsckrun after systemd. unix.stackexchange.com/a/236968/5132â JdeBP
Jun 28 at 14:59