Description of problem: When installing Mageia and setting up disk partitions of which one or more is encrypted partitions, drakdisk does this and creates a "dependency" which should not exist. When booting the installation of Mageia and selecting NOT to decrypt one or more of the encrypted partitions a bug situation is created. The unnecessary dependency shows up as "failed dependency" during splash screen when booting Mageia. (it shouldn't be a dependency to decrypt all encrypted partitions) When trying to open drakdisk in control center a message the message "this program has exited abnormally" shows up. Further details can be seen by using the terminal to execute drakdisk, and the fuller error message is included below. Version-Release number of selected component (if applicable): Problem has been inherited from Mageia 4 at least, and most likely previous versions as well. I can confirm for certain the same issue is valid in Mageia 4, and I can almost certainly confirm that it is also valid in Mageia 3. How reproducible: 100% for me, should be 100% in general. Steps to Reproduce: 1. Install Mageia and create encrypted partitions 2. Finish installation and start new installation 3. Avoid opening/decrypting one (or more) encrypted partitions during boot 4. When started up, try starting diskdrake (in terminal) This should then happen: [code] Ignore the following Glib::Object::Introspection & Gtk3 warnings Too late to run INIT block at /usr/lib/perl5/vendor_perl/5.20.1/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 257. Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.20.1/Gtk3.pm line 296. [b]device-mapper: table ioctl on crypt_sda11 failed: No such device or address Command failed INTERNAL ERROR: unknown device mapper/crypt_sda11[/b] MDK::Common::Various::internal_error() called from /usr/lib/libDrakX/devices.pm:131 devices::entry() called from /usr/lib/libDrakX/devices.pm:146 devices::make() called from /usr/lib/libDrakX/fs/type.pm:254 fs::type::call_blkid() called from /usr/lib/libDrakX/fs/type.pm:262 fs::type::type_subpart_from_magic() called from /usr/lib/libDrakX/fs/dmcrypt.pm:172 fs::dmcrypt::_get_existing_one() called from /usr/lib/libDrakX/fs/dmcrypt.pm:131 fs::dmcrypt::_get_existing_one_with_state() called from /usr/lib/libDrakX/fs/dmcrypt.pm:59 fs::dmcrypt::read_crypttab_() called from /usr/lib/libDrakX/fs/dmcrypt.pm:71 fs::dmcrypt::read_crypttab() called from /usr/lib/libDrakX/fsedit.pm:96 fsedit::dmcrypts() called from /usr/lib/libDrakX/fsedit.pm:309 fsedit::get_hds() called from /usr/libexec/drakdisk:74 [/code] Its even worse when trying through the control center because it only gives you the message "this program has exited abnormally" which is not very descriptive. In my case above, I have an encrypted partition sda11 that I do not decrypt during boot. This is intentional and as I want it. When I actually decrypt the partition during boot and use it (and all the others) then I do not get this error message when starting drakdisk, so it works normally provided I decrypt all my volumes. This same problem was also valid in Mageia 4 for sure, I have experienced it there as well, before I was really aware what the reason for it was. I think personally that the problem was inherited from Mandriva and that it applies to all Mageia versions. If I understood the reason for the problem, I would try to fix it myself.. It seems to only be in drakx, but could perhaps be deeper. If I do not remember entirely incorrect, this issue actually affects other drak components as well, and gives the same error message when trying to start them up. Not sure about this, but I can vaguely remember that it might have happened to me in the "control center", but I have no idea where. Reproducible: Steps to Reproduce:
Setting version to cauldron, since released iso can no longer be fixed. Putting (MGA5) on the whiteboard, to indicate that was the last Mageia version in which this issue was seen. @ Maximus Can you please attach: /root/drakx/report.bug.xz and also attach: /etc/fstab
Keywords: (none) => NEEDINFOCC: (none) => marja11, thierry.vignaudVersion: 5 => CauldronAssignee: bugsquad => pterjanWhiteboard: (none) => (MGA)
Ok, thanks for your answer. I don't think there is any relevant information in there. Perhaps you can easily try to reproduce the problem instead? I said it was 100% reproducible. You can reproduce it on a separate partition. Kind regards,
(In reply to maximus zeebra from comment #2) > Ok, > > thanks for your answer. > > I don't think there is any relevant information in there. Perhaps you can > easily try to reproduce the problem instead? > I said it was 100% > reproducible. You can reproduce it on a separate partition. > I _cannot_ reproduce it. The laptop I'm using has an encrypted partition that is currently neither decrypted, nor mounted, I have a tiny script to easily decrypt and mount it when I need it, but do usually not do that at all. I've had such a setup since at least a year, but have never seen your problem, never seen "INTERNAL ERROR: unknown device mapper/crypt_sda*". Also, I'm never asked for the password of the encrypted partition while booting into this Mageia install. I have the impression you are. So this is certainly not easily reproducible. I may have done something slightly different in diskdrake in installer. We'll never know if you do not supply the requested information. I very much regret already having assigned this report to our diskdrake man and having CC'ed our drakxtools maintainer. I hate to waste their time. So, for now closing the report as INVALID, because it does not contain the needed information. Please reopen it (by clicking on the drop-down list next to "Status:" at the bottom left of this report, and selecting "REOPENED") when you're ready to supply the information that was asked for in comment 1 If you do not know how to get that information, then please ask in our forums for help first https://forums.mageia.org/en/ Kind regards, Marja
Status: NEW => RESOLVEDResolution: (none) => INVALIDWhiteboard: (MGA) => (MGA5)
My guess is that the difference would be something like "noauto" in the fstab causing it to not be mounted on boot. When it is set to be mounted on boot and that fail, things could be in a bad partial state not handled well (I guess systemd is nowadays what handles the mounting during boot).
(In reply to maximus zeebra from comment #0) Can you please post the contents of /etc/fstab /etc/crypttab This could be the same issue as bug 16248
CC: (none) => doktor5000
(In reply to Pascal Terjan from comment #4) > My guess is that the difference would be something like "noauto" in the > fstab causing it to not be mounted on boot. > When it is set to be mounted on boot and that fail, things could be in a bad > partial state not handled well (I guess systemd is nowadays what handles the > mounting during boot). Well, I do not have it in my fstab here at all and my crypttab is empty. I don't want to use it unless I need it, which is after less than half my boots. However, I do now doubt that I really did what I thought I did during the original install: choose to encrypt the partition in diskdrake in installer and then remove its mountpoint and continue to install. There is a possibility that I had to reboot for the diskdrake step in installer before being able to continue or that I've changed things shortly after that install, without now remembering. I reinstalled Mageia here a month ago and then just chose to not use the encrypted partition, so the original logs are gone :-/
Steps to reproduce: 1. Install Mageia 5 on any computer with the following conditions: - It has a hard drive - Create 3 partitions, 2 encrypted and 1 unencrypted - Use 1 partition as / one encrypted as /home and another encrypted one as /home/userx or /opt - Make sure decryption passwords are different on /home and "/home/userx or /opt" 2. Start the new "STANDARD" installation of Mageia. Type in encryption password for /home, but do NOT type in encryption password for "/home/userx or /opt". Let the system start into X as normal. 3. Your system has now started. You have decrypted /home during startup, but not decrypted your other encrypted partition "/home/userx or /opt". This is when the problem will occur, and it should be 100% reproducible on any PC if you follow these exact steps. - During splash screen there will be a dependency fail due to not decrypting the partition. - Once Mageia is booted into without decrypting "/home/userx or /opt" partition, drakdisk will fail to start with the original error message I put here in the bugreport. - If you decryot both /home and "/home/userx or /opt", drakdisk will work as normal in Mageia I dont have the option to include those logs. I have switched back to Mageia 4 actually, due to some strange HPLIP/CUPS issue I had in Mageia 5.
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
Step2. This ofcourse means pressing ctrl+c to skip decrypting the second partition.
Target Milestone: --- => Mageia 6
(In reply to Pascal Terjan from comment #4) > My guess is that the difference would be something like "noauto" in the > fstab causing it to not be mounted on boot. > When it is set to be mounted on boot and that fail, things could be in a bad > partial state not handled well (I guess systemd is nowadays what handles the > mounting during boot). I want to have the option of decrypting it at boot actually, but I also want to be able not to decrypt it if I want to, without having issues with drakdisk as a result.
Here is the core of the issue from journalctl: Feb 13 15:44:12 ------ systemd-cryptsetup[697]: Invalid passphrase. Feb 13 15:44:12 ------ systemd-cryptsetup[697]: Too many attempts; giving up. Feb 13 15:44:12 ------ systemd[1]: systemd-cryptsetup@crypt_sda11.service: main process exited, code=exited, status=1/FAILURE Feb 13 15:44:12 ------ systemd[1]: Failed to start Cryptography Setup for crypt_sda11. Feb 13 15:44:12 ------ systemd[1]: Dependency failed for Encrypted Volumes. ***** Feb 13 15:44:12 ------ systemd[1]: Dependency failed for dev-mapper-crypt_sda11.device. ***** Feb 13 15:44:12 ------ systemd[1]: Unit systemd-cryptsetup@crypt_sda11.service entered failed state. Feb 13 15:44:12 ------ systemd[1]: systemd-cryptsetup@crypt_sda11.service failed.
If you have partitions listed in /etc/crypttab which have entries in /etc/fstab, which are not encrypted at the time of running diskdrake, then the diskdrake crash is exactly what happens currently was reported already in bug 16248. As you didn't provide contents of fstab or crypttab, marking as duplicate. @Pascal: Only option that I could think of would be some failsafe tests for all entries that are not mounted yet, like "cryptsetup isLuks" and then "cryptsetup luksOpen" or similar for all those partitions that have not been encrypted yet, or if they shouldn't be opened, simply ignore them after telling the user this. At least the diskdrake crash should be prevented, and an understandable error message should be provided to tell the user he needs to decrypt his remaining partitions. *** This bug has been marked as a duplicate of bug 16248 ***
Status: REOPENED => RESOLVEDResolution: (none) => DUPLICATE
This bug is not a duplicate of bug 16248. It is related according to your description and the bug description. This is regarding the reported bug, under standard installation of Mageia and certain user conditions, which crashes drakdisk under normal use on the newly installed system, unless all encrypted disks are decrypted. This doesn't make any sense. And you saying that drakdisk should behave like this, indicate in my opinion that you didn't fully understand my decription of the problem. A user shouldn't have to decrypt all his partitions for diskdrake to function. Unfortunately, I don't have more information than what I have currently given. The problem can be bypassed by removing the entry from fdisk, yes, sure. But that is not the issue. The issue can also be bypassed by not selecting to "use" the disk, during your partition setup in the installer, which also voids writing the entry to fstab. But then it does not allow you the auto option of mounting the encrypted disk during boot. I guess you can say that what I would like to see as a result, is that you can easily void decrypting partitions when you start your systems, without that creating system problems and without crashing diskdrake. Proposed solution: - Remove whatever "dependency" creates the issue in the first place. A system should not depend on all encrypted partitons being decrypted during boot. - Enhance the function at boot which handles decryption of disks, show a better overview and allow disks not to be decrypted during startup, and remove all possible resulting errors of such behaviours. Thanks for taking the time, but please have a little bit more patience the next time, otherwise it takes all the fun out of reporting bugs in the first place. Thanks for all the good work and, Cheers,
Status: RESOLVED => REOPENEDResolution: DUPLICATE => (none)
(In reply to maximus zeebra from comment #12) > This bug is not a duplicate of bug 16248. It is related according to your > description and the bug description. > > > I guess you can say that what I would like to see as a result, is that you > can easily void decrypting partitions when you start your systems, without > that creating system problems and without crashing diskdrake. We're just a bunch of volunteers who make Mageia in our free time. We don't get paid for it. Most (if not all) of the ones that were CC'ed or active in this bug report are active in other Mageia teams, too. We enjoy working on Mageia, but we don't want to be crushed by the workload. There are currently 975 bugs assigned to BugSquad, most of which either need to be assigned to someone who can fix them, or, e.g. when insufficient information was supplied, need to be closed as invalid (unless the reporter is willing to help and give the needed information). There are currently 158 _installer_ bugs that need to be fixed. For traditional installer bugs, report.bug.xz is always needed https://wiki.mageia.org/en/Triage_guide#Traditional_installer Additionally, for this bug the contents of /etc/fstab /etc/crypttab are needed too. The contents of those 3 files increases the chance that a developer can pinpoint how which steps led to this bug, and do something about it. Please be as kind as to reproduce the issue and attach the requested files.
(In reply to maximus zeebra from comment #12) > This is regarding the reported bug, under standard installation of Mageia > and certain user conditions, which crashes drakdisk under normal use on the > newly installed system, unless all encrypted disks are decrypted. Which is exactly what bug 16248 is about - diskdrake crashes when not all partitions are decrypted. It _is_ a duplicate. And I've never said that diskdrake should behave like this, on the contrary - this crash is exactly why I reported bug 16248 on behlaf of another user. And simply adding another bugreport for this just makes no sense. Adding more bugreports won't fix issues faster. Decryption of disks is handled via systemd, if you want anything improved in the handling during boot then please request that upstream : https://github.com/systemd/systemd/issues *** This bug has been marked as a duplicate of bug 16248 ***