Bug 1216673

"Installer doesn't allow for non-standard boot configurations" - that is not a problem, it's a statement of fact. And it's not even true, either.

There are certain scenarios (lots of them!) that are supported on many architectures, and others that are not. There is no way that the YaST installer can support every conceivable scenario, even the most exotic ones. At some point, manual interaction becomes required.

We also cannot limit all other hardware / other scenarios to the very specific requirements of one very special hardware.


AFAICS, this is really a feature request for direct out-of-the-box support of such a very special hardware with very specific requirements.

So, what specific hardware is it? What architecture? What CPU, what chipset / mainboard? If our hardware enablement team team has access to such hardware, there may be a chance to support it. If not, then probably not.

> AFAICS, this is really a feature request for direct out-of-the-box support of such a very special hardware with very specific requirements.

it's a feature request to allow better support for any device that can't have root os on the boot device for space (or performance) reasons.
as the installer does not allow for snapshots on /boot if its not on the same device as the root os so I believe this problem could be hit on x86 systems also its just its a rare thing to do in that space
I could see someone wanting to say do local to device /boot but the root os is on an networked iSCSI device that only is accessible after the kernel and network is up

> So, what specific hardware is it? What architecture? What CPU, what chipset / mainboard? If our hardware enablement team team has access to such hardware, there may be a chance to support it. If not, then probably not.

I stated the hardware in the first line of my comment
here is link to the hardware to purchase:
https://pine64.com/product-category/soquartz/
link to wiki specs/info:
https://wiki.pine64.org/wiki/SOQuartz

tldr:
arm based system using a Rockchip RK3566 SoC

and i should also note that I did open bug #1216674 requesting a u-boot package to support this kit
as the u-boot package is really only item 'missing' from opensuse to support this hardware

I just asked our YaST bootloader expert Josef Reidinger, and he told me that support for U-Boot comes indirectly via Grub2 (chain booting if I understood him correctly). So that part is nothing that should need any change in YaST.

As for partitioning requirements: In many (not all) cases, it's the exact opposite, i.e. the root filesystem is required to be on the boot disk.

This is one of those cases where manual interaction might be required; the YaST storage proposal is just that, a proposal. If that doesn't fit your needs, you can use the "guided setup" for some more human control, or the expert partitioner for total control.

Reassigning to one of our ARM64 experts, Michal Suchanek.

Maybe there is even a solution for this specific hardware.

(In reply to Bret Towe from comment #2)
> 
> it's a feature request to allow better support for any device that can't
> have root os on the boot device for space (or performance) reasons.
> as the installer does not allow for snapshots on /boot if its not on the
> same device as the root os so I believe this problem could be hit on x86
> systems also its just its a rare thing to do in that space

As far as I understand, the installer enforces /boot to be part of root file-system when snapshots are used because that's a requisite for the standard snapshots tools we ship in the distribution.

I guess the configuration of Snapper, transactional-update, the bootloader and whatnot can be tweaked to work in that environment with separate /boot and / file-system. But I think the default configuration of all those tools assume everything is hosted in the same file-system. That's why the installer enforces that.

(In reply to Bret Towe from comment #0)
> 
> so the first item the installer needs to worry about is partitions need to
> allow setting an offset at the beginning

Can't you do that in the Expert Partitioner by selecting "Custom Region" while defining the partition size?

(In reply to Ancor Gonzalez Sosa from comment #6)
> (In reply to Bret Towe from comment #2)
> > 
> > it's a feature request to allow better support for any device that can't
> > have root os on the boot device for space (or performance) reasons.
> > as the installer does not allow for snapshots on /boot if its not on the
> > same device as the root os so I believe this problem could be hit on x86
> > systems also its just its a rare thing to do in that space
> 
> As far as I understand, the installer enforces /boot to be part of root
> file-system when snapshots are used

Sorry for adding confusion. My previous statement is is actually not precise. The installer actually allows to setup snapshots for the root file-system even if /boot is a separate file-system.

The setup that, indeed, the installer does not offer is having separate file-systems for /boot and / and to setup snapshots for BOTH file-systems. The installer only allows to setup snapshots for the root file-system, not any other.

> because that's a requisite for the standard snapshots tools we ship
> in the distribution.

That part of my previous message is still true. The reason for supporting only one kind of scenarios (snapshots enabled for / and not for other file-systems) is to match the expectation and default configuration of all the snapshots tools in the distribution.

I don't think it's possible to have snapshots span multiple filesystems.

As for original problem: its should be possible

1) install system into SD/emmc and use NVMe for data

2) build u-boot with NVMe support, install only u-boot to SD/emmc and boot system form NVMe

Some pine64 hardware also may have a SPI flash memory for installing u-boot. When u-boot is installed there the generic arm64 EFI image can be used on any medium u-boot supports.

What's the status of RockChip NVMe support in u-boot?

Last time I looked into it there was some downstream u-boot build with some extra patches to support his.

(In reply to Ancor Gonzalez Sosa from comment #7)
> (In reply to Bret Towe from comment #0)
> > 
> > so the first item the installer needs to worry about is partitions need to
> > allow setting an offset at the beginning
> 
> Can't you do that in the Expert Partitioner by selecting "Custom Region"
> while defining the partition size?

I don't recall seeing this, I only recall being able to set max size not start point

(In reply to Michal Suchanek from comment #10)
> What's the status of RockChip NVMe support in u-boot?
> 
> Last time I looked into it there was some downstream u-boot build with some
> extra patches to support his.

its unsupported in the kwiboo git branch at this time. once the patches are usable kwiboo tends add them so I assume whatever patches exist at the moment are not stable.
so it likely will work 'at some point' but at least in short term it just not a choice

Created attachment 870518 [details]
Step to add a partition

(In reply to Bret Towe from comment #11)
> 
> I don't recall seeing this, I only recall being able to set max size not
> start point

The option is there for every new partition you create with Expert Partition. See attachment.

(In reply to Ancor Gonzalez Sosa from comment #13)
> Created attachment 870518 [details]
> Step to add a partition
> 
> (In reply to Bret Towe from comment #11)
> > 
> > I don't recall seeing this, I only recall being able to set max size not
> > start point
> 
> The option is there for every new partition you create with Expert
> Partition. See attachment.

so it does. any chance to have an option to choose by megabyte or the likes instead?