remove redundant one-shot first-boot workarounds #116

[phillxnet]

At one time these oneshot first boot only systemd services were required to rebuild the initrd image and re-install grub. They now represent a distance with upstream that can only complicate things.

Fixes #116
Hopefully!

Awaiting testing on pr before merging.

[phillxnet]

Testing

Post build on x86_64 profile we have a successful first boot of the installed image. N.B. we still have the kexec issue however.
But our prior systemd service files are no more:

installer:~ # ls -la /usr/lib/systemd/system/dracut_hostonly.service
ls: cannot access '/usr/lib/systemd/system/dracut_hostonly.service': No such file or directory
installer:~ # ls -la /usr/lib/systemd/system/grub_config.service
ls: cannot access '/usr/lib/systemd/system/grub_config.service': No such file or directory

A subsequent reboot with or without installer device attached also boots up just find.

N.B. tested only on non UEFI seup (KVM). We should also test for equivalent behaviour as to that found in:
#82 (comment)

[phillxnet]

Testing boot on UEFI only KVM setup as per: #82 (comment)

and we have the same function as before.
N.B. we do still see our to-be-issued kexec failure where just after our image transfer there is a failure to kexec the newly imaged install and effectively boot it.
But most pertinent to this pr we do have a successful UEFI only boot when the appropriate device is selected from the KVM UEFI firmware. So all is as before we removed the suspected as redundant oneshot on first boot only prior workarounds.
I.e. removing the installer medium after the above results in the installed system booting as expected and by default.

[phillxnet]

Tested boot of raw and qcow2 images for ARM64EFI profile and both were as-was post this proposed change.
Note however that these installers are the end installed image, the transfer of the image, unlike our X86_64 installer, is done by the user. So in this case we do not see the KEXEC issue mentioned above.

[phillxnet]

I have now tested a Pi4 profile build, and from the perspective of this patches changes we appear to have a functional image there also. Like the other ARM images there was no KEXEC handover to the installed image because we started out with the installed image pre-loaded on the intended system disk (a fast USB key in this case).