alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2024-02-07T09:01:15Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15744Mounting an XFS filesystem breaks on Alpine 3.192024-02-07T09:01:15ZLars AndringaMounting an XFS filesystem breaks on Alpine 3.19For our infrastructure, we mount a file-based XFS filesystem into our Alpine docker container:
```
apk update && apk add xfsprogs xfsprogs-extra
touch xfs.bin && mkfs.xfs -d size=5g -n ftype=1 xfs.bin && mkdir /xfs
mount -o prjquota -t x...For our infrastructure, we mount a file-based XFS filesystem into our Alpine docker container:
```
apk update && apk add xfsprogs xfsprogs-extra
touch xfs.bin && mkfs.xfs -d size=5g -n ftype=1 xfs.bin && mkdir /xfs
mount -o prjquota -t xfs xfs.bin /xfs
```
The mount fails with the following error:
```
mount: mounting /dev/loop2 on /xfs failed: Invalid argument
```
I start the docker container using:
```
docker run -it --privileged alpine:3.19
```
This used to work perfectly fine on alpine:3.18https://gitlab.alpinelinux.org/alpine/aports/-/issues/15743Add GitLab bot to automate package upgrades2024-02-04T14:07:34ZSören TempelAdd GitLab bot to automate package upgradesI noticed the other day that [Wolfi](https://wolfi.dev/) has a [GitHub Bot](https://wolfi.dev/) for automating packages upgrade (CC: @ariadne). The bot uses [release-monitoring.org](https://release-monitoring.org) to determine if a new r...I noticed the other day that [Wolfi](https://wolfi.dev/) has a [GitHub Bot](https://wolfi.dev/) for automating packages upgrade (CC: @ariadne). The bot uses [release-monitoring.org](https://release-monitoring.org) to determine if a new release is available and then [creates a pull request](https://github.com/wolfi-dev/wolfictl/blob/main/docs/update.md) for bumping the affected packages to that release. Naturally, this only works unless the package requires changes (e.g. new patches). If the build fails, the bot therefore [creates an issue](https://github.com/wolfi-dev/wolfictl), such an issue can then be assigned to the package maintainer. I think something like this could be extremely beneficial for Alpine as well as it automated the boring package upgrades and reduces the amount of manual labor required to deal with those, thereby freeing capacities for other stuff.
See also:
* https://github.com/wolfi-dev/wolfictl/blob/main/docs/update.md
* https://github.com/wolfi-dev/wolfictl/blob/main/docs/cmd/wolfictl_update.md
* https://github.com/wolfi-dev/wolfictl/blob/main/docs/cmd/wolfictl_update_package.mdhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15742texlive-luatex: lualatex and zlib version mismatch2024-02-19T08:26:06ZEric Skoglundtexlive-luatex: lualatex and zlib version mismatchThe current version of texlive-luatex is built against `zlib 1.3`. That package got updated to `1.3.1` in [this](https://git.alpinelinux.org/aports/commit/main/zlib?id=c9225fb0e5f25bffbe87461a9aa360b9249975c5) commit 10 days ago. This br...The current version of texlive-luatex is built against `zlib 1.3`. That package got updated to `1.3.1` in [this](https://git.alpinelinux.org/aports/commit/main/zlib?id=c9225fb0e5f25bffbe87461a9aa360b9249975c5) commit 10 days ago. This breaks texlive-luatex and gives the following error when trying to build tex files `PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.3, library: 1.3.1)`.
A rebuild against `zlib 1.3.1` should fix the issue (see also this issue for a previous version https://gitlab.alpinelinux.org/alpine/aports/-/issues/15239)
```plaintext
/ # luatex --credits
This is LuaTeX, Version 1.17.0 (TeX Live 2023/Alpine Linux)The LuaTeX team is Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso.LuaTeX merges and builds upon (parts of) the code from these projects:tex : Donald Knuth
etex : Peter Breitenlohner, Phil Taylor and friends
omega : John Plaice and Yannis Haralambous
aleph : Giuseppe Bilotta
pdftex : Han The Thanh and friends
kpathsea : Karl Berry, Olaf Weber and others
lua : Roberto Ierusalimschy, Waldemar Celes and Luiz Henrique de Figueiredo
metapost : John Hobby, Taco Hoekwater, Luigi Scarso, Hans Hagen and friends
pplib : Paweł Jackowski
fontforge : George Williams (partial)
luajit : Mike Pall (used in LuajitTeX)Compiled with libpng 1.6.40; using 1.6.40
Compiled with lua version 5.3.6
Compiled with mplib version 2.02
Compiled with zlib 1.3; using 1.3.1
Development id: 7581
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/15741aports/community/amfora: please add ncurses dependency to APKBUILD2024-02-04T17:41:58ZCarlo Monteaports/community/amfora: please add ncurses dependency to APKBUILDinfocmp is part of the ncurses package.
Installing ncurses solves the following problem (as suggested by the author in a separate thread):
```
panic: exec: "infocmp": executable file not found in $PATH
goroutine 1 [running]:
main.main(...infocmp is part of the ncurses package.
Installing ncurses solves the following problem (as suggested by the author in a separate thread):
```
panic: exec: "infocmp": executable file not found in $PATH
goroutine 1 [running]:
main.main()
github.com/makeworld-the-better-one/amfora/amfora.go:72 +0x788
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/15740The latest git change breaks some CICD2024-03-28T13:37:30ZMorlandThe latest git change breaks some CICDHi guys!
It seems like apline recently introduced some updates in the git apk: https://git.alpinelinux.org/aports/commit/main/git/APKBUILD?id=81e0ab5e96559a2d77cc45cff3defe7ee8ef358e. And I noticed this change was suppose to install tem...Hi guys!
It seems like apline recently introduced some updates in the git apk: https://git.alpinelinux.org/aports/commit/main/git/APKBUILD?id=81e0ab5e96559a2d77cc45cff3defe7ee8ef358e. And I noticed this change was suppose to install templates only when git-doc installed: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/59248. This new behaviour will generate a very slim `.git` folder because all default templates were removed from the clean installation.
This will actually break some CICD systems. We noticed this because we have a pipeline that exported some exclusion rules using: `echo "rules" >> .git/info/exclude"`. This is not working now as `info` won't be created from the empty templates. (Default template includes some comments inside the `exclude` file even though it doesn't has any rule). I know it's easy to fix by just create the folder using `mkdir -p .git/info`. However, I feel this improvements will break lots of images out there because of the lacking of some empty files. Do you think it's a good idea to do so? I know the concept of alpine is to deliver a small, clean and easy to use baseos, but isn't it a bit too opinionated in this case?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15739community/loki: Package does not create "loki" user2024-02-04T16:54:20Zchimo omichcommunity/loki: Package does not create "loki" userOn a fresh Alpine 3.19:
`# apk add loki && service loki start`
```
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/APKINDEX.tar.gz
(1/2) I...On a fresh Alpine 3.19:
`# apk add loki && service loki start`
```
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/APKINDEX.tar.gz
(1/2) Installing loki (2.9.2-r0)
(2/2) Installing loki-openrc (2.9.2-r0)
Executing busybox-1.36.1-r15.trigger
OK: 80 MiB in 32 packages
* Caching service dependencies ... [ ok ]
* Starting loki ...
* start-stop-daemon: user `loki' not found
* Failed to start loki [ !! ]
* ERROR: loki failed to start`
```
The `grafana' group might need to be created too.Michael PirogovMichael Pirogovhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15738Stuck at boot "Loading initramfs-virt..."2024-02-01T19:44:57Zleo852Stuck at boot "Loading initramfs-virt..."I am currently using:
https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.1-x86_64-bios-cloudinit-r0.qcow2
I am using this image with proxmox kvm. Whenever I boot the vm, it's stuck at boot "Loading initramfs-...I am currently using:
https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.1-x86_64-bios-cloudinit-r0.qcow2
I am using this image with proxmox kvm. Whenever I boot the vm, it's stuck at boot "Loading initramfs-virt...". No matter how long I wait, it will still stuck there. I've tried giving it more resources, such as ram, cpu or even more nvme, it's still stuck. And it will always full load the first core, so ~100% if I give it one core, ~50% if I give 2 cores, and ~ 25% if I give 4 cores.
![image](/uploads/f03b33599ad0484894c8fae6fc828f60/image.png)
![image](/uploads/7a91b3dd25bb5d63b96037fe521eff9b/image.png)
![image](/uploads/7aae2dd07b8b5182c6fa8221a8bdeb2f/image.png)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10972package version formatting2024-03-27T16:28:48ZSertonixpackage version formattingThe issue has mutated to a discussion about the version formatting in general.
Related !144, #7100, #10816
## Old description
The version format for virtual packages (`YYYYmmdd.HHMMSS`) doesn't include a `pkgrel` like packages normall...The issue has mutated to a discussion about the version formatting in general.
Related !144, #7100, #10816
## Old description
The version format for virtual packages (`YYYYmmdd.HHMMSS`) doesn't include a `pkgrel` like packages normally have (`<pkgver>-r<pkgrel>`).
This creates ambiguity in the output of the `apk list` command. Normally it is enough the strip the last 2 dashes but that doesn't work with the version format of virtual packages:
- `<pkgname>-<pkgver>-r<pkgrel>`
- `<pkgname>-YYYYmmdd.HHMMSS`
I suggest adding `-r0` to the version of virtual packages [`app_add.c#L118`](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/acefa1acc1ce0e1871d17b4eafe4b1888f45d4d0/src/app_add.c#L118). !132 does fix the `apk list` problem too but a consistent version format would still be better.v3.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/15737ps -> procps-ng@edge >&2 get_mempolicy: Function not implemented2024-03-27T19:28:59ZMatthias Dienerps -> procps-ng@edge >&2 get_mempolicy: Function not implementedThe **ps** binary in the **procps-ng** package is giving a message to stderr: ...The **ps** binary in the **procps-ng** package is giving a message to stderr:
get_mempolicy: Function not implemented
(beside that it is working properly)
This is in **edge** and happened after the numactl update, so I asume it might be connected, even if they are not linked...
Important. It only happens with the **linux-virt** kernel, where NUMA is not configured. With linux-edge, everything is fine.Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15736let abuild manage GOCACHE, GOMODCACHE, GOTMPDIR, CARGO_HOME2024-03-21T17:52:00ZSertonixlet abuild manage GOCACHE, GOMODCACHE, GOTMPDIR, CARGO_HOMEWhen the `MOVE_CACHES` environmental variable is set abuild will export `GOCACHE`, `GOMODCACHE`, `GOTMPDIR`, `CARGO_HOME`.
A lot of `APKBUILD` files export these variables too though. I suggest removing the exports from the `APKBUILD` f...When the `MOVE_CACHES` environmental variable is set abuild will export `GOCACHE`, `GOMODCACHE`, `GOTMPDIR`, `CARGO_HOME`.
A lot of `APKBUILD` files export these variables too though. I suggest removing the exports from the `APKBUILD` files.
Since this would be a larger effort I want to know some opinions on that before starting.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15735DHCP fails on netboot in system with dual port NIC since 3.19.12024-02-04T01:11:37ZScott YeagerDHCP fails on netboot in system with dual port NIC since 3.19.1I've been testing network booting Alpine 3.19 on bare metal. At version 3.19.0, the system was able to boot up. In version 3.19.1, something has changed and `udhcpc` no longer obtains a lease, so the system doesn't finish booting.
My bo...I've been testing network booting Alpine 3.19 on bare metal. At version 3.19.0, the system was able to boot up. In version 3.19.1, something has changed and `udhcpc` no longer obtains a lease, so the system doesn't finish booting.
My boot method is via iPXE with no special kernel args. Two routes produce the same result:
1. [3.19.1 archive](https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/x86_64/alpine-netboot-3.19.1-x86_64.tar.gz) extracted to my local web server and an iPXE script based on the [wiki example](https://wiki.alpinelinux.org/wiki/Netboot_Alpine_Linux_using_iPXE)
2. Booting the latest 3.19 artifacts directly from Alpine CDN using netboot.xyz
The system in question has a dual port NIC, `eth0` and `eth1`, with only `eth1` plugged in. Perhaps the issue is that lease solicitation is only happening on `eth0`, but I haven't tested swapping the ethernet cable to `eth0`. If I boot from a 3.19.1 standard ISO, I can bring up `eth1` and obtain a lease with `udhcpc` manually by targeting the interface specifically.
Hardware is Intel Xeon D-1518 SOC using integrated NIC.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15734main/grub-efi: 2.12 breaking boot in Alpine edge2024-01-30T21:54:44ZMayathebeeemain/grub-efi: 2.12 breaking boot in Alpine edgeHi, the latest introduction of `grub-efi` v2.12 seem to break some systems (and it broke mine, as well as this person's: https://www.reddit.com/r/linuxquestions/comments/19bhw7k/hot_to_fix_grub_on_alpine_linux/), I had to manually revert...Hi, the latest introduction of `grub-efi` v2.12 seem to break some systems (and it broke mine, as well as this person's: https://www.reddit.com/r/linuxquestions/comments/19bhw7k/hot_to_fix_grub_on_alpine_linux/), I had to manually revert back to `2.06-r17` and re-run `grub-install` to make Alpine boot again.
I've seen [this draft](https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.20.0) around the Alpine 3.20 release, however the proposed fix doesn't seem to work, because running `grub-install` on `2.12` still made grub crash, but the same procedure after downgrading to `2.06-r17` made my system functional again.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/78Future of init systems (pid-1, service manager)2024-02-13T17:11:37ZSertonixFuture of init systems (pid-1, service manager)The current init stack (busybox init + openrc) has it's flaws.
Current efforts exist to at least allow other configurations (https://gitlab.alpinelinux.org/alpine/aports/-/issues/15725).
There are a lot of possible alternatives but the...The current init stack (busybox init + openrc) has it's flaws.
Current efforts exist to at least allow other configurations (https://gitlab.alpinelinux.org/alpine/aports/-/issues/15725).
There are a lot of possible alternatives but the ones where I have seen people interested in are `dinit` (from @PureTryOut) and `s6-linux-init`+`s6-rc` (from @skarnet).
These are some questions that arise and that might effect a lot of packages:
- Do we want to allow changing pid-1 / service manager? (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/59848)
- Do we want to support multiple pid-1 / service managers? (`dinit`, `runit`, `s6-linux-init`, `s6-rc` are already packaged)
- Do we want to change the default pid-1 / service manager?
I try to create a unified service format that can get converted into at least the `dinit`, `openrc` and `s6-rc` formats (Current status: [sertonix/cross-services](https://gitlab.alpinelinux.org/sertonix/cross-services)). When that works supporting multiple service managers shouldn't be that big of a maintenance problem.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15733If pam-rundir and elogind are both installed, gnome desktop won't launch from...2024-02-01T17:30:46ZAhmad RaniriIf pam-rundir and elogind are both installed, gnome desktop won't launch from tty.Recently I can't launch gnome desktop from tty, using display manager is just fine. After I searched for solution I found this [post](https://www.reddit.com/r/voidlinux/comments/vpjvbr/how_to_change_elogind_to_seatd_on_void_msul_with/). ...Recently I can't launch gnome desktop from tty, using display manager is just fine. After I searched for solution I found this [post](https://www.reddit.com/r/voidlinux/comments/vpjvbr/how_to_change_elogind_to_seatd_on_void_msul_with/). It's said that pam-rundir and elogind are not supposed to be installed at the same time or we should not have them in the same system. After I removed pam-rundir, I can launch gnome desktop from tty.
Before I removed pam-rundir, I got this in /var/log/messages
```
auth.warn elogind[2376]: Directory "/run/user" already exists, but has mode 0775 that is too permissive (0755 was requested), refusing.
```
After removed pam-rundir, that message disappear.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15732REQUEST: Implement AXP20X + ANALOGIX ANX6345 drivers in linux-lts/edge for OL...2024-03-27T19:28:58ZJacob HrbekREQUEST: Implement AXP20X + ANALOGIX ANX6345 drivers in linux-lts/edge for OLIMEX Teres-IContext: I don't know how you manage your linux-lts/edge and i don't want to disrupt that so submitting it in this way.
These drivers are needed for OLIMEX Teres-I to work on Alpine and subsequently on postmarketOS without issues, curre...Context: I don't know how you manage your linux-lts/edge and i don't want to disrupt that so submitting it in this way.
These drivers are needed for OLIMEX Teres-I to work on Alpine and subsequently on postmarketOS without issues, currently the device fails to set voltages for the card and get a functional display
> Card did not respond to voltage select! : -110
..after the u-boot phase (using u-boot that was previously tested with a working kernel to work without issues):
```
U-Boot SPL 2024.01 (Jan 18 2024 - 19:32:49 +0100)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.10.0 (debug):
NOTICE: BL31: Built : 01:25:38, Dec 4 2023
NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE: BL31: Found U-Boot DTB at 0x20a2d98, model: Olimex A64 Teres-I
INFO: ARM GICv2 driver initialized
INFO: Configuring SPC Controller
INFO: PMIC: Probing AXP803 on RSB
INFO: PMIC: aldo1 voltage: 2.800V
INFO: PMIC: dcdc1 voltage: 3.300V
INFO: PMIC: dcdc5 voltage: 1.500V
INFO: PMIC: dcdc6 voltage: 1.100V
INFO: PMIC: dldo1 voltage: 3.300V
INFO: PMIC: dldo2 voltage: 2.500V
INFO: PMIC: dldo3 voltage: 1.200V
INFO: PMIC: dldo4 voltage: 3.300V
INFO: PMIC: fldo1 voltage: 1.200V
INFO: PMIC: Enabling DC SW
INFO: BL31: Platform setup done
INFO: BL31: Initializing runtime services
INFO: BL31: cortex_a53: CPU workaround for erratum 843419 was applied
INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied
INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
INFO: PSCI: Suspend is unavailable
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x4a000000
INFO: SPSR = 0x3c9
U-Boot 2024.01 (Jan 18 2024 - 19:32:49 +0100) Allwinner Technology
CPU: Allwinner A64 (SUN50I)
Model: Olimex A64 Teres-I
DRAM: 2 GiB
Core: 74 devices, 24 uclasses, devicetree: separate
WDT: Not starting watchdog@1c20ca0
MMC: mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In: serial,usbkbd
Out: serial,vidconsole
Err: serial,vidconsole
Net: No ethernet found.
starting USB...
Bus usb@1c1b000: USB EHCI 1.00
scanning bus usb@1c1b000 for devices... EHCI timed out on TD - token=0x80008c80
4 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Card did not respond to voltage select! : -110
BootOrder not defined
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootaa64.efi
83456 bytes read in 6 ms (13.3 MiB/s)
Booting /efi\boot\bootaa64.efi
EFI stub: Decompressing Linux Kernel...
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
<<Unknown what it's doing, no serial console output and black screen on the device>>
```
Expected additions:
```
CONFIG_BATTERY_AXP20X=m # Battery Gauge
CONFIG_AXP20X_ADC=m # Battery
CONFIG_DRM_ANALOGIX_ANX6345=m # Display bridge drivers (important!)
# These should be automatically enabled
CONFIG_PINCTRL_AXP209=y
CONFIG_INPUT_AXP20X_PEK=y
```
Consider also `CONFIG_PREEMPT_DYNAMIC` to enable the change of preemption model bcs e.g. teres prefers low-latency over the current desktop and `CONFIG_EFI_ZBOOT` as it's supposed to speed up the boot (https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4774#note_1748507441)
If you know of any missing configuration then feel free to propose additions e.g. I don't know what's needed to address `INFO: PSCI: Suspend is unavailable` atm, but i assume it's the lack of crust firmware complied in the testing u-boot.
Blocks: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4743
CC @ncopa - The Linux-LTS/Edge Maintainer in Alpine Linux
CC @mps - The Device Maintainer in Alpine LinuxNatanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15731[Package request]: bkt - subprocess caching utility2024-01-30T22:12:21ZYonas Yanfa[Package request]: bkt - subprocess caching utility**Name:** bkt
**License:** MIT
**Repository:** https://github.com/dimo414/bkt
**Releases:** https://github.com/dimo414/bkt/releases
**Dependencies:** Requires Rust to compile**Name:** bkt
**License:** MIT
**Repository:** https://github.com/dimo414/bkt
**Releases:** https://github.com/dimo414/bkt/releases
**Dependencies:** Requires Rust to compilehttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10130apk update index error2024-03-13T15:20:12Zdebiansidapk update index errori was trying to update my own apk index.it show error like this
```
alpine:~/packages/main/x86_64$ apk index -vU -o APKINDEX.tar.gz *.apk
WARNING: No provider for the dependencies:
/bin/sh bash bison elfutils-dev flex gmp-dev initramfs...i was trying to update my own apk index.it show error like this
```
alpine:~/packages/main/x86_64$ apk index -vU -o APKINDEX.tar.gz *.apk
WARNING: No provider for the dependencies:
/bin/sh bash bison elfutils-dev flex gmp-dev initramfs-generator linux-firmware-any mpc1-dev
mpfr-dev pc:libmnl perl pkgconfig python3 so:libc.musl-x86_64.so.1 so:libcrypto.so.3
so:libelf.so.1 so:libgmp.so.10 so:libjansson.so.4 so:libmnl.so.0 so:libreadline.so.8
so:libstdc++.so.6 so:libz.so.1 zstd
WARNING: Total of 24 unsatisfiable package names. Your repository may be broken.
Index has 0 packages (of which 22 are new)
```https://gitlab.alpinelinux.org/alpine/infra/docker/alpine/-/issues/3Azure defender reported a false positive that a GDB file is a Wacatac trojan2024-01-29T21:43:11ZThuyen LamAzure defender reported a false positive that a GDB file is a Wacatac trojanhttps://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images/-/issues/153doas and ssh_import_id problems2024-02-04T19:51:05ZDonhectordoas and ssh_import_id problemsHi folks,
I'm testing https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.0-x86_64-bios-cloudinit-r0.qcow2 in my Proxmox server (ie: KVM virtualization). My goal (like I simply do with Ubuntu 22.04 cloud image...Hi folks,
I'm testing https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.0-x86_64-bios-cloudinit-r0.qcow2 in my Proxmox server (ie: KVM virtualization). My goal (like I simply do with Ubuntu 22.04 cloud images) is to use SSH keys exclusively to log into my custom user (ie: 'hector' and not the default 'alpine' one).
To do so I leverage cloud init's `ssh_import_id`, however I'm facing issues under the linked Alpine cloudinit image. Reading up in the cloudinit documentation, I see that one must install `ssh-import-id` apk package for the cloud init `ssh_import_id` module to actually run. After installing the package, the cloudinit module indeed runs, but then I get a `doas: Operation not permitted` error and it fails to install my public keys from Github:
![image](/uploads/e06d7ced48a2d65cb49c4c3d8546ed8c/image.png)
I tried to see what could be going on in the cloud-init logs (had to actually enable password login to be able to read the logs since the machine failed to import my ssh publick keys), but I could not find the cause for the doas operation not permitted.
![image](/uploads/cb405af427261377d916d446e2bc24d6/image.png)
Interestingly enough, if I log into the failed cloudinit vm with user/pass for debugging and manually run "doas -u hector ssh-import-id gh:donhector" then the command is successful.
For completeness here's what cloudinit rendered in terms of doas config:
![image](/uploads/e9e6b20fdf4ed2a12f84c5c353b7a451/image.png)
And here's my user-data:
```yaml
#cloud-config
### Locale
timezone: Europe/Madrid
locale: en_US.UTF-8
### Hostname stuff
hostname: alpine-vm
manage_etc_hosts: true
### SSH daemon hardening
ssh_pwauth: false
disable_root: true
bootcmd:
- apk add ssh-import-id
### User configuration
users:
- name: hector
doas:
- permit nopass hector
sudo: "ALL=(ALL) NOPASSWD:ALL"
lock_passwd: true
groups: [wheel, adm, docker]
ssh_import_id:
- gh:donhector
# Package management
package_upgrade: true
package_reboot_if_required: true
packages:
- qemu-guest-agent
- docker
- docker-cli-compose
- curl
- wget
# Ensuring services start on boot
runcmd:
- rc-update add qemu-guest-agent default
- rc-update add docker default
### Reboot
power_state:
mode: reboot
delay: now
message: "Finished cloud init. Rebooting."
```
Is there anything obvious in my configuration that will cause `doas` not work well with `ssh_import_id`?
I had also tried `- permit nopass hector as root` but same error occurred.
For comparison, the following user-data works perfect on my ubuntu22.04 cloud image (https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img)
```yaml
#cloud-config
### Locale
timezone: Europe/Madrid
locale: en_US.UTF-8
### Hostname stuff
hostname: ubuntu-vm
manage_etc_hosts: true
### SSH daemon hardening
ssh_pwauth: false
disable_root: true
### User configuration
users:
- name: hector
sudo: "ALL=(ALL) NOPASSWD:ALL"
lock_passwd: true
shell: /bin/bash
groups: [adm, sudo, docker]
ssh_import_id:
- gh:donhector
### Package management
package_upgrade: true
package_reboot_if_required: true
packages:
- qemu-guest-agent
runcmd:
- systemctl enable qemu-guest-agent
- curl -sSL 'https://get.docker.com' | sh
### Reboot
power_state:
mode: reboot
delay: now
message: "Finished cloud init. Rebooting."
```
An interesting note is that if I `apk add ssh-import-id sudo` in `bootcmd:` then cloudinit ssh_import_id uses `sudo` instead of `doas` to run the `ssh-import-id` command and the keys are imported successfully.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15730[Package request]: tailspin - A log file highlighter2024-03-27T19:28:58ZYonas Yanfa[Package request]: tailspin - A log file highlighter**Name:** tailspin
**License:** MIT
**Repository:** https://github.com/bensadeh/tailspin
**Releases:** https://github.com/bensadeh/tailspin
**Dependencies:** Requires Rust to compile**Name:** tailspin
**License:** MIT
**Repository:** https://github.com/bensadeh/tailspin
**Releases:** https://github.com/bensadeh/tailspin
**Dependencies:** Requires Rust to compile