Hi, What do the following systemd messages mean, particularly the fstab ones about the specified address not being a device, particularly when the specified addresses have been mounted via fstab?
[ 69.310393] systemd-fstab-generator[1889]: Checking was requested for "192.168.1.12:/mnt/HD/HD_a2", but it is not a device. [ 69.314850] systemd-sysv-generator[1899]: SysV service '/etc/rc.d/init.d/livesys' lacks a native systemd unit file, automatically generating a unit file for compatibility. [ 69.314854] systemd-sysv-generator[1899]: Please update package to include a native systemd unit file. [ 69.314856] systemd-sysv-generator[1899]: ! This compatibility logic is deprecated, expect removal soon. ! [ 69.314881] systemd-sysv-generator[1899]: SysV service '/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file, automatically generating a unit file for compatibility. [ 69.314886] systemd-sysv-generator[1899]: Please update package to include a native systemd unit file. [ 69.314888] systemd-sysv-generator[1899]: ! This compatibility logic is deprecated, expect removal soon. ! [ 70.822449] systemd-fstab-generator[1889]: Checking was requested for "//192.168.1.12/Volume_1", but it is not a device. [
regards, Steve
Am 18.03.2025 um 09:02:25 Uhr schrieb Stephen Morris:
[ 69.310393] systemd-fstab-generator[1889]: Checking was requested for "192.168.1.12:/mnt/HD/HD_a2", but it is not a device.
Please post /etc/fstab and check the last number in the line.
The sixth field (fs_passno). This field is used by fsck(8) to determine the order in which filesystem checks are done at boot time. The root filesystem should be specified with a fs_passno of 1. Other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. Defaults to zero (don’t check the filesystem) if not present.
It makes no sense for me to check NFS file systems from the remote.
On 18/3/25 17:45, Marco Moock wrote:
Am 18.03.2025 um 09:02:25 Uhr schrieb Stephen Morris:
[ 69.310393] systemd-fstab-generator[1889]: Checking was requested for "192.168.1.12:/mnt/HD/HD_a2", but it is not a device.
Please post /etc/fstab and check the last number in the line.
The sixth field (fs_passno). This field is used by fsck(8) to determine the order in which filesystem checks are done at boot time. The root filesystem should be specified with a fs_passno of 1. Other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. Defaults to zero (don’t check the filesystem) if not present.It makes no sense for me to check NFS file systems from the remote.
That message is for an nfs network device while the same message at the bottom is for the cifs interface to the same device, but why is it saying that they are not a device when they were successfully mounted. Having said this though I was trying to use this as a safeguard against the device not "talking" causing, as it has done in the past, other mounts to not be done.
regards, Steve
Am 19.03.2025 um 09:17:58 Uhr schrieb Stephen Morris:
On 18/3/25 17:45, Marco Moock wrote:
Am 18.03.2025 um 09:02:25 Uhr schrieb Stephen Morris:
[ 69.310393] systemd-fstab-generator[1889]: Checking was requested for "192.168.1.12:/mnt/HD/HD_a2", but it is not a device.
Please post /etc/fstab and check the last number in the line.
The sixth field (fs_passno). This field is used by fsck(8) to determine the order inwhich filesystem checks are done at boot time. The root filesystem should be specified with a fs_passno of 1. Other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. Defaults to zero (don’t check the filesystem) if not present.
It makes no sense for me to check NFS file systems from the remote.
That message is for an nfs network device while the same message at the bottom is for the cifs interface to the same device, but why is it saying that they are not a device when they were successfully mounted. Having said this though I was trying to use this as a safeguard against the device not "talking" causing, as it has done in the past, other mounts to not be done.
The message is a bit arbitrary, but checking a network file system from the remote is not intended IIRC, so disable the file system check option in fstab. Do the checks on the remote system.
On Wed, 2025-03-19 at 07:57 +0100, Marco Moock wrote:
That message is for an nfs network device while the same message at the bottom is for the cifs interface to the same device, but why is it saying that they are not a device when they were successfully mounted. Having said this though I was trying to use this as a safeguard against the device not "talking" causing, as it has done in the past, other mounts to not be done.
The message is a bit arbitrary, but checking a network file system from the remote is not intended IIRC, so disable the file system check option in fstab. Do the checks on the remote system.
Although the message is not as clear as it might be, it's still a big no-no to try to run fsck on *any* mounted filesystem, local or remote. Given that remote implies mounted, that's enough reason for the error.
poc
On Wed, 2025-03-19 at 07:57 +0100, Marco Moock wrote:
The message is a bit arbitrary, but checking a network file system from the remote is not intended IIRC, so disable the file system check option in fstab. Do the checks on the remote system.
Patrick O'Callaghan:
Although the message is not as clear as it might be, it's still a big no-no to try to run fsck on *any* mounted filesystem, local or remote. Given that remote implies mounted, that's enough reason for the error.
Even if you were just doing a validity check, and no attempts at repairs, would remote access through NFS even be feasible to something like that filesystem check?
I would thought the NFS handler would act more as a barrier, than acting as a bridge to make it appear seamlessly like local device access.
*From:* Patrick O'Callaghan pocallaghan@gmail.com
*Sent:* Wednesday, 19 March 2025 at 20:31 UTC+11
*To:* users@lists.fedoraproject.org
*Subject:* RE: Strange Systemd Messages
On Wed, 2025-03-19 at 07:57 +0100, Marco Moock wrote:
That message is for an nfs network device while the same message at the bottom is for the cifs interface to the same device, but why is it saying that they are not a device when they were successfully mounted. Having said this though I was trying to use this as a safeguard against the device not "talking" causing, as it has done in the past, other mounts to not be done.
The message is a bit arbitrary, but checking a network file system from the remote is not intended IIRC, so disable the file system check option in fstab. Do the checks on the remote system.
Although the message is not as clear as it might be, it's still a big no-no to try to run fsck on *any* mounted filesystem, local or remote. Given that remote implies mounted, that's enough reason for the error.
From what I've been able to determine the remote system doesn't appear to provide checking functionality, so adding checking options on to the device entries in fstab was the only way I could see to prevent the device being unavailable from terminating the fstab process at the mount of that device as has happened numerous times in the past. I should not have to put the mount of the device at the end of fstab for mounts that are specified after it in fstab to be actioned. Just on the checking topic, what is the difference between checking a device on your machine and a network device that is semi-local, ie: attached to my local router. As far as I am concerned they are both the same.
regards, Steve
poc
On Thu, 2025-03-20 at 05:06 +1030, Tim via users wrote:
On Wed, 2025-03-19 at 07:57 +0100, Marco Moock wrote:
The message is a bit arbitrary, but checking a network file system from the remote is not intended IIRC, so disable the file system check option in fstab. Do the checks on the remote system.
Patrick O'Callaghan:
Although the message is not as clear as it might be, it's still a big no-no to try to run fsck on *any* mounted filesystem, local or remote. Given that remote implies mounted, that's enough reason for the error.
Even if you were just doing a validity check, and no attempts at repairs, would remote access through NFS even be feasible to something like that filesystem check?
I would thought the NFS handler would act more as a barrier, than acting as a bridge to make it appear seamlessly like local device access.
IMHO it makes no sense. NFS provides filesystem-level access, but fsck needs actual physical device access to check that the filesystem structure is valid. NFS will just believe what the superblock on the remote system says, but has no way to check that it's correct.
A Google search shows that fsck.nfs (referenced by the fsck man page) did apparently exist about 20 years ago, but was essentially a dummy and is not in Fedora. The man page should maybe be updated.
poc
On Thu, 2025-03-20 at 08:36 +1100, Stephen Morris wrote:
*From:* Patrick O'Callaghan pocallaghan@gmail.com
*Sent:* Wednesday, 19 March 2025 at 20:31 UTC+11
*To:* users@lists.fedoraproject.org
*Subject:* RE: Strange Systemd Messages
On Wed, 2025-03-19 at 07:57 +0100, Marco Moock wrote:
That message is for an nfs network device while the same message at the bottom is for the cifs interface to the same device, but why is it saying that they are not a device when they were successfully mounted. Having said this though I was trying to use this as a safeguard against the device not "talking" causing, as it has done in the past, other mounts to not be done.
The message is a bit arbitrary, but checking a network file system from the remote is not intended IIRC, so disable the file system check option in fstab. Do the checks on the remote system.
Although the message is not as clear as it might be, it's still a big no-no to try to run fsck on *any* mounted filesystem, local or remote. Given that remote implies mounted, that's enough reason for the error.
From what I've been able to determine the remote system doesn't appear to provide checking functionality, so adding checking options on to the device entries in fstab was the only way I could see to prevent the device being unavailable from terminating the fstab process at the mount of that device as has happened numerous times in the past. I should not have to put the mount of the device at the end of fstab for mounts that are specified after it in fstab to be actioned.
There are mount options to prevent the process hanging when a remote server fails to respond quickly. See mount(8).
Just on the checking topic, what is the difference between checking a device on your machine and a network device that is semi-local, ie: attached to my local router. As far as I am concerned they are both the same.
The difference is that the remote is not a device, it's a filesystem. They are definitely not the same. fsck needs direct physical access to the hardware device, and that's not what NFS provides.
NFS (and Samba) try to present remote filesystems as being equivalent to local ones and that usually works, but they have different failure modes, e.g. a local disk going offline unexpectedly is a serious error, but a remote filesystem not responding quickly may or may not be a problem. As the old saying goes, "You can't tell down from disconnected".
poc
-
Marco Moock -
Patrick O'Callaghan -
Stephen Morris -
Tim