openSUSE Storage

Download

storage@lists.opensuse.org

May 2016

2 participants
2 discussions

Review partitioning requirements - x86
by Jiri Srain 14 Jul '16

14 Jul '16

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(a)opensuse.org To contact the owner, e-mail: opensuse-storage+owner(a)opensuse.org

4 12

Mid-term goal for storage-ng
by Ancor Gonzalez Sosa 19 May '16

19 May '16

I have been planning to send this mail for quite some time. Since we were lately focused on implementing features for SP2 I had put it on hold. In this sprint we have some storage-ng related PBIs again so... This is kind of a suggestion for our product owner about sorting team-S' PBIs. Following the agile approach of trying to have something shippable as soon as possible (and always shippable), I would like to see an installable Tumbleweed image using libstorage-ng the sooner the better. Something that can turn our own instance of openQA green for, at least, one scenario. The three main "users" of libstorage (from the top of my head) are: - (a) The partitioning proposal - (b) Yast-Bootloader - (c) The expert partitioner For (a) we already have working code for very simple scenarios (ms-dos style partitions with contiguous space). (c) is not absolutely needed to perform an installation[1]. Yast-Bootloader has been recently refactored to the ground, killing a lot of old code and replacing SCR with the more object-oriented CFA. It should be in a sane-enough state to be touched. So, as much as I would like to keep working in improving the proposal and supporting LVM (two things that are indeed quite interesting from a developer's point of view), I think we should postpone improving what we already have and focus on having a first version of the stuff that is missing (i.e. stuff that is preventing us from having that installable ISO). (b) comes to mind, but sure I'm forgetting something. Cheers. [1] Moreover, we should probably use the opportunity to have the UI of the expert partitioner redesigned (or at least reviewed), but that's another story. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-storage+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-storage+owner(a)opensuse.org

2 1