After upgrading to Mageia 2 the boot is very long (about 3 minutes) I click on ESC to see the messages (verbose mode) and it hangs in the "Started /home/" (screenshot) The message after this is: "Dependency failed. Aborted start of Cryptography Setup for crypt_sdb1" I dont have any encrypted partition.
Created attachment 2376 [details] Screenshot with the hang
Created attachment 2377 [details] boot.log
In the mageia discuss mailing list, i was suggested from David W. Hodgins to delete the "/etc/crypttab" file and run "dracut -f" This have solved the problem
I'm curious about how you did the installation, as the file should not have been created, unless you are using an encrypted filesystem, unless you used to have an encrypted filesystem, but have since removed it, without cleaning up that file.
CC: (none) => davidwhodgins
I dont have the information when it was created, actualy for testing i did nt delete the file but i renamed: [dglent@localhost etc]$ cat crypttab.bak crypt_sdb1 UUID=d423df2e-38e8-4b5e-98f1-f996b97523b0 [dglent@localhost etc]$ ls -la crypttab.bak -rw-rw-r-- 1 root root 53 May 20 2011 crypttab.bak Is there enything else thay we could retreive from the file ? I ve never used encryption in my system.
Attachment 2377 mime type: text/x-log => text/plain
Summary: Long hang on boot => Long hang on boot (encrypted home)
Based on the contents of the file, at some time in the past, sdb1 was an encrypted filesystem, likely created using diskdrake. If some other partitioning tool was later used to change it to a non-encrypted filesystem, that would be why the crypttab entry was left. I think, when dracut is creating the initrd, it should check /etc/crypttab entries and ignore them if the device they point to either doesn't exist, or blkid doesn't return TYPE="crypto_LUKS", and generate a warning message. Adding Colin to the cc list, and setting the rpm to dracut.
CC: (none) => mageiaSource RPM: (none) => dracut-017-16.mga2.src.rpm
Created attachment 2410 [details] Output of /var/log/syslog of the 1 June Today i had a freeze in my system, i could nt move even the mouse, i mogged out with CTRL+ALT+BACKSPACE and i relogged in without succes. The system was freezed after a few seconds when i saw the wallpaper in my desktop. I see in the /var/log/syslog a message about encryption: "Jun 1 07:22:59 localhost udisksd[3675]: Error opening /etc/crypttab file: Failed to open file '/etc/crypttab': No such file or directory (g-file-error-quark, 4)"
You can ignore the message from udisksd. It's normal. There is a bug report requesting that the messages be removed, but they should be considered information messages only. The only think I can see in the syslog, is the general protection fault near the beginning, but there should be more lines before that, that would help indicate where the gpf is happening. As the gpf has nothing to do with dracut ignoring invalid crypttab entries, please open a new bug about the gpf, and attach the syslog output starting from around 30 lines before where this one starts, up to the line that contains X server for display :0 terminated unexpectedly
Ok, done: https://bugs.mageia.org/show_bug.cgi?id=6285
Personall(In reply to comment #6) > Based on the contents of the file, at some time in the past, sdb1 > was an encrypted filesystem, likely created using diskdrake. > > If some other partitioning tool was later used to change it to > a non-encrypted filesystem, that would be why the crypttab entry > was left. This seems like a good analysis to me. > I think, when dracut is creating the initrd, it should check > /etc/crypttab entries and ignore them if the device they point > to either doesn't exist, or blkid doesn't return TYPE="crypto_LUKS", > and generate a warning message. > > Adding Colin to the cc list, and setting the rpm to dracut. Hmm, I'm not sure here. I'm struggling to disagree with the sentiment, but there are lots of ways in which an enterprising user could confuse dracut here, not just in crypttab. I'll see what upstream say, but is it worth keeping this downstream bug open in the mean time?
As comment 3 indicates the specific case was solved, and it's really a configuration error, not a problem most users will encounter, I'll go ahead and close the bug. I understand the complexity of dracut, and checking for every possible configuration error is outside of it's current scope. It would be nice if it could, but can't really be considered a bug, that it doesn't, yet :-).
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME