setup-alpine: race condition when initramfs configures network
- The test at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-alpine.in#L62 does not detect a network configured via initramfs (e.g. explicit or implicit
ip=dhcp
passed to initramfs), which means that when using a remote answerfile that the network gets reconfigured. - When using udhcpc (the initramfs default), bringing down the network and setup up a new one does not block so, depending on the timing things like
tzdata
download (forsetup-ntp
) can get interrupted and fail (but not fatally; if one is not watching the output one would not be immediately aware of the issue). - It seems to me improving test for in an existing network in
setup-interfaces
at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-interfaces.in#L56 and moving tolib-alpine.sh
might be the way to go. - In my testing I created what I consider a 'hackier' solution (it works, but I think it's 'messy') which is to create a sentinel file
/var/cache/misc/earlynet
with eitherudhcpc
ormanual
(depending on how the the network was configured) ininitramfs-init
'sconfig_ip
function and copying to the new$sysroot
in the same location just beforepivot_root
. I then used the function below to check for the presence of a network atsetup-alpine
in place of the current line 62 check:
is_network_up() {
if [ -s /var/cache/misc/earlynet ]; then
case $(cat /var/cache/misc/earlynet) in
udhcpc|manual)
return 0;;
esac
elif rc-status networking --quiet status; then
return 0
fi
return 1
}
- This eliminated the network race condition for me, but I'd like to know, for creating an MR, which solution you would prefer.
This was discovered will working on danielfdickinson/aports!1
Also related:
and
Also, where is the best place to handle such cross-repository issues / MR sets?