aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2021-02-07T14:51:24Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/7997http_proxy results in 'wget: error getting response' using ISO boot2021-02-07T14:51:24Zalgitbothttp_proxy results in 'wget: error getting response' using ISO boot**Setup:**
Using Alpine 3.6.2 Standard ISO x86\_64.
Booting from the iso.
Have a Squid 3.1.x proxy setup using environmental variable http\_proxy.
**Test:**
Regardless of manual tests (set env and test wget) or setup-alpine, wge...**Setup:**
Using Alpine 3.6.2 Standard ISO x86\_64.
Booting from the iso.
Have a Squid 3.1.x proxy setup using environmental variable http\_proxy.
**Test:**
Regardless of manual tests (set env and test wget) or setup-alpine, wget
returns:
`wget: error getting response`
This was last working on the standard x86\_64 ISO in Alpine 3.5.2.
Squid proxy report `TCP_MISS/000 0 GET`
**Problem caused:**
Unable to proceed with installation of 3.6.2 without proxy working.
*(from redmine: issue id 7997, created on 2017-10-11)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9963patch -R : patch: can't remove file 'null': No such file or directory2021-02-06T17:43:26ZLeo Baltuspatch -R : patch: can't remove file 'null': No such file or directoryattached patch when applied creates a new file
patch -p2 </src/ipxe-77f64b1.embed-retry-dhcp.patch
creating myscript.ipxe
However, when using -R (reverse) it says:
patch -R -p2 <ipxe-77f64b1.embed-retry-dhcp.patch
patching...attached patch when applied creates a new file
patch -p2 </src/ipxe-77f64b1.embed-retry-dhcp.patch
creating myscript.ipxe
However, when using -R (reverse) it says:
patch -R -p2 <ipxe-77f64b1.embed-retry-dhcp.patch
patching file null
patch: can’t open ‘null’: No such file or directory
I expected patch to remove the new file, like gnu-patch does.
*(from redmine: issue id 9963, created on 2019-02-06)*
* Uploads:
* [ipxe-77f64b1.embed-retry-dhcp.patch](/uploads/3fa2fe1b4afc62e72e459fcfd173183c/ipxe-77f64b1.embed-retry-dhcp.patch)https://gitlab.alpinelinux.org/alpine/aports/-/issues/8725Squid 3.5.27 Intel2021-02-06T17:41:58ZRandy SchusterSquid 3.5.27 IntelAlpine Intel Squid package experiences segmentation faults many times a
day when ran on VMware 14 Player 64-bit or Intel® Pentium® Processor
N3700 hardware.
Recompiled squid from http://www.squid-cache.org on the N3700 seems to
have res...Alpine Intel Squid package experiences segmentation faults many times a
day when ran on VMware 14 Player 64-bit or Intel® Pentium® Processor
N3700 hardware.
Recompiled squid from http://www.squid-cache.org on the N3700 seems to
have resolved the issue for that system.
Samples messages from the VMware instance are listed below.
Mar 11 12:36:00 squid local4.notice squid\[3747\]: Squid Parent:
(squid-1) process 3749 exited due to signal 11 with status 0
Mar 11 12:36:00 squid kern.info kernel: \[ 9167.609068\] squid\[3749\]:
segfault at 73e700000028 ip 000009c763e64599 sp 000078901080c110 error 4
in squid\[9c763bb6000+471000\]
Mar 11 12:36:00 squid kern.alert kernel: \[ 9167.609092\] grsec: From
192.168.72.1: Segmentation fault occurred at 000073e700000028 in
/usr/sbin/squid\[squid:3749\] uid/euid:31/31 gidMar 11 12:36:00 squid
kern.alert kernel: \[ 9167.609103\] grsec: From 192.168.72.1: denied
resource overstep by requesting 4096 for RLIMIT\_CORE against limit 0
for /usr/sbin/squid\[sMar 11 12:36:00 squid kern.alert kernel: \[
9167.609110\] grsec: From 192.168.72.1: bruteforce prevention initiated
for the next 30 minutes or until service restarted, stalling each
*(from redmine: issue id 8725, created on 2018-03-24)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/8630virtualbox-guest-modules-virthardened missing vbovvideo and vboxdrv2021-02-06T17:40:09Zalgitbotvirtualbox-guest-modules-virthardened missing vbovvideo and vboxdrvI’ve notice that the virtual-box-guest-modules for virt and virthardened
appear to be missing vboxvideo
https://pkgs.alpinelinux.org/contents?file=vboxvideo.ko&path=&name=&branch=edge
https://pkgs.alpinelinux.org/contents?file=vbox\*.k...I’ve notice that the virtual-box-guest-modules for virt and virthardened
appear to be missing vboxvideo
https://pkgs.alpinelinux.org/contents?file=vboxvideo.ko&path=&name=&branch=edge
https://pkgs.alpinelinux.org/contents?file=vbox\*.ko&path=&name=&branch=edge
Not sure if there a reason for this? Attempting to get display resizing
and seamless mode working with virtualbox.
Thanks
*(from redmine: issue id 8630, created on 2018-03-08)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10138ovs-vswitchd: possible memory leak in 2.10.1 (Alpine 3.9)2021-02-05T07:02:50ZFernando Casas Schössowovs-vswitchd: possible memory leak in 2.10.1 (Alpine 3.9)I’m running OVS on a Qemu/KVM virtualization host for a while now. The
virtualization host is running around 12 VMs without a huge network
activity. The OVS configuration is very simple, nothing fancy. Four
VLANs, two bond ports with two...I’m running OVS on a Qemu/KVM virtualization host for a while now. The
virtualization host is running around 12 VMs without a huge network
activity. The OVS configuration is very simple, nothing fancy. Four
VLANs, two bond ports with two slaves each, three internal ports and
then one port for each VM (I can provide the output of ovs-vsctl show if
needed).
Recently I noticed that when the ovs-vswitchd process starts it’s
consuming around 10MB of RAM but after two weeks (the server is running
24x7) ovs-vswitchd can be consuming around 2.5GB of RAM and after let’s
say a month or so it will be around 5GB or even a bit more.
What I’m doing now to keep ovs-vswitchd memory usage under control is to
restart the service every couple of weeks but this is far from ideal.
Please find below some additional information about my setup and feel
free to ask for any other details I may have missed.
OVS command line: /usr/sbin/ovs-vswitchd
—pidfile=/var/run/openvswitch/ovs-vswitchd.pid —detach —monitor
—mlockall unix:/var/run/openvswitch/db.sock
OVS version: 2.10.1
Distro: Alpine Linux 3.9.2
Linux kernel version: 4.19.26
Qemu version: 3.1
Libvirt version: 4.10.0
OVS memory usage from log file:
2018-09-07T22:02:54+02:00 vmsvr01 ovs-vswitchd: ovs|00030|memory|INFO|10316 kB peak resident set size after 10.0 seconds
2018-09-07T22:02:54+02:00 vmsvr01 ovs-vswitchd: ovs|00031|memory|INFO|handlers:5 ports:2 revalidators:3 rules:5 udpif keys:23
2018-09-07T22:12:05+02:00 vmsvr01 ovs-vswitchd: ovs|00030|memory|INFO|10316 kB peak resident set size after 10.0 seconds
2018-09-07T22:12:05+02:00 vmsvr01 ovs-vswitchd: ovs|00031|memory|INFO|handlers:5 ports:2 revalidators:3 rules:5 udpif keys:21
2018-09-08T10:48:18+02:00 vmsvr01 ovs-vswitchd: ovs|00702|memory|INFO|peak resident set size grew 51% in last 3472.0 seconds, from 10300 kB to 15572 kB
2018-09-08T10:48:18+02:00 vmsvr01 ovs-vswitchd: ovs|00703|memory|INFO|handlers:5 ports:13 revalidators:3 rules:5 udpif keys:18
2018-09-08T12:21:11+02:00 vmsvr01 ovs-vswitchd: ovs|00704|memory|INFO|peak resident set size grew 51% in last 5573.2 seconds, from 15572 kB to 23492 kB
2018-09-08T12:21:11+02:00 vmsvr01 ovs-vswitchd: ovs|00705|memory|INFO|handlers:5 ports:13 revalidators:3 rules:5 udpif keys:32
2018-09-08T14:46:16+02:00 vmsvr01 ovs-vswitchd: ovs|00706|memory|INFO|peak resident set size grew 51% in last 8705.3 seconds, from 23492 kB to 35372 kB
2018-09-08T14:46:16+02:00 vmsvr01 ovs-vswitchd: ovs|00707|memory|INFO|handlers:5 ports:13 revalidators:3 rules:5 udpif keys:16
2018-09-08T17:46:03+02:00 vmsvr01 ovs-vswitchd: ovs|00708|memory|INFO|peak resident set size grew 50% in last 10786.3 seconds, from 35372 kB to 53060 kB
2018-09-08T17:46:03+02:00 vmsvr01 ovs-vswitchd: ovs|00709|memory|INFO|handlers:5 ports:13 revalidators:3 rules:5 udpif keys:18
2018-09-08T23:08:45+02:00 vmsvr01 ovs-vswitchd: ovs|00720|memory|INFO|peak resident set size grew 50% in last 19362.0 seconds, from 53060 kB to 79724 kB
2018-09-08T23:08:45+02:00 vmsvr01 ovs-vswitchd: ovs|00721|memory|INFO|handlers:5 ports:14 revalidators:3 rules:5 udpif keys:27
2018-09-09T06:41:39+02:00 vmsvr01 ovs-vswitchd: ovs|00722|memory|INFO|peak resident set size grew 50% in last 27174.2 seconds, from 79724 kB to 119588 kB
2018-09-09T06:41:39+02:00 vmsvr01 ovs-vswitchd: ovs|00723|memory|INFO|handlers:5 ports:14 revalidators:3 rules:5 udpif keys:26
2018-09-09T18:02:35+02:00 vmsvr01 ovs-vswitchd: ovs|00724|memory|INFO|peak resident set size grew 50% in last 40856.1 seconds, from 119588 kB to 179516 kB
2018-09-09T18:02:35+02:00 vmsvr01 ovs-vswitchd: ovs|00725|memory|INFO|handlers:5 ports:14 revalidators:3 rules:5 udpif keys:37
2018-09-10T10:58:41+02:00 vmsvr01 ovs-vswitchd: ovs|00727|memory|INFO|peak resident set size grew 50% in last 60965.9 seconds, from 179516 kB to 269276 kB
2018-09-10T10:58:41+02:00 vmsvr01 ovs-vswitchd: ovs|00728|memory|INFO|handlers:5 ports:15 revalidators:3 rules:5 udpif keys:39
2018-09-11T14:54:02+02:00 vmsvr01 ovs-vswitchd: ovs|00734|memory|INFO|peak resident set size grew 50% in last 100521.3 seconds, from 269276 kB to 403916 kB
2018-09-11T14:54:02+02:00 vmsvr01 ovs-vswitchd: ovs|00735|memory|INFO|handlers:5 ports:14 revalidators:3 rules:5 udpif keys:16
2018-09-13T08:06:22+02:00 vmsvr01 ovs-vswitchd: ovs|00740|memory|INFO|peak resident set size grew 50% in last 148339.4 seconds, from 403916 kB to 605876 kB
2018-09-13T08:06:22+02:00 vmsvr01 ovs-vswitchd: ovs|00741|memory|INFO|handlers:5 ports:15 revalidators:3 rules:5 udpif keys:15
2018-09-15T21:54:39+02:00 vmsvr01 ovs-vswitchd: ovs|00750|memory|INFO|peak resident set size grew 50% in last 222497.4 seconds, from 605876 kB to 908948 kB
2018-09-15T21:54:39+02:00 vmsvr01 ovs-vswitchd: ovs|00751|memory|INFO|handlers:5 ports:14 revalidators:3 rules:5 udpif keys:20
2018-09-19T18:15:25+02:00 vmsvr01 ovs-vswitchd: ovs|00763|memory|INFO|peak resident set size grew 50% in last 332445.8 seconds, from 908948 kB to 1363556 kB
2018-09-19T18:15:25+02:00 vmsvr01 ovs-vswitchd: ovs|00764|memory|INFO|handlers:5 ports:13 revalidators:3 rules:5 udpif keys:46
2018-09-25T11:54:40+02:00 vmsvr01 ovs-vswitchd: ovs|00855|memory|INFO|peak resident set size grew 50% in last 495554.7 seconds, from 1363556 kB to 2045468 kB
2018-09-25T11:54:40+02:00 vmsvr01 ovs-vswitchd: ovs|00856|memory|INFO|handlers:5 ports:16 revalidators:3 rules:5 udpif keys:53
2018-10-04T08:31:40+02:00 vmsvr01 ovs-vswitchd: ovs|00888|memory|INFO|peak resident set size grew 50% in last 765420.9 seconds, from 2045468 kB to 3068204 kB
2018-10-04T08:31:40+02:00 vmsvr01 ovs-vswitchd: ovs|00889|memory|INFO|handlers:5 ports:14 revalidators:3 rules:5 udpif keys:42
2018-10-16T14:45:35+02:00 vmsvr01 ovs-vswitchd: ovs|00911|memory|INFO|peak resident set size grew 50% in last 1059234.5 seconds, from 3068204 kB to 4602308 kB
2018-10-16T14:45:35+02:00 vmsvr01 ovs-vswitchd: ovs|00912|memory|INFO|handlers:5 ports:14 revalidators:3 rules:5 udpif keys:27
2018-11-04T06:27:02+01:00 vmsvr01 ovs-vswitchd: ovs|01015|memory|INFO|peak resident set size grew 50% in last 1615287.6 seconds, from 4602308 kB to 6903596 kB
2018-11-04T06:27:02+01:00 vmsvr01 ovs-vswitchd: ovs|01016|memory|INFO|handlers:5 ports:13 revalidators:3 rules:5 udpif keys:1
2018-12-01T19:28:14+01:00 vmsvr01 ovs-vswitchd: ovs|01092|memory|INFO|peak resident set size grew 50% in last 2379671.3 seconds, from 6903596 kB to 10355396 kB
2018-12-01T19:28:14+01:00 vmsvr01 ovs-vswitchd: ovs|01093|memory|INFO|handlers:5 ports:13 revalidators:3 rules:5 udpif keys:18
2019-01-12T13:12:25+01:00 vmsvr01 ovs-vswitchd: ovs|01234|memory|INFO|peak resident set size grew 50% in last 3606251.1 seconds, from 10355396 kB to 15533228 kB
2019-01-12T13:12:25+01:00 vmsvr01 ovs-vswitchd: ovs|01235|memory|INFO|handlers:5 ports:13 revalidators:3 rules:5 udpif keys:46
Also I’m attaching two screenshots from Munin monitoring ovs-vswitchd
rss size and meminfo for around five days and how memory usage growth is
almost linear to time.
I can provide a memory dump of the process while consuming 500MB of RAM
(collected using gcore) if that would help.
Please let me know if you need any more details.
*(from redmine: issue id 10138, created on 2019-03-19)*
* Uploads:
* ![meminfo_ovs-vswitchd](/uploads/fb9fdf16f5cede0fc867e3c854a0c028/meminfo_ovs-vswitchd.png)
* ![rss_ovs-vswitchd](/uploads/602eed37350672dc2279f6714bbd84f5/rss_ovs-vswitchd.png)https://gitlab.alpinelinux.org/alpine/aports/-/issues/10115missing iptables kernel modules2021-02-03T16:22:40ZIvan Kalashnikovmissing iptables kernel modulesThe package linux-rpi not contains modules xt\_socket.ko,
nf\_socket\_ipv4.ko and nf\_socket\_ipv6.ko,
but they exists in the outdated package, release 3.7 and early.
*(from redmine: issue id 10115, created on 2019-03-14)*
* Uploads...The package linux-rpi not contains modules xt\_socket.ko,
nf\_socket\_ipv4.ko and nf\_socket\_ipv6.ko,
but they exists in the outdated package, release 3.7 and early.
*(from redmine: issue id 10115, created on 2019-03-14)*
* Uploads:
* [iptables_filtered.config](/uploads/fce10a3f1fad8b6e2eafcba2c0ccdb2e/iptables_filtered.config)3.12.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/10443Raspberry Pi 3 Mod B not booting2021-01-30T13:23:56ZPeter EggenRaspberry Pi 3 Mod B not bootingHi,
following the install procedure for Mac I tried to install the new
version 3.9.4. Whithout anychanges, the Pi did not boot up at all
signaling a
missing kernel - green LED will blink 7 times.
After editing the config.txt file a...Hi,
following the install procedure for Mac I tried to install the new
version 3.9.4. Whithout anychanges, the Pi did not boot up at all
signaling a
missing kernel - green LED will blink 7 times.
After editing the config.txt file and including a section for Pi3 (see
below) I was able to at least start the boot process but ending in a
kernel panic.
Wondering if anyone has ever tested this out.
Regards Gunhawk
disable\_splash=1
boot\_delay=0
gpu\_mem=256
gpu\_mem\_256=64
\[pi3\]
kernel=boot/vmlinuz-rpi2
Initramfs boot/initramfs-rpi2
\[pi0\]
kernel=boot/vmlinuz-rpi
initramfs boot/initramfs-rpi
\[pi1\]
kernel=boot/vmlinuz-rpi
initramfs boot/initramfs-rpi
\[all\]
include usercfg.txt
*(from redmine: issue id 10443, created on 2019-05-10)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/102063.9.2 not parsing /etc/network/interfaces correctly2021-01-30T13:21:05ZJohn Doe3.9.2 not parsing /etc/network/interfaces correctlyIf I have an /etc/network/interfaces file like the below, when the
system gets rebooted, only eth0 and eth0:0 are created, eth0:1 never
gets created.
This seems to be a bug of some sort ?
auto lo
iface lo inet loopback
aut...If I have an /etc/network/interfaces file like the below, when the
system gets rebooted, only eth0 and eth0:0 are created, eth0:1 never
gets created.
This seems to be a bug of some sort ?
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.0.2.30
netmask 255.255.255.0
broadcast 192.0.2.255
gateway 192.0.2.250
auto eth0:0
iface eth0:0 inet static
name Foo
address 192.0.2.31
netmask 255.255.255.0
broadcast 192.0.2.255
auto eth0:1
iface eth0:1 inet static
name Bar
address 192.0.2.32
netmask 255.255.255.0
broadcast 192.0.2.255
*(from redmine: issue id 10206, created on 2019-04-07)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/8768nagios incompatible with busybox's ping2021-01-30T00:46:06ZHadmut Danischnagios incompatible with busybox's pingHi,
I was just trying to pack nagios into a alpine-3.7-based docker images
with the nagios packages coming with alpine, and ran into an
alpine-specific problem: nagios kept complaining that it could not parse
the output of the /bin/ping...Hi,
I was just trying to pack nagios into a alpine-3.7-based docker images
with the nagios packages coming with alpine, and ran into an
alpine-specific problem: nagios kept complaining that it could not parse
the output of the /bin/ping command and thus the ping test failed
permanently.
Reason: On common linux machines /bin/ping is a binary with u+s (setuid
root) to allow all users to send ping packages. In contrast, on alpine
it is just a symlink to busybox, which does the same job, but does not
have the setuid bit set. A simple chmod u+s /bin/busybox solves the
problem, nagios then works, but it obviously opens a hell of security
problems when all commands implemented by busybox have a suid bit.
*(from redmine: issue id 8768, created on 2018-04-05)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/8301Segmentation fault occurs when running "setup-disk"2021-01-30T00:41:24ZDavid FallahSegmentation fault occurs when running "setup-disk"As part of an attempt to install Alpine Linux in traditional (sys) mode
on a Rasberry Pi, the guide
[here](https://wiki.alpinelinux.org/wiki/Classic_install_or_sys_mode_on_Raspberry_Pi)
instructs to run `setup-disk -m sys /mnt` after mou...As part of an attempt to install Alpine Linux in traditional (sys) mode
on a Rasberry Pi, the guide
[here](https://wiki.alpinelinux.org/wiki/Classic_install_or_sys_mode_on_Raspberry_Pi)
instructs to run `setup-disk -m sys /mnt` after mounting an
ext4-formatted partition on the SD card under `/mnt`.
I consistently find the progress bar reaches 90% and then encounters a
segmentation fault. This is in addition to other errors displayed while
running the command (that I can supposedly ignore).
rpi:~# setup-disk -m sys /mnt
ERROR: unsatisfiable constraints:
syslinux (missing):
required by: world[syslinux]
Installing system on /dev/mmcblk0p2:
sed: /etc/update-extlinux.conf: No such file or directory
/sbin/setup-disk: line 1178: extlinux: not found
ERROR: Failed to create lib/firmware/iwlwifi-7265D-29.ucode: No error information
ERROR: linux-firmware-20171121-r0: BAD signature
ERROR: linux-rpi2-4.9.65-r0: BAD signature
ERROR: openssh-keygen-7.5_p1-r7: BAD signature
ERROR: openssh-client-7.5_p1-r7: IO ERROR
ERROR: openssh-sftp-server-7.5_p1-r7: BAD signature
90% ############################################################################################################################################# Segmentation fault
Attached is a “core” file containing more information.
*(from redmine: issue id 8301, created on 2017-12-14)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/8384postgresql-dev contains references to undefined symbols2021-01-30T00:40:03Zalgitbotpostgresql-dev contains references to undefined symbolsWhen attempting to statically link an executable which uses libpq, I get
a series of errors from gcc (see attached). I suspect that the problem
lies in how the postgresql package is built, namely the —with-openssl
flag. The package depen...When attempting to statically link an executable which uses libpq, I get
a series of errors from gcc (see attached). I suspect that the problem
lies in how the postgresql package is built, namely the —with-openssl
flag. The package depends on libressl, which doesn’t have any of the
symbols libpq expects.
https://github.com/postgres/postgres/blob/6271fceb8a4f07dafe9d67dcf7e849b319bb2647/src/interfaces/libpq/Makefile\#L54
I was able to successfully build an APK without —with-openssl. Might
this be a good fix?
*(from redmine: issue id 8384, created on 2018-01-07)*
* Uploads:
* [error.txt](/uploads/46f05f2785c88fd3c9361b5ecb93de8c/error.txt)https://gitlab.alpinelinux.org/alpine/aports/-/issues/8486please rip out all unneeded parts of busybox's fsck from initrd2021-01-30T00:36:59ZFlorian Heiglplease rip out all unneeded parts of busybox's fsck from initrdCurrently, there are multiple parts that look like we have a working
fsck in an initramfs provided by busybox.
As per kaniini the only supported fsck is the one from e2fsprogs.
We still got things like fsck.auto and some busybox-fsck ...Currently, there are multiple parts that look like we have a working
fsck in an initramfs provided by busybox.
As per kaniini the only supported fsck is the one from e2fsprogs.
We still got things like fsck.auto and some busybox-fsck symlinks that
also seem to be there even if they don’t work.
Would be great if this stuff could be completely removed.
*(from redmine: issue id 8486, created on 2018-02-13)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/8407/boot has somehow become a symlink to /2021-01-30T00:16:14ZJose Jurado/boot has somehow become a symlink to /x86\_64 architecture; 3.6.3 was earlier upgraded to 3.7.0; original .iso
was a hardened x86\_64 c. 3.6.2. First noticed this problem because I
couldn’t find /boot/syslinux/syslinux.cfg
root@localhost:~# cd /boot
root@localhost:/...x86\_64 architecture; 3.6.3 was earlier upgraded to 3.7.0; original .iso
was a hardened x86\_64 c. 3.6.2. First noticed this problem because I
couldn’t find /boot/syslinux/syslinux.cfg
root@localhost:~# cd /boot
root@localhost:/boot# ls
System.map-hardened extlinux.conf.old libcom32.c32 menu.c32
boot initramfs-hardened libutil.c32 vesamenu.c32
config-hardened ldlinux.c32 lost+found vmlinuz-hardened
extlinux.conf ldlinux.sys mboot.c32
root@localhost:/boot# cd boot
root@localhost:/# cd /boot/boot/
root@localhost:/# ls
bin dev home lost+found mnt root run srv sys usr
boot etc lib media proc rules.d sbin swap tmp var
root@localhost:/# cd /boot/boot/boot
root@localhost:/boot# ls
System.map-hardened extlinux.conf.old libcom32.c32 menu.c32
boot initramfs-hardened libutil.c32 vesamenu.c32
config-hardened ldlinux.c32 lost+found vmlinuz-hardened
extlinux.conf ldlinux.sys mboot.c32
On closer examination, /boot has become a symlink to / as shown:
root@localhost:~# cd ..
root@localhost:/# pwd
/
root@localhost:/# ls -l
total 113
drwxr-xr-x 2 root root 4096 Dec 21 13:52 bin
drwxr-xr-x 3 root root 1024 Dec 3 02:31 boot
drwxr-xr-x 17 root root 3640 Jan 20 11:30 dev
drwxr-xr-x 65 root root 4096 Jan 18 19:15 etc
drwxr-xr-x 3 root root 4096 Jan 17 15:26 home
drwxr-xr-x 9 root root 4096 Jan 19 13:05 lib
drwx------ 2 root root 16384 Nov 14 17:11 lost+found
drwxr-xr-x 7 root root 4096 Nov 16 23:15 media
drwxr-xr-x 3 root root 4096 Nov 22 10:57 mnt
dr-xr-xr-x 223 root readproc 0 Jan 20 11:30 proc
drwx------ 15 root root 4096 Dec 29 16:44 root
drwxr-xr-x 2 root root 4096 Jan 13 18:01 rules.d
drwxr-xr-x 15 root root 580 Jan 20 11:32 run
drwxr-xr-x 2 root root 12288 Jan 13 18:00 sbin
drwxr-xr-x 2 root root 4096 Nov 14 17:12 srv
drwxr-xr-x 2 root root 4096 Nov 14 17:17 swap
dr-xr-xr-x 13 root root 0 Jan 20 11:30 sys
drwxrwxrwt 5 root root 32768 Jan 20 11:37 tmp
drwxr-xr-x 11 root root 4096 Nov 15 09:55 usr
drwxr-xr-x 12 root root 4096 Dec 3 00:46 var
root@localhost:/# cd /boot
root@localhost:/boot# ls -l
total 20363
-rw-r--r-- 1 root root 4131160 Nov 27 10:59 System.map-hardened
lrwxrwxrwx 1 root root 1 Nov 14 17:16 boot -> /
-rw-r--r-- 1 root root 165139 Nov 27 10:59 config-hardened
-rw-r--r-- 1 root root 439 Dec 13 15:26 extlinux.conf
-rw-r--r-- 1 root root 439 Dec 1 10:33 extlinux.conf.old
-rw-r--r-- 1 root root 11574996 Nov 30 17:34 initramfs-hardened
-r--r--r-- 1 root root 116924 Dec 3 02:31 ldlinux.c32
-r--r--r-- 1 root root 69632 Dec 3 02:31 ldlinux.sys
-rw-r--r-- 1 root root 181996 Dec 3 02:31 libcom32.c32
-rw-r--r-- 1 root root 23616 Dec 3 02:31 libutil.c32
drwx------ 2 root root 12288 Nov 14 17:11 lost+found
-rw-r--r-- 1 root root 11712 Dec 3 02:31 mboot.c32
-rw-r--r-- 1 root root 26568 Dec 3 02:31 menu.c32
-rw-r--r-- 1 root root 27020 Dec 3 02:31 vesamenu.c32
-rw-r--r-- 1 root root 4502608 Nov 27 10:59 vmlinuz-hardened
root@localhost:/boot# cd /boot/boot
root@localhost:/# ls -l
total 113
drwxr-xr-x 2 root root 4096 Dec 21 13:52 bin
drwxr-xr-x 3 root root 1024 Dec 3 02:31 boot
drwxr-xr-x 17 root root 3640 Jan 20 11:30 dev
drwxr-xr-x 65 root root 4096 Jan 18 19:15 etc
drwxr-xr-x 3 root root 4096 Jan 17 15:26 home
drwxr-xr-x 9 root root 4096 Jan 19 13:05 lib
drwx------ 2 root root 16384 Nov 14 17:11 lost+found
drwxr-xr-x 7 root root 4096 Nov 16 23:15 media
drwxr-xr-x 3 root root 4096 Nov 22 10:57 mnt
dr-xr-xr-x 222 root readproc 0 Jan 20 11:30 proc
drwx------ 15 root root 4096 Dec 29 16:44 root
drwxr-xr-x 2 root root 4096 Jan 13 18:01 rules.d
drwxr-xr-x 15 root root 580 Jan 20 11:32 run
drwxr-xr-x 2 root root 12288 Jan 13 18:00 sbin
drwxr-xr-x 2 root root 4096 Nov 14 17:12 srv
drwxr-xr-x 2 root root 4096 Nov 14 17:17 swap
dr-xr-xr-x 13 root root 0 Jan 20 11:30 sys
drwxrwxrwt 5 root root 32768 Jan 20 11:37 tmp
drwxr-xr-x 11 root root 4096 Nov 15 09:55 usr
drwxr-xr-x 12 root root 4096 Dec 3 00:46 var
This is being flagged up as a possible vulnerability, but I couldn’t
identify how it was created. System has otherwise appeared to have been
booting and running unsuspectingly smoothly except for the following:
\- Battery began to quickly empty (within minutes) shortly after
purchase, so AC power is required.
- Launching a shell has been returning a prompt with an “ash: out of
range” response for months, which led me to an attempt today to try to
fix this and to notice that I couldn’t find syslinux.cfg (further to
suggestion to fix grub, as at
https://ubuntuforums.org/showthread.php?t=1751950)
Months ago, syslinux.cfg had been found and edited. Running a search for
syslinux.cfg today yields no results; note response to ls
/usr/bin/syslinux:
root@localhost:/boot# whereis syslinux.cfg
syslinux: /usr/bin/syslinux /usr/share/syslinux
root@localhost:/boot# ls /usr/bin/syslinux
/usr/bin/syslinux
root@localhost:/boot# ls /usr/share/syslinux
altmbr.bin dmi.c32 isohdpfx.bin lpxelinux.0 reboot.c32
altmbr_c.bin dmitest.c32 isohdpfx_c.bin ls.c32 rosh.c32
altmbr_f.bin dosutil isohdpfx_f.bin lua.c32 sanboot.c32
cat.c32 efi64 isohdppx.bin mboot.c32 sdi.c32
chain.c32 elf.c32 isohdppx_c.bin mbr.bin sysdump.c32
cmd.c32 ethersel.c32 isohdppx_f.bin mbr_c.bin syslinux.c32
cmenu.c32 gfxboot.c32 isolinux-debug.bin mbr_f.bin syslinux.com
com32 gptmbr.bin isolinux.bin memdisk syslinux.exe
config.c32 gptmbr_c.bin kbdmap.c32 meminfo.c32 syslinux64.exe
cptime.c32 gptmbr_f.bin kontron_wdt.c32 menu.c32 vesa.c32
cpu.c32 gpxecmd.c32 ldlinux.c32 pci.c32 vesainfo.c32
cpuid.c32 hdt.c32 lfs.c32 pcitest.c32 vesamenu.c32
cpuidtest.c32 hexdump.c32 libcom32.c32 pmload.c32 vpdtest.c32
debug.c32 host.c32 libgpl.c32 poweroff.c32 whichsys.c32
dhcp.c32 ifcpu.c32 liblua.c32 prdhcp.c32 zzjson.c32
diag ifcpu64.c32 libmenu.c32 pwd.c32
dir.c32 ifmemdsk.c32 libutil.c32 pxechn.c32
disk.c32 ifplop.c32 linux.c32 pxelinux.0
I considered posting this on the forum but was concerned due to the
relative lack of response there (but I am very grateful for so much
development activity!)
*(from redmine: issue id 8407, created on 2018-01-20)*3.7.4Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/8068setup-interfaces: Don't echo wlan pre-shared key2021-01-30T00:08:23Zalgitbotsetup-interfaces: Don't echo wlan pre-shared keyCurrently, `setup-interfaces` will echo the pre-shared key as the user
types it, which is something I haven’t seen elsewhere. I’m proposing
this as a feature, though perhaps there’s a rationale behind this that
I’m not seeing.
*(from r...Currently, `setup-interfaces` will echo the pre-shared key as the user
types it, which is something I haven’t seen elsewhere. I’m proposing
this as a feature, though perhaps there’s a rationale behind this that
I’m not seeing.
*(from redmine: issue id 8068, created on 2017-10-27)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/6699wpa_supplicant missing from alpine-desktop iso build2021-01-30T00:06:57ZMr Greenwpa_supplicant missing from alpine-desktop iso buildHave tried a number of times to get network-extras to load into
alpine-desktop iso. Apks are being loaded at boot (can see progress bar)
however there is no sign of wpa\_supplicant once booted. Xfce4 takes
around 5 minutes to load and de...Have tried a number of times to get network-extras to load into
alpine-desktop iso. Apks are being loaded at boot (can see progress bar)
however there is no sign of wpa\_supplicant once booted. Xfce4 takes
around 5 minutes to load and desktop appear. Will admit this is on an
old i686 laptop with very little ram. What I do not understand is that
wpa\_supplicant is present on normal install iso.
If there was a way to change screen resolution at boot I could tell you
what is holding up boot process, guessing it could be network trying to
start and then failing….
*(from redmine: issue id 6699, created on 2017-01-17)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/8380busybox config request2021-01-29T02:01:02Zalgitbotbusybox config requestI have noticed the default busybox used by Alpine is not enabling who(1)
nor w(1). Those are quite useful commands. Request to enable it in
‘busyboxconfig’.
*(from redmine: issue id 8380, created on 2018-01-05)*I have noticed the default busybox used by Alpine is not enabling who(1)
nor w(1). Those are quite useful commands. Request to enable it in
‘busyboxconfig’.
*(from redmine: issue id 8380, created on 2018-01-05)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10627clang requires a few gcc libraries, which supposed to be privided by compiler-rt2021-01-29T01:16:23ZTrevis Schifferclang requires a few gcc libraries, which supposed to be privided by compiler-rtHello, I noticed something strange.
Some of the crt files should come from compiler-crt, but these ones come
with gcc:
crtprec32.o
crtendS.o
crtbeginS.o
crtfastmath.o
crtprec64.o
crtbeginT.o
crtprec80.o
...Hello, I noticed something strange.
Some of the crt files should come from compiler-crt, but these ones come
with gcc:
crtprec32.o
crtendS.o
crtbeginS.o
crtfastmath.o
crtprec64.o
crtbeginT.o
crtprec80.o
crtbegin.o
crtend.o
Above libs are not usable without gcc libs (Thus I guess GPL is still
enforced?).
b17wise@eula47 /tmp % clang Hello.c -o hello -fuse-ld=/usr/bin/ld.lld
ld.lld: error: cannot open crtbeginS.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: cannot open crtendS.o: No such file or directory
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
b17wise@eula47 /tmp % sudo apk add gcc
[sudo] password for b17wise:
(1/8) Installing binutils (2.32-r0)
(2/8) Installing isl (0.18-r0)
(3/8) Installing libgomp (8.3.0-r0)
(4/8) Installing libatomic (8.3.0-r0)
(5/8) Installing mpfr3 (3.1.5-r1)
(6/8) Installing mpc1 (1.1.0-r0)
(7/8) Installing gcc (8.3.0-r0)
(8/8) Installing gcc-zsh-completion (5.7.1-r0)
Executing busybox-1.30.1-r2.trigger
OK: 2012 MiB in 482 packages
b17wise@eula47 /tmp % clang Hello.c -o hello -fuse-ld=/usr/bin/ld.lld
b17wise@eula47 /tmp % ./hello
Hello, Alpine
b17wise@eula47 /tmp % apk info -L gcc | grep -e *crtendS*
b17wise@eula47 /tmp % apk info -L gcc | grep crt
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtbegin.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtend.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtbeginT.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtbeginS.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtprec32.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtprec80.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtprec64.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtendS.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtfastmath.o
Full log can be found here: http://0x0.st/z2k6.txt
Also there was an issue raised in 2017: https://reviews.llvm.org/D28791
*(from redmine: issue id 10627, created on 2019-06-27)*3.10.6https://gitlab.alpinelinux.org/alpine/aports/-/issues/10302Raspberry Pi Zero W wont boot with alpine-rpi-3.9.3-armhf.tar.gz2021-01-28T23:07:57ZAlex BallasRaspberry Pi Zero W wont boot with alpine-rpi-3.9.3-armhf.tar.gzRaspberry Pi Zero W wont boot with alpine-rpi-3.9.3-armhf.tar.gz. It
keeps blinking 7 times, pause and repeat.
alpine-rpi-3.9.2-armhf.tar.gz on the other hand worked just fine.
No issues with the dowloaded file either:
$ sha256sum -c...Raspberry Pi Zero W wont boot with alpine-rpi-3.9.3-armhf.tar.gz. It
keeps blinking 7 times, pause and repeat.
alpine-rpi-3.9.2-armhf.tar.gz on the other hand worked just fine.
No issues with the dowloaded file either:
$ sha256sum -c alpine-rpi-3.9.3-armhf.tar.gz.sha256
alpine-rpi-3.9.3-armhf.tar.gz: OK
*(from redmine: issue id 10302, created on 2019-04-18)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9979Alpine doesn't start on Raspberry PI 3 Model B+2021-01-28T23:07:18ZImanuel UlbrichtAlpine doesn't start on Raspberry PI 3 Model B+I try to run my spare Raspberry PI 3 Model B+ with the most recent
version of Alpine Linux (3.9.0). After I plugged everything in, HDMI,
keyboard, LAN, SD Card and power, I don’t get any reaction. After trying
to select the input on my s...I try to run my spare Raspberry PI 3 Model B+ with the most recent
version of Alpine Linux (3.9.0). After I plugged everything in, HDMI,
keyboard, LAN, SD Card and power, I don’t get any reaction. After trying
to select the input on my screen I get no signal and it searches for
other signals. It seems like no HDMI signal is send, and only the red
power LED is on. The activity LED stays off and it doesn’t matter how
long I keep it connected to the power it doesn’t happen anything.
I get the same behavior if I connect the PI to the offical Raspberry PI
touchscreen.
Installing the OS I followed exactly these instructions:
https://wiki.alpinelinux.org/wiki/Classic\_install\_or\_sys\_mode\_on\_Raspberry\_Pi
*(from redmine: issue id 9979, created on 2019-02-13, closed on 2019-02-18)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10040Broken amdgpu support and kms/fbcon not present2021-01-28T20:08:04ZMarco De StefaniBroken amdgpu support and kms/fbcon not presentHi there! Xorg keep saying that kms is disabled/not supported even if
setted in
<code class="text">
etc/mkinitfs/mkinitfs.conf
</code>
And fbcon is not found in available modules.
Xorg fails to startup without kms. It ...Hi there! Xorg keep saying that kms is disabled/not supported even if
setted in
<code class="text">
etc/mkinitfs/mkinitfs.conf
</code>
And fbcon is not found in available modules.
Xorg fails to startup without kms. It only works with the old
xf86-video-vesa driver.
*(from redmine: issue id 10040, created on 2019-03-04)*