Mailinglist Archive: opensuse-storage (12 mails)

< Previous Next >
Re: [opensuse-storage] Review partitioning requirements - x86
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-storage+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups