[Bug 808017] New: with crypted lvm in UEFI mode no /boot partition is proposed
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c0 Summary: with crypted lvm in UEFI mode no /boot partition is proposed Classification: openSUSE Product: openSUSE 12.3 Version: RC 2 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: YaST2 AssignedTo: aschnell@suse.com ReportedBy: lnussel@suse.com QAContact: jsrain@suse.com CC: fehr@suse.com Found By: --- Blocker: --- Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flag| |SHIP_STOPPER? Created an attachment (id=528681) --> (http://bugzilla.novell.com/attachment.cgi?id=528681) yast2 logs when clicking the option to use lvm and to encrypt the volume group yast does not create a /boot partition resulting in an unbootable system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c1 --- Comment #1 from Ludwig Nussel <lnussel@suse.com> 2013-03-07 11:38:22 CET --- the text of the proposal is also misleading as it calls /boot/efi the "boot volume" -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aschnell@suse.com AssignedTo|aschnell@suse.com |fehr@suse.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c2 Thomas Fehr <fehr@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #2 from Thomas Fehr <fehr@suse.com> 2013-03-07 11:09:41 UTC --- You are right this case is broken. I assumed initrd and kernel are copied to in /boot/efi in UEFI mode. If they would be there they could be accessed by bootloader. If they are under /boot we need two boot partitions for the case of encrypted root volume and UEFI. - one unencrypted with linux fs mounted under /boot - another one with vfat fs mounted under /boot/efi Of course changes in proposal code are non-trivial to make it propose two boot volumes, so there is certainly no fast fix for that. AFAIK it would make more sense to put kernel and initrd to the vfat partition in UEFI case. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c3 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|SHIP_STOPPER? | --- Comment #3 from Ludwig Nussel <lnussel@suse.com> 2013-03-07 13:31:12 CET --- In today's go/nogo meeting we decided to ship openSUSE 12.3 with this bug unfixed. Wrt putting the kernel in the efi partition I think that's what future systemd will favor. Judging from my Windows installation the efi partition might be too small by default though. Also, the upgrade case is not yet considered I suppose. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c4 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arvidjaar@gmail.com, | |mchang@suse.com --- Comment #4 from Michael Chang <mchang@suse.com> 2013-03-08 09:06:04 UTC --- IMHO, we shouldn't follow that decision (mount ESP on boot). It just made things worse than before. The immortal /boot (vfat) partition is a retard to linux evolution. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c5 --- Comment #5 from Thomas Fehr <fehr@suse.com> 2013-03-08 09:16:40 UTC --- Yeah, and the fact that we need two different boot partitions (on with vfat because of the standard and on with a linux fs because of ideological reasons) for every scenario involving an encrypted root fs is an incredible breakthrough that will make linux on desktop succeed by sheer elegance of such a "solution". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c6 --- Comment #6 from Michael Chang <mchang@suse.com> 2013-03-08 10:04:35 UTC --- Boot partition is boot partition and ESP is ESP, they shouldn't mix. The boot partition is historical relic we introduced to workaround boot problem on some scenarios, what we have to do is not dependent on it at all, if boot loader technology get breakthrough. For example, fully disk encryption (kerenl and initrd exposed ..) and btrfs snapshot (can't snapshot your kernel and config status with rootfs) will suffer by separate (ext3,vfat) boot partition, also in software raid you'd better get your /boot mirrored in case any fail happened you have backup and boot your system again .. (otherwise you have to duplicate your /boot to different disks after kernel update) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c7 --- Comment #7 from Ludwig Nussel <lnussel@suse.com> 2013-03-08 12:04:53 CET --- Looks like there are different opinions about what is the best setup. For reference, here is a discussion on the systemd list which indicates that they plan to mount the ESP at /boot: http://lists.freedesktop.org/archives/systemd-devel/2013-January/008273.html AFAICT there are several proposals so far: 1. ESP at /boot/efi, separate /boot as usual, only bootloader in ESP 2. ESP at /boot/efi, /boot on /, bootloader in ESP, bootloader implements all features to access raid, lvm, crypto etc. itself. 3. ESP at /boot/efi, /boot on /, bootloader in ESP, bootloader setup script copies kernel&initrd to ESP. 4. ESP at /boot, bootloader (optional), kernel and initrd in ESP. kernel&initrd would need to be packaged in e.g. /boot/EFI/opensuse then. 1. and 2. require feature rich bootloaders like grub2 while 3 and 4 don't. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c8 Thomas Fehr <fehr@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |coolo@suse.com --- Comment #8 from Thomas Fehr <fehr@suse.com> 2013-03-11 17:26:39 UTC --- So the need to change the proposal code to create two different partitions needed for booting in the case of encrypted root only if we got for "solution" number 1. Since it is now too late for 12.3 anyway, I set this to NEEDINFO for coolo so that he tells me when/if a changed proposal is required fir next openSUSE release. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c9 --- Comment #9 from Michael Chang <mchang@suse.com> 2013-03-12 08:28:40 UTC --- (In reply to comment #7)
Looks like there are different opinions about what is the best setup. For reference, here is a discussion on the systemd list which indicates that they plan to mount the ESP at /boot: http://lists.freedesktop.org/archives/systemd-devel/2013-January/008273.html
AFAICT there are several proposals so far: 1. ESP at /boot/efi, separate /boot as usual, only bootloader in ESP 2. ESP at /boot/efi, /boot on /, bootloader in ESP, bootloader implements all features to access raid, lvm, crypto etc. itself. 3. ESP at /boot/efi, /boot on /, bootloader in ESP, bootloader setup script copies kernel&initrd to ESP. 4. ESP at /boot, bootloader (optional), kernel and initrd in ESP. kernel&initrd would need to be packaged in e.g. /boot/EFI/opensuse then.
1. and 2. require feature rich bootloaders like grub2 while 3 and 4 don't.
My 0.02 cents For none uefi firmware, there's no choice but either #2 or #1, so the solution can be considered "generic" .. (if bootloader can't support #2 then fallback to #1). For uefi, we could offer ESP on /boot as (better?) alternative to propose #1, it can't be any way better than #2 as that's the real meat. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c10 Stephan Kulow <coolo@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED CC| |coolo@suse.com InfoProvider|coolo@suse.com | --- Comment #10 from Stephan Kulow <coolo@suse.com> 2013-03-19 13:51:09 CET --- I don't think we make friends with kernel in ESP, so I would go for #1 actually. But I don't see why #1 requires feature rich bootloaders. The /boot wasn't on LVM nor on encrypted, so what feature does it require? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c11 --- Comment #11 from Ludwig Nussel <lnussel@suse.com> 2013-03-19 14:02:28 CET --- gummiboot != feature rich for example -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c12 --- Comment #12 from Thomas Fehr <fehr@suse.com> 2013-03-19 13:03:53 UTC --- Either you need a feature rich bootloader that is able to set up root fs (in case of plain LVM grub2 can do that, in case of encrypted LVM it cannot do that yet). To support encryption the bootloader would need to ask for crypt password and call "cryptsetup luksOpen ..." before setting up LVM VG. If the bootloader is not able to do that, you need at least three partitions for any installation using encrypted LVM: - /boot/efi formatted as vfat for ESP - /boot unencrypted with linux fs (ext4,btrfs) for kernel and initrd - LVM physical volume with encryption Same would be true for other setup like e.g. raid if bootloader would not be able to access root filesystem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c13 Simon Toth <Happy.Cerberus@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Happy.Cerberus@gmail.com --- Comment #13 from Simon Toth <Happy.Cerberus@gmail.com> 2013-03-26 17:28:06 UTC --- This bug is also relevant for software RAID situations. I have two SSD disks I want to setup in mirror, but that's impossible with the EFI boot partition. 1) this partition must stay outside of the raid 2) the actual /boot partition also probably has to stay out of the raid I have been wrestling with the installer for last 6 hours with no results. My last attempt was this: ssd1 -> FAT EFI (256MB) -> Raid 1/2 mirror swap (4GB) -> Raid 1/2 mirror LVM (~50GB) ssd2 -> empty (256MB) -> Raid 2/2 mirror swap (4GB) -> Raid 2/2 mirror LVM (~50GB) LVM -> root (~25GB) -> home (~25GB) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c14 --- Comment #14 from Thomas Fehr <fehr@suse.com> 2013-03-26 18:10:28 UTC --- if bootloader cannot handle LVM over raid you are right, Michael is this supposed to be handled by bootloader? In above case I would suggest to use the (now unused) slot on second ssd as partiton for /boot So if ssd1 is /dev/sda and ssd2 is /dev/sdb you would have the following: /dev/sda1 256M vfat mount at /boot/efi /dev/sdb1 256M ext4 mount at /boot /dev/sda2 and /dev/sdb2 build /dev/md0 4G swap mount as swap /dev/sda3 and /dev/sdb3 build /dev/md1 50G as phsyical volume for LVM VG AFAIK this should work and be doable with installer without a problem If bootloader setup does not have a problem with /boot/efi and /boot being on different disks the system should work fine. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c15 --- Comment #15 from Simon Toth <Happy.Cerberus@gmail.com> 2013-03-26 18:12:48 UTC --- I think I just tried a slightly different but similar variant that did install, but won't boot up: /dev/sda1 + /dev/sdb1 mirror vfat /boot/efi /dev/sda2 + /dev/sdb2 mirror ext4 /boot /dev/sda3 + /dev/sdb3 mirror LVM -> swap/root/home -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c16 --- Comment #16 from Thomas Fehr <fehr@suse.com> 2013-03-26 18:20:19 UTC --- Not sure if bootloader setup is clever enough to see through raid and use the disk contained in the raid instead for booting. I would suggest trying to use plain partitions for /boot and /boot/efi. I doubt the bios being smart enough to access sdb if it gets IO-errror on sda anyway, so there is not much added redundancy and robustness by having /boot/efi on a raid anyway. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c17 --- Comment #17 from Simon Toth <Happy.Cerberus@gmail.com> 2013-03-26 18:52:52 UTC --- Well as for the robustness, ending up with an unbootable system vs. having a fully functional system is a pretty major difference for me. Is there any way I can force the installer not to use the stupid EFI support? The motherboard should be able to boot legacy disks just fine. How do I do a legacy installation? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c18 --- Comment #18 from Thomas Fehr <fehr@suse.com> 2013-03-26 19:12:46 UTC --- YaST looks at /sys/firmware/efi/vars if this directory exist it assumes a EFI system and proposes EFI setup. If your BIOS is in EFI mode there is to my knowledge no way around a /boot/efi partition using vfat. If you can switch your system to Legacy mode before booting linux installation, there should be no directory /sys/firmware/efi/vars present and YaST will propose legacy partitioning with plain /boot. Maybe you should create new (msdos type) partition tables on both disks since EFI enforces GPT disk label and I am not sure if your BIOS can handle GPT disk label when in legacy mode. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c19 --- Comment #19 from Simon Toth <Happy.Cerberus@gmail.com> 2013-03-26 19:28:12 UTC --- There is no option to switch the system into legacy mode. However when choosing the boot options there are legacy entries for the disks. This basically means that I will have to install the system on a different non-EFI machine to get it into working state. Or I can try to hack the /boot/efi onto an USB stick and always boot from that USB stick. Unfortunately on my desktop I was unable to make grub-efi boot across disks (I have one disk with Windows and one disk with Linux there) so that probably won't work either. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c20 --- Comment #20 from Andrey Borzenkov <arvidjaar@gmail.com> 2013-03-27 02:50:09 UTC --- (In reply to comment #19)
Unfortunately on my desktop I was unable to make grub-efi boot across disks (I have one disk with Windows and one disk with Linux there)
I'd it the same as https://bugzilla.novell.com/show_bug.cgi?id=809038? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c21 --- Comment #21 from Michael Chang <mchang@suse.com> 2013-03-27 04:08:26 UTC --- (In reply to comment #14)
if bootloader cannot handle LVM over raid you are right, Michael is this supposed to be handled by bootloader?
RAID on LVM (or the other way round) cannot be handled by grub2, as far as I know. :(
In above case I would suggest to use the (now unused) slot on second ssd as partiton for /boot
Yes we need a /boot partition for it.
AFAIK this should work and be doable with installer without a problem If bootloader setup does not have a problem with /boot/efi and /boot being on different disks the system should work fine.
It should have no problem /boot and /boot/efi on different disks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c22 --- Comment #22 from Michael Chang <mchang@suse.com> 2013-03-27 04:14:22 UTC --- (In reply to comment #17)
How do I do a legacy installation?
For bootloader you can switch to grub2 or grub in yast2 bootloader, not sure about rest of the installation you need to take care of but better using msdos table for legacy. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c23 --- Comment #23 from Michael Chang <mchang@suse.com> 2013-03-27 04:16:58 UTC --- (In reply to comment #15)
I think I just tried a slightly different but similar variant that did install, but won't boot up:
/dev/sda1 + /dev/sdb1 mirror vfat /boot/efi
Apparently UEFI firmware can hanlde ESP on RAID thus booting failed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c24 --- Comment #24 from Simon Toth <Happy.Cerberus@gmail.com> 2013-03-27 10:35:25 UTC ---
Apparently UEFI firmware can hanlde ESP on RAID thus booting failed.
Yup seems so. I have now tried this layout: /dev/sda1 vfat /boot/efi /dev/sdb1 vfat empty /dev/sda2 + /dev/sdb2 mirror ext4 /boot /dev/sda3 + /dev/sdb3 mirror LVM -> swap/root/home And it leads to a bootable system. The problem is that if I disconnect /dev/sda I end up with an unbootable machine. Doing a simple "dd if=/dev/sda1 of=/dev/sdb1" isn't enough. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c25 --- Comment #25 from Simon Toth <Happy.Cerberus@gmail.com> 2013-03-27 11:51:11 UTC --- There are still some weird issues, but I seem to have managed to get this into a working state. 1) create a layout where you have a non-raid, non-lvm /boot/efi 2) create a /boot that is non-lvm (can be raid) 3) create the rest 4) let the install do it's work 5) clone the /boot/efi using dd 6) add an efi record for the clone "efibootmgr -c -g -d /dev/sdb -p 1 -L "opensuse" -l '\EFI\opensuse\grubx64.efi'" 7) using "efibootmgr --bootorder" change the boot order so that the two opensuse records are next to each other -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c26 --- Comment #26 from Andrey Borzenkov <arvidjaar@gmail.com> 2013-03-28 10:13:26 UTC --- (In reply to comment #21)
RAID on LVM (or the other way round) cannot be handled by grub2, as far as I know. :(
Of course it can, I just tested it (grub ${prefix} on LVM on MD). grub.efi size is 147K, so in even easily fits in modern post-MBR gap (1M by default). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c27 --- Comment #27 from Andrey Borzenkov <arvidjaar@gmail.com> 2013-03-28 10:18:52 UTC --- (In reply to comment #23)
Apparently UEFI firmware can hanlde ESP on RAID thus booting failed.
You probably mean "can not". Do not forget that you need to use metadata version 0.9 or 1.0. And default is 1.2. 1.1 and 1.2 place metadata at the beginning of device so firmware does not find filesystem. I tested booting from ESP on Linux MD RAID1 and it worked just fine, but I think something got confused (grub2-install or perl-bootloader). The main problem with this is - you cannot prevent writing to ESP while in firmware, which in case of RAID1 leads to filesystem corruption. So I would really prefer two independent ESPs on different disks and manual synchronization by perl-bootloader (after all we just need to copy couple of files). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c28 Thomas Fehr <fehr@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #28 from Thomas Fehr <fehr@suse.com> 2013-07-04 13:56:36 UTC --- Fixed according to Coolo´s demands in comment#10 in yast2-storage version 2.24.6 When encrypted LVM is proposed on an EFI system, the proposal now contains two small unencrypted partitions: 1) a vfat partition mounted at /boot/EFI (as is the case for EFI since ages) 2) a ext4 partition (size about 400M) mounted at /boot (this one is new) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c29 --- Comment #29 from Thomas Fehr <fehr@suse.com> 2013-07-04 14:51:07 UTC --- Sorry for typo. ESP mount point is of course still "/boot/efi", no idea why I used uppercase "EFI" in mount point. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com