Hide Forgot
Description of problem: When a ReiserFS partition is present in /etc/fstab, the system will hard lock (requiring pressing of reset button) when trying to mount them, with a message Mount: Operation not permitted/supported (or something along those lines in English, original line in Spanish: Mount: Operación no soportada). This has happened in both IDE ATAPI drives and S-ATA drives, so S-ATA drivers are not an issue. However, once the system has booted, the partitions can be mounted normally as root from any command prompt. The same happens if the partitions are mounted from the /etc/rc.d/rc.local file, which is processed at the end of the initialization sequence. Even there, the same message appears, and the system locks up. Nothing is responsinve, you can't swtch VT's, or ctrl+alt+del, nothing. Only pressing of the reset button is possible. At the moment I have to disable all the RiserFS partitions using the rescue mode. Also fsck.reiserfs in rescue mode segfaults for some reason at the very end of any check process. Version-Release number of selected component (if applicable): I'm not sure the component at fault here is either the initscripts package, the reiserfs-utils package or the kernel itself. In any case, here are the versions of each: initscripts: initscripts-8.45.3-1 reiserfs-utils: reiserfs-utils-3.6.19-2.4.1 kernel: kernel-2.6.18-1.2798.fc6 How reproducible: Always. Steps to Reproduce: 1. Create a ReiserFS partition and format it as ReiserFS 3.6 2. Add the partition to the /etc/fstab file 3. Reboot. Actual results: The system hard locks, resulting in a needed reboot into rescue mode to disable the partitions from the file. The partitions can be mounted once the system has booted, but not during boot. Expected results: For the partitions to be able to be mounted when the system is booting up. Additional info:
If it's locking the system, that's a kernel issue, not an initscripts issue. Reassigning.
What I don't understand is why after boot, the partitions can be mounted. I'll try with a vanilla kernel and see if the problem is still present there. One question, though. Does the new Fedora Kernel has the extra security flags enabled for ReiserFS by default? (IIRC, the FC5 kernel does not)... Just shot in the dark, but could this problem be due to that?
Confirmed!, the extra attributes present in the Fedora Kernel for the Reiser Filesystem (ReiserFS) are the responsibles for this problem occuring. The only solution I see for now is to remove these extra attributes from the configuration, or to re-format the partitions... Or is there a way to make the partitions use the extra attributes even when they were formatted with a driver which did not have these? I'm trying to find out about this, in the mean time, these are the configuration flags that the official kernel has, that the custom kernel I'm currently running does not: CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y This is the configuration that worked for me: CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y # CONFIG_REISERFS_FS_XATTR is not set So yes, it is a kernel problem, but it may also be a partition's flag problem, so how could I set the proper flag into the partitions to avoid this problem from happening? (Or will I be better off rebuilding the official kernel with those flags disabled?)
Your best bet is to report this upstream (linux-kernel@vger.kernel.org). Introduction of XATTRs should not have prevented mounting non-xattr aware filesystems. As reiserfs is completely unsupported by Fedora, this needs to be brought to the attention of those responsible for its maintainence.
Thank you very much. I'll try to get this to the persons responsible.
Just to add, that upon further investigation this seems to be related to SELinux, and as a quick "workaround" disabling SELinux will allow mounting ReiserFS partitions with the official kernel, with support for XATTR in the RieserFS driver. I'm not sure yet where's the problem, if in SELinux way of tagging the filesystem (as it seems even when the driver supports XATTR an option is passed to mount which is not recognized by the driver, and hence the error). Is there any special options SELinux passes to mount when a filesystem is tagged? If so, which are they?