Review partitioning requirements - x86
Hi, find below the review from Michael Chang, based on the rspec version of the specification. Jiri Yast::Storage::BootRequirementsChecker #needed_partitions in a x86 system using UEFI with a partitions-based proposal if there are no EFI partitions requires only a new /boot/efi partition if there is already an EFI partition only requires to use the existing EFI partition with a LVM-based proposal if there are no EFI partitions requires /boot and a new /boot/efi partition if there is already an EFI partition requires /boot and a reused /boot/efi partition not using UEFI (legacy PC) with an MS-DOS partition table with sufficently large MBR gap in a partitions-based proposal does not require any particular volume in a LVM-based proposal requires only a /boot partition 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. with too small MBR gap raises an exception with no MBR gap raises an exception It is a little messy here, how it works currently depends on file system and any disk abstractions user is going to create. Please note I am assuming we still specify --force to "grub2-install" so that fallback can really be triggered. 1. Filesystem like extX, XFS: Fallback to blocklist mode, which is more "fragile" so displaying warnings. 2. COW File system. Btrfs(ZFS): Fallback to use filesystem provided bootloader pad which can be equivalent to mbr gap. 3. Any disk abstractions like LVM and mdadm: expliclty require MBR gap, so error out is reasonable. 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 ? if there is already a GRUB partition in a partitions-based proposal does not require any particular volume in a LVM-based proposal only requires a /boot partition Do we have any reason to keep /boot partition for LVM ? It should be the same with previous "does not require any particular volume" to me. when proposing a boot partition requires /boot to be ext4 with at least 100 MiB requires /boot to be in the system disk out of LVM recommends /boot to be 200 MiB when proposing an new EFI partition requires /boot/efi to be vfat with at least 33 MiB requires /boot/efi to be out of LVM recommends /boot/efi to be 500 MiB requires /boot/efi to be close enough to the beginning of disk when proposing an new GRUB partition requires it to have the correct id requires it to be out of LVM requires it to be between 256KiB and 8MiB, despite the alignment recommends it to be 1 MiB -- To unsubscribe, e-mail: opensuse-storage+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-storage+owner@opensuse.org
On 05/20/2016 08:46 AM, Jiri Srain wrote:
Hi,
find below the review from Michael Chang, based on the rspec version of the specification.
Jiri
Yast::Storage::BootRequirementsChecker #needed_partitions in a x86 system using UEFI with a partitions-based proposal if there are no EFI partitions requires only a new /boot/efi partition if there is already an EFI partition only requires to use the existing EFI partition with a LVM-based proposal if there are no EFI partitions requires /boot and a new /boot/efi partition if there is already an EFI partition requires /boot and a reused /boot/efi partition not using UEFI (legacy PC) with an MS-DOS partition table with sufficently large MBR gap in a partitions-based proposal does not require any particular volume in a LVM-based proposal requires only a /boot partition
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...
with too small MBR gap raises an exception
with no MBR gap raises an exception
It is a little messy here, how it works currently depends on file system and any disk abstractions user is going to create.
Please note I am assuming we still specify --force to "grub2-install" so that fallback can really be triggered.
1. Filesystem like extX, XFS: Fallback to blocklist mode, which is more "fragile" so displaying warnings.
2. COW File system. Btrfs(ZFS): Fallback to use filesystem provided bootloader pad which can be equivalent to mbr gap.
3. Any disk abstractions like LVM and mdadm: expliclty require MBR gap, so error out is reasonable.
Ok. I will adjust the code to cover those scenarios.
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 ?
Yo are right. We probably took the "always use /boot in LVM" thingy too far. Should I change this part of the summary? https://github.com/yast/yast-storage-ng/blob/master/doc/boot-partition.md#ge... If I got it right, where it says "always create a /boot partition on raid, eLVM, LVM" it should probably be: "with raid, eLVM and LVM - on GPT always create a GRUB partition - otherwise, always create a /boot partition" Isn't it?
if there is already a GRUB partition in a partitions-based proposal does not require any particular volume in a LVM-based proposal only requires a /boot partition
Do we have any reason to keep /boot partition for LVM ? It should be the same with previous "does not require any particular volume" to me.
Already commented above. We should change the summary and the implementation.
when proposing a boot partition requires /boot to be ext4 with at least 100 MiB requires /boot to be in the system disk out of LVM recommends /boot to be 200 MiB when proposing an new EFI partition requires /boot/efi to be vfat with at least 33 MiB requires /boot/efi to be out of LVM recommends /boot/efi to be 500 MiB requires /boot/efi to be close enough to the beginning of disk when proposing an new GRUB partition requires it to have the correct id requires it to be out of LVM requires it to be between 256KiB and 8MiB, despite the alignment recommends it to be 1 MiB
Thanks for your review! -- 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
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. Thorsten -- 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
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? 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
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. If we need a /boot partition with LVM to have a reliable working grub-once, we have a real problem with btrfs and rollback. This sounds like we need a further, deep discussion with our bootloader experts on the different architectures... 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
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
On 07/12/2016 06:41 AM, Michael Chang wrote:
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.
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 * 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) For PPC64, as long as we have PReP bios_grub is not required. Thanks -- 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
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
On 07/12/2016 01:28 PM, Jiri Srain wrote:
On 12.7.2016 13:02, Ancor Gonzalez Sosa wrote:
On 07/12/2016 06:41 AM, Michael Chang wrote:
On Fri, Jul 08, 2016 at 02:27:44PM +0200, Thorsten Kukuk wrote:
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. 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?
I have just had a very productive conversation with Michael and actually there is a way. We would need to adapt the way we manage Grub2, but it's doable. Quoting that conversation (slightly reordered): <mchang> Yes, it's trying to place place /boot/grub2/grubenv from file system to a raw system sector then it can be written directly by bootloader <mchang> We did a similar hack for btrfs .. the environment block is "chained" from file system block to btrfs's reserved area for bootloader. <mchang> But we need to make sure we don't step on each other's toe as the bios_grub is shared with bootloader image <ancorgs> but that's something that is also under our control, isn't it? <mchang> Yes, I suppose bios_grub is under our control .. as we already use it to embed the image and the unused space can be used for grub environment block <ancorgs> For both definitions of "control": the partition is under our control (not shared) and we control the different software pieces (grub2, yast2-booloader...) He also gave me some useful information about PPC (we will need to confirm that, but it's already something to work with). So I will come up with a new version of the specification incorporating Chang's input for everybody to review. 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
On 07/12/2016 02:08 PM, Ancor Gonzalez Sosa wrote:
On 07/12/2016 01:28 PM, Jiri Srain wrote:
On 12.7.2016 13:02, Ancor Gonzalez Sosa wrote:
On 07/12/2016 06:41 AM, Michael Chang wrote:
On Fri, Jul 08, 2016 at 02:27:44PM +0200, Thorsten Kukuk wrote:
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. 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?
I have just had a very productive conversation with Michael and actually there is a way. We would need to adapt the way we manage Grub2, but it's doable. Quoting that conversation (slightly reordered):
<mchang> Yes, it's trying to place place /boot/grub2/grubenv from file system to a raw system sector then it can be written directly by bootloader <mchang> We did a similar hack for btrfs .. the environment block is "chained" from file system block to btrfs's reserved area for bootloader. <mchang> But we need to make sure we don't step on each other's toe as the bios_grub is shared with bootloader image <ancorgs> but that's something that is also under our control, isn't it? <mchang> Yes, I suppose bios_grub is under our control .. as we already use it to embed the image and the unused space can be used for grub environment block <ancorgs> For both definitions of "control": the partition is under our control (not shared) and we control the different software pieces (grub2, yast2-booloader...)
He also gave me some useful information about PPC (we will need to confirm that, but it's already something to work with). So I will come up with a new version of the specification incorporating Chang's input for everybody to review.
So assuming we will use the technique suggested by Michael (/boot/grub2/grubenv to a raw system sector) and trying to incorporate all the feedback from the thread. This is how the spec could look like. https://notehub.org/v17eo (I tried to create a gist for it, but github is experiencing problems right now) Could please everybody review that? Thanks. -- 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
On 07/12/2016 06:47 PM, Ancor Gonzalez Sosa wrote:
So assuming we will use the technique suggested by Michael (/boot/grub2/grubenv to a raw system sector) and trying to incorporate all the feedback from the thread. This is how the spec could look like.
https://notehub.org/v17eo (I tried to create a gist for it, but github is experiencing problems right now)
Could please everybody review that?
Michael already reviewed and gave me more feedback and information about the grubenv embedding technique. We also coordinate to make sure is 100% realistic to have that working before storage-ng hits any distribution. This is the adjusted result after Michael's review (finally gist is working again) https://gist.github.com/ancorgs/db671cf6c0c12c5f2c62bae36a7d68c0 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
On Tue, Jul 12, 2016 at 01:28:44PM +0200, Jiri Srain wrote:
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?
No. We don't, unless we put it also on top lvm or mdadm, but currently no UEFI firmware can support booting it. To fix grub2-once, we may also chain /boot/grub2/grubenv to the file on it.
* 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.
That are all bootable by grub2, and that's why we think we can remove the biggest rock on the road, the /boot partition in order to boot them, that stumbled us in the past.
Is there really no reliable way to avoid separate /boot in such cases?
So that I think it's not worth to keep it alive just for the grub2-once to work "reliably". And we have plan to fix it now. Thanks, Michael
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
-- To unsubscribe, e-mail: opensuse-storage+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-storage+owner@opensuse.org
On Fri, Jul 08, 2016 at 02:19:10PM +0200, 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?
Not really. It depends on the firmware type. In short the bios_grub is reserved space for bootloader's stage2 image that can't fit into disk's 512 byte master boot record. For legacy pc bios + gpt table, bios_grub partition is required for booting lvm paritition directly. If you don't create bios_grub partition, then you'll have to create (rather suboptimal) separate partition for /boot without any underlying volume managers like lvm or mdadm. In other words, bios_grub is required for gpt on legacy pc bios if you don't want to require a separate boot partition, which is out to system's root file system so may not be able to fulfill desired storage management plans, for eg implementing btrfs or even lvm snapshots on the full system with kernel and so on. For PPC64, I don't think bios_grub is required as long as firmware will boot PReP partition directly and never use MBR.
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
So that [2] looks wrong to me ... Thanks, Michael
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
-- To unsubscribe, e-mail: opensuse-storage+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-storage+owner@opensuse.org
participants (4)
-
Ancor Gonzalez Sosa -
Jiri Srain -
Michael Chang -
Thorsten Kukuk