mkinitcpio-archiso merge requestshttps://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge_requests2024-03-26T13:25:30Zhttps://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge_requests/48hooks/archiso: implement searching for archisodevice2024-03-26T13:25:30Znl6720hooks/archiso: implement searching for archisodeviceIf `archisosearchuuid` is specified, assign `archisodevice`:
* to a device with `UUID=${archisosearchuuid}`, if it exists,
* to a device containing `archisosearchfilename` (`/boot/${archisosearchuuid}.uuid` by default).
This avoids havi...If `archisosearchuuid` is specified, assign `archisodevice`:
* to a device with `UUID=${archisosearchuuid}`, if it exists,
* to a device containing `archisosearchfilename` (`/boot/${archisosearchuuid}.uuid` by default).
This avoids having to specify `archisodevice`.
Related to https://gitlab.archlinux.org/archlinux/archiso/-/issues/217v70nl6720nl6720https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge_requests/27Integrity verification against external source2022-08-12T11:51:40ZTallero TalleroIntegrity verification against external sourceIt adds support for comparing `airootfs` signature against a backup file eventually put on an external device, for example on an integrity dongle.
The signature file can be specified using the `sigdevice` kernel parameter, using the sam...It adds support for comparing `airootfs` signature against a backup file eventually put on an external device, for example on an integrity dongle.
The signature file can be specified using the `sigdevice` kernel parameter, using the same syntax as the one for the `cryptdevice` parameter in the encrypt module, i.e. <br />
```
sigdevice="UUID=<UUID>:<fs_type>:<file_path>"
```
This same feature is provided by the `encrypt` hook in `cryptsetup-sigfile` ([`AUR`](https://aur.archlinux.org/packages/cryptsetup-sigfile))
when the root file system is encrypted because it would be pointless to verify the signature after having tried to unlock a potentially malicious
image.
**Notes**:
this branch is based on !25.https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge_requests/25Make compatible with cryptsetup's encrypt hook2022-10-12T10:27:40ZTallero TalleroMake compatible with cryptsetup's encrypt hookThis merge request makes `archiso` hook compatible with the correct output of the `encrypt` hook, that can so be enabled
and configured to handle LUKS encrypted archiso systems.
### Changes
When the `encrypt` successfully ends, it exp...This merge request makes `archiso` hook compatible with the correct output of the `encrypt` hook, that can so be enabled
and configured to handle LUKS encrypted archiso systems.
### Changes
When the `encrypt` successfully ends, it exports a static `root` variable
containing the path of the device mapper representing the root device
(by default `/dev/mapper/root`).
Since the root device here is on a file on the `bootmnt` and not on a disk directly,
I've changed the cryptsetup `encrypt` hook to support an intermediate mount for `bootmnt`
on `/run/cryptdev`.
Compatibility is obtained by bind mounting `/run/cryptdev` to `bootmnt`
and replacing the loopmount with `root` if it exists.
Value of `archisodevice` has been changed from
`/dev/disk/by-label/$archisolabel` to
`dev/disk/by-uuid/$archisouuid`
to avoid boot problems when multiple `archisolabel`'d devices are inserted.
Depends on [nested cryptkey support](https://aur.archlinux.org/cryptsetup-nested-cryptkey) `cryptsetup` merge request (where should it be submitted for review?).
Solves #14 and #15.
See specular MR on https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/217.