On 11.09.17 10:16, Ancor Gonzalez Sosa wrote:
On 09/08/2017 01:38 PM, Andreas Färber wrote:
Hi Ancor,
Sorry for the delay. I've skimmed through the whole document, but let's tap into the collective Arm brains in CC for maximum input. :)
CCing to yast-devel as well. There is some important technical considerations about booting ARM here not to be missed.
What I am not seeing for the <partitions/> section is a selection for GPT vs. MBR partitioning type? For the Raspberry Pi and some other boards (e.g., Marvell) we need to force the old MBR format due to bootloader requirements.
It's indeed not there. We have a separate function in the code to calculate the preferred partition type. So far, it simply returns GPT for most devices (except DASD devices). We can make the function smarter to take the current architecture into account (which is most likely the more straightforward approach and what I suggest) or we can make it configurable in the control.xml.
We really only have 2 cases on AArch64: 1) GPT 2) Leave label intact Case 2 is relevant if the firmware also sits on the same storage device we're installing onto and the code that loads that firmware does not know how to read a GPT but expects partitions. Or if space needs to get preserved, like a 10MB offset for firmware that Andreas mentioned. Then too we shouldn't touch the existing partitions (and partition table).
Where do these XML proposals for SLES/openSUSE/SLES4SAP/CaaSP get maintained? Inside YaST GitHub code or in an external product package?
https://github.com/yast/skelcd-control-SLES https://github.com/yast/skelcd-control-openSUSE etc.
The SLES proposal looks fine for ARM (except Raspberry Pi), but openSUSE may need changes to the <volumes/> proposal - in particular for some platforms we need to force a separate /boot partition in U-Boot-readable format (i.e., ext4). I only spot try_separate_home, but not ..._boot? We would need that a) for .dtb files and b) whenever UEFI support is not available and the kernel+initrd needs to be loaded by U-Boot itself rather than by GRUB.
Something that may not be completely clear in the document. The volumes proposed there are the ones desired for general system operation. In addition, YaST will always create the partitions needed for boot. But that's not configured via control.xml because the partitions needed for boot depend on too many factors and are independent of the product. Is not something for the release manager to decide and write in advance, it's simply dictated by the concrete technologies being used in the system. Which partitions do we propose then? Glad you asked: :-)
https://github.com/yast/yast-storage-ng/blob/master/doc/boot-requirements.md
How would we reserve space before the volumes? For some openSUSE/SLES platforms user volumes can only start at e.g. ~10 MB, with various bootloader blobs going before that.
Again, that's not something to specify in control.xml but to take into account while calculating the above-mentioned boot requirements. As you can see, there is no ARM section in that document (which is auto-generated from the automated tests and, thus, from the final implementation). That's something we are trying to fix during the current Scrum sprint and I guess Steffen already contacted you about that.
This will usually depend on the installation target. If installing to a new SATA disk then the default proposal is probably okay, whereas if we're trying to install to an SD card or eMMC device we just booted from, then certain partitions or offsets may need to be preserved. One proposal from Alex had been to have some kind of file preinstalled that would give YaST a hint on how to handle the partitions. Won't work if there's no filesystem partitions, of course.
In the end though we'll need to test this on various platforms to see how this works out. Background of some of the above is that we are looking to reduce the amount of openSUSE JeOS images in favor of the official installer, where the user would then need to create compatible partitions - no need to have all that be auto-magical from day one, but suitable UI/XML options would help.
Cheers, Andreas
Thanks for all the information. As said, most of it is more relevant to calculate the boot requirements than to improve the control.xml format. But is still VERY useful.
Outside of the boot setup, I don't think we should be any different from x86_64 :). Alex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org