aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2024-03-11T10:39:54Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13017main/alpine-baselayout: profile $PATH has the wrong path order with SSH2024-03-11T10:39:54ZEric Shiehmain/alpine-baselayout: profile $PATH has the wrong path order with SSHCurrently `/etc/profile` checks for duplicate paths, however, when used with SSH, this will lead to incorrect PATH order after SSH login.
```shell
$ grep PATH /etc/ssh/sshd_config
# This sshd was compiled with PATH=/bin:/usr/bin:/sbin:/...Currently `/etc/profile` checks for duplicate paths, however, when used with SSH, this will lead to incorrect PATH order after SSH login.
```shell
$ grep PATH /etc/ssh/sshd_config
# This sshd was compiled with PATH=/bin:/usr/bin:/sbin:/usr/sbin
# login from console
$ printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# login from SSH
$ printenv PATH
/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin
```
Since SSH already comes with PATH `/bin:/usr/bin:/sbin:/usr/sbin`,
after logging in and excluding duplicates, it becomes `/bin:/usr/bin:/sbin:/usr/sbin` + `:/usr/local/sbin:/usr/local/bin`.
Steps to reproduce (with docker):
start-sshd.sh
```shell
#!/bin/sh
set -e
apk --no-cache --update \
--repository https://dl-cdn.alpinelinux.org/alpine/v3.14/main \
add openssh-server
rm -rf /var/lib/apk/*
passwd -d -u root
ssh-keygen -t ed25519 -P "" -f /etc/ssh/ssh_host_ed25519_key
sed -i \
-e 's/#\(PermitRootLogin\).*/\1 yes/g' \
-e 's/#\(PasswordAuthentication\).*/\1 yes/g' \
-e 's/#\(PermitEmptyPasswords\).*/\1 yes/g' \
/etc/ssh/sshd_config
exec /usr/sbin/sshd -D
```
```shell
# 1. Run the SSH server
CONTAINER_ID=$(docker run -d --rm -v $PWD/start-sshd.sh:/start-sshd.sh:ro --init alpine:3.14 /bin/sh /start-sshd.sh)
CONTAINER_IP=$(docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "$CONTAINER_ID" | head -n1)
# 2. Check $PATH with docker exec
$ docker exec "$CONTAINER_ID" printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# 3. Check $PATH after SSH login
$ ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null "root@$CONTAINER_IP"
$ printenv PATH
/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin
# 4. Stop and remove container
$ docker stop "$CONTAINER_ID"
```
related:
- Issue #12803
- MR !22657
- Commit 6104bf463.18.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/11730main/busybox: Busybox /bin/su and /bin/login bypass PAM configuration when us...2023-10-27T19:46:31Zwebstrandmain/busybox: Busybox /bin/su and /bin/login bypass PAM configuration when using linux-pamOn systems using `linux-pam`, where a more restrictive authentication mechanism is used—such as `pam_yubico.so`—the Busybox binaries `/bin/su` and `/bin/login` are not PAM-aware and bypass the PAM configuration. This may be a vulnerabili...On systems using `linux-pam`, where a more restrictive authentication mechanism is used—such as `pam_yubico.so`—the Busybox binaries `/bin/su` and `/bin/login` are not PAM-aware and bypass the PAM configuration. This may be a vulnerability on some systems, since `su` cannot be disabled without also disabling its multi-call binary `/bin/bbsuid`.
Busybox could be built with PAM support by setting `CONFIG_PAM=y` in its configuration. Adding the packages `busybox-pam` ~~and `busybox-suid-pam` would fix the issue~~.
Alternatively, the `shadow` package _is_ PAM aware and provides replacement binaries for `su`, `login`, `passwd`, and `chpasswd`. But removing `busybox-suid` is still problematic, and as long as it's available on the system, it may be a vulnerability.https://gitlab.alpinelinux.org/alpine/aports/-/issues/11645php misuses fpu control, causing improper math behavior in musl2023-09-22T13:54:32ZAndy Postnikovphp misuses fpu control, causing improper math behavior in muslThere's second report about php is wrong with float/double types
- https://gitlab.alpinelinux.org/alpine/aports/-/issues/11446#note_83824
- https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9188#note_96140 (x86-64 x86 s390x ...There's second report about php is wrong with float/double types
- https://gitlab.alpinelinux.org/alpine/aports/-/issues/11446#note_83824
- https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9188#note_96140 (x86-64 x86 s390x archs)
Both places using `atof()` or `strtod()`, also I recall https://github.com/php/pecl-file_formats-yaml/pull/29
Same time working on upgrade of PHP I found `sin()` and `cos()` also getting overflow with floats (to investigate)https://gitlab.alpinelinux.org/alpine/aports/-/issues/10678Create a simple ca-certificates provider2020-03-05T16:01:21ZCarlo LandmeterCreate a simple ca-certificates providerWe currently have two packages to provide a certificate db cert.pem and ca-certificates.crt found in ca-certificates and ca-certificates-cacert.
Currently ca-certificates-cacert will create a concatted db of all mozilla certificates as `...We currently have two packages to provide a certificate db cert.pem and ca-certificates.crt found in ca-certificates and ca-certificates-cacert.
Currently ca-certificates-cacert will create a concatted db of all mozilla certificates as `/etc/ssl/cert.pem` which is the same filename which was previously provided by libressl.
It would be nice if we could provide `/etc/ssl/cert.pem` as `/etc/ssl/certs/ca-certificates.crt` so applications can pick this up and use it per default. If users would need certification control they would install ca-certificates and it would overwrite the current `/etc/ssl/certs/ca-certificates.crt`.
To my understanding only libtls-standalone depends on this to support busybox but maybe some external users still depend on this location.Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10532apk doesn't handle upgrades correctly when old dep versions are still availab...2019-07-23T10:34:22ZA. Wilcoxapk doesn't handle upgrades correctly when old dep versions are still available in repositoryWe’ve just released Adélie 1.0-BETA3, and due to that, we have lots of
people upgrading their computers… we’ve had at least three cases so far
today where there’s been the same error:
ERROR: unsatisfiable constraints:
harfbuzz...We’ve just released Adélie 1.0-BETA3, and due to that, we have lots of
people upgrading their computers… we’ve had at least three cases so far
today where there’s been the same error:
ERROR: unsatisfiable constraints:
harfbuzz-icu-1.8.8-r1:
breaks: harfbuzz-dev-2.4.0-r0[harfbuzz-icu=2.4.0-r0]
libpcrecpp-8.42-r1:
breaks: pcre-dev-8.43-r0[libpcrecpp=8.43-r0]
All of these cases are when qt5-qtbase-dev (or another Qt 5 development
package) is installed. This helpfully included our primary web server,
which has only adelie-base, apache-httpd, and qt5-qtbase-dev installed.
I enabled DEBUG\_PRINT in apk/solver.c, rebuilt, and tried again with
this custom apk-tools build. Output is included in the attached 1.33 MB
log file.
In the middle you find this chunk:
select_package: harfbuzz-icu (requirers=1, iif=0)
consider harfbuzz-icu-1.8.8-r1 iif_triggered=0, tag_ok=1, selectable=1, provider_priority=0, installed=1
consider harfbuzz-icu-2.3.1-r0 iif_triggered=0, tag_ok=1, selectable=1, provider_priority=0, installed=0
consider harfbuzz-icu-2.4.0-r0 iif_triggered=0, tag_ok=1, selectable=1, provider_priority=0, installed=0
selecting: harfbuzz-icu-1.8.8-r1, available: 1
assign harfbuzz-icu to harfbuzz-icu-1.8.8-r1
disqualify_package: harfbuzz-icu-2.3.1-r0 (conflicting provides)
queue_dirty: pc:harfbuzz
disqualify_package: harfbuzz-icu-2.4.0-r0 (conflicting provides)
assign so:libharfbuzz-icu.so.0 to harfbuzz-icu-1.8.8-r1
This seems to be a small issue in the solver:
https://git.alpinelinux.org/apk-tools/tree/src/solver.c\#n514 - it
“Prefer\[s\] existing package\[s\]”, even during a system upgrade.
Anything in world is considered for upgrade, but **dependencies** of
world are only considered for upgrade if the existing package versions
are no longer present/available. I’m aware that the Alpine policy is to
run the equivalent of cleanoldpkg on every build, but it isn’t our
policy at Adélie - once a package is published to our mirrors, it is
never removed for any reason other than if there is a license error
My personal opinion is that there should perhaps be another flag to
upgrade, maybe -d/—deep for “deep upgrades” which will upgrade **every**
package, not just world.
*(from redmine: issue id 10532, created on 2019-06-01)*Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10527update-kernel script -- mounting /media/usb failed2021-01-14T05:54:24ZLubos Dolezalupdate-kernel script -- mounting /media/usb failed# update-kernel
%<...
mount: mounting /dev/sda1 on /media/usb failed: Resource busy
The situation is probably associated with the transition modloop to
overlayfs.
Detailed output and other details: https://pastebin.com/raw/NEaH...# update-kernel
%<...
mount: mounting /dev/sda1 on /media/usb failed: Resource busy
The situation is probably associated with the transition modloop to
overlayfs.
Detailed output and other details: https://pastebin.com/raw/NEaHuSNU
*(from redmine: issue id 10527, created on 2019-05-31)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10526update-kernel script prints warning even if extra firmware doesn't exist2022-02-27T02:25:16ZLubos Dolezalupdate-kernel script prints warning even if extra firmware doesn't exist# update-kernel
Warning: extra firmware "" not found!
%<...
Install extra firmware only if *modloopfw* variable is not empty:
--- /sbin/update-kernel
+++ /tmp/update-kernel.new
@@ -293,14 +293,16 @@
fi
# ...# update-kernel
Warning: extra firmware "" not found!
%<...
Install extra firmware only if *modloopfw* variable is not empty:
--- /sbin/update-kernel
+++ /tmp/update-kernel.new
@@ -293,14 +293,16 @@
fi
# install extra firmware files in modloop (i.e. not detected by modinfo)
-for _xfw in "$modloopfw"; do
- if [ -f "$ROOT/lib/firmware/$_xfw" ]; then
- install -pD "$ROOT/lib/firmware/$_xfw" \
- "$MODLOOP"/modules/firmware/"$_xfw"
- else
- echo "Warning: extra firmware \"$_xfw\" not found!"
- fi
-done
+if [ -n "$modloopfw" ]; then
+ for _xfw in "$modloopfw"; do
+ if [ -f "$ROOT/lib/firmware/$_xfw" ]; then
+ install -pD "$ROOT/lib/firmware/$_xfw" \
+ "$MODLOOP"/modules/firmware/"$_xfw"
+ else
+ echo "Warning: extra firmware \"$_xfw\" not found!"
+ fi
+ done
+fi
# include bluetooth firmware in modloop
if [ -e "$ROOT"/lib/modules/*/kernel/drivers/bluetooth/btbcm.ko ]; then
*(from redmine: issue id 10526, created on 2019-05-31)*3.14.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10464deluge not starting after latest libtorrent-rasterbar update2019-07-23T11:09:55ZMatthieu Castellazzideluge not starting after latest libtorrent-rasterbar updateGood evening,
After updating libtorrent-rasterbar from 1.1.12-r0 to 1.1.13-r0,
deluge-1.3.15-r3 is not starting anymore.
$ deluged
[ERROR ] 18:30:14 main:248 No module named libtorrent
Traceback (most recent call last):...Good evening,
After updating libtorrent-rasterbar from 1.1.12-r0 to 1.1.13-r0,
deluge-1.3.15-r3 is not starting anymore.
$ deluged
[ERROR ] 18:30:14 main:248 No module named libtorrent
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/deluge/main.py", line 241, in start_daemon
Daemon(options, args)
File "/usr/lib/python2.7/site-packages/deluge/core/daemon.py", line 144, in __init__
from deluge.core.core import Core
File "/usr/lib/python2.7/site-packages/deluge/core/core.py", line 38, in <module>
from deluge._libtorrent import lt
File "/usr/lib/python2.7/site-packages/deluge/_libtorrent.py", line 59, in <module>
import libtorrent as lt
ImportError: No module named libtorrent
Looks like the following commit broke something:
https://git.alpinelinux.org/aports/commit/?id=bb2b956ae9787706a773a25e5a2d13ff9edc0aa1
Thanks for your help.
Matthieu
*(from redmine: issue id 10464, created on 2019-05-18, closed on 2019-06-19)*
* Changesets:
* Revision b911ba3c98d2f11988cc6fbb658c152ab94d71e0 by prs pkt on 2019-05-27T23:31:30Z:
```
testing/deluge: fix source url
- Rebuild against py2-libtorrent-rasterbar.
Fixes #10464
```3.10.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10285Removing packages when creating alpine image2022-12-06T13:37:50ZRoi GreenbergRemoving packages when creating alpine imageHi.
In our work, we need custom Alpine docker and for that we need to remove
some packages from the final image\[minirootfs\] (basically, anything
that related to network/ssl)
We try to remove the packages from the container itself fr...Hi.
In our work, we need custom Alpine docker and for that we need to remove
some packages from the final image\[minirootfs\] (basically, anything
that related to network/ssl)
We try to remove the packages from the container itself from inside, but
doing “apk del ssl\_client” for example, do nothing.
We also tried to edit the genrootfs script so after adding all the
packages it will delete those we don’t want, but if I do:
<code class="text">
${APK:-apk} del --keys-dir "$keys_dir" \
--repositories-file "$repositories_file" \
*--root "$tmp"* $unwanted_packages
</code>
The script crash, and if I remove **—root “$tmp”** I receive permissions
error, probably since it tries to delete the container packages.
Is there any way to accomplish what we want? maybe prevent “apk add” to
install those packages?
*(from redmine: issue id 10285, created on 2019-04-18)*Simon Fsimon-alpine@fraho.euSimon Fsimon-alpine@fraho.euhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10140main/musl libc6-compat broken for most libraries on x86_642023-07-03T03:13:32ZX Xanonidmain/musl libc6-compat broken for most libraries on x86_64With
https://git.alpinelinux.org/aports/commit/main/musl/APKBUILD?id=7b32fee49798e36cb5a7dfde30183f9717472cf6
`/lib64` was changed to a separate folder.
Before `/lib64` was a symlink to `/lib`.
Now `ld-linux-x86-64.so.2` is only creat...With
https://git.alpinelinux.org/aports/commit/main/musl/APKBUILD?id=7b32fee49798e36cb5a7dfde30183f9717472cf6
`/lib64` was changed to a separate folder.
Before `/lib64` was a symlink to `/lib`.
Now `ld-linux-x86-64.so.2` is only created as
`/lib64/ld-linux-x86-64.so.2` and therefore no longer available in
`/lib/ld-linux-x86-64.so.2`.
Unfortunately, `/lib64` is not in the default `LD_LIBRARY_PATH`. As a
result of this, loading of libraries built with glibc is broken in
alpine >= 3.9 (except for those libraries who refer explicitly to
/lib64/ld-linux-x86-64.so.2).
This caused https://github.com/docker-flink/docker-flink/issues/69 .
*(from redmine: issue id 10140, created on 2019-03-20)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10123Alpine 3.9.2 busybox is missing udhcpd?2019-07-23T11:13:25ZChris MckenzieAlpine 3.9.2 busybox is missing udhcpd?Hi. Great work on Alpine. I spent all night working on a Alpine based
wireless router and I stumbled when trying to start udhcpd. The included
busybox has udhcpc (client) but not udhcpd (server). This kind of put s
damper on the wiki pag...Hi. Great work on Alpine. I spent all night working on a Alpine based
wireless router and I stumbled when trying to start udhcpd. The included
busybox has udhcpc (client) but not udhcpd (server). This kind of put s
damper on the wiki page
(https://wiki.alpinelinux.org/wiki/Wireless\_AP\_with\_udhcpd\_and\_NAT)
that covers configuring udhcpd (server).
Any tips on how to add it? Is there a different busybox update I should
be adding? Or is this a difference between Alpine distribution versions?
If it is, I would suggest avoiding un-obvious differences like this. I
have almost everything the way I want it, just missing udhcpd.
apk add udhcpd
1. ls -al /etc/udhcpd.conf
-rw-r—r— 1 root root 4389 Mar 16 16:10 /etc/udhcpd.conf
<!-- -->
1. ls -al /etc/init.d/udhcpd
-rwxr-xr-x 1 root root 174 Dec 24 15:36 /etc/init.d/udhcpd
<!-- -->
1. busybox udhcpd
udhcpd: applet not found
<!-- -->
1. busybox —list | grep udhc
udhcpc
udhcpc6
*(from redmine: issue id 10123, created on 2019-03-16, closed on 2019-03-16)*3.9.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10070eudev: 64-btrfs.rules broken2019-07-23T11:13:58ZSteffen Nurpmesoeudev: 64-btrfs.rules brokenhi, with eudev-3.2.7-r0 i see warnings in /var/log/daemon:
@
Mar 7 15:04:01 kernel: \[109959.858552\] udevd\[15802\]: failed to
execute ‘/lib/udev/${exec\_prefix}/bin/udevadm’
‘${exec\_prefix}/bin/udevadm trigger -s block -p ID\_BTRF...hi, with eudev-3.2.7-r0 i see warnings in /var/log/daemon:
@
Mar 7 15:04:01 kernel: \[109959.858552\] udevd\[15802\]: failed to
execute ‘/lib/udev/${exec\_prefix}/bin/udevadm’
‘${exec\_prefix}/bin/udevadm trigger -s block -p ID\_BTRFS\_READY=0’: No
such file or directory
@
I have changed the path to /bin/udevadm locally, let’s see.
*(from redmine: issue id 10070, created on 2019-03-07, closed on 2019-06-19)*
* Changesets:
* Revision c68893f1a0d72c67601baa195103e7236614cb8c on 2019-03-07T17:07:17Z:
```
main/eudev: fix variable substitution in 64-btrfs.rules
GNU autotools doesn't fully expand the @bindir@ variable in
64-btrfs.rules and expands it to ${exec_prefix}/bin instead.
To workaround this issue explicitly set bindir from configure.
See also: https://bugs.gentoo.org/show_bug.cgi?id=666892#c12
Fixes #10070
```3.10.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9959libressl and openssl pkgconf have the same provides2019-11-01T15:30:36ZCarlo Landmeterlibressl and openssl pkgconf have the same providesThe pkgconfig files provided by libressl and openssl provide the same
thing.
And because apk will select the highest version libressl will be
selected.
This causes issues like: https://bugs.alpinelinux.org/issues/9958
*(from redmine...The pkgconfig files provided by libressl and openssl provide the same
thing.
And because apk will select the highest version libressl will be
selected.
This causes issues like: https://bugs.alpinelinux.org/issues/9958
*(from redmine: issue id 9959, created on 2019-02-04, closed on 2019-02-25)*
* Relations:
* blocks #9958
* Changesets:
* Revision 376ccc5bd695e792768a679409fbb428defe0770 by Natanael Copa on 2019-02-22T13:57:08Z:
```
abuild: add support for pkg-config prefix pcprefix
Fix issue when two -dev packages provides same pkg-config wil but with
different versions. For example libressl-dev and openssl-dev both ships
libssl.pc and libcrypto.pc, which resulted in automatic provides of
pc:libssl and pc:libcrypto.
apk would end up picking libressl-dev over openssl-dev for packages that
had automatic pc:libssl depends (for example libssl2-dev), when
openssl-dev was the one that was used during build.
To fix this we add support for a pcprefix so we can set
pcprefix="libressl:" in libressl APKBUILD which makes libressl-dev
provide pc:libressl:libssl. This is similar to what we do with
sonameprefix.
We do not yet automatically detect when the prefixed variant should be
used so for now we will have to explicitly add libressl-dev.
ref #9959
```
* Revision 715b4a332048238d5f4784bdaa8f128859e755a0 by Natanael Copa on 2019-02-22T14:42:47Z:
```
main/abuild: backport support for pcprefix
ref #9959
```
* Revision 5db940af6587abdb7e3ca4d226ed0fec79773a88 by Natanael Copa on 2019-02-25T08:40:32Z:
```
main/libressl: upgrade to 2.7.5 and set pcprefix
ref #9959
```
* Revision 5dc3f744de00ce60ba421c3db7eaaaa143045446 by Natanael Copa on 2019-02-25T10:57:43Z:
```
main/abuild: backport support for pcprefix
ref #9959
(cherry picked from commit 715b4a332048238d5f4784bdaa8f128859e755a0)
```
* Revision 08ab682249a645c4dc445a8400f60b73fc259d36 by Natanael Copa on 2019-02-25T17:41:28Z:
```
main/libressl: upgrade to 2.7.5 and set pcprefix
fixes #9959
(cherry picked from commit 5db940af6587abdb7e3ca4d226ed0fec79773a88)
```
* Revision 5aba7d2b4943fa3b49e8f704f06de80c2dd0d583 by Natanael Copa on 2019-02-27T08:13:14Z:
```
community/remmina: explict depend on openssl
force rebuild against openssl instead of libressl due to implicit
dependency.
ref #9959
```3.9.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9811On edge of VM (almost three years of updating) and laptop (two months), alpin...2019-07-23T11:16:44ZSteffen NurpmesoOn edge of VM (almost three years of updating) and laptop (two months), alpine-base differsThe laptop also has community and testing, the VM server only main.
All report v3.8.0-4284-g5a7e6b2c57, but on the VM i have
@
\#?0|sdaoden:/boot\# apk info —who-owns /etc/os-release
/etc/os-release is owned by alpine-base-3.8.0-r...The laptop also has community and testing, the VM server only main.
All report v3.8.0-4284-g5a7e6b2c57, but on the VM i have
@
\#?0|sdaoden:/boot\# apk info —who-owns /etc/os-release
/etc/os-release is owned by alpine-base-3.8.0-r0
@
(it says 3.8.0) whereas on the laptop i have
@
\#?0|essex:/boot\# apk info —who-owns /etc/os-release
/etc/os-release is owned by alpine-base-3.8.1-r0
@
and it says 3.8.1.
*(from redmine: issue id 9811, created on 2018-12-28, closed on 2019-06-19)*3.10.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9775CIFS shares not auto mounting after reboot even with switch _netdev in fstab2021-02-08T12:47:26ZNebula ITCIFS shares not auto mounting after reboot even with switch _netdev in fstabI’m using this entry in fstab to mount a windows file share
<code class="c">
//Server Host Name/Data" /mnt/LocalData cifs uid-0,gid=0,user=username, password=password, domain=mydomain,_netdev 0 0
</code>
This works fine if ...I’m using this entry in fstab to mount a windows file share
<code class="c">
//Server Host Name/Data" /mnt/LocalData cifs uid-0,gid=0,user=username, password=password, domain=mydomain,_netdev 0 0
</code>
This works fine if I run “Mount -a”, this mounts the share and I can
work with it. But whenever I reboot the machine this share is not auto
mounted. Originally I thought issue was because it was trying to mount
the file share before network comes online, after some research I found
the “\_netdev” switch which tells fstab that it is a network drive and
it should wait till network is online before trying to mount. But that
does not change anything on Alpine version 3.8.1, I was unable to find
much info about this in logs as well.
I have tested this same fstab entry on latest version of centOS and it
works on reboot perfectly fine. Let me know if I can provide any
additional information to get this resolved.
*(from redmine: issue id 9775, created on 2018-12-19)*Nebula ITNebula IThttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9765Seg Fault py-usb on alpine armhf in x86_64 docker container with qemu_arm_static2020-04-10T19:33:16ZTom LloydSeg Fault py-usb on alpine armhf in x86_64 docker container with qemu_arm_staticSteps to reproduce:
docker run —rm —privileged multiarch/qemu-user-static:register —reset
------------------------------------------------------------------------
Dockerfile:
FROM multiarch/alpine:armhf-edge
RUN echo ‘http://dl-cdn....Steps to reproduce:
docker run —rm —privileged multiarch/qemu-user-static:register —reset
------------------------------------------------------------------------
Dockerfile:
FROM multiarch/alpine:armhf-edge
RUN echo ‘http://dl-cdn.alpinelinux.org/alpine/edge/testing’ >>
/etc/apk/repositories
RUN apk update
RUN apk add python2 libusb py-usb
------------------------------------------------------------------------
docker build .
docker run -it —rm <image-ref> /bin/sh
python2
import os
os.environ\[‘PYUSB\_DEBUG’\] = ‘debug’
import usb.core
usb.core.find()
------------------------------------------------------------------------
Expected output:
Command runs without seg fault but does load libusb-1.0.so.0.1.0 and
tries to enumerate usb devices
------------------------------------------------------------------------
Actual output:
Python 2.7.15 (default, Nov 7 2018, 16:59:23)
\[GCC 8.2.0\] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>>import os
>>>os.environ\[‘PYUSB\_DEBUG’\] = ‘debug’
>>>import usb.core
>>>usb.core.find()
2018-12-12 19:36:35,179
DEBUG:usb.backend.libusb1:*LibUSB.init*\_(<CDLL
‘libusb-1.0.so.0.1.0’, handle ff377530 at ff0b5d10>)
2018-12-12 19:36:35,185 ERROR:usb.backend.libusb1:Error loading libusb
1.0 backend
Traceback (most recent call last):
File “/usr/lib/python2.7/site-packages/usb/backend/libusb1.py”, line
945, in get\_backend
return \_LibUSB(\_lib)
File “/usr/lib/python2.7/site-packages/usb/\_debug.py”, line 60, in
do\_trace
return f(**args,**\*named\_args)
File “/usr/lib/python2.7/site-packages/usb/backend/libusb1.py”, line
708, in *init*
\_check(self.lib.libusb\_init(byref(self.ctx)))
File “/usr/lib/python2.7/site-packages/usb/backend/libusb1.py”, line
595, in \_check
raise USBError(\_strerror(ret), ret, \_libusb\_errno\[ret\])
USBError: \[Errno None\] Other error
2018-12-12 19:36:35,191
DEBUG:usb.backend.libusb1:\_LibUSB.\_finalize\_object()
Segmentation fault (core dumped)
*(from redmine: issue id 9765, created on 2018-12-12)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9655vc4_dri.so is missing from mesa in 3.8/3.8.1/edge2019-07-14T23:09:39ZYaron Shahrabanivc4_dri.so is missing from mesa in 3.8/3.8.1/edgeThe file was there in 3.7:
https://pkgs.alpinelinux.org/contents?file=&path=&name=mesa&branch=v3.7&repo=main&arch=armhf
In edge and 3.8 it’s missing although the other file is there, I tried
looking at the build log just to figure out...The file was there in 3.7:
https://pkgs.alpinelinux.org/contents?file=&path=&name=mesa&branch=v3.7&repo=main&arch=armhf
In edge and 3.8 it’s missing although the other file is there, I tried
looking at the build log just to figure out it’s too big for me to
analyze since I’m not really sure what I’m looking for.
https://pkgs.alpinelinux.org/contents?file=&path=&name=mesa&branch=v3.8&repo=main&arch=armhf
https://pkgs.alpinelinux.org/contents?file=&path=&name=mesa&branch=edge&repo=main&arch=armhf
I’m sure there’s an easier way to load X on a Dockerized Alpine running
on Raspberry Pi but I just couldn’t figure it yet…
*(from redmine: issue id 9655, created on 2018-11-20)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9653Trying to install desktop causes "ip ioctl 0x8913 failed No such device" errro2023-07-25T07:09:36ZJan CostermansTrying to install desktop causes "ip ioctl 0x8913 failed No such device" errroThis may or may not be the same issue as this one
https://bugs.alpinelinux.org/issues/9079.
The proposed fix does not resolve the issue in my case:
<code class="text">
echo "rc_need=udev-settle" > /etc/conf.d/networking && lbu ...This may or may not be the same issue as this one
https://bugs.alpinelinux.org/issues/9079.
The proposed fix does not resolve the issue in my case:
<code class="text">
echo "rc_need=udev-settle" > /etc/conf.d/networking && lbu ci
</code>
I am using a bootable USB installation on an old laptop (x86 CPU)
Part I. Setting up the bootable usb (this part may not be relevant for
the bug)
1. Create an install usb from alpine-standard-3.8.1-x86.iso
2. setup-alpine
3. prepare the second usb using fdisk, mkdosfs and setup-bootable
Part II. Booting the new bootable USB (run-from-ram)
1. setup-alpine
- I set up wlan0 (eth0 is not configured)
- I use the USB to store the apkovl
2. Save changes
<code class="text">
lbu commit
</code>
3. When rebooting, I have to
- run wpa\_supplicant
<code class="text">
/etc/wpa_supplicantwpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf
</code>
<!-- -->
- and restart networking
<code class="text">
/etc/init.d/networking restart
</code>
4. But when installing a desktop and rebooting, I cannot get the network
up anymore
<code class="text">
setup-xorg-base
</code>
5. On reboot you’ll see “ip ioctl 0x8913 failed No such device” and ip
link show will now no longer show wlan0 even in down state as mentioned
by bug \#9079.
I didn’t try this on Alpine Edge (yet)
*(from redmine: issue id 9653, created on 2018-11-18)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9368python3 strftime does not work properly in Alpine linux2019-07-23T11:22:08ZJc Dinpython3 strftime does not work properly in Alpine linuxIn alpine3.6 linux build strftime still returns an empty string whenever
\`dash\` is used in the format section.
Ubuntu using docker image alpine:3.6 with python3.6
<code class="python">
Python 3.6.6 (default, Aug 22 2018, 20:5...In alpine3.6 linux build strftime still returns an empty string whenever
\`dash\` is used in the format section.
Ubuntu using docker image alpine:3.6 with python3.6
<code class="python">
Python 3.6.6 (default, Aug 22 2018, 20:53:29)
[GCC 6.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> now = datetime.now()
>>> format = '%B %-d, %Y, %-I:%M %p'
>>> now.strftime(format)
''
>>>
</code>
Ubuntu using docker image alpine:3.6 with python2.7
<code class="python">
Python 2.7.15 (default, Aug 22 2018, 21:15:48)
[GCC 6.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> now = datetime.now()
>>> format = '%B %-d, %Y, %-I:%M %p'
>>> now.strftime(format)
'August 31, 2018, 11:03 AM'
>>>
</code>
*(from redmine: issue id 9368, created on 2018-08-31, closed on 2018-09-11)*3.6.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9279Busybox syslogd with -Z saves timestamps one hour behind2019-07-23T11:23:18ZEduard SanouBusybox syslogd with -Z saves timestamps one hour behindI noticed that entries of Busybox syslogd at /var/log/messages have the
wrong timezone: all timestamps are one hour behind localtime.
Steps to reproduce:
1 - Do a fresh install of alpine 3.8
2 - Read /var/log/messages
Example outpu...I noticed that entries of Busybox syslogd at /var/log/messages have the
wrong timezone: all timestamps are one hour behind localtime.
Steps to reproduce:
1 - Do a fresh install of alpine 3.8
2 - Read /var/log/messages
Example output (from a fresh alpine 3.8 install):
<code>
test:~# ls -l /etc/localtime
lrwxrwxrwx 1 root root 33 Aug 19 04:03 /etc/localtime -> /etc/zoneinfo/America/Los_Angeles
test:~# date
Sun Aug 19 04:13:37 PDT 2018
test:~# logger "$(date)"
test:~# tail /var/log/messages
Aug 19 03:05:40 test auth.info login[2116]: root login on 'tty1'
Aug 19 03:05:43 test daemon.info chronyd[2036]: Selected source 80.127.152.30
Aug 19 03:05:51 test user.notice root: Sun Aug 19 04:05:51 PDT 2018
Aug 19 03:06:49 test daemon.info chronyd[2036]: Selected source 212.45.35.66
Aug 19 03:11:08 test daemon.info chronyd[2036]: Selected source 213.154.236.182
Aug 19 03:12:56 test auth.info sshd[2115]: Received signal 15; terminating.
Aug 19 03:12:56 test auth.info sshd[2176]: Server listening on 0.0.0.0 port 22.
Aug 19 03:12:56 test auth.info sshd[2176]: Server listening on :: port 22.
Aug 19 03:13:22 test auth.info sshd[2181]: Accepted password for root from 192.168.122.1 port 34502 ssh2
Aug 19 03:13:43 test user.notice root: Sun Aug 19 04:13:43 PDT 2018
</code>
*(from redmine: issue id 9279, created on 2018-08-19, closed on 2019-03-05)*
* Changesets:
* Revision 397f0cd902eaadce3b74e1e3021e941d9bb6ba72 on 2019-02-15T22:23:00Z:
```
main/busybox: upgrade to 1.30.0
Notable changes:
* The sysklogd -Z option has been removed in favor of -t option
which has been added by upstream.
* Our own nologin.c applet has been replaced by an upstream
nologin shell applet.
* New bc applet.
OK ncopa@
Fixes #9279
Fixes #7818
```3.8.3Natanael CopaNatanael Copa