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