https://bugzilla.novell.com/show_bug.cgi?id=808017 https://bugzilla.novell.com/show_bug.cgi?id=808017#c1 --- Comment #1 from Ludwig Nussel 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#c2 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #2 from Thomas Fehr 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#c4 Michael Chang changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arvidjaar@gmail.com, | |mchang@suse.com --- Comment #4 from Michael Chang 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#c6 --- Comment #6 from Michael Chang 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#c8 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |coolo@suse.com --- Comment #8 from Thomas Fehr 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#c10 Stephan Kulow changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED CC| |coolo@suse.com InfoProvider|coolo@suse.com | --- Comment #10 from Stephan Kulow 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#c12 --- Comment #12 from Thomas Fehr 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#c14 --- Comment #14 from Thomas Fehr 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#c16 --- Comment #16 from Thomas Fehr 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#c18 --- Comment #18 from Thomas Fehr 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#c20 --- Comment #20 from Andrey Borzenkov 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#c22 --- Comment #22 from Michael Chang 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#c24 --- Comment #24 from Simon Toth 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#c26 --- Comment #26 from Andrey Borzenkov 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#c28 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #28 from Thomas Fehr 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.