Bugzilla – Bug 1094963
Opensuse 15.0 installation or upgrade fails if disk contains encrypted partition LUKS
Last modified: 2019-04-26 09:50:20 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build Identifier: You can proceed with the install until the moment where it asks you for existin LUKS partition password. WHen password is provided yast shows error and advises to report a bug Reproducible: Always Steps to Reproduce: 1. Have an existing encrypted LUKS parition 2. Launch Opensuse Leap 15.0 installation with Install or Upgrade option 3. Pass all the steps until the one where you are prompted to provide LUKS password Actual Results: Error message Expected Results: Ability to use and mount the existing partition Log file can be uploaded
Created attachment 771626 [details] yast_log_file for install error for LUKS
Probed devicegraph (01-probed.yml from the attached y2logs tarball): # 2018-05-28 09:23:31 +0200 --- - disk: name: "/dev/sda" size: 40 GiB block_size: 0.5 KiB io_size: 0 B min_grain: 1 MiB align_ofs: 0 B partition_table: msdos mbr_gap: 1 MiB partitions: - free: size: 1 MiB start: 0 B - partition: size: 2054 MiB (2.01 GiB) start: 1 MiB name: "/dev/sda1" type: primary id: swap file_system: swap - partition: size: 12480 MiB (12.19 GiB) start: 2055 MiB (2.01 GiB) name: "/dev/sda2" type: primary id: linux file_system: xfs - partition: size: 16719 MiB (16.33 GiB) start: 14535 MiB (14.19 GiB) name: "/dev/sda3" type: primary id: linux file_system: xfs encryption: type: luks name: "/dev/mapper/cr-auto-1" - partition: size: 9706 MiB (9.48 GiB) start: 31254 MiB (30.52 GiB) name: "/dev/sda4" type: primary id: linux file_system: xfs
From the y2log: 2018-05-28 09:23:43 <1> install(3471) [Ruby] modules/RootPart.rb:1116 mounting /dev/mapper/cr_ata-VBOX_HARDDISK_VB355f98fa-3fd6ea5a-part3 to /home 2018-05-28 09:23:43 <3> install(3471) [libstorage] BlkDevice.cc:49 THROW: device not found, name:/dev/mapper/cr_ata-VBOX_HARDDISK_VB355f98fa-3fd6ea5a-part3 2018-05-28 09:23:43 <1> install(3471) [Ruby] y2storage/devicegraph.rb:333 Device nil found by its libstorage-ng name /dev/mapper/cr_ata-VBOX_HARDDISK_VB355f98fa-3fd6ea5a-part3 2018-05-28 09:23:44 <3> install(3471) [libstorage] SystemCmd.cc:97 THROW: command '/sbin/udevadm info '/dev/mapper/cr_ata-VBOX_HARDDISK_VB355f98fa-3fd6ea5a-part3'' failed: stderr: Unknown device, --name=, --path=, or absolute path in /dev/ or /sys expected. exit code: 4
From 01-probed.xml: <Luks> <sid>48</sid> <name>/dev/mapper/cr-auto-1</name> <sysfs-name>dm-0</sysfs-name> <sysfs-path>/devices/virtual/block/dm-0</sysfs-path> <region> <length>34236416</length> <block-size>512</block-size> </region> <dm-table-name>cr-auto-1</dm-table-name> <mount-by>device</mount-by> <in-etc-crypttab>false</in-etc-crypttab> <uuid>d01e6a0c-46c1-4ce0-8f30-103984bc2d6f</uuid> </Luks> So it appears that this LUKS was not in /etc/crypttab (?); not sure if this contributed to the problem.
The LUKS could successfully be opened with "cryptsetup", and "dmsetup table" and "blkid" showed it correctly: 2018-05-28 09:23:29 <1> install(3471) [libstorage] SystemCmd.cc:186 SystemCmd Executing: "/sbin/cryptsetup --batch-mode luksOpen '/dev/sda3' 'cr-auto-1' --tries 1 --key-file -" ... Returns:0 2018-05-28 09:23:30 <1> install(3471) [libstorage] SystemCmd.cc:186 SystemCmd Executing: "/sbin/dmsetup table" -> "cr-auto-1: 0 34236416 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:3 4096" Returns:0 2018-05-28 09:23:30 <1> install(3471) [libstorage] SystemCmd.cc:186 SystemCmd Executing: "/sbin/blkid -c '/dev/null'" -> ... "/dev/mapper/cr-auto-1: UUID="2b7823b8-a8b0-443a-9e81-b7b1bd6f51e8" TYPE="xfs"" Returns:0
One problem appears to be the different /dev/mapper names. It looks like in the old system, it was /dev/mapper/cr_ata-VBOX_HARDDISK_VB355f98fa-3fd6ea5a-part3, and in the new system, it would become /dev/mapper/cr-auto-1 : Hardware probing with "blkid": 2018-05-28 09:23:20 <1> install(3471) [libstorage] SystemCmd.cc:186 SystemCmd Executing:"/sbin/blkid -c '/dev/null'" /dev/sda1: UUID="51e570af-2ff8-41b0-91eb-2e9025190e5e" TYPE="swap" /dev/sda2: UUID="8d1dca84-8509-4da9-bc74-0adcca709fe0" TYPE="xfs" /dev/sda3: UUID="d01e6a0c-46c1-4ce0-8f30-103984bc2d6f" TYPE="crypto_LUKS" /dev/sda4: UUID="6c9da8e5-cc2b-4300-86ea-a87b976026cf" TYPE="xfs" /dev/sr0: UUID="2018-05-16-17-45-22-53" LABEL="openSUSE-Leap-15.0-DVD-x86_64267" Reading the old /etc/fstab: 2018-05-28 09:23:37 <1> install(3471) [Ruby] modules/RootPart.rb:901 fstab: [ $[ "file":"swap", "freq":0, "mntops":"defaults", "passno":0, "spec":"UUID=51e570af-2ff8-41b0-91eb-2e9025190e5e", "vfstype":"swap" ], $[ "file":"/", "freq":1, "mntops":"defaults", "passno":1, "spec":"UUID=8d1dca84-8509-4da9-bc74-0adcca709fe0", "vfstype":"xfs" ], $[ "file":"/home", "freq":0, "mntops":"nofail", "passno":2, "spec":"/dev/mapper/cr_ata-VBOX_HARDDISK_VB355f98fa-3fd6ea5a-part3", "vfstype":"xfs" ], $[ "file":"/mnt/additional", "freq":1, "mntops":"defaults", "passno":2, "spec":"UUID=6c9da8e5-cc2b-4300-86ea-a87b976026cf", "vfstype":"xfs" ] ]
Right now it's just a gut feeling (which we will have to investigate further), but I have the impression that there is a disconnect between the old /etc/fstab where that devicemapper device is called /dev/mapper/cr_ata-VBOX_HARDDISK_VB355f98fa-3fd6ea5a-part3, the missing old /etc/crypttab that should contain the information which devicemapper device this actually refers to, and the new devicemapper device as the current kernel (the one loaded from the installation media) uses (/dev/mapper/cr-auto-1), so for some of the commands that old name seems to be used, but that device is now unknown to the current kernel. I have the impression that this LUKS was created a long time ago by a very old SUSE release where the kernel used a completely different naming scheme, and the transition from that old naming scheme to the current one was somehow lost during multiple generations of SUSE releases and the corresponding kernels.
(In reply to Stefan Hundhammer from comment #7) > I have the impression that this LUKS was created a long time ago by a very > old SUSE release where the kernel used a completely different naming scheme, > and the transition from that old naming scheme to the current one was > somehow lost during multiple generations of SUSE releases and the > corresponding kernels. Forget that part: In the past, we did not support creating LUKS encryption containers without LVM - not LUKS on a plain partition as used here.
Created attachment 771714 [details] y2log-12sp3.gz Installation logs for a fresh SLE 12-SP3 installation with an analog partition schema as mentioned in the report.
Created attachment 771715 [details] y2log-15_after_encryption_password_prompt.tar.xz After starting a SLE 15 installation, and being asked for the encryption password, everything works as expected. Assuming that SLE12 migration to SLE15 is not affected by this scenario. Trying now migration from Leap 42.3 to Leap 15.
I am able to reproduce it on my laptop with lvm and also on a VM with streight partition. For both cases I am almost sure I have done the fresh install not longer than march 2016
Created attachment 771719 [details] y2log-Leap42.3.gz Fresh Leap 42.3 installation with analog partition schema.
Created attachment 771720 [details] y2log-Leap15_after_encryption_password_prompt.tar.xz Not able to reproduce.
The name of the device mapper table for the LUKS device is defined by the user, /etc/crypttab or whoever activates it. (Note: the logs mention cryptotab which is obsolete for many years.) When the LUKS device is activated the content of /etc/crypttab is in general not yet known (think of /etc being placed on the LUKS device itself). Thus the code generates a arbitrary name, cr-auto-1 in this case. So for the kernel and libstorage-ng the device is known as /dev/mapper/cr-auto-1 but not as cr_ata-VBOX_HARDDISK_VB355f98fa-3fd6ea5a-part3 as found in the fstab. AFAIS the update code has to read crypttab and lookup the underlying device of cr_ata-VBOX_HARDDISK_VB355f98fa-3fd6ea5a-part3 and then use the device name known to the kernel. BTW: Using UUIDs to identify LUKSes would likely also solve the issue. This is done for new installation of e.g. openSUSE Leap 15.0.
I know wanted to gather yast log for the physical(laptop) upgrade failure. I use lvm and Luka encrypted home partition. It fails with the same defect so it accepts password , displays currently installed leap 42.3 and stops with an error prompt encouraging to launch yast debugger. No matter which option I choose it freezes several seconds after not allowing me to copy the results of save_yastlog from /tmp to another place. Switching terminal with alt or ctelalt +F1 2 or 7 does nothing...
outputs of: cat /etc/fstab ; parted -l; cat /etc/crypttab; below in case it gives more explenation: cat /etc/fstab UUID=3b34086d-f56d-449d-aaec-d961ac852755 swap swap defaults 0 0 /dev/vg1/mainos / ext4 acl,user_xattr 1 1 /dev/mapper/cr_mainhome /home Model: ATA Crucial_CT250MX2 (scsi) Disk /dev/sdb: 250GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 43,0GB 43,0GB primary boot, lvm, type=8e 2 43,0GB 250GB 207GB extended lba, type=0f 5 43,0GB 248GB 205GB logical lvm, type=8e 6 248GB 250GB 1612MB logical linux-swap(v1) type=82 7 250GB 250GB 552MB logical xfs type=83 Model: Linux device-mapper (crypt) (dm) Disk /dev/mapper/cr_mainhome: 183GB Sector size (logical/physical): 512B/4096B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0,00B 183GB 183GB xfs Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/vg1-os3: 32,2GB Sector size (logical/physical): 512B/4096B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0,00B 32,2GB 32,2GB xfs Error: /dev/mapper/vg1-mainhome: unrecognised disk label Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/vg1-mainhome: 183GB Sector size (logical/physical): 512B/4096B Partition Table: unknown Disk Flags: Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/vg1-mainos: 33,1GB Sector size (logical/physical): 512B/4096B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0,00B 33,1GB 33,1GB ext4 cat /etc/crypttab cr_mainhome /dev/vg1/mainhome none none
No idea what's different in your setup vs. Sergio's attempt to reproduce this. This might be a tough nut to crack.
Moving to our SCRUM task queue for the time being.
maybe the parted -l result "Error: /dev/mapper/vg1-mainhome: unrecognised disk label Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/vg1-mainhome: 183GB Sector size (logical/physical): 512B/4096B Partition Table: unknown" is something to catch on? Anything else (any log or stat) I could provide from my Leap42.3 to make the troubleshooting easier/ The bad part is that when the upgrade failed on the VM that I mentioned before i tried zypper dup that made the system totally unusable - not even login screen appeared. So the only way to upgrade the system seems to be clean install
A volume group should not have a disk label (a partition table), so this is not a problem AFAICS.
Created attachment 771803 [details] y2log from physical machine After booting installator in text mode the install did not freeze so I was able to gather y2logs and attache it here
I think the code https://github.com/yast/yast-update/blob/master/src/modules/RootPart.rb#L1525 should be updated and reenabled.
*** Bug 1095678 has been marked as a duplicate of this bug. ***
*** Bug 1095685 has been marked as a duplicate of this bug. ***
*** Bug 1096693 has been marked as a duplicate of this bug. ***
I think with so many duplicate bug reports on this one it is now clear it is not only my "strange" partition/LUKS setup. I understand it takes time to troubleshoot and even more time to fix but my questions is - what is the strategy for deploying the fix ? Should we (the affected ones) hope to get a re-spin of 15.0 ISO with patched installer or we should rather forget about upgrading to 15.0 and wait for 15.1?
(In reply to Sebastian Turzański from comment #26) > I think with so many duplicate bug reports on this one it is now clear it is > not only my "strange" partition/LUKS setup. > > I understand it takes time to troubleshoot and even more time to fix but my > questions is - what is the strategy for deploying the fix ? > Should we (the affected ones) hope to get a re-spin of 15.0 ISO with patched > installer or we should rather forget about upgrading to 15.0 and wait for > 15.1? YaST installer performs a self-update when starting. I guess it will be possible to apply that fixes by passing a repository url as boot parameter, but I cannot confirm it. Anyway, we are already working in the fix for this bug.
Big thank you to HuHa, Arvin and everyone else looking into this! Also affected by this during attempted upgrade from fresh 42.3 Install with encrypted /home to 15.0, no LVM however. I can confirm Arvin's analysis, in my case it tries to use /dev/mapper/cr_home but there is only /dev/mapper/cr-auto-1.
This bug is fixed with yast2-storage-ng >= 4.0.187 and yast2-update >= 4.0.16. Now, encryption devices can be found by its name on crypttab file. PR: https://github.com/yast/yast-storage-ng/pull/659/files PR: https://github.com/yast/yast-update/pull/101/files
*** Bug 1096960 has been marked as a duplicate of this bug. ***
(In reply to Knut Alejandro Anderssen González from comment #30) > *** Bug 1096960 has been marked as a duplicate of this bug. *** Notice that Bug 1096960 hits when YaST reads the partition to upgrade, not when asking for encryption password. And that disk does not contain any encrypted partition, they are on other disks. I'm thus not sure that Bug 1096960 is a duplicate of this one.
*** Bug 1094749 has been marked as a duplicate of this bug. ***
So can the problem and workarounds/mitigations be described in a few words suitable to put into the release notes?
(In reply to Ludwig Nussel from comment #34) > So can the problem and workarounds/mitigations be described in a few words > suitable to put into the release notes? * Problem: * During the system recognition, encryption devices are probed by YaST with an arbitrary name (e.g., /dev/dm/cr-auto-1). When probing the hardware, there is no way to know how that devices are named in each possible installed system. * When a system is selected for upgrading, the upgrade process tries to mount all devices indicated in the fstab file of the selected system. * The specific name of encryption devices in the fstab file of that system (e.g. /dev/dm/cr_sda4) do not match to probed encryption names. * As consequence, YaST was not able to found in the system the encryption devices indicated in the fstab file. * Technical solution * Update encryption device names by using names in the crypttab file. * The crypttab file is parsed, the underlying device of each entry is found and its encryption device is updated with the name in that crypttab entry. * How to mitigate the problem * Basically, the installer must be updated. For this last point, is there any "official" way to upgrade the Leap image to mitigate the issue?
there is no installer upgrade, that's why I am asking for documentation for the release notes. And I wonder why openQA didn't discover this. We do have upgrade tests from 42.x each also with fully encrypted disks.
eg 42.3 update test https://openqa.opensuse.org/tests/677447
ok, got it. For those cases crypttab doesn't matter as fstab contains references to the logical volume path which is not impacted by crypttab. So the problem only occurs on manually configured encrypted partitions that are mounted by path in fstab. So if we recommend switching the path to UUID or label in fstab before the upgrade it should also work, right?
For encrypted partitions, the hard disk real device is referenced in the crypttab file, not in fstab. Label is not available here, because it is part of the filesystem which is not accessible yet (not deciphered). On GPT disks /dev/disk/by-partlabel/ works. LUKS2 supports a label, but I don't know how to access it, and anyway, is not supported by 42.3 or older, so a problem for multiboot machines. In my case, I use UUID on crypttab. I think this is the YaST default, too. fstab references the /dev/mapper/ device instead, which is deciphered. Fstab can not reference the underlying hard disk device, because it is encrypted. So both files have to be parsed. And my guess is, parsed before probing for partitions. After all, if importing fstab the probing results should be ignored. Mmm... complex. Another question. The DVD doesn't autoupdate YaST at runtime on openSUSE. What about the netinstall media? It always downloads the actual installer, so does it get an updated one?
So I tried this and filed bug#1097811 to document the problem in the release notes. The net install so far is not updated. An updated one would be bigger as the whole instsys needs to be included and a separate control.xml would be required to enable online repos by default. The installation that way would require more RAM than the current way. IOW it's doable with some effort but those are the caveats.
On my system, which uses GPT, mounting via /dev/disk/by-label/home seems to work as expected. Now I am confused as I understood the above explanation such that this would not work. IMHO using /dev/disk/by-label is much easier and more intuitive than mounting via UUID. Only caveat is that one has to set FS-labels once via btrfs, e2label, xfs_admin, and friends.
I forgot that once the encrypted device is opened, the filesystem label appears and fstab can use it. There might be a delay, though, something has to populate the symlinks. I've never tried this. You can use: LABEL=home ... instead of: /dev/disk/by-label/home
(In reply to Ludwig Nussel from comment #38) > ok, got it. For those cases crypttab doesn't matter as fstab contains > references to the logical volume path which is not impacted by crypttab. > > So the problem only occurs on manually configured encrypted partitions that > are mounted by path in fstab. So if we recommend switching the path to UUID > or label in fstab before the upgrade it should also work, right? Yes, it should work. Anyway, by using UUID= or LABEL= in the fstab, it still could fail when no filesystem is found with that UUID/LABEL. This was fixed in [1] and it is included in libstorage-ng 3.3.305, which is not shipped with Leap 15.0. So, to avoid any possible failure, I recommend to use udev paths in fstab like: /dev/disk/by-uuid/4d2e6fde-d105-4f15-b8e1-4173badc8c66 /dev/disk/by-id/ata-HGST_HTS725050A7E630_TF655AWHGATD2L /dev/disk/by-label/DATA [1] https://github.com/openSUSE/libstorage-ng/pull/535
And I forget to mention that the filesystem could not be found by two reason: (a) the filesystem actually does not exist, or (b) the encryption device was not activated during the probing phase (user did not enter the password). The first case should not happen if the user has modified the fstab just before the upgrade (in case he writes the UUID/LABEL correctly, of course), but the second one probably could happen more frequently (e.g., user decides to not enter the password at that moment). In those cases, the installer will explode if the filesystem with indicated UUID/LABEL is not found.
Is there any update route we can take for 15.0 or do we need to wait for 15.1?
(In reply to Sebastian Turzański from comment #45) > Is there any update route we can take for 15.0 or do we need to wait for > 15.1? Upgrading with an up-to-date installer is not super-easy, but it's doable. Check this comment explaining some options. https://bugzilla.suse.com/show_bug.cgi?id=1094749#c21
Please confirm, if following upgrade procedure is valid: Precondition: Fixed components are published in (official) repositories, e.g. https://download.opensuse.org/update/leap/15.0/oss/x86_64/ and system partition is not encrypted 1. Boot old Linux (e.g. 42.3), login as root. In /etc/fstab comment non system encrypted entries (e.g. /home) 2. Reboot with USB NET Leap 15.0. During upgrade select repository with fixed components, so they are installed. During upgrade do not provide password for encrypted disk partitions ("cancel") 3. After upgrade is complete, boot new Linux 15.0. Login as root, in /etc/fstab uncomment entries commented in point 1 4. Reboot an enjoy
That worked for me. Thanks a lot, Peter.
I've had the same problem: Home partition ONLY encrypted during openSUSE 42.3 installation. Trying to upgrade to 15 gives error mentioned at the start and installation fails. How I solved it: cat /etc/crypttab Locate the second column for the partition you want. If it starts with something like /dev/disk... ls -l /dev/disk... and locate the device file it points to eg ../../sda2 ls -l /dev/disk/by-uuid Find the device file name on the right side eg ../../sda2 and copy the uuid on the left Edit crypttab and replace the second column (/dev/disk....) with UUID=the_uuid_from_above cat /etc/fstab Locate the line with the partition you want. If it starts with something like /dev/mapper/... ls -l /dev/mapper/... and locate the device file it points to eg ../../dm-0 ls -l /dev/disk/by-uuid Find the device file name on the right side eg ../../dm-0 and copy the uuid on the left Edit fstab and replace the first column (/dev/disk....) with UUID=the_uuid_from_above I hope this will help anyone trying to upgrade as the ISO image is not going to be updated with the fixed storage module. PS. After changing crypttab and fstab reboot to verify the new values work for your existing system, then proceed with the upgrade. PS2. Editing crypttab and fstab manually can render your system unbootable if there is an error. Make sure you know what you are doing!
SUSE-RU-2018:2183-1: An update that has 20 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1065258,1073633,1078359,1081605,1083851,1085134,1089643,1089699,1094157,1094875,1094924,1094963,1095253,1096240,1096758,1097634,1098594,1099691,760213,966637 CVE References: Sources used: SUSE Linux Enterprise Module for Basesystem 15 (src): libstorage-ng-3.3.312-3.9.3, yast2-firstboot-4.0.5-3.3.5, yast2-installation-4.0.67-3.3.8, yast2-storage-ng-4.0.200-3.13.2, yast2-update-4.0.17-3.4.9 SUSE Linux Enterprise INSTALLER 15 (src): libstorage-ng-3.3.312-3.9.3, yast2-storage-ng-4.0.200-3.13.2, yast2-update-4.0.17-3.4.9
openSUSE-RU-2018:2249-1: An update that has 20 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1065258,1073633,1078359,1081605,1083851,1085134,1089643,1089699,1094157,1094875,1094924,1094963,1095253,1096240,1096758,1097634,1098594,1099691,760213,966637 CVE References: Sources used: openSUSE Leap 15.0 (src): libstorage-ng-3.3.312-lp150.2.6.1, yast2-firstboot-4.0.5-lp150.2.3.1, yast2-installation-4.0.67-lp150.2.9.1, yast2-storage-ng-4.0.200-lp150.2.9.1, yast2-update-4.0.17-lp150.2.3.1
I have the same issue. Let's be honest: For Leap 15 **NOTHING is fixed** as long as there is **no DUD**. Boot option "self_update=1" does not help. Now everybody should do the hacky workaround in comment 65? Really? I've built a DUD with the latest YaST RPMs and wrote a README for this. Can be found here: > https://github.com/sriemer/spars-coding/tree/master/opensuse_fixes/leap15 With the DUD and mksusecd even a new installation DVD could be created. It would contain and apply the DUD automatically. The DUD fixes this for me. System is coming up fine after upgrade. So setting to VERIFIED-FIXED.
(In reply to Sebastian Parschauer from comment #70) > I have the same issue. Let's be honest: > For Leap 15 **NOTHING is fixed** as long as there is **no DUD**. Boot option > "self_update=1" does not help. > > Now everybody should do the hacky workaround in comment 65? Really? As commented in another related bug, openSUSE Leap does not have an official channel for the installer self-update or to release official DUDs. That means that everybody has to either do the hacky workaround or wait until the release of openSUSE Leap 15.1 (where the bugs are fixed). There is no official way to fix the installer of an already released version of openSUSE Leap.
(In reply to Ancor Gonzalez Sosa from comment #71) That's fine. But the DUD doesn't have to be official/signed for openSUSE, as "insecure=1" can be used. It just has to contain the official update RPMs or the respective RPM signing key additionally and should be tested working to avoid that others have to build it themselves again. Of cause use these DUDs at own risk and those are unsupported.
New primary DUD location for SEO: > https://github.com/sriemer/fix-opensuse-leap-15-upgrade-encrypted-dud It will take a bit until Google will find it. But Google loves GitHub.
I see, the preferred workaround is in the release notes: > https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.0/#sec.upgrade.encrypted-disk
(In reply to Sebastian Parschauer from comment #73) > New primary DUD location for SEO: > > https://github.com/sriemer/fix-opensuse-leap-15-upgrade-encrypted-dud > > It will take a bit until Google will find it. But Google loves GitHub. Thank you - I have successfully used this now for the upgrade of two of my installations using the USB technique described in the README on the github site. Works perfectly.
*** Bug 1117203 has been marked as a duplicate of this bug. ***