RO File System after adding Nut & DPI

Support
#1

NethServer Version: 7.5.1804 (final)
Module: nut-2.7.2-4.el7.x86_64, nethserver-nut-1.3.2-1.ns7.noarch, nut-client-2.7.2-4.el7.x86_64
nethserver-ndpi-1.1.2-1.ns7.noarch, kmod-xt_ndpi-2.0.4-1.ns7.x86_64
kernel-3.10.0-862.11.6.el7.x86_64, kernel-3.10.0-514.26.2.el7.x86_64

Active kernel: kernel-3.10.0-514.26.2.el7.x86_64
If we run the later kernel the lv_root partition is mounted ro switch back to older kernel and it is rw. The partition was rw before adding nut and dpi modules. Note DPI is not running under the kernel-3.10.0-514.26.2.el7.x86_64

ro_FileSystem
ro_FileSystem.png1030×569 43.7 KB

before_update
older_kernel
older_kernel.png691×84 5.62 KB

Any attempt to update fully results in ro file system. It does appear to be the dpi rather than nut as is working. Of coarse when the system boots a ro we do not get any logs.:woozy_face:

#2

@support_team
Any ideas?

#3

Try to boot with a previous kernel. Therefore, do a full update.

#4

I guess you are upgrading from 7.4 to 7.5.

Usually the ro filesystem happens when wrong filesystem options are set inside the fstab.
Reboot with the old kernel and past the output of:

  • config show fstab
  • cat /etc/fstab

The fstab configuration should be something like:

[root@test ~]# config show fstab 
fstab=configuration
    /=defaults
1 Like
#5

Michael Yes we did this twice and result the same. Actually reinstated the working image and tried the update again. When that went RO, repeated the exercise but this time only added nut and dpi. Again the system came up RO. Finally rebooted to the earlier kernel. No DPI but was working and so was nut.

Gaicomo: fstab is default as is config. They are the settings that are working on the older (current) kernel. If we update without DPI and then reinstall? Have not seen this issue on systems apart from needing the reboot to load the DPI supporting kernel. So a little difficult to replicate and this system is downstream of a satellite connection.

#6

As Giacomo stated, this is usually an invalid fstab option. I have had to manually edit mine after something changed in CentOS and an update broke the system in a similar fashion.

That it was a valid and working config in the previous version, doesn’t really count in this case. Not sure which option I removed, I’ll try to find it.

#7
#8

I’m pretty sure that RO filesystem doesn’t depend on NDPI module.

Please, inspect the messages, you should be able to find the cause.

#9

Thanks all

Looks like it was the acl,user_xattr setting in the lv_root line in the fstab.

Is this something that was in an earlier kernel that has now been dropped?

#10

Yes: in the previous kernel both options were ignored if already supported by the filesystem.