alpine-conf issueshttps://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues2022-05-28T09:03:16Zhttps://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10515Add chroot script2022-05-28T09:03:16ZAnjandev MomiAdd chroot scripthttps://wiki.alpinelinux.org/wiki/Chroot#Performing_the_chroot
I would be willing to submit a MR with this script so it's easier to chroot on a livecd. Will this be accepted?https://wiki.alpinelinux.org/wiki/Chroot#Performing_the_chroot
I would be willing to submit a MR with this script so it's easier to chroot on a livecd. Will this be accepted?https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10514setup-disk: global failure if luks passphrase missmatch2022-05-23T10:45:11Zdonobansetup-disk: global failure if luks passphrase missmatchThe simple solution seems to add this cryptsetup option:
```
--tries, -T
How often the input of the passphrase shall be retried. This
option is relevant every time a passphrase is asked, for example
...The simple solution seems to add this cryptsetup option:
```
--tries, -T
How often the input of the passphrase shall be retried. This
option is relevant every time a passphrase is asked, for example
for open, luksFormat or luksAddKey. The default is 3 tries.
```https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10513setup-desktop: plasma is not mentioned in usage2022-05-23T11:52:37ZDekedrosetup-desktop: plasma is not mentioned in usagehttps://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10512setup-disk: Honor BOOT_SIZE environment variable for EFI install2022-05-11T21:52:52ZDavesetup-disk: Honor BOOT_SIZE environment variable for EFI installIn `setup-disk`, native_disk_install() and native_disk_install_lvm() will look at the environment variable BOOT_SIZE and use it to specify how much space to give to the boot partition. If BOOT_SIZE is not specified, there is a default. L...In `setup-disk`, native_disk_install() and native_disk_install_lvm() will look at the environment variable BOOT_SIZE and use it to specify how much space to give to the boot partition. If BOOT_SIZE is not specified, there is a default. Like so:
```
local boot_size=${BOOT_SIZE:-100}
```
However, with EFI it's a fixed value with no option to override the size.
```
BOOT_SIZE=512
```
I don't think 512M is a magic number. After researching the minimum size for EFI, I have seen anything from 32M to 550M being quoted as the proper size. Personally, I've used 100M EFI partitions on Virtualbox and Intel NUC with no problems.
>Some discussion on the topic: https://superuser.com/questions/1310927/what-is-the-absolute-minimum-size-a-uefi-system-partition-can-be#1310938
It would be nice if `export BOOT_SIZE=XXX ; setup-alpine` could be made to work for EFI installs the same way it does for non-EFI.
The quickest fix seems to be the change shown below.
```
--- setup-disk.orig
+++ setup-disk
@@ -1435,7 +1435,7 @@
if is_efi || [ -n "$USE_EFI" ]; then
USE_EFI=1
DISKLABEL=gpt
- BOOT_SIZE=512
+ BOOT_SIZE=${BOOT_SIZE:-512}
BOOTFS=vfat
: ${BOOTLOADER:=grub}
fi
```
I've tested it on a Virtualbox install (with EFI enabled) using `export BOOT_SIZE=100 ; setup-alpine` and it works as expected.
Alternatively, if one does not buy into the _EFI must be 512M_ line of reasoning, BOOT_SIZE=512 can be removed from setup-disk and everything will work just fine.https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10511lbu: support backups of multiple hosts on one device2022-05-13T06:04:11ZRoland Pabellbu: support backups of multiple hosts on one deviceI have two computers running apline and would like to use the same usb stick to save their lbu backup files. But lbu complains when there are two apkovl files present:
~~~
two:/mnt# lbu ci
The following apkovl file(s) were found:
/media...I have two computers running apline and would like to use the same usb stick to save their lbu backup files. But lbu complains when there are two apkovl files present:
~~~
two:/mnt# lbu ci
The following apkovl file(s) were found:
/media/usb/one.apkovl.tar.gz
/media/usb/two.apkovl.tar.gz
Please use -d to replace.
~~~
I understand that apkovl is the active file, since backup_apkovl() in lbu replaces "apkovl" with the date.
But I think the functionality could easily be enabled if lbu would only consider files starting with the hostname, which is true almost everywhere except in these 3 occasions in function cmd_commit():
~~~
line 453: local rmfiles=$(ls "$mnt/"*.apkovl.tar.gz* 2>/dev/null)
line 460: [ -z "$DRYRUN" ] && rm "$mnt/"*.apkovl.tar.gz*
line 463: lines=$(ls -1 "$mnt"/*.apkovl.tar.gz* 2>/dev/null)
~~~
I changed these locally to `${hostname}.*.apkovl.tar.gz` and that works as expected.
What I don't know is: Is this by design? Should there ever only be one apkovl file on any given device?https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10510unattended installs for lxd2024-01-26T13:10:48ZEzequiel Bruniunattended installs for lxdHere's the thing: I'm kind of a newbie in the sysadmin/Alpine world. I'm using it a lot for LXD containers, and I'm getting a little tired of running a full setup-alpine process every time I spin up a new container. Currently, when I gen...Here's the thing: I'm kind of a newbie in the sysadmin/Alpine world. I'm using it a lot for LXD containers, and I'm getting a little tired of running a full setup-alpine process every time I spin up a new container. Currently, when I generate an answer file, it just has some defaults, right? And it doesn't list every possible setting available on my platform.
I haven't been able to find a list of all possible settings that you can put in an answer file, and I _still_ haven't figured out how to select just "dhcp" in the networking section without breaking my containers. I don't know what to do with the sort of "grid" of networking options in the default answer file.
I'd love it if I could generate an answer file from one of my current container configurations, or at least generate a custom answer file _while_ I go through the setup-alpine script one more time. Would that be at all possible?
(And yes, I've read all the docs I can find on the subject, but I still feel like I'm missing something.)https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10509setup-interface: [security][wpa_supplicant][wpa_passphrase] WiFi password / P...2022-04-19T12:15:08ZSiu Ching Pong -Asuka Kenji-setup-interface: [security][wpa_supplicant][wpa_passphrase] WiFi password / PSK being leaked to unprivileged user after setupLet's mimic the code in `setup-interface` [here](https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-interfaces.in#L143) and try executing `wpa_passphrase`:
```
# wpa_passphrase router_ssid password_123456
network={
ss...Let's mimic the code in `setup-interface` [here](https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-interfaces.in#L143) and try executing `wpa_passphrase`:
```
# wpa_passphrase router_ssid password_123456
network={
ssid="router_ssid"
#psk="password_123456"
psk=10714215f131837c4c22a6d98065204c0aa2803fe445cd72663a49296b1d9547
}
```
As you can see, the plaintext password is shown in the output.
The current implementation for invoking `wpa_passphrase`, as shown below, has severe problems:
```sh
wpa_passphrase "$essid" "$psk" >> "$conffile"
```
1. The plaintext password is stored in `/etc/wpa_supplicant/wpa_supplicant.conf`, which defeats virtually any cyber security guideline.
1. Even if the above line is removed, the file `/etc/wpa_supplicant/wpa_supplicant.conf` is still world readable, letting any unprivileged user on the same machine to read it. Then, he can copy the pre-shared key (PSK), use it on his own device, connect to the router, and potentially do harm to the network.
Unfortunately, there seems to be no option to suppress `wpa_passphrase` from printing out the plaintext password, therefore we should remove it immediately after the config file is created (or updated), as shown below:
```diff
diff --git a/setup-interfaces.in b/setup-interfaces.in
index e6cbf57..3ba6096 100644
--- a/setup-interfaces.in
+++ b/setup-interfaces.in
@@ -140,7 +140,8 @@ config_wpa_supp() {
local iface="$1" essid="$2" auth_type="$3" psk="$4"
local conffile=/etc/wpa_supplicant/wpa_supplicant.conf
if [ "$auth_type" = "WPA-PSK" ]; then
- wpa_passphrase "$essid" "$psk" >> "$conffile"
+ (umask 0077 && wpa_passphrase "$essid" "$psk" >> "$conffile")
+ sed -i -e '/^\t#psk=.*/d' "$conffile"
else
cat << EOF >> $conffile
network={
```https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10508Why not config ntp if qemu guest2022-07-05T12:46:46ZBruceWhy not config ntp if qemu guestTechnically, this is not an issue, but a question.
I am wondering why this commit #8a4c35a42708c497288315e6133c9074e9757073 was added, in which the `setup-ntp` is not called if qemu guest.Technically, this is not an issue, but a question.
I am wondering why this commit #8a4c35a42708c497288315e6133c9074e9757073 was added, in which the `setup-ntp` is not called if qemu guest.https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10506setup-disk fails when installing over identical previous installation2022-11-17T14:28:12ZUniqueActivesetup-disk fails when installing over identical previous installationHello,
while instaling in "sys" mode, setup-disk fails to install on top of an identical previous installation in most cases, the behaviour produces this output:
```
[...]
WARNING: Erase the above disk(s) and continue? (y/n) [n] y
Part...Hello,
while instaling in "sys" mode, setup-disk fails to install on top of an identical previous installation in most cases, the behaviour produces this output:
```
[...]
WARNING: Erase the above disk(s) and continue? (y/n) [n] y
Partition #1 contains a ext4 signature.
Partition #2 contains a swap signature.
Partition #3 contains a ext4 signature.
Creating file systems...
The file /dev/sda1 does not exist and no size was specified.
The file /dev/sda3 does not exist and no size was specified.
mount: mounting /dev/sda3 on /mnt failed: No such file or directory
```
Sometimes either `/dev/sda1` or `/dev/sda3` are recognized, rarely both, meaning that this operation fails the overwhelming majority of times.
## Solution
As I had previously seen funky behaviour with `sfdisk` when creating partitions on top of existing identical partitions, I remembered that the following consistently worked:
1. Create new disklabel
2. Create partitions (and optionally wipe signatures)
Doing both in one command as it is currently being done in line 848 of the script does not work reliably.
I suggest first running this to create the label:
```
echo "label: $DISKLABEL" | sfdisk --quiet $diskdev
```
Then modifying line 850 to look like this:
```
) sfdisk --quiet $diskdev
```
Even better would be this, to also wipe the previous signatures, otherwise you need to confirm overwriting the previous signatures again with the mkfs.$whatever commands:
```
) sfdisk --quiet -w always -W always $diskdev
```
Perhaps this is also needed in other places, I am not sure. I will submit a patch fixing this particular instance, please let me know if you have feedback!https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10505setup-disk: enable keymap feature in mkinitfs when crypt is used2022-02-19T17:36:12ZSören Tempelsetup-disk: enable keymap feature in mkinitfs when crypt is usedWhen the crypt installation option is used, the keymap feature should automatically be enabled in mkinitfs. Otherwise, users may have to enter their FDE password with an unfamiliar keymap.When the crypt installation option is used, the keymap feature should automatically be enabled in mkinitfs. Otherwise, users may have to enter their FDE password with an unfamiliar keymap.https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10504setup-sshd: prompt if root login should be enabled2022-05-11T21:52:52ZSören Tempelsetup-sshd: prompt if root login should be enabledNowadays, OpenSSH's `PermitRootLogin` option defaults to `prohibit-password` thereby not allowing root login without a password by default. However, since setup-alpine does not configure any additional unprivileged user accounts you migh...Nowadays, OpenSSH's `PermitRootLogin` option defaults to `prohibit-password` thereby not allowing root login without a password by default. However, since setup-alpine does not configure any additional unprivileged user accounts you might end up with a system where you cannot login over SSH.
The OpenBSD installer resolves this by asking if root login should be enabled for OpenSSH or, alternatively, also allows configuring an unprivileged user account in the installer. IMHO setup-sshd should also prompt the user to check if root login should be enabled.https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10503[3.15] setup-alpine in headless situation altered by network restart2022-03-16T09:41:51Zmacmpi[3.15] setup-alpine in headless situation altered by network restart@ncopa Since Alpine 3.15, the following change https://gitlab.alpinelinux.org/alpine/alpine-conf/-/commit/39c91c1486c55ce1ee3ec1e646032d04e21406ed, which unconditionally forces network interfaces restart during `setup-alpine`, breaks abi...@ncopa Since Alpine 3.15, the following change https://gitlab.alpinelinux.org/alpine/alpine-conf/-/commit/39c91c1486c55ce1ee3ec1e646032d04e21406ed, which unconditionally forces network interfaces restart during `setup-alpine`, breaks ability to configure Alpine in headless situation (like under pre-existing ssh session), as the session gets disconnected within setup-alpine script execution...
How about making such networking restart conditional with a setup-alpine parameter, or include a sanity-check to prevent it if ongoing network communication is already active, or ask user for explicit confirmation for restarting interfaces in interactive mode?
Thanks for consideration.
EDIT: maybe sth similar might be needed to avoid ssh install collision with pre-existing headless session too...https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10502setup-disk: NVMe not added to initfs_features if installing on RAID1+LVM+NVMe2022-05-18T06:43:41ZDoug Swarinsetup-disk: NVMe not added to initfs_features if installing on RAID1+LVM+NVMeIf installing on LVM+RAID1 to two NVMe devices, the NVMe feature is not added to `initfs_features` in `install_mounted_root()`. I think on modern systems that NVMe is becoming prevalent enough that it should be added by default to `initf...If installing on LVM+RAID1 to two NVMe devices, the NVMe feature is not added to `initfs_features` in `install_mounted_root()`. I think on modern systems that NVMe is becoming prevalent enough that it should be added by default to `initfs_features` rather than being detected later in the function. As an alternate solution, an environment variable could be added (e.g. `$ADDITIONAL_INITFS_FEATURES`) to allow forcing features without needing to modify `setup-disk` before installing (but I think this would be less user-friendly).
To reproduce, install on a system with two NVMe devices (e.g. `nvme0n1` and `nvme1n1`). Install as `lvmsys` and specify both devices on the same line to set them up as RAID1. After rebooting, the system will be unable to start as the NVMe driver will not be loaded early enough. Adding `nvme` to the default `initfs_features` list in `setup-disk` before installing corrects this issue.https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10501setup-disk: Allow specification of LVM size2022-07-12T15:16:05ZDoug Swarinsetup-disk: Allow specification of LVM sizeIt's not currently possible to specify the size of the LVM partition during installation. This would be a trivial change which would allow leaving free space on the specified root disk(s) after install.
In `setup-disk.in` in `native_dis...It's not currently possible to specify the size of the LVM partition during installation. This would be a trivial change which would allow leaving free space on the specified root disk(s) after install.
In `setup-disk.in` in `native_disk_install_lvm()`, all that is necessary is to replace:
```shell
local lvm_size=
```
with:
```shell
local lvm_size=${LVM_SIZE}
```https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10500Add support for syslinux EFI in setup-disk2022-04-01T09:44:36ZPhilippe SchommersAdd support for syslinux EFI in setup-diskHi,
I'd really like to be able to use `setup-disk` with `syslinux` for an EFI system.
Currently, one needs to mount the EFI partition on `/boot/efi`, and only `bootx64.efi` will be installed by `grub-efi` on that partition, keeping the ...Hi,
I'd really like to be able to use `setup-disk` with `syslinux` for an EFI system.
Currently, one needs to mount the EFI partition on `/boot/efi`, and only `bootx64.efi` will be installed by `grub-efi` on that partition, keeping the kernel and stuff out of it.
What I'd like to achieve is having the EFI partition mounted on `/boot`, so that `initramfs` and `vmlinuz` end up on the EFI partition (which is required for `syslinux` as far as I know, as the root would be on LVM).
I think this goes well in line with the Alpine philosophy.
Is this something you'd be interested in / that would get merged if I opened a PR? If so, is there something I should be mindful of?
Maybe this could be done with a `syslinux-efi` package? One thing I noticed is that installing `syslinux` automatically "pollutes" `/boot` with `.m32` and `.sys` as well as `extlinux.conf` files, which are not required for an EFI setup. Is there a way around this?https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10499setup-disk: Install to virtiofs2023-01-26T15:11:54ZMuskwa Sissetup-disk: Install to virtiofsWhen attempting to use root on virtiofs we get this error:
```
localhost:~# setup-disk /mnt
ERROR: unable to select packages:
u-boot (no such package):
required by: world[u-boot]
virtiofs is not supported. Only supported are: ext2...When attempting to use root on virtiofs we get this error:
```
localhost:~# setup-disk /mnt
ERROR: unable to select packages:
u-boot (no such package):
required by: world[u-boot]
virtiofs is not supported. Only supported are: ext2 ext3 ext4 btrfs xfs vfat
```
The goal here is to be able to use virtiofs as the root directory.
https://virtio-fs.gitlab.io/howto-boot.html
We might need more than just allowing virtiofs here, since in my environment running
```
mount -t virtiofs share /mnt
```
Creates `/mnt/alpine`, where alpine is the name of the shared directory in the host.https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10498setup-disk crypt doesn't add mkinitfs disk features2022-05-18T06:43:42ZAlex Xu (Hello71)setup-disk crypt doesn't add mkinitfs disk featureshttps://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10497setup-disk does not install e2fsprogs via install_mounted_root()2022-07-01T16:34:21ZLucid Onesetup-disk does not install e2fsprogs via install_mounted_root()Trying to generally follow [this](https://wiki.alpinelinux.org/wiki/Classic_install_or_sys_mode_on_Raspberry_Pi) on an RPI4
`/sbin/setup-disk -v -m sys /mnt` does not install `e2fsprogs` when ROOTFS="ext4"
Also, it looks like `init_pr...Trying to generally follow [this](https://wiki.alpinelinux.org/wiki/Classic_install_or_sys_mode_on_Raspberry_Pi) on an RPI4
`/sbin/setup-disk -v -m sys /mnt` does not install `e2fsprogs` when ROOTFS="ext4"
Also, it looks like `init_progs()` is not called by `install_mounted_root()` which I guess makes sense if you don't need `sfdisk` but you still need `e2fsprogs` to `fsck` so \o/.
I'm happy to generate a MR but I'm not sure why the code paths seem so different between `native_disk_install()` and `install_mounted_root()`.https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10496[diskless mode] lbu ignoring whole directory instead of one file2021-11-30T14:44:34ZCi7rix[diskless mode] lbu ignoring whole directory instead of one fileWhen using lbu on diskless installation to ignore `etc/zfs/zpool.cache` config file in `/etc/zfs`, the whole folder is ignored.
Steps to reproduce :
1. Create a bootable disk with `setup-bootable` from Alpine 3.15.0 x86_64 Extended ISO...When using lbu on diskless installation to ignore `etc/zfs/zpool.cache` config file in `/etc/zfs`, the whole folder is ignored.
Steps to reproduce :
1. Create a bootable disk with `setup-bootable` from Alpine 3.15.0 x86_64 Extended ISO
1. Boot from it
1. Install zfs : `apk add zfs`
1. Import existing tank : `zfs import tank`
1. Exclude cache file : `lbu exclude /etc/zfs/zpool.cache`
1. The whole `/etc/zfs` directory is now ignored
Thankshttps://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10495setup-alpine : error message when using/creating a vlan interface2022-07-05T16:17:57Zbltsetup-alpine : error message when using/creating a vlan interface```
Which one do you want to initialize? (or '?' or 'done') [eth0] vlan130
Available raw devices are: eth0.
Which one do you want use for vlan130? (or 'done') [eth0]
```
results to
```
ERROR: unable to select packages:
vlan-2.2-r2:
...```
Which one do you want to initialize? (or '?' or 'done') [eth0] vlan130
Available raw devices are: eth0.
Which one do you want use for vlan130? (or 'done') [eth0]
```
results to
```
ERROR: unable to select packages:
vlan-2.2-r2:
breaks: ifupdown-ng-0.11.3-r0[!vlan]
satisfies: world[vlan]
```
vlan interface is working fine but the error can be confusing for a user