On Fri, Jul 08, 2016 at 02:27:44PM +0200, Thorsten Kukuk wrote:
Hi,
On Fri, Jul 08, Ancor Gonzalez Sosa wrote:
On 07/08/2016 12:26 PM, Thorsten Kukuk 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?
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
I don't know. 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) 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.
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). Thanks, Michael
Thorsten
Right now, for PPC64+LVM we always require /boot (similar to what we had in x86), as you can see in https://github.com/yast/yast-storage-ng/blob/master/doc/boot-requirements.md
Should this current block [1] be something like this[2]?
[1] with a LVM-based proposal if there are no PReP partitions requires /boot and PReP partitions if the existent PReP partition is not in the target disk requires /boot and PReP partitions if there is already a PReP partition in the disk only requires a /boot partition
[2] with a LVM-based proposal with a MS-DOS partition table if there are no PReP partitions requires /boot and PReP partitions if the existent PReP partition is not in the target disk requires /boot and PReP partitions if there is already a PReP partition in the disk only requires a /boot partition with a GPT partition table if there are no PReP partitions requires GRUB and PReP partitions if the existent PReP partition is not in the target disk requires GRUB and PReP partitions if there is already a PReP partition in the disk only requires a GRUB partition
Cheers -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-storage+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-storage+owner@opensuse.org
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-storage+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-storage+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-storage+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-storage+owner@opensuse.org