aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2022-03-20T23:14:14Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13616community/fwupd: upgrade fails without bash2022-03-20T23:14:14Zraspbeguycommunity/fwupd: upgrade fails without bashHello,
When I upgraded my alpine linux from 3.15 to 3.15.1, I encountered an error with grub.
The file `/etc/grub.d/35_fwupd` contains the shebang `#! /bin/bash` which produces an error when APK calls `grub-mkconfig` and bash isn't ins...Hello,
When I upgraded my alpine linux from 3.15 to 3.15.1, I encountered an error with grub.
The file `/etc/grub.d/35_fwupd` contains the shebang `#! /bin/bash` which produces an error when APK calls `grub-mkconfig` and bash isn't installed. I had to install bash and then execute `apk fix`.
So it seems there is two solutions:
* Add bash as dependency for grub (not really satisfying IMHO)
* Rewrite this config part so it doesn't need bash (and possibly submit it upstream)https://gitlab.alpinelinux.org/alpine/aports/-/issues/11589Diskless APKOVL loading dosn't work on btrfs and xfs filesystems, or nvme-bas...2022-05-02T09:07:13ZTyler James FrederickDiskless APKOVL loading dosn't work on btrfs and xfs filesystems, or nvme-based devicesHi,
I'm using the stock 3.11.6 ISO in conjunction with an APKOVL for a diskless-boot. The configuration works just fine when I place the APKOVL on an ext4-formatted partition on a SCSI-device. However, when I place the same APKOVL on an...Hi,
I'm using the stock 3.11.6 ISO in conjunction with an APKOVL for a diskless-boot. The configuration works just fine when I place the APKOVL on an ext4-formatted partition on a SCSI-device. However, when I place the same APKOVL on any of the following, it's not loaded:
* A btrfs-formatted partition
* An xfs-formatted partition
* Any partition on an NVMe device (e.g. nvme0n1p1)
* Anywhere other than the root of a partition (e.g. in a subdirectory)
I can see the last item being by design, but as for the others, there's already native btrfs/xfs/nvme support, so I would expect them to be supported out-of-the-box.
Thanks!https://gitlab.alpinelinux.org/alpine/aports/-/issues/10635initramfs-init should wait device shows up then mount2019-08-20T09:18:38Z杨文 陈initramfs-init should wait device shows up then mountBoot alpine from usb in server may run into this problem
https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in\#L487
. Mount failed, because usb is detect async. There is a rootwait kernel
param
\[rootwait\](https://githu...Boot alpine from usb in server may run into this problem
https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in\#L487
. Mount failed, because usb is detect async. There is a rootwait kernel
param
\[rootwait\](https://github.com/torvalds/linux/blob/728254541ebcc7fee869c3c4c3f36f96be791edb/Documentation/admin-guide/kernel-parameters.txt\#L4172)
to control this, alpine should do this too.
*(from redmine: issue id 10635, created on 2019-06-29)*3.10.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10547after install on ssd on reboot sysroot failed2019-07-12T15:48:46Zmartin lolliniafter install on ssd on reboot sysroot failedInstalling alpine in a eeepc netbook and running alpine iso from a
sdcard then execute setup-alpine, last, install \[sys\] to ssd disk to
/dev/sdb.
Reboot and get this sysroot failed. More Details on error.jpg.
The UUID is /dev/sda3 ...Installing alpine in a eeepc netbook and running alpine iso from a
sdcard then execute setup-alpine, last, install \[sys\] to ssd disk to
/dev/sdb.
Reboot and get this sysroot failed. More Details on error.jpg.
The UUID is /dev/sda3 not /dev/sda1 that is the boot partition.
I try changing UUID in extlinux.conf without positive effect.
*(from redmine: issue id 10547, created on 2019-06-09)*
* Uploads:
* ![error](/uploads/e1179e5e98ef129af350017d06eb13bc/error.jpeg)
* ![blkidemergencyconsole](/uploads/0220ab274335e2ca44ec5e50c3abd3a1/blkidemergencyconsole.jpeg) blkid command on emergency console
* ![blkidfromsdcard](/uploads/5949d7c1a7dd2f9281803e7f78b62738/blkidfromsdcard.jpeg) blkid command from console booting from sdcard
* ![kernelpanic](/uploads/d5621daab266883bf2493b6ccb223395/kernelpanic.jpeg) exit command from emergency consoleNatanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10525Unmounting /media/usb fails during shutdown if udev is running2023-06-30T07:30:11ZLubos DolezalUnmounting /media/usb fails during shutdown if udev is runningAttachments show two cases:
*unmounting\_with-udev*: udev (and udev-trigger) was previously started
in the sysinit runlevel.
*unmounting\_without-udev*: udev (and udev-trigger) was stopped before
shutdown.
Installed udev packages:
u...Attachments show two cases:
*unmounting\_with-udev*: udev (and udev-trigger) was previously started
in the sysinit runlevel.
*unmounting\_without-udev*: udev (and udev-trigger) was stopped before
shutdown.
Installed udev packages:
udev-init-scripts-32-r2
udev-init-scripts-openrc-32-r2
eudev-libs-3.2.7-r0
eudev-3.2.7-r0
/proc/mounts: https://pastebin.com/hzvQirkg
*(from redmine: issue id 10525, created on 2019-05-31)*
* Uploads:
* ![unmounting_with-udev](/uploads/b31f0ed8a657e91eba51b03d46bc9339/unmounting_with-udev.png)
* ![unmounting_without-udev](/uploads/64ce364123ae64e23a15f08eab02fe36/unmounting_without-udev.png)3.12.1Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10385kernel option apkovl is not working2023-05-09T14:24:06Zalgitbotkernel option apkovl is not workingCheck **initramfs-init.in** file:
- **unpack\_apkovl** is called before setting **$repofile**
That’s why booting is crashes with filed to install openssl package
*(from redmine: issue id 10385, created on 2019-05-01)*Check **initramfs-init.in** file:
- **unpack\_apkovl** is called before setting **$repofile**
That’s why booting is crashes with filed to install openssl package
*(from redmine: issue id 10385, created on 2019-05-01)*3.19.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10217XFS on GPT boot partition2019-07-23T11:12:10ZAndrew DutyXFS on GPT boot partitionAlpine fails to boot using syslinux when disk is GPT partitioned and
boot partition uses XFS.
These setups work:
MBR + XFS (boot) + XFS (root)
GPT + ext4 (boot) + XFS (root)
This fails (results in “Missing OS” message):
GPT + XFS...Alpine fails to boot using syslinux when disk is GPT partitioned and
boot partition uses XFS.
These setups work:
MBR + XFS (boot) + XFS (root)
GPT + ext4 (boot) + XFS (root)
This fails (results in “Missing OS” message):
GPT + XFS (boot) + XFS (root)
I have tried disabling sparse inodes when creating the XFS boot
partition, as the default behavior for this was recently changed, but
this had no effect.
Environment: VM (SeaBIOS) under KVM. I have tried both the standard and
virt ISOs.
I lack the knowledge to proceed in troubleshooting this and would
appreciate help.
*(from redmine: issue id 10217, created on 2019-04-08, closed on 2019-04-25)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9978Allow initramfs search depth to be user-configurable2021-01-09T18:04:01ZChloe KudryavtsevAllow initramfs search depth to be user-configurableCurrently, the initramfs searches for two items:
- A “bootrepo”, identified by a `.boot_repository` file
- An apkovl file, identified as `*.apkovl.tar.gz*`
This is done within `nlplug-findfs`, which recurses into various
coldplugge...Currently, the initramfs searches for two items:
- A “bootrepo”, identified by a `.boot_repository` file
- An apkovl file, identified as `*.apkovl.tar.gz*`
This is done within `nlplug-findfs`, which recurses into various
coldplugged devices.
The depth of the recursion is controlled by
`struct recurseopts.maxdepth`, which is hardcoded to 1 in
`nlplug-findfs.c::893`.
There is also a `find_boot_repositories` function in
`initramfs-init.in::240`, which uses a hardcoded maxdepth of 3.
However, `find_boot_repositories` seems to be more of a fallback, only
being called after relocation, and using `$ALPINE_REPO` if/when
available.
This is fine for the default images, in which `apks` is in the root of
the filesystem, but makes creating custom boot media much more
difficult.
As such, please make the maxdepth configurable, with the initramfs flag
being shared between `nlplug-findfs` and `find_boot_repositories`.
These are the things that would need to be done, from what I can tell:
1. Add a new initramfs-init command line option, e.g “depth”, which
should default to 1 (current value).
2. Use `$KOPT_depth` in `find_boot_repositories`.
3. Add a new int to `struct ueventconf`, e.g “depth”, which should be
of type int, or unsigned int.
4. Add parsing for ‘d’ in `main()` and document it in `usage()`.
5. Set `.maxdepth` to `conf->depth` in `nlplug-findfs.c::893`.
6. Set various invocations of `trigger_path` to use `conf->depth`
instead of a hardcoded `max_depth` when appropriate.
7. Pass `-d $KOPT_depth` to `nlplug-findfs` when appropriate within
`initramfs-init`.
8. Document the changes in `nlplug-findfs.1.in` and
`mkinitfs-bootparam.7.in`.
*(from redmine: issue id 9978, created on 2019-02-12)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9961Replace libressl with openssl in initramfs2019-07-23T11:14:54ZCarlo LandmeterReplace libressl with openssl in initramfsCurrently we still pull in libressl even though we have switched to
openssl.
- https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in\#n44
- https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in\#n691
*(from redmine: is...Currently we still pull in libressl even though we have switched to
openssl.
- https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in\#n44
- https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in\#n691
*(from redmine: issue id 9961, created on 2019-02-05, closed on 2019-03-01)*
* Changesets:
* Revision 17bb28059bbb00e41c2f32227e54e237551b601d by Natanael Copa on 2019-02-26T17:27:11Z:
```
main/mkinitfs: upgrade to 3.4.1
fixes #9961
(cherry picked from commit b5fca7279cf14ae2c843d9649715f71a98b5626b)
```3.9.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9960Boot delay/issues because of limited entropy2020-02-11T21:03:42ZCarlo LandmeterBoot delay/issues because of limited entropyIn Alpine Linux 3.9, the booting process may be slowed down by entropy
generation.
This is because RDRAND (entropy gathering that requires trusting the
CPU) is disabled by default.
This decision was made due to a lack of consensus as ...In Alpine Linux 3.9, the booting process may be slowed down by entropy
generation.
This is because RDRAND (entropy gathering that requires trusting the
CPU) is disabled by default.
This decision was made due to a lack of consensus as to whether or not
the hardware can be trusted to perform randomness generation (a
security-critical task).
It is possible to re-enable it through the kernel command line as so:
‘random.trust\_cpu=on’.
If you trust the CPU manufacturer, add ‘random.trust\_cpu=on’ to your
kernel command line using the configuration of your boot manager.
If you do not, but still wish to gain a faster boot speed, you may
consider haveged or similar entropy-generating daemons.
We already discussed on IRC how we could work around this issue by
detecting entropy in the installer but this would not cover users who
are upgrading.
Other ways would be to alarm the user at boot when entropy is too low
and services would be slow or fail to start.
*(from redmine: issue id 9960, created on 2019-02-04, closed on 2019-05-09)*
* Changesets:
* Revision e67c2f8bcb163695a5917e059a2c7ba46726ee89 by Natanael Copa on 2019-04-25T12:31:17Z:
```
main/linux-vanilla: upgrade to 4.19.36
also enable CONFIG_RANDOM_TRUST_CPU
https://askubuntu.com/questions/1070433/will-ubuntu-enable-random-trust-cpu-in-the-kernel-and-what-would-be-the-effect/1071196#1071196
ref #9960
```
* Revision 3dab4b1742164b25f19cb39b91f51762c68f76d5 by Natanael Copa on 2019-05-06T12:30:12Z:
```
main/linux-vanilla: upgrade to 4.19.36
also enable CONFIG_RANDOM_TRUST_CPU
https://askubuntu.com/questions/1070433/will-ubuntu-enable-random-trust-cpu-in-the-kernel-and-what-would-be-the-effect/1071196#1071196
fixes #9960
(cherry picked from commit e67c2f8bcb163695a5917e059a2c7ba46726ee89)
```3.9.4Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9945RPi fails to boot if gpu_mem=162020-04-10T20:07:53ZalgitbotRPi fails to boot if gpu_mem=16for a headless server, the gpu is not really needed. But when setting
this to the minimum of 16 MB, the RPI (version 1 Model B) does not
boot.
It will flash the green led 4 times periodically.
When setting this to 32 MB, Alpine boots ...for a headless server, the gpu is not really needed. But when setting
this to the minimum of 16 MB, the RPI (version 1 Model B) does not
boot.
It will flash the green led 4 times periodically.
When setting this to 32 MB, Alpine boots without issues.
4 flashes means loader.bin or start.elf not launched
Are these files in the raspberry image supplied by Alpine Linux? If not,
feel free to close this issue.
*(from redmine: issue id 9945, created on 2019-01-29)*3.8.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9928sysctl scripts not run at boot time2020-03-16T01:55:21ZOliver Dittmersysctl scripts not run at boot timeSysctl doesn’t seem to run kernel parameters at boot time. Either
manually entering “sysctl -p” or running “service sysctl restart” will
load the parameters set in /etc/sysctl.conf or under /etc/sysctl.d/
The readme files and https://wi...Sysctl doesn’t seem to run kernel parameters at boot time. Either
manually entering “sysctl -p” or running “service sysctl restart” will
load the parameters set in /etc/sysctl.conf or under /etc/sysctl.d/
The readme files and https://wiki.alpinelinux.org/wiki/Sysctl.conf seem
to indicate that this is not the expected behavior.
*(from redmine: issue id 9928, created on 2019-01-27)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9777init.d/urandom: increase saved entropy2019-07-23T11:17:15ZSteffen Nurpmesoinit.d/urandom: increase saved entropymy startup (whether on real hardware or my server VM) currently involves
long hangs of sshd, and warnings on uninitialized random reads by
dnsmasq.
When i look into init.d/urandom i see mysterious calculations which
result in 512 bytes...my startup (whether on real hardware or my server VM) currently involves
long hangs of sshd, and warnings on uninitialized random reads by
dnsmasq.
When i look into init.d/urandom i see mysterious calculations which
result in 512 bytes to be saved for restoring purposes, and i wonder why
this is so.
I would assume that the kernel passes data fed in to seed the PRNG
through (possibly even multiple) sophisticated algorithms.., and uses
conservative guessing on the quality of bytes fed into urandom.
Hence my suggestion to increase the number of bytes saved in between
reboots, e.g., like so (untested):
save\_seed()
{
local ibs=1024
if \[ -e /proc/sys/kernel/random/poolsize \]; then
ibs=$(cat /proc/sys/kernel/random/poolsize)
fi
( \# sub shell to prevent umask pollution
umask 077
dd if=/dev/urandom of=“$urandom\_seed” \\
ibs=$ibs count=1 2>/dev/null
)
}
*(from redmine: issue id 9777, created on 2018-12-19, closed on 2019-01-08)*3.9.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9744hostname variable configuration in /etc/conf.d/hostname made moot by /etc/hos...2021-09-09T05:52:43ZGeorgi Sminhostname variable configuration in /etc/conf.d/hostname made moot by /etc/hostname being created by alpine-baselayout at bootExpected behavior of /etc/init.d/hostname script is to check if
/etc/hostname exists, else set hostname to the variable configured in
/etc/conf.d/hostname
However, /etc/hostname will always exist prior to this check since it is
installe...Expected behavior of /etc/init.d/hostname script is to check if
/etc/hostname exists, else set hostname to the variable configured in
/etc/conf.d/hostname
However, /etc/hostname will always exist prior to this check since it is
installed by alpine-baselayout at boot (set to ‘localhost’). The init.d
script will always return True when checking for the file, which results
in the conf.d variable never being used.
Related to: https://bugs.alpinelinux.org/issues/9737
*(from redmine: issue id 9744, created on 2018-12-10)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9737/etc/init.d/hostname openrc script ignores variable set in /etc/conf.d/hostname2019-07-23T11:17:41ZGeorgi Smin/etc/init.d/hostname openrc script ignores variable set in /etc/conf.d/hostnameRelevant lines from /etc/conf.d/hostname:
hostname=“localhost”
Relevant lines from /etc/init.d/hostname:
opts=“localhost”
hostname $opts
If /etc/hostname does not exist hostname is explicitly set to
‘localhost’, ignoring any vari...Relevant lines from /etc/conf.d/hostname:
hostname=“localhost”
Relevant lines from /etc/init.d/hostname:
opts=“localhost”
hostname $opts
If /etc/hostname does not exist hostname is explicitly set to
‘localhost’, ignoring any variable set in /etc/conf.d/hostname
This can be fixed by changing line 13 to: opts=$hostname
*(from redmine: issue id 9737, created on 2018-12-06, closed on 2019-05-04)*
* Changesets:
* Revision b6b6dcd2e868031216140f6f75906eed1e9cbd40 by Natanael Copa on 2018-12-07T14:44:18Z:
```
main/openrc: fix hostname script
we should not override hostname set in /etc/conf.d/hostname
ref #9737
```
* Revision f6e6c2dd9fe9ff2c597c3cf5164e6238b8f29c71 by Natanael Copa on 2018-12-07T14:47:07Z:
```
main/openrc: fix hostname script
we should not override hostname set in /etc/conf.d/hostname
fixes #9737
(cherry picked from commit b6b6dcd2e868031216140f6f75906eed1e9cbd40)
```Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9619Support for xenpci in initramfs so we can build XEN storage driver domains wi...2019-07-23T11:18:54ZHenrik RiomarSupport for xenpci in initramfs so we can build XEN storage driver domains with alpineAdd a new feature to mkinitfs allowing xen-pcifront.ko to be part of
initramfs
PR: https://github.com/alpinelinux/mkinitfs/pull/45
*(from redmine: issue id 9619, created on 2018-11-02, closed on 2019-01-23)*Add a new feature to mkinitfs allowing xen-pcifront.ko to be part of
initramfs
PR: https://github.com/alpinelinux/mkinitfs/pull/45
*(from redmine: issue id 9619, created on 2018-11-02, closed on 2019-01-23)*3.9.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9588USB keyboard is not working when booting in singlmode2022-11-08T11:28:45ZalgitbotUSB keyboard is not working when booting in singlmodeAccording to the initramfs-init, singlemode shell launched before
coldplug of devices via nlplug-findfs.
So, USB keyboard is not working ins singlemode.
*(from redmine: issue id 9588, created on 2018-10-25)*According to the initramfs-init, singlemode shell launched before
coldplug of devices via nlplug-findfs.
So, USB keyboard is not working ins singlemode.
*(from redmine: issue id 9588, created on 2018-10-25)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9539Can't mount BTRFS volume using fstab2024-03-27T19:28:59ZLouis MatthijssenCan't mount BTRFS volume using fstabI installed Alpine on <code>/dev/sda</code> in <code>sys</code> mode
using <code>ext4</code>. Then I created a <code>btrfs</code> volume on
<code>/dev/sdb</code> and <code>/dev/sdc</code> using:
apk add btrfs-progs
modprobe btrf...I installed Alpine on <code>/dev/sda</code> in <code>sys</code> mode
using <code>ext4</code>. Then I created a <code>btrfs</code> volume on
<code>/dev/sdb</code> and <code>/dev/sdc</code> using:
apk add btrfs-progs
modprobe btrfs && echo btrfs > /etc/modules
mkfs.btrfs -m raid1 -d raid1 /dev/sdb /dev/sdc
mkdir /data && mount /dev/sdb /data
This is working fine. Now I add this mount to <code>/etc/fstab</code>
like this:
UUID=da110dca-aed5-48b8-a5b6-c1b41c10c419 /data btrfs defaults 0 0
On reboot I get the following error:
mount: mounting /dev/sdc on /data failed: Invalid argument
Output of <code>dmesg</code>:
[ 5.950849] BTRFS: device fsid da110dca-aed5-48b8-a5b6-c1b41c10c419 devid 2 transid 12 /dev/sdc
[ 5.952786] BTRFS info (device sdc): disk space caching is enabled
[ 5.952791] BTRFS info (device sdc): has skinny extents
[ 5.954055] BTRFS warning (device sdc): devid 1 uuid 6a45e7d4-78df-4263-be09-b83a3a15e6e0 is missing
[ 5.954063] BTRFS error (device sdc): failed to read the system array: -5
[ 6.002364] BTRFS error (device sdc): open_ctree failed
I fixed this by adding <code>/sbin/btrfs device scan</code> to the top
of the <code>start</code> method in <code>/etc/init.d/localmount</code>.
However, I have a feeling that this command is already ran on boot but
only *after* mounting <code>/etc/fstab</code>, because when I simply run
<code>mount /dev/sdb /data</code> right after booting it’s working.
It seems that this command is being called if the root file system is
<code>btrfs</code> (see \#6903); I think this should also be done if
there is any other <code>btrfs</code> file system in
<code>/etc/fstab</code>.
*(from redmine: issue id 9539, created on 2018-10-08)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9471Impossible to enable ipv6 at boot time through sysctl file in alpine container2019-07-23T11:20:48ZNicolas BonnandImpossible to enable ipv6 at boot time through sysctl file in alpine containerDear support,
I can’t manage to enable ipv6 at boot time.
I am using release 3.8.1
1. ip addr
1: lo: &lt;LOOPBACK,UP,LOWER\_UP>mtu 65536 qdisc noqueue state
UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00...Dear support,
I can’t manage to enable ipv6 at boot time.
I am using release 3.8.1
1. ip addr
1: lo: <LOOPBACK,UP,LOWER\_UP>mtu 65536 qdisc noqueue state
UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid\_lft forever preferred\_lft forever
148: eth0@if149: <BROADCAST,MULTICAST,UP,LOWER\_UP,M-DOWN>mtu
1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid\_lft forever preferred\_lft forever
If I try to add an ipv6 address, it doesn’t work
bash-4.4\# ip addr add fdf3::100/64 dev eth0
ip: RTNETLINK answers: Permission denied
For you information, docker container was launched with these parameters
docker container run —privileged -it -d -h DOCK10 —name DOCK10
b80cd820830e /bin/bash
This dockerfile was used to generate docker image
FROM docker.io/alpine
RUN apk update
RUN apk add bash
RUN apk add iperf
RUN echo “net.ipv6.conf.all.disable\_ipv6 = 0” >
/etc/sysctl.d/00-00-ipv6\_enable.conf
RUN echo “net.ipv6.conf.default.disable\_ipv6 = 0” >>
/etc/sysctl.d/00-00-ipv6\_enable.conf
CMD \[“/bin/sh”\]
Inside container, I can see that sysctl file has been correctly created
bash\# docker container attach DOCK10
bash-4.4\# ls -la /etc/sysctl.d/00-00-ipv6\_enable.conf
-rw-r—r— 1 root root 74 Sep 25 10:15
/etc/sysctl.d/00-00-ipv6\_enable.conf
This file content is correct
bash-4.4\# cat /etc/sysctl.d/00-00-ipv6\_enable.conf
net.ipv6.conf.all.disable\_ipv6 = 0
net.ipv6.conf.default.disable\_ipv6 = 0
/etc/modules is correct
bash-4.4\# cat /etc/modules
af\_packet
ipv6
We can see that /etc/sysctl.d/\* was not read at boot because old values
are still here
bash-4.4\# sysctl -a | grep disable\_ipv6
net.ipv6.conf.all.disable\_ipv6 = 1
sysctl: error reading key ‘net.ipv6.conf.all.stable\_secret’: I/O
error
net.ipv6.conf.default.disable\_ipv6 = 1
sysctl: error reading key ‘net.ipv6.conf.default.stable\_secret’: I/O
error
net.ipv6.conf.eth0.disable\_ipv6 = 1
sysctl: error reading key ‘net.ipv6.conf.eth0.stable\_secret’: I/O
error
net.ipv6.conf.lo.disable\_ipv6 = 1
sysctl: error reading key ‘net.ipv6.conf.lo.stable\_secret’: I/O error
If I force reading of /etc/sysctl.d/00-00-ipv6\_enable.conf, ipv6 will
be enabled and everything will work
bash-4.4\# sysctl -p /etc/sysctl.d/00-00-ipv6\_enable.conf
net.ipv6.conf.all.disable\_ipv6 = 0
net.ipv6.conf.default.disable\_ipv6 = 0
I can now add ipv6 address and there’s no error this time !
bash-4.4\# ip addr add fdf3::100/64 dev eth0
bash-4.4\# ip –6 addr show dev eth0
148: eth0@if149: <BROADCAST,MULTICAST,UP,LOWER\_UP,M-DOWN>mtu
1500 state UP
inet6 fdf3::100/64 scope global
valid\_lft forever preferred\_lft forever
inet6 fe80::42:acff:fe11:2/64 scope link
valid\_lft forever preferred\_lft forever
Do you confirm that /etc/sysctl.d/\* is not read at boot time in alpine
container ?
If so, what is the correct way to enable ipv6 ?
Regards
Nicolas
*(from redmine: issue id 9471, created on 2018-09-25, closed on 2018-09-25)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9230Alpine 3.7 is not working on Raspberry Pi 3B+2019-07-23T11:23:51ZYaron ShahrabaniAlpine 3.7 is not working on Raspberry Pi 3B+I recently switched to the newer version of Raspberry Pi from 3B to
3B<span class="underline">, the OS and appliance was working pretty well
on the 3B but when I switched to 3B</span> I got a blank screen and the
red LED doesn’t turn on ...I recently switched to the newer version of Raspberry Pi from 3B to
3B<span class="underline">, the OS and appliance was working pretty well
on the 3B but when I switched to 3B</span> I got a blank screen and the
red LED doesn’t turn on at all, the green LED flashes first quickly,
then a little slower and eventually very slow.
I tried looking at the logs but nothing has changed since the kernel
wasn’t loading.
Not sure this version is even intended to work on this model.
*(from redmine: issue id 9230, created on 2018-08-12, closed on 2019-05-04)*Natanael CopaNatanael Copa