On 12.7.2016 13:02, Ancor Gonzalez Sosa wrote:
On 07/12/2016 06:41 AM, Michael Chang wrote:
Hi,
On Fri, Jul 08, Ancor Gonzalez Sosa wrote:
On Fri, Jul 08, Ancor Gonzalez Sosa wrote:
On 05/20/2016 08:46 AM, Jiri Srain wrote: > I am not sure why the /boot parititon is needed here. If you have sufficently > large MBR gap to embed stage2 image, then it could boot off from LVM volumes > directly. We did that based in the Michael Chang's comment that is documented at https://github.com/yast/yast-storage-ng/blob/master/doc/boot-partition.md#ge...
Our conclusion from that comment was "ditching /boot is harder than expected, so to stay safe always propose /boot with LVM". That's reflected in the summary section here https://github.com/yast/yast-storage-ng/blob/master/doc/boot-partition.md#ge... Ok, I understand the problems with grub-once, but: always creating a /boot with LVM makes snapshots/rollback with LVM impossible :(
Looks like this needs a further discussion with the bootloader people, if there isn't a solution for at least GPT based partition schemes or so.
"with raid, eLVM and LVM - on GPT always create a GRUB partition - otherwise, always create a /boot partition"
Isn't it? Ok, and this is what we have today, fine with me. Is the GRUB partition required in all architectures when LVM is used? I don't know. From how I read the whole stuff: LVM without /boot: grub-once will not work reliable. But for x86-64 with GPT, you have LVM without /boot but a gpt boot
On 07/08/2016 12:26 PM, Thorsten Kukuk wrote: partition. If this means, grub-once work reliable with a gpt boot partition, we should go that road on all architectures if possible. If grub-once does not work reliable with LVM and a gpt boot partition, we have a problem on x86-64. Unfortunately it's unreliable regardless using gpt boot (ie bios_grub)
On Fri, Jul 08, 2016 at 02:27:44PM +0200, Thorsten Kukuk wrote: partition or not. Although we created early systemd serivce and hibernation hook to clear that (boot once)flag in lieu of bootloader, it's still unreliable if booting fails before reaching that level. That's what we understood initially. That's why we always propose a separate /boot when LVM is used. But then we got this comment from Michael:
with GPT partition table if there is no GRUB partition in a partitions-based proposal only requires a new GRUB partition in a LVM-based proposal requires /boot and a GRUB partitions
Why not also creating new GRUB partition for LVM so that /boot can be omitted ?
Wouldn't the same problem with hibernation apply to this scenario? I mean, I understood from Michael that /boot with LVM can never be omitted if you want hibernation to work reliably, but here it looks like he suggests to omit it.
If we need a /boot partition with LVM to have a reliable working grub-once, we have a real problem with btrfs and rollback. In server, hibernate is not much required, so can the proposal be done as server or desktop basis ?
This sounds like we need a further, deep discussion with our bootloader experts on the different architectures... The workaround may be allocating (writable) environment block on the raw gpt bios_grub partition, there's seems no better way out. (Unless native write support in grub is implemented for all filesystems, lvm and mdadm, but I don't see any sign that it will happen). If that approach is used, can we always drop /boot in favor of a bios_grub partition? Any reason to not use always that workaround?
Last but not least, just to verify that I had understood the scenarios, confirm if these statements are true or false. They assume the above-mentioned workaround is not used (since I'm not sure if I understood the use-case for it).
In x86 using GPT - Using UEFI Do we need any special partition in addition to the EFI partition if using uEFI, no matter what the other options (as written below, plain / LVM) are?
* Plain partitions -> no separate /boot needed. No bios_grub needed * LVM + If we DON'T care about hibernation -> -> no separate /boot needed. bios_grub needed. + If we DO care about hibernation -> -> separate /boot needed. bios_grub not needed (we have /boot) - Using legacy boot * Plain partitions -> no separate /boot needed. bios_grub needed * LVM + If we DON'T care about hibernation -> -> no separate /boot needed. bios_grub needed. + If we DO care about hibernation -> -> separate /boot needed. bios_grub not needed (we have /boot) I only have one problem with the scenarios when /boot is needed: Full system encryption, which will not cover the /boot partition outside LVM. And, additionally, rollback will not work reliably if /boot is out of its control.
Is there really no reliable way to avoid separate /boot in such cases? Jrii
For PPC64, as long as we have PReP bios_grub is not required.
Thanks
-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: opensuse-storage+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-storage+owner@opensuse.org