alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2024-03-27T19:28:59Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15763RFC: split tzdata "right" timezones in a tzdata-right subpackage2024-03-27T19:28:59ZDominique MartinetRFC: split tzdata "right" timezones in a tzdata-right subpackageThis is just me being greedy here -- would it make sense to split the tzdata in two packages?
Rationale is I'm not aware of many people using the TAI timezones, so I'd like to only install the posix timezones on our device (we'll need t...This is just me being greedy here -- would it make sense to split the tzdata in two packages?
Rationale is I'm not aware of many people using the TAI timezones, so I'd like to only install the posix timezones on our device (we'll need to support changing timezones, and while we could install them in a one-shot fashion like `setup-timezone` I think it makes more sense to just install tzdata to keep them up to date as DST changes etc are frequent enough)
An alternative that'd be even bigger work would be really explode the package (per "continent"? tzdata-america, tzdata-asia, tzdata-europe, tzdata-pacific, tzdata-etc, tzdata-misc, tzdata-right-america, tzdata-right-asia, ...), make the 'tzdata' package a virtual package for tzdata-*, then we could have setup-timezone install the correct package and keep users' timezones up to date without installing everything.
I'm not sure that's worth the trouble, but I don't think keeping timezone frozen by default is correct as there are multiple updates a year recently...
Cc @nmeum (added right timezones) @ncopa (maintainer)https://gitlab.alpinelinux.org/alpine/aports/-/issues/15762custom domain names set with dnsmasq won't resolve2024-02-19T02:54:17ZDavid Mudgecustom domain names set with dnsmasq won't resolveI've seen this issue before and supposedly, it was fixed but this my issue:
ASUS Router running merlin in dhcp all my physical devices have a hostname set for example a Raspberry Pi. Also in that pi raspi-config hostname is set to the s...I've seen this issue before and supposedly, it was fixed but this my issue:
ASUS Router running merlin in dhcp all my physical devices have a hostname set for example a Raspberry Pi. Also in that pi raspi-config hostname is set to the same
However I also have some custom domains set up in /jffs/configs/dnsmasq.conf.add all these point to my NAS where nginx-proxy-manager is running on port 80/443. This means for all my docker containers I can hit dockercontain.mydomain.net they will be picked up the reverse proxy and then reverse proxied to the nas ip address and port that container is listening on
Have confirmed in my router in /etc/dnsmasq.conf all these custom domains are appended
In the Alpine docker container I can do a ping to my pi at its hostname.mydomain.net
if I do an nslookup on the pi:
```
Server: xxx.xxx.x.x
Address: xxx.xxx.x.x:53
Name: subdomain.mydomain.net
Address: xxx.xxx.x.xxx
Non-authoritative answer:
```
However, if I do an nslookup on one my custom domains I get:
```
Server: xxx.xxx.x.x
Address: xxx.xxx.x.x:53
Name: subdomain.mydomain.net
Address: xxx.xxx.x.xxx
** server can't find subdomain.mydomain.net: NXDOMAIN
```
So the ip address is actually resolved however if I try to ping this custom domain, I get:
`ping: bad address 'subdomain.mydomain.net'`
Same if I try to do a curl or ssh cant resolve host
I am running other docker containers on the NAS that use Debian and they work fine to ping these custom domain names however I noted in these debian containers in /etc/resolv.conf they have the following:
whereas in the alpine container, it's set as:
```
nameserver 127.0.0.11
options ndots:0
```
```
nameserver xxx.xxx.x.x
nameserver xxx.xxx.x.x
domain mydomain.net
```
I tried setting the Alpine container to the same and the nslookup and ping times out. I even tried another suggestion changing ndots to 5 or 1 and didn't help
It's worth noting in my pi's its setup as:
```
search mydomain.net
nameserver xxx.xxx.x.x
```
on my nas it's:
```
nameserver xxx.xxx.x.xxx
options ndots:0
```
and they work fine to ping the custom domains. These settings don't work though for Alpine
not sure what else I need to try but it's frustrating because I run a lot of docker containers for example radarr and sonarr which use alpine and also overseerr which uses alpine but the overseerr cant connect to my radarr and overseerr by their custom domain. I have to use ip address
Alpine versions on my containers are 3.18.6 and 3.19.1 both have the same issuehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15761[package request]: zint2024-02-08T02:52:36ZEloi Torrents[package request]: zintURL: https://github.com/zint/zint
barcode encoding library
It is required for using this: https://gitlab.com/AndyM48/storecardsURL: https://github.com/zint/zint
barcode encoding library
It is required for using this: https://gitlab.com/AndyM48/storecardshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15760testing/electron: move to community2024-02-11T12:23:29ZAntoine Martintesting/electron: move to community`Electron` has been on Alpine's testing repo since July 2022, more and more aports are being introduced that rely on `electron`.
@selfisekai, what would need to happen for electron to be moved to community? Is it a question of getting ...`Electron` has been on Alpine's testing repo since July 2022, more and more aports are being introduced that rely on `electron`.
@selfisekai, what would need to happen for electron to be moved to community? Is it a question of getting more help on maintaining `latest` branch of Alpine? I've been simply building electron for `latest` version on my personal infrastructure.lauren n. liberdalauren n. liberdahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15759valgrind on armv7 doesn't work2024-03-01T20:57:33Zqaqlandvalgrind on armv7 doesn't workProblem first found when package mustach !59786 , armv7 get check failed.
Setup qemu-arm following [wiki](https://wiki.alpinelinux.org/wiki/How_to_make_a_cross_architecture_chroot) and run `valgrind uname` also get errors:
<details><su...Problem first found when package mustach !59786 , armv7 get check failed.
Setup qemu-arm following [wiki](https://wiki.alpinelinux.org/wiki/How_to_make_a_cross_architecture_chroot) and run `valgrind uname` also get errors:
<details><summary>Click to expand logs</summary>
```
lab:~/test-c# valgrind uname
==19523== Memcheck, a memory error detector
==19523== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==19523== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==19523== Command: uname
==19523==
==19523== error calling PR_SET_PTRACER, vgdb might block
disInstr(thumb): unhandled instruction: 0xDEFF 0x6803
disInstr(thumb): unhandled instruction: 0xDEFF 0xF8D6
disInstr(thumb): unhandled instruction: 0xDEFF 0x2502
disInstr(thumb): unhandled instruction: 0xDEFF 0x4584
disInstr(thumb): unhandled instruction: 0xDEFF 0x682B
disInstr(thumb): unhandled instruction: 0xDEFF 0x4A83
disInstr(thumb): unhandled instruction: 0xDEFF 0xF850
==19523== Invalid write of size 4
==19523== at 0x48956F4: strcpy (in /usr/libexec/valgrind/vgpreload_memcheck-arm-linux.so)
==19523== Address 0x3f8007ac is on thread 1's stack
==19523== 56 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x4884466: ??? (in /usr/libexec/valgrind/vgpreload_core-arm-linux.so)
==19523== Address 0x3f800c80 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x488B4C2: ??? (in /usr/libexec/valgrind/vgpreload_memcheck-arm-linux.so)
==19523== Address 0x3f800c80 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x115AFE: ??? (in /bin/busybox)
==19523== Address 0x3f800c80 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
disInstr(thumb): unhandled instruction: 0xDEFF 0xF850
disInstr(thumb): unhandled instruction: 0xDEFF 0x1B1F
disInstr(thumb): unhandled instruction: 0xDEFF 0x5D73
disInstr(thumb): unhandled instruction: 0xDEFF 0x2602
==19523== Invalid write of size 4
==19523== at 0x1160E2: ??? (in /bin/busybox)
==19523== Address 0x3f800d40 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x115CA2: ??? (in /bin/busybox)
==19523== Address 0x3f800d38 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x18D644: ??? (in /bin/busybox)
==19523== Address 0x3f800d38 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x115E0C: ??? (in /bin/busybox)
==19523== Address 0x3f800d18 is on thread 1's stack
==19523== 24 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x115B3C: ??? (in /bin/busybox)
==19523== Address 0x3f800d00 is on thread 1's stack
==19523== 24 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x115D5E: ??? (in /bin/busybox)
==19523== Address 0x3f800d20 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x115D12: ??? (in /bin/busybox)
==19523== Address 0x3f800d18 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x173A56: ??? (in /bin/busybox)
==19523== Address 0x3f800ae4 is on thread 1's stack
==19523== 560 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x182E78: ??? (in /bin/busybox)
==19523== Address 0x3f800ac0 is on thread 1's stack
==19523== 24 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x182984: ??? (in /bin/busybox)
==19523== Address 0x3f80063c is on thread 1's stack
==19523== 1144 bytes below stack pointer
==19523==
Linux
==19523== Invalid write of size 4
==19523== at 0x1931FE: ??? (in /bin/busybox)
==19523== Address 0x3f800ae8 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x1822C6: ??? (in /bin/busybox)
==19523== Address 0x3f800ae0 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x1165B2: ??? (in /bin/busybox)
==19523== Address 0x3f800ad8 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x115A9A: ??? (in /bin/busybox)
==19523== Address 0x3f800a10 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x488B45E: ??? (in /usr/libexec/valgrind/vgpreload_memcheck-arm-linux.so)
==19523== Address 0x3f800a10 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x4884402: ??? (in /usr/libexec/valgrind/vgpreload_core-arm-linux.so)
==19523== Address 0x3f800a10 is on thread 1's stack
==19523== 8 bytes below stack pointer
==19523==
==19523== Invalid write of size 4
==19523== at 0x48844A8: _vgnU_freeres (in /usr/libexec/valgrind/vgpreload_core-arm-linux.so)
==19523== Address 0x3f800a9c is on thread 1's stack
==19523== 48 bytes below stack pointer
==19523==
==19523==
==19523== HEAP SUMMARY:
==19523== in use at exit: 0 bytes in 0 blocks
==19523== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==19523==
==19523== All heap blocks were freed -- no leaks are possible
==19523==
==19523== For lists of detected and suppressed errors, rerun with: -s
==19523== ERROR SUMMARY: 25 errors from 21 contexts (suppressed: 0 from 0)
```
</details>Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15758Enable CONFIG_FW_LOADER_COMPRESS_ZSTD for all kernels that need to load firmw...2024-03-27T19:28:59ZNewbyteEnable CONFIG_FW_LOADER_COMPRESS_ZSTD for all kernels that need to load firmware from linux-firmwareSee https://gitlab.alpinelinux.org/alpine/aports/-/issues/15756 and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60282 for context.
@mpsSee https://gitlab.alpinelinux.org/alpine/aports/-/issues/15756 and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60282 for context.
@mpsMilan P. StanićMilan P. Stanićhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15757rtl8723bs_nic.bin is missing from alpine-standard-3.19.0-x86_64.iso 's modloop.2024-03-01T00:48:53ZEric Toombsrtl8723bs_nic.bin is missing from alpine-standard-3.19.0-x86_64.iso 's modloop.It has meant that my computer's wifi wouldn't work on boot.
I had to add the firmware file to the modloop squashfs image myself.
I don't know how this happened.
The firmware file is in [the linux-firmware-rtlwifi package](https://pkgs.a...It has meant that my computer's wifi wouldn't work on boot.
I had to add the firmware file to the modloop squashfs image myself.
I don't know how this happened.
The firmware file is in [the linux-firmware-rtlwifi package](https://pkgs.alpinelinux.org/contents?file=&path=&name=linux-firmware-rtlwifi&branch=v3.19&repo=main&arch=x86_64).
(I would have installed linux-firmware-rtlwifi, but the /lib/firmware directory was read-only, so the apk add command failed.)Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15756Compress linux-firmware packages2024-03-10T10:49:54ZNewbyteCompress linux-firmware packagesCurrently, installing all linux-firmware packages results in a `/lib/firmware` directory which is around 1,0 GB in size. This could be significantly smaller if we started compressing firmware during packaging. The Linux kernel has suppor...Currently, installing all linux-firmware packages results in a `/lib/firmware` directory which is around 1,0 GB in size. This could be significantly smaller if we started compressing firmware during packaging. The Linux kernel has supported loading compressed firmware since version 5.3 and other distributions such as Fedora and Arch Linux have already implemented this successfully. In Fedora, for example, at the time of writing the entire `/lib/firmware` directory is a more modest 238 MB.
There are some problems however. Not all firmware can be compressed, so exceptions would have to be made on a per-file basis. In particular, firmware served to certain remote processors on Qualcomm devices cannot be compressed at the moment as the serving happens in userspace rather than kernelspace. There may also be other necessary exceptions, so this would require extensive testing to avoid breakage. As other distributions already have implemented this, we could investigate what files (if any) they exempt as a start. However, their lists may not be complete as it is unlikely that they've tested more obscure ARM hardware.Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15755Can I have the old Docker version back?2024-02-10T19:21:50ZHenrik Ugglahenrik.uggla@kristianstad.seCan I have the old Docker version back?Hi!
This Friday you updated Docker for Alpine 3.18 to version 25 from previously 23 (I think). This broke things for us. Please make the older version available again.Hi!
This Friday you updated Docker for Alpine 3.18 to version 25 from previously 23 (I think). This broke things for us. Please make the older version available again.Jake Buchholz GöktürkJake Buchholz Göktürkhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15754Header file missing, linux/types.h2024-02-08T14:22:07Zbengt klebergHeader file missing, linux/types.hGreetings,
Installing (apk) lksctp-tools-dev will add the header file netinet/sctp.h
This header file include linux/types.h, which is not present.
It is not possible to compile files that include netinit/sctp.h
Please help me to install...Greetings,
Installing (apk) lksctp-tools-dev will add the header file netinet/sctp.h
This header file include linux/types.h, which is not present.
It is not possible to compile files that include netinit/sctp.h
Please help me to install linux/types.h
Best Wishes,
bengthttps://gitlab.alpinelinux.org/alpine/help/-/issues/24Header file missing, linux/types.h2024-02-05T11:45:54Zbengt klebergHeader file missing, linux/types.hGreetings,
Installing (apk) lksctp-tools-dev will add the header file netinet/sctp.h
This header file include linux/types.h, which is not present.
It is not possible to compile files that include netinit/sctp.h
Please help me to install...Greetings,
Installing (apk) lksctp-tools-dev will add the header file netinet/sctp.h
This header file include linux/types.h, which is not present.
It is not possible to compile files that include netinit/sctp.h
Please help me to install linux/types.h
Best Wishes,
bengthttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15753testing/nix: crash on running nix commands2024-03-27T19:28:59ZHoang Nguyentesting/nix: crash on running nix commandsThis only started happening after the 2.20.1 upgrade recently.
Error log from `nix-daemon`:
```c
/usr/include/c++/13.2.1/string_view:258: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT...This only started happening after the 2.20.1 upgrade recently.
Error log from `nix-daemon`:
```c
/usr/include/c++/13.2.1/string_view:258: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT, _Traits>::operator[](size_type) const [with _CharT = char; _Traits = std::char_traits<char>; const_reference = const char&; size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed.
```
How to reproduce (at least on my side):
* Start `nix-deamon` (my nix.conf allows @wheel group to connect to the Nix daemon)
* Run a command that requires a connection to the Nix socket, .e.g `nix-collect-garbage` or `nix search nixpkgs go` and it crashes
There is a coredump file each time it crashes, but we don't have `nix-dbg` package for the debug symbol, so I can't get anything useful from it.Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15752testing/crust: Promote to community2024-02-06T12:31:27ZArnav Singhtesting/crust: Promote to communitypostmarketOS uses its own crust package as a makedepends of our u-boot package for the PinePhone. It is redundant with the one in aports, but we have to have it because we consider the PinePhone to be a "main" device, so it cannot have d...postmarketOS uses its own crust package as a makedepends of our u-boot package for the PinePhone. It is redundant with the one in aports, but we have to have it because we consider the PinePhone to be a "main" device, so it cannot have dependencies that are unavailable in stable Alpine.
testing/crust has been around since 2021-10, and I can confirm the latest v0.6 works fine on the PinePhone at least. Could it be promoted to community?
cc @mpshttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/79Establish a policy in case of aports developer inactivity2024-03-02T10:02:34ZPatrycja Rosaalpine@ptrcnull.meEstablish a policy in case of aports developer inactivityvaguely inspired by https://wiki.gentoo.org/wiki/Project:Retirement:
> **Inactivity retirement.** Happens after roughly 12-16 months of inactivity and four warning mails. The exact timeline and process depends on the developer's prior ac...vaguely inspired by https://wiki.gentoo.org/wiki/Project:Retirement:
> **Inactivity retirement.** Happens after roughly 12-16 months of inactivity and four warning mails. The exact timeline and process depends on the developer's prior activity and current situation.
currently we have 24 members of the Developers team. of those, 5 haven't been seen since 2020, some spanning all the way back to 2018, and one [not having any recorded activity since the migration to GitLab][1]; and yet, they hold full commit rights to aports, and could push changes at any time
[1]: https://gitlab.alpinelinux.org/Shizhttps://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/issues/31automaintainer: in case of teams, request review from team members instead of...2024-02-03T23:26:01ZPatrycja Rosaalpine@ptrcnull.meautomaintainer: in case of teams, request review from team members instead of assigning the MRa review can have multiple members, thus it gives us an easy way for getting attention of all people - a comment might at most add it to todos, a review request appears in the "Merge Requests" context menu:
![image](/uploads/66a7b023644...a review can have multiple members, thus it gives us an easy way for getting attention of all people - a comment might at most add it to todos, a review request appears in the "Merge Requests" context menu:
![image](/uploads/66a7b023644a0fd91db7127742c1b689/image.png)https://gitlab.alpinelinux.org/alpine/aports/-/issues/15751netsurf preferences dialog unintelligible2024-02-03T17:17:56ZAdamnetsurf preferences dialog unintelligibleNetsurf's preferences dialog does not show preference descriptions, but something that's perhaps their variable names.
Debian's package does not have this problem.
Screenshot comparing Debian and Alpine netsurf preferences dialog:
![S...Netsurf's preferences dialog does not show preference descriptions, but something that's perhaps their variable names.
Debian's package does not have this problem.
Screenshot comparing Debian and Alpine netsurf preferences dialog:
![Screenshot_2024-02-03_11-13-28](/uploads/d3cf0fedaf477862315a85e2cf6b724f/Screenshot_2024-02-03_11-13-28.png)
I'm interested in fixing this, just wanted a place to document it.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15750weechat-matrix and weechat-matrix-pyc are empty?2024-02-04T16:00:26ZWillowcontact@willowbarraco.frweechat-matrix and weechat-matrix-pyc are empty?Hey there,
I tried to use weechat matrix module after a long while. And discovered the package now is empty.
Something broke with the recent changes with python packages?
cc @craftyguy
Thanks o/Hey there,
I tried to use weechat matrix module after a long while. And discovered the package now is empty.
Something broke with the recent changes with python packages?
cc @craftyguy
Thanks o/https://gitlab.alpinelinux.org/alpine/aports/-/issues/15749openrc start-stop-daemon scheduler param is not working2024-02-05T17:33:28Zipoupailleopenrc start-stop-daemon scheduler param is not workingCode use fonction sched_setscheduler as seen here: [https://github.com/OpenRC/openrc/blob/master/src/start-stop-daemon/start-stop-daemon.c#L1126C8-L1126C26](https://github.com/OpenRC/openrc/blob/master/src/start-stop-daemon/start-stop-da...Code use fonction sched_setscheduler as seen here: [https://github.com/OpenRC/openrc/blob/master/src/start-stop-daemon/start-stop-daemon.c#L1126C8-L1126C26](https://github.com/OpenRC/openrc/blob/master/src/start-stop-daemon/start-stop-daemon.c#L1126C8-L1126C26).
But this method is not implemented in musl as explained here: [https://www.openwall.com/lists/musl/2016/03/01/5](https://www.openwall.com/lists/musl/2016/03/01/5)
Should start-stop-daemon be patched to use pthread_getschedparam and pthread_setschedparam methods instead?Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15748community/k3s: v1.29.1.1-r0 breaks at runtime due to upstream change2024-03-08T22:26:41ZMayathebeeecommunity/k3s: v1.29.1.1-r0 breaks at runtime due to upstream changeHi,
After upgrading to `v1.29.1.1-r0` and restarting the service, I noticed the service would start but be unavailable and logs would report the following message every second: `time="2024-02-03T02:13:51+01:00" level=fatal msg="Failed t...Hi,
After upgrading to `v1.29.1.1-r0` and restarting the service, I noticed the service would start but be unavailable and logs would report the following message every second: `time="2024-02-03T02:13:51+01:00" level=fatal msg="Failed to validate golang version: kubernetes golang build version not set - see 'golang: upstream version' in https://github.com/kubernetes/kubernetes/blob/v1.29.1/build/dependencies.yaml"`.
I investigated and the change seems to come from this upstream change, to force people to use the supported version of `golang` while building `k3s`: https://github.com/k3s-io/k3s/commit/b297996b9252b02e56e9425f55f6becbf6bb7832.
The fact that they made this break at runtime and not at compile-time may need to be addressed by the upstream at some point.
The fix seems to be adding a new path in the `VERSIONFLAGS` variable and rebuild, I will look into this today.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15747watchdog reboot when cgroup is in unified mode while docker containers startup2024-03-04T18:34:02Zipoupaillewatchdog reboot when cgroup is in unified mode while docker containers startupI have a rpi2 with several docker containers automaticaly started at boot. I saw the problem after migrating from alpine 3.18 to alpine 3.19. I downgraded to 3.18 (thanks to btrfs snapshots), and then reproduced the same problem on 3.18:...I have a rpi2 with several docker containers automaticaly started at boot. I saw the problem after migrating from alpine 3.18 to alpine 3.19. I downgraded to 3.18 (thanks to btrfs snapshots), and then reproduced the same problem on 3.18:
When cgroup is configured on unified mode (v2) and watchdog is activated (bcm2835-wdt), the board is rebooted while docker containers are starting.
If cgroup is on hybrid mode, or if watchdog is not activated or if docker containers are not started, no reboot.
I have kernel 6.1.73-v7+ compiled from sources from raspberry github.
When docker containers are started, the uptime go to more than 5.
I tried those in /etc/conf.d/watchdog:
```
export SSD_IONICELEVEL=1
export SSD_NICELEVEL=-20
rc_cgroup_settings="
cpu.weight 300
"
```
But it does not seem to have any effect.Natanael CopaNatanael Copa