I am using kernel 2.6.39-hardened-r6 and I am getting segmentation fault message upon boot up for the portion of mounting filesystems. The filesystems do not fail to mount, however. And this has no ill effect on my system that I can see. My fstab is mounting boot(sda1),root(sda2),cdrom, and tmpfs. All sda* filesystems are Ext4(built into the kernel, not module) with options discard(trim for sdd drive), noatime, defaults. I made sure the CD Rom was empty. I had /selinux mounting but I disabled it(commented it out) to make sure this was not the cause, and it wasn't. A initramfs is used and built into the kernel, but this only contains software for Uvesa console graphics. Reproducible: Always Steps to Reproduce: 1.Boot up 2.Mounting Portion of boot up 3.Segmentation fault of message 4.Filesystems seem to mount anyways Actual Results: Filesystems mount successfully, however 'Segmentation Fault message' is given for the mounting portion of boot up. Expected Results: No Segmentation Fault message I just upgraded the kernel, so I believe this is one of the reasons to be the root cause. Other reason, the ext4 is built into the kernel so the more obvious reason. Although the system seems to not be effected by this, I marked this critical because of the possibility of data lose or corruption on a lower level that would not be obvious.
emerge --info? Do you have a dmesg somewhere? It may show what segfaulted. Also does the segfault occure before or after OpenRC has started?
Created attachment 280547 [details] emerge --info, fstab, /proc/mounts/, and kernel .config
Above URL is a picture of the boot up screen. Here is another picture, a close up, of the boot up screen: http://img.photobucket.com/albums/v66/dman777/IMG_20110721_141621.jpg Attached is the system info. My system isn't complete yet, so I had to do this from paste bin copied into windows notepad...so it may have the extra carriage return control characters. *Please not that even though I have selinux commmented out, it looks like it still shows mounted in /proc/mounts.
also, forgot to wgetpaste while in my linux system but i did a dmesg | grep -i seg and this error message did not show. if a dmesg is needed i will come back and post it.
Created attachment 280549 [details] Attached is the dmesg
(In reply to comment #3) > *Please not that even though I have selinux commmented out, it looks like it > still shows mounted in /proc/mounts. That is IIRC because OpenRC always mounts it if selinux is enabled in kernel. Since you do not have grsec activated in your kernel and the logging of segfaults it provides (and I cannot remember if and how you can get segfault-logging from the vanilla-options), I have no idea about what crashes, but since it is while OpenRC tries to mount the local file-systems, I would guess at a mount.* helper. However everything seems to get mounted as it should...
If it is the case that Selinux is mounting anyways, could this be the cause of the segmentation fault? The reason why I ask is I upgraded my system and one of the selinux libraries would not recompile because of python. Then someone told me to upgrade swig which is a wrapper for the library which allows it to interface/compile with the most python 3.*(can remember the exact ver). This was a success and the selinux library(can't remember the library name but it had to with selinux manage tools).
When you're booted, can you try umounting and mounting the non-vital locations to see which could be the cause of the segmentation fault? I've had a segfault a while back when udev mounted /dev, but that would've shown quite early in the boot process (not at the location where you are at). My initial idea is that it is as the /tmp mount, so ~# umount /tmp ~# mount -a See if that triggers the segmentation fault again.
segmentation fault comes when I want to encrypt a partition with luksFormat. This is the same problem when this bug was first filed in 2009. It makes me upset that the patch was never placed in the ebuild thus not being maintained, although now the patch doesn't seem to work when I used to be able to use it in the past.
Sorry, please disregard the above. I thought this was for bug #283470 in which there is a segmentation fault for crypsetup. The problem with this particular bug is that I had permissions set to 1777 in fstab for the tmpfs /tmp. When I took those permission away for the /tmp then the segmentation faults stopped.
There's indeed a problem related to this, see bug #373381
*** This bug has been marked as a duplicate of bug 373381 ***
