Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by gbr-app-1.alpinelinux.org (Postfix) with ESMTPS id 83FB42240D8 for <~alpine/users@lists.alpinelinux.org>; Sun, 9 Feb 2025 09:20:53 +0000 (UTC) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-43938828d02so1012905e9.1 for <~alpine/users@lists.alpinelinux.org>; Sun, 09 Feb 2025 01:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739092850; x=1739697650; darn=lists.alpinelinux.org; h=content-transfer-encoding:mime-version:references:in-reply-to :organization:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=s3tnf0Qa4D8prEOEifo01n+dRN0qqs6dXevkljU9FVs=; b=kp2fMYTb6ZtKrNR7UM5fYi7K9ytoO1PCysy+pCVVa+g800a2Aa8GODpLTHpD0BYxkD y+4khh53Lb/yzuSoGpomHxy0azTmvYC3AW0CQevYtO11GP+M0JDt9o4Ma0p9PeXNzlhU fgQxie5LoYE9b0gNRm5Xr4dIB6dl1Tnz7x71Sa45PzPBsFTq23AbGMPr4cHy72LtH+tE BLGdi1331Igk9k8/S64rmnPo3JOsDqlfCaxiKP7dYU9vxXFoLwIdJlO7DLPz0UF7vpHs DyvJ4+jIiAKvVlR7U12YPB0fvupTXS5a2AApdJqJO1TEJMmoUbU8KytmPDlBkd65tvyD ewEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739092850; x=1739697650; h=content-transfer-encoding:mime-version:references:in-reply-to :organization:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=s3tnf0Qa4D8prEOEifo01n+dRN0qqs6dXevkljU9FVs=; b=CmSaMcNRRiyTMpEq5BTTcGWQrX6OFvNZU+3i3jRYmwb62MhR5lQvpD0zvonj7VpHHC lcl4Fmz7xkdjlCl4HfS/TEv7h7POg6LeMOHxFpnZp+3WUJmCAwCzzO3JshQQpW32bbZM 1RXw6sm9swbGxznoY5J+elvioL7cLYzEoTb7GprGikRPNHsnN9c3aQq6JLYWLQibIVZ3 p+gnRKXHxgjVxKWqa1Yg+t0dcQrbchWDZcqh7jgvv5KBRPx+/Qi7LXlmC7nP6Jt/pFga BHbZpVyLJWbXLMNuVDrO3nOG9gzONJQiyOPj+jbn0NbtdxKGv17jnWY+6BwYymwto7Fy fWuQ== X-Gm-Message-State: AOJu0Ywb6I4ptJppAAzJrEH1/+x7b6X3BhGYkicqTBHAuyWvONYwA22v X+/KzJn2oDo9om4uA1nODSCcmANCdKZrTBbVwtUJMKkTsxbcmpv3L7/aDw== X-Gm-Gg: ASbGncvotOv1IK2L4oSMXS0T9Thq5NDamQgkpv16eZ5mZuicfQCIYQTdLCEmdiWjXBZ au4LDb2g8O+2bM75ePLsOmXz+mBiHSwPRHUYsNqEl/OU6XYbIISH0IFSHSuiq1i19fwDZlO7rW9 gfsPFf2Y1rCg5C79juQDTQlnKbKSAHD7/I/pDcDLi9MJ6cGP+BTcfr064N/khjURXpU1Ltv0NKd 8+qK1phC7Sq/gTMAGXYbIPv8NunE6Q8VrIIMdctax+dAQ5n5LvP5QZG3645OjEQZX+ync1P9jW4 xACai6aWCAPk3/wx+iEs3CnnmY1GpylX X-Google-Smtp-Source: AGHT+IHsPzwMUsJTc0P87JJWYVpZ8vwQAEfegRaZ2nNvcKwI1ENR6eT1JmfLI0jMz19f8s/l+V4eXw== X-Received: by 2002:a05:600c:4691:b0:436:fb10:d583 with SMTP id 5b1f17b1804b1-4392497ea09mr31609435e9.2.1739092850090; Sun, 09 Feb 2025 01:20:50 -0800 (PST) Received: from cloud.fritzweb.at (cloud.fritzweb.at. [37.252.189.50]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43936bcc04fsm34830475e9.20.2025.02.09.01.20.49 for <~alpine/users@lists.alpinelinux.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Feb 2025 01:20:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cloud.fritzweb.at (Postfix) with ESMTP id AB6C58008B6; Sun, 9 Feb 2025 10:20:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cloud.fritzweb.at Received: from cloud.fritzweb.at ([IPv6:::1]) by localhost (cloud.fritzweb.at [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Zu9Lez5InxVV; Sun, 9 Feb 2025 10:20:45 +0100 (CET) Received: from ntb-norbert.localnet (unknown [62.93.118.77]) by cloud.fritzweb.at (Postfix) with ESMTPSA id 0B650800BB0; Sun, 9 Feb 2025 10:20:45 +0100 (CET) From: MBB To: Prabu Anand Kalivaradhan Cc: "~alpine/users@lists.alpinelinux.org" <~alpine/users@lists.alpinelinux.org> Subject: Re: Diskless systems do not boot with latest apk versions from cache Date: Sun, 09 Feb 2025 10:20:44 +0100 Message-ID: <4971180.GXAFRqVoOG@ntb-norbert> Organization: Private In-Reply-To: References: <9410103.CDJkKcVGEf@ntb-norbert> <23824424.6Emhk5qWAg@ntb-norbert> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart1925493.tdWV9SEqCh" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1925493.tdWV9SEqCh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Am Samstag, 8. Februar 2025, 10:01:44 Mitteleurop=C3=A4ische Normalzeit sch= rieb Prabu Anand Kalivaradhan: > Hi MBB, >=20 > Please confirm if the steps given in the page > https://wiki.alpinelinux.org/wiki/Diskless_Mode#Upgrading_a_Diskless_Syst= em > is complete. >=20 > If something is missing, please highlight here or in the wiki. Most of > the content on the above page has been consolidated from other parts > of wiki. Since i don't use diskless i'm not 100% sure about the > correctness of the content. >=20 > I am still hesitating to touch those wiki pages related to Raspberry. > Anyone willing to offering to help test content changes, please reply > me here in the list or personally. >=20 > Regards, > Prabu >=20 These steps are basically what I did to update the kernel. To my understanding, the update is not memory heavy. It succeeded on a RPi2= with 1GB RAM.=20 But there must be enough space in /tmp for the update. Since SBCs don't have much RAM for a large enough tmpfs, the update fails, = but it didn't result in a broken modloop-image in my case. To work around, I used the environment variable TMPDIR to point to a direct= ory on a physical device, like a SD-Card or USB-Stick. TMPDIR=3D/media/sdc1/tmp update-kernel /media/mmcblk0p1/boot/ This must be a *nix file system, FAT won't work. > On Sat, 8 Feb 2025 at 13:56, MBB wrote: > > > > Am Montag, 3. Februar 2025, 16:07:18 Mitteleurop=C3=A4ische Normalzeit = schrieb Kevin Garman: > > > > > I have long been struggling with similar issues on my diskless instal= ls. I run.. > > > > > > > > > > apk cache -v sync > > > > > > > > > > ...and sometimes it breaks my system(s) and sometimes it doesn't. I'= ve read where cache sync should be used with care, but I believe I'm using = it as intended. It seems like it should be straight forward as all it's su= ppose to do (as I understand it) is make the cache match what the system ne= eds during boot. It seems like running cache sync should be the solution t= o problem it's causing! > > > > > > > > > > I've been working to figure out a simple/repeatable set of steps to r= eproduce the problem, but so far I haven't been able to get there. > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > From: ~alpine/users <~alpine/users@lists.alpinelinux.org> on behalf o= f MBB > > > > > Sent: Sunday, February 2, 2025 09:16 > > > > > To: ~alpine/users@lists.alpinelinux.org <~alpine/users@lists.alpineli= nux.org>; Sertonix > > > > > Subject: Re: Diskless systems do not boot with latest apk versions fr= om cache > > > > > > > > > > > > > > > Am Sonntag, 2. Februar 2025, 09:11:22 Mitteleurop=C3=A4ische Normalze= it schrieb MBB: > > > > > > Am Samstag, 1. Februar 2025, 14:39:34 Mitteleurop=C3=A4ische Normal= zeit schrieb MBB: > > > > > > > Am Samstag, 1. Februar 2025, 13:12:29 Mitteleurop=C3=A4ische Norm= alzeit schrieb Sertonix: > > > > > > > > On Sat Feb 1, 2025 at 9:24 AM CET, MBB wrote: > > > > > > > > > Hi all! > > > > > > > > > > > > > > > > > > I have 3 Raspberry Pis, different PI versions and different A= lpine versions (3.18.9, 3.19.1, 3.19.4). > > > > > > > > > > > > > > > > > > All have the same issue. > > > > > > > > > > > > > > > > > > I'm doing: > > > > > > > > > apk update; apk upgrade > > > > > > > > > > > > > > > > > > Checking the version of an upgraded binary before reboot, e.g= =2E named, looks ok. > > > > > > > > > > > > > > > > > > After reboot, it loads an old version even though a newer pac= kage is available in cache. > > > > > > > > > > > > > > > > > > gate [/etc/apk]$ ls -al cache > > > > > > > > > lrwxrwxrwx 1 root root 22 Feb 1 08:50 cach= e -> /media/mmcblk0p1/cache > > > > > > > > > > > > > > > > > > gate [/etc/apk/cache]$ ls -altr bind-9* > > > > > > > > > -rwxr-xr-x 1 root root 207297 Mar 15 2024 bind= =2D9.18.24-r1.5aca84cc.apk > > > > > > > > > -rwxr-xr-x 1 root root 208996 Dec 17 16:37 bind= =2D9.18.32-r0.1254446d.apk > > > > > > > > > -rwxr-xr-x 1 root root 209078 Jan 29 19:44 bind= =2D9.18.33-r0.b6697cb2.apk > > > > > > > > > > > > > > > > > > gate [/etc/apk/cache]$ named -V > > > > > > > > > BIND 9.18.32 (Extended Support Version) > > > > > > > > > running on Linux armv7l 6.6.14-0-rpi #1-Alpine SMP Fri Jan 26= 13:40:47 UTC 2024 > > > > > > > > > > > > > > > > > > Is there something I'm doing wrong? > > > > > > > > > > > > > > > > It looks correct what you are doing. Could you try if running t= his > > > > > > > > commands returns any error? > > > > > > > > > > > > > > > > $ apk --simulate add bind=3D9.18.33-r0 --no-network > > > > > > > > > > > > > > No errors with this command. > > > > > > > > > > > > > > *gate [*~*]$ *doas apk --simulate add bind=3D9.18.33-r0 --no-netw= ork > > > > > > > doas (norbert@gate) password: > > > > > > > (1/5) Upgrading bind-libs (9.18.32-r0 -> 9.18.33-r0) > > > > > > > (2/5) Upgrading bind-tools (9.18.32-r0 -> 9.18.33-r0) > > > > > > > (3/5) Upgrading bind-dnssec-root (9.18.32-r0 -> 9.18.33-r0) > > > > > > > (4/5) Upgrading bind (9.18.32-r0 -> 9.18.33-r0) > > > > > > > (5/5) Upgrading bind-openrc (9.18.32-r0 -> 9.18.33-r0) > > > > > > > OK: 157 MiB in 215 packages > > > > > > > > > > > > I removed all outdated bind packages from the cache with the result= , that bind is no longer available after reboot. > > > > > > After moving the bind*9.18.32-r0*.apk files back into the cache dir= ectory, the service gets restored and starts up without issues after reboot. > > > > > > > > > > > > It seems that something's pointing to a specific version. > > > > > > > > > > > > > > > > `apk cache sync` breaks the entire system. > > > > > > > > > > This cleans the cache from outdated APKINDEX* and *.apk files. > > > > > But after reboot nothing is loaded and the boot process ends with a `= (none) local:` prompt. > > > > > > > > > > Restoring the old cache directory, brings the system to life again. > > > > > > > > > > Same issue when I manually delete only the APKINDEX* files, and updat= e the local DB with `apk update` to download fresh APKINDEX. > > > > > > > > > > Restoring the old APKINDEX* files from a backup fixes this. > > > > > > > > > > > I fixed it for all 3 of my systems. > > > > Key is to update the /media/mmcblk0p1/boot/initramfs-rpi > > > > > > I created a new one following this guide: https://wiki.alpinelinux.org/= wiki/Initramfs_init > > > > I activated these features to get an initramfs which matches the origin= al > > > > > > features=3D"base dhcp keymap kms mmc squashfs usb" > > > > > > > > When I compared the old an new initramfs, only these binaries showed di= fferences: > > > > > > Files initramfs/bin/busybox and mkinitfs/bin/busybox differ > > Files initramfs/lib/libapk.so.2.14.0 and mkinitfs/lib/libapk.so.2.14.0 = differ > > Files initramfs/lib/libcrypto.so.3 and mkinitfs/lib/libcrypto.so.3 diff= er > > Files initramfs/lib/libssl.so.3 and mkinitfs/lib/libssl.so.3 differ > > Files initramfs/sbin/apk and mkinitfs/sbin/apk differ > > > > > > > > Because creating a new initramfs is part of the update-kernel script, u= pdating the kernel fixes the issue as well. > > > > https://wiki.alpinelinux.org/wiki/Diskless_Mode#Upgrading_a_Diskless_Sy= stem > > > > > > > > > > > > > > > > > > > BR > > > > > > > > > Norbert > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 --nextPart1925493.tdWV9SEqCh Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Am Samstag, 8. Februar 2025, 10:01:44 Mitteleurop=C3=A4ische Normalzeit = schrieb Prabu Anand Kalivaradhan:

>= ; Hi MBB,

>= ;

>= ; Please confirm if the steps given in the page

>= ; https://wiki.alpinelinux.org/wiki/Diskless_Mode#Upgrading_a_Diskless_Syst= em

>= ; is complete.

>= ;

>= ; If something is missing, please highlight here or in the wiki. Most of

>= ; the content on the above page has been consolidated from other parts

>= ; of wiki. Since i don't use diskless i'm not 100% sure about the

>= ; correctness of the content.

>= ;

>= ; I am still hesitating to touch those wiki pages related to Raspberry.

>= ; Anyone willing to offering to help test content changes, please reply

>= ; me here in the list or personally.

>= ;

>= ; Regards,

>= ; Prabu

>= ;

The= se steps are basically what I did to update the kernel.


To my understanding, the update is not memory heavy. It succeeded on a R= Pi2 with 1GB RAM.

But= there must be enough space in /tmp for the update.

Sin= ce SBCs don't have much RAM for a large enough tmpfs, the update fails, but= it didn't result in a broken modloop-image in my case.

To = work around, I used the environment variable TMPDIR to point to a directory= on a physical device, like a SD-Card or USB-Stick.

 

TMPDIR=3D/media/sdc1/tmp update-kernel /m= edia/mmcblk0p1/boot/

Thi= s must be a *nix file system, FAT won't work.


> On Sat, 8 Feb 2025 at 13:56, MBB <mbbert@gmail.com> wrote:

>= ; >

>= ; > Am Montag, 3. Februar 2025, 16:07:18 Mitteleurop=C3=A4ische Normalze= it schrieb Kevin Garman:

>= ; >

>= ; > > I have long been struggling with similar issues on my diskless = installs.  I run..

>= ; >

>= ; > >

>= ; >

>= ; > >  apk cache -v sync

>= ; >

>= ; > >

>= ; >

>= ; > > ...and sometimes it breaks my system(s) and sometimes it doesn'= t.  I've read where cache sync should be used with care, but I believe= I'm using it as intended.  It seems like it should be straight forwar= d as all it's suppose to do (as I understand it) is make the cache match wh= at the system needs during boot.  It seems like running cache sync sho= uld be the solution to problem it's causing!

>= ; >

>= ; > >

>= ; >

>= ; > > I've been working to figure out a simple/repeatable set of step= s to reproduce the problem, but so far I haven't been able to get there.

>= ; >

>= ; > >

>= ; >

>= ; > >

>= ; >

>= ; > >

>= ; >

>= ; > >

>= ; >

>= ; > > ________________________________

>= ; >

>= ; > > From: ~alpine/users <~alpine/users@lists.alpinelinux.org>= on behalf of MBB <mbbert@gmail.com>

>= ; >

>= ; > > Sent: Sunday, February 2, 2025 09:16

>= ; >

>= ; > > To: ~alpine/users@lists.alpinelinux.org <~alpine/users@lists= =2Ealpinelinux.org>; Sertonix <sertonix@posteo.net>

>= ; >

>= ; > > Subject: Re: Diskless systems do not boot with latest apk versi= ons from cache

>= ; >

>= ; > >

>= ; >

>= ; > >

>= ; >

>= ; > > Am Sonntag, 2. Februar 2025, 09:11:22 Mitteleurop=C3=A4ische No= rmalzeit schrieb MBB:

>= ; >

>= ; > > > Am Samstag, 1. Februar 2025, 14:39:34 Mitteleurop=C3=A4isc= he Normalzeit schrieb MBB:

>= ; >

>= ; > > > > Am Samstag, 1. Februar 2025, 13:12:29 Mitteleurop=C3= =A4ische Normalzeit schrieb Sertonix:

>= ; >

>= ; > > > > > On Sat Feb 1, 2025 at 9:24 AM CET, MBB wrote:

>= ; >

>= ; > > > > > > Hi all!

>= ; >

>= ; > > > > > >

>= ; >

>= ; > > > > > > I have 3 Raspberry Pis, different PI versio= ns and different Alpine versions (3.18.9, 3.19.1, 3.19.4).

>= ; >

>= ; > > > > > >

>= ; >

>= ; > > > > > > All have the same issue.

>= ; >

>= ; > > > > > >

>= ; >

>= ; > > > > > > I'm doing:

>= ; >

>= ; > > > > > > apk update; apk upgrade

>= ; >

>= ; > > > > > >

>= ; >

>= ; > > > > > > Checking the version of an upgraded binary = before reboot, e.g. named, looks ok.

>= ; >

>= ; > > > > > >

>= ; >

>= ; > > > > > > After reboot, it loads an old version even = though a newer package is available in cache.

>= ; >

>= ; > > > > > >

>= ; >

>= ; > > > > > > gate [/etc/apk]$ ls -al cache

>= ; >

>= ; > > > > > > lrwxrwxrwx    1 root &n= bsp;   root         =    22 Feb  1 08:50 cache -> /media/mmcblk0p1/cache

>= ; >

>= ; > > > > > >

>= ; >

>= ; > > > > > > gate [/etc/apk/cache]$ ls -altr bind-9*

>= ; >

>= ; > > > > > > -rwxr-xr-x    1 root &n= bsp;   root        207297 Mar = 15  2024 bind-9.18.24-r1.5aca84cc.apk

>= ; >

>= ; > > > > > > -rwxr-xr-x    1 root &n= bsp;   root        208996 Dec = 17 16:37 bind-9.18.32-r0.1254446d.apk

>= ; >

>= ; > > > > > > -rwxr-xr-x    1 root &n= bsp;   root        209078 Jan = 29 19:44 bind-9.18.33-r0.b6697cb2.apk

>= ; >

>= ; > > > > > >

>= ; >

>= ; > > > > > > gate [/etc/apk/cache]$ named -V

>= ; >

>= ; > > > > > > BIND 9.18.32 (Extended Support Version) <= ;id:d1f1392>

>= ; >

>= ; > > > > > > running on Linux armv7l 6.6.14-0-rpi #1-Alp= ine SMP Fri Jan 26 13:40:47 UTC 2024

>= ; >

>= ; > > > > > >

>= ; >

>= ; > > > > > > Is there something I'm doing wrong?

>= ; >

>= ; > > > > >

>= ; >

>= ; > > > > > It looks correct what you are doing. Could you t= ry if running this

>= ; >

>= ; > > > > > commands returns any error?

>= ; >

>= ; > > > > >

>= ; >

>= ; > > > > > $ apk --simulate add bind=3D9.18.33-r0 --no-netw= ork

>= ; >

>= ; > > > >

>= ; >

>= ; > > > > No errors with this command.

>= ; >

>= ; > > > >

>= ; >

>= ; > > > > *gate [*~*]$ *doas apk --simulate add bind=3D9.18.33-= r0 --no-network

>= ; >

>= ; > > > > doas (norbert@gate) password:

>= ; >

>= ; > > > > (1/5) Upgrading bind-libs (9.18.32-r0 -> 9.18.33-r= 0)

>= ; >

>= ; > > > > (2/5) Upgrading bind-tools (9.18.32-r0 -> 9.18.33-= r0)

>= ; >

>= ; > > > > (3/5) Upgrading bind-dnssec-root (9.18.32-r0 -> 9.= 18.33-r0)

>= ; >

>= ; > > > > (4/5) Upgrading bind (9.18.32-r0 -> 9.18.33-r0)

>= ; >

>= ; > > > > (5/5) Upgrading bind-openrc (9.18.32-r0 -> 9.18.33= =2Dr0)

>= ; >

>= ; > > > > OK: 157 MiB in 215 packages

>= ; >

>= ; > > >

>= ; >

>= ; > > > I removed all outdated bind packages from the cache with t= he result, that bind is no longer available after reboot.

>= ; >

>= ; > > > After moving the bind*9.18.32-r0*.apk files back into the = cache directory, the service gets restored and starts up without issues aft= er reboot.

>= ; >

>= ; > > >

>= ; >

>= ; > > > It seems that something's pointing to a specific version.<= /p>

>= ; >

>= ; > > >

>= ; >

>= ; > >

>= ; >

>= ; > > `apk cache sync` breaks the entire system.

>= ; >

>= ; > >

>= ; >

>= ; > > This cleans the cache from outdated APKINDEX* and *.apk files.<= /p>

>= ; >

>= ; > > But after reboot nothing is loaded and the boot process ends wi= th a `(none) local:` prompt.

>= ; >

>= ; > >

>= ; >

>= ; > > Restoring the old cache directory, brings the system to life ag= ain.

>= ; >

>= ; > >

>= ; >

>= ; > > Same issue when I manually delete only the APKINDEX* files, and= update the local DB with `apk update` to download fresh APKINDEX.

>= ; >

>= ; > >

>= ; >

>= ; > > Restoring the old APKINDEX* files from a backup fixes this.

>= ; >

>= ; > >

>= ; >

>= ; >

>= ; > I fixed it for all 3 of my systems.

>= ; >

>= ; > Key is to update the /media/mmcblk0p1/boot/initramfs-rpi

>= ; >

>= ; >

>= ; > I created a new one following this guide: https://wiki.alpinelinux.o= rg/wiki/Initramfs_init

>= ; >

>= ; > I activated these features to get an initramfs which matches the ori= ginal

>= ; >

>= ; >

>= ; > features=3D"base dhcp keymap kms mmc squashfs usb"

>= ; >

>= ; >

>= ; >

>= ; > When I compared the old an new initramfs, only these binaries showed= differences:

>= ; >

>= ; >

>= ; > Files initramfs/bin/busybox and mkinitfs/bin/busybox differ

>= ; > Files initramfs/lib/libapk.so.2.14.0 and mkinitfs/lib/libapk.so.2.14= =2E0 differ

>= ; > Files initramfs/lib/libcrypto.so.3 and mkinitfs/lib/libcrypto.so.3 d= iffer

>= ; > Files initramfs/lib/libssl.so.3 and mkinitfs/lib/libssl.so.3 differ<= /p>

>= ; > Files initramfs/sbin/apk and mkinitfs/sbin/apk differ

>= ; >

>= ; >

>= ; >

>= ; > Because creating a new initramfs is part of the update-kernel script= , updating the kernel fixes the issue as well.

>= ; >

>= ; > https://wiki.alpinelinux.org/wiki/Diskless_Mode#Upgrading_a_Diskless= _System

>= ; >

>= ; >

>= ; > > > > >

>= ; >

>= ; > > > > > > BR

>= ; >

>= ; > > > > > > Norbert

>= ; >

>= ; > > > > >

>= ; >

>= ; > > > > >

>= ; >

>= ; > > > >

>= ; >

>= ; > > > >

>= ; >

>= ; > > >

>= ; >

>= ; > >

>= ; >

>= ; > >

>= ; >

>= ; > >

>= ; >

>= ; > >

>= ; >

>= ; >

>= ;


--nextPart1925493.tdWV9SEqCh--