[Bug 980303] New: openSUSE Leap 42.1 has boot issues with encrypted partitions on NVMe after updates
http://bugzilla.suse.com/show_bug.cgi?id=980303 Bug ID: 980303 Summary: openSUSE Leap 42.1 has boot issues with encrypted partitions on NVMe after updates Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: sebastian.parschauer@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- When installing openSUSE Leap 42.1 on an NVMe SSD with encrypted home without networking, booting it, setting up networking, installing updates and rebooting, then nothing asks for the decryption password any more. The boot continues directly to asking for the user name and login password which of cause fails as the home partition isn't decrypted yet. It happens with the default setup with btrfs on / with encryped XFS /home and also with ext4 on /. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=980303
http://bugzilla.suse.com/show_bug.cgi?id=980303#c1
--- Comment #1 from Sebastian Parschauer
http://bugzilla.suse.com/show_bug.cgi?id=980303
http://bugzilla.suse.com/show_bug.cgi?id=980303#c2
Sebastian Parschauer
http://bugzilla.suse.com/show_bug.cgi?id=980303
http://bugzilla.suse.com/show_bug.cgi?id=980303#c3
Hannes Reinecke
http://bugzilla.suse.com/show_bug.cgi?id=980303
http://bugzilla.suse.com/show_bug.cgi?id=980303#c4
Sebastian Parschauer
http://bugzilla.suse.com/show_bug.cgi?id=980303
http://bugzilla.suse.com/show_bug.cgi?id=980303#c5
--- Comment #5 from Sebastian Parschauer
http://bugzilla.suse.com/show_bug.cgi?id=980303
http://bugzilla.suse.com/show_bug.cgi?id=980303#c6
Thomas Blume
Well. We've had similar reports here (bug#944132, bug#928391), so I'm surprised they haven't been ported to Leap... However, I really would think this is the wrong way to handle it. Thing is, NVMe devices should be using the eui name provided by the NVMe device itself, and not rely on the (fake) SCSI ID to be present. The SCSI ID one can be compiled out (it's been moved to a module), so you might end up with an NVMe device which does _not_ provide a SCSI interface at all.
Oops, this was a mistake from another commit which was a bit too aggressive. Meanwhile upstream has added nvme support. Upstream commit: 427a28ecbe0eb170e651e0530ab58d6e6f6c498c shows: -->-- +# NVMe +KERNEL=="nvme*[0-9]n*[0-9]", ATTR{wwid}=="?*", SYMLINK+="disk/by-id/nvme-$attr{wwid}" +KERNEL=="nvme*[0-9]n*[0-9]p*[0-9]", ENV{DEVTYPE}=="partition", ATTRS{wwid}=="?*", SYMLINK+="disk/by-id/nvme-$attr{wwid}-part%n" + --<-- Hannes, is this the eui you've mentioned? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=980303
Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=980303
http://bugzilla.suse.com/show_bug.cgi?id=980303#c14
--- Comment #14 from Bernhard Wiedemann
http://bugzilla.suse.com/show_bug.cgi?id=980303
http://bugzilla.suse.com/show_bug.cgi?id=980303#c15
--- Comment #15 from Swamp Workflow Management
participants (1)
-
bugzilla_noreply@novell.com