On Wed, 22 Mar 2023 09:45:37 +0100 Daniel Baumann
wrote:
> On 3/22/23 06:18, Cyrus Lien wrote:
> > This bug still needs a boot script mounting efivarfs in initrd for
> > systems whose rootfs are on RAID volume.
>
> as the bug sais: this has been fixed in mdadm 4.2+20230223-1.
How could mounting
On 3/22/23 06:18, Cyrus Lien wrote:
> This bug still needs a boot script mounting efivarfs in initrd for
> systems whose rootfs are on RAID volume.
as the bug sais: this has been fixed in mdadm 4.2+20230223-1.
Regards,
Daniel
Dear maintainer,
This bug still needs a boot script mounting efivarfs in initrd for systems
whose rootfs are on RAID volume.
Either as Jörn Heissler's suggestion to put boot script in /init-premount,
or in /init-top, something like this
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_
Same problem here, efivarfs isn't mounted. Also, mdadm must be called
before running cryptsetup, at least on my system (crypted rootfs on
raid).
Solution: Create /target/etc/initramfs-tools/scripts/init-premount/fakeraid
(chmod +x),
then rebuild the initrd: in-target update-initramfs -u -k all
#
So the same issue was fixed in Arch Linux by explicitly mounting
efivars inside initramfs:
- https://bugs.archlinux.org/task/52768
-
https://github.com/archlinux/mkinitcpio/commit/70511e5ccb7e2500213e04173a70c067a7c9aa35
Maybe the issue should be transferred to Debian's counterpart (initramfs-too
Package: mdadm
Version: 4.2~rc2-7
Severity: normal
X-Debbugs-Cc: cuihao@gmail.com
Dear Maintainer,
I installed Debian bullseye on a Intel RST (also known as IMSM/PCH RAID) RAID 1
volume. The system couldn't boot itself because the RAID volume which the
rootfs is on wasn't detected.
I am aw
6 matches
Mail list logo