add Fedora rootfs installer and first-boot user setup

[katiaTsaruk]

• Bootstrap installer now formats eMMC partition 2 as ext4 and extracts the Fedora rootfs tarball directly from the host PC
• First boot prompts for username/password on the serial console and creates a non-root user with sudo access
• Board IP is printed above the login prompt via /etc/issue so SSH is usable even when the console is noisy

Closes #52

[ozan956]

Since I just discovered https://github.com/analogdevicesinc/br2-external/pull/56/changes#r3715363851

We should be handling both PHYs. Because its not going to work if I use eth1, the other port on the carrier.

Its not in the scope of this PR, so I will open an issue then we can fix it there.

Edit: Actually its in the scope of this PR, since hardcoding end0 can be also problematic. We should detect the links instead of hardcoding the port.

[pamolloy]

Keep it simple. We'll eventually move to Systemd as init.

[katiaTsaruk]

@pamolloy do you want me to revert the current changes I did about it?

[github-actions]

LLM review

This series extends the ev-sc598-som bootstrap installer to also flash a
separately-built Fedora rootfs onto eMMC, and adds first-boot user
provisioning plus a serial-console IP banner to that Fedora rootfs.

run: 30948455226

58e3a15 - bootstrap/overlay/init: download eMMC image and Fedora rootfs

Partition-table race: the script dds a whole-disk image containing a
new partition table onto /dev/mmcblk0, then immediately runs
mkfs.ext4 -F /dev/mmcblk0p2 and mount, with no rescan in between and no
explicit error check (relying only on set -e). This is the same concern
already raised on init:93. It's not just theoretical: busybox's blockdev
applet (--rereadpt/BLKRRPART) is disabled by default in this tree
(buildroot/package/busybox/busybox.config:609), and bootstrap.fragment
pulls in no partprobe equivalent, so there is currently no way for the
initramfs to force the kernel to pick up the newly written table before
formatting it.

Hardcoded eth0: same root cause as the end0 issue below — the SC598
carrier has two PHYs, and hardcoding one interface breaks the installer on
the other port.

2a559ed - ci/mkosi: add first-boot user setup and IP on serial console

Hardcoded end0: firstboot-user.sh:55 only checks end0 for an IP.
The 99-update-issue dispatcher script added in the same commit already
does this correctly by taking the interface from $1 — the same pattern
should be reused here instead of hardcoding a name.

Masking left unexplained: systemd-firstboot.service and
systemd-getty-generator are masked with no comment, as already flagged in
review; a one-line explanation is enough.

Checked (and cleared) as not a bug: the SIGRTMIN+20/SIGRTMIN+21 usage
in firstboot-user.sh against upstream systemd(1) — disable status
messages on entry (+21), re-enable on exit (+20), which is correct.

CI / Buildroot integration

Neither commit touches external.desc, external.mk, Config.in, or any
configs/*_defconfig; only configs/bootstrap.fragment and board/mkosi
assets changed, so no make savedefconfig update is needed. The two new
symbols added to the fragment (BR2_PACKAGE_E2FSPROGS, BR2_PACKAGE_ZSTD)
are valid and correctly satisfy their dependencies. git diff --check is
clean and list-defconfigs still resolves the external tree correctly
against the local buildroot submodule.

Verification data

• Confirmed BR2_PACKAGE_E2FSPROGS/BR2_PACKAGE_ZSTD Kconfig symbols and
  gating directly in the vendored buildroot/ submodule.
• Confirmed # CONFIG_BLOCKDEV is not set in
  buildroot/package/busybox/busybox.config, backing the partition-rescan
  concern with evidence rather than speculation.
• Fetched upstream systemd(1) docs to verify SIGRTMIN+20/21 semantics.
• Ran bash -n on the modified scripts (post-fix), git diff --check, and
  make -C buildroot BR2_EXTERNAL=... list-defconfigs; no full image build
  was run (out of scope here — same flows are already covered by
  top-level.yml's flavor: bootstrap build + adsp/bootstrap hardware
  test, and fedora.yml, which is the right minimal validation scope for
  each of these two commits respectively).

Suggested patches

Apply the suggested patches with:

cd path/to/repository
export GITHUB_TOKEN=ghp_***
apply-patches --repo=analogdevicesinc/br2-external 30948455226

Install instructions

The following one-liner installs the script if not present already:

curl -fSsL "https://raw.githubusercontent.com/analogdevicesinc/doctools/refs/heads/main/ci/scripts/apply-patches.sh"      -o ~/.local/bin/apply-patches.sh &&   grep -q "/apply-patches.sh" ~/.bashrc || echo "source ~/.local/bin/apply-patches.sh" >> $_ ; . $_

More information at AI Usage.

[katiaTsaruk]

In 924608e I replaced all exit calls in the bootstrap init with a rescue_shell() helper that execs /bin/sh. The reason is that init runs as PID 1 in the initramfs, and if PID 1 exits the kernel panics immediately with no useful output.

The helper prints what went wrong and tells the user they can run reboot -f or /init to restart the installer and then hands off to a shell.
The question is, if it is the right solution here, or would it be better to just print the message and loop so the user can't accidentally do something destructive from the shell or get confused or keeping exit with kernel panic was the right thing?
@CalebEthridgeADI, you commented on #30 about this, do you think it is a right approach now?
@pamolloy what do you think about it?

[pamolloy]

In 924608e I replaced all exit calls in the bootstrap init with a rescue_shell() helper that execs /bin/sh. The reason is that init runs as PID 1 in the initramfs, and if PID 1 exits the kernel panics immediately with no useful output.

The helper prints what went wrong and tells the user they can run reboot -f or /init to restart the installer and then hands off to a shell. The question is, if it is the right solution here, or would it be better to just print the message and loop so the user can't accidentally do something destructive from the shell or get confused or keeping exit with kernel panic was the right thing? @CalebEthridgeADI, you commented on #30 about this, do you think it is a right approach now? @pamolloy what do you think about it?

A rescue shell sounds great. It is a very common concept from Linux distros, often implemented in the initramfs. In fact you could even give the user the option to switch into the shell at anytime, but don't worry about that for now.

[pamolloy]

With the clarification on "eMMC image only" vs. "eMMC image + Fedora rootfs"