[Task]: Improve `armbian-install` when using multiple partitions

[ColorfulRhino]

Task description

Forum topic for reference: https://forum.armbian.com/topic/41699-how-to-debugfix-armbian-config-for-kernel-update/

Quoting the issues @hi-ko had from #6828 (comment)

short version

having something like parted ${ARMBIAN_PARTITION} set 1 boot on in arbian-install would have avoided my issue discussed in the forum.

long version

I had three issues, described in the forum thread:

• inconsistent /etc/armbian-release file due to renaming BOARDFAMILY to rockchip64 which broke armbian-config / armbian-install
• unbootable system after running armbian-config to switch/update the kernel (which then may not fit to the bootloader config)
• unbootable system after running armbian-install from sdcard to install into a manual wiped partition due to missing boot flag on that partition

supporting multiple partitions should be always seen as best practice since it may be required to replace the armbian partition from time to time (since there is no such thing like a do-release-upgrade for now). Having one or more data partitions, which will guarantee to survive, could be a life saver then.

That does not necessarily mean, that all scenarios should be supported by the armbian-install. Experienced people have no problems in rsyning the sdcard to a custom partition or to wipe an already used partition but they may need to know the steps expected to be done and the knowledge how to configure/check the bootloader. at least for me u-boot is new territory. I will need to dig into u-boot and your scripts.

So my suggestion to start with is:

we should document (I could help on that)

• the steps to be done manually if not using armbian-install
• the not supported scenarios by armbian-install

features I would like to have are:

• run armbian-install with parameters / without dialogue (e.g. armbian-install --bootloader-mtd-flash /dev/nvme0n1p2 /mnt/armbian/boot/)

Task list

• Improve armbian-install when using multiple partitions by (maybe?) checking/adding a boot flag to the respective partition
• Add documentation as quoted above to https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-sata-nvme-usb (GitHub: https://github.com/armbian/documentation/blob/master/docs/User-Guide_Getting-Started.md )
  • the steps to be done manually if not using armbian-install
  • the not supported scenarios by armbian-install
• (maybe) Add possibility to run armbian-install with parameters / without dialogue (e.g. armbian-install --bootloader-mtd-flash /dev/nvme0n1p2 /mnt/armbian/boot/)

[github-actions]

Jira ticket: AR-2410

[The-going]

A very good place to discuss!

There are two big pitfalls that we can stumble over:

1. GPT or MSDOS partition table.
   Not for all families, the u-boot loader will be able to work correctly on both types of partition tables.

2. The type of file system for partitions (boot, root).
   The bootloader and kernel must support FAT32, EXT4, BTRFS, ZFS, ....

We have to analyze this in some way and offer the user only working options in the selection menu.
Perhaps we can provide this in the write_uboot_platform function?

[SteeManMI]

That information is known at build time. So potentially saving it to /etc/armbian-image-release or /etc/armbian-release (I don't know how they differ) would be the way to access this information at runtime.

[The-going]

That information is known at build time. So potentially saving it to /etc/armbian-image-release or /etc/armbian-release

I think that information about the capabilities of the loader should be located directly in the loader package.
When the loader package is updated and the new package contains advanced functionality, this functionality can be provided to expand the menu options in the armbian-install script.

[SteeManMI]

I agree that makes logical sense. However, I'm concerned with having similar information located in various places around the system. Armbian already has armbianEnv.txt, armbian-release and armbian-image-release (there may be even more that I don't know about). So adding yet another config file may be fine, but when the same information ends up in these different files, the problem is that it often is inconsistent, depending on what gets updated when. Which then leads to confusion and eventually bugs in code in the future. As a new contributor uses information from one of these files only to find out later that that information isn't maintained and that they should be getting that information from a different file.

[hi-ko]

I would suggest to have one generic config (structure) below /etc/armbian/ similar to many other debian packages and the toolset is responsible to do any change (to be done in any other location) to generate all the other config files like armbianEnv.txt on every run.

[The-going]

I agree that makes logical sense. However, I'm concerned with having similar information located in various places around the system. Armbian already has armbianEnv.txt, armbian-release and armbian-image-release (there may be even more that I don't know about). So adding yet another config file may be fine, but when the same information ends up in these different files, the problem is that it often is inconsistent, depending on what gets updated when. Which then leads to confusion and eventually bugs in code in the future. As a new contributor uses information from one of these files only to find out later that that information isn't maintained and that they should be getting that information from a different file.

Okay, I understand your point of view and your concern.

Only we already have the u-boot configuration file in the package of the same name.
And we already have the kernel configuration file in the kernel package.
This information is already enough to offer the user only valid information in the selection menu.

So, we downloaded and launched a new armbian-install script on a running OS (older or newer Armbian).
In your opinion, which menu choice can or does the user want to see?

[The-going]

I would suggest to have one generic config (structure) below /etc/armbian/ similar to many other debian packages and the toolset is responsible to do any change (to be done in any other location) to generate all the other config files like armbianEnv.txt on every run.

We assume that the script file can be downloaded and run on some OS.
Please try to formulate what the user should see in the selection menu
and what the script should be able to do in your opinion without going
into the technical details of the implementation.