#initramfs — Public Fediverse posts

Been trying to get my phone to boot from the sdcard again, but ever time I try it it gets stuck after #initramfs.

Maybe it doesn't have the right drivers installed to mount f2fs or I should probably run update-initramfs from within a chroot.

Not being able to receive calls or text sure is an interesting experience

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

Ubuntu 24.04.4 LTS linux kernel 6.17.0-23-generic boots to initramfs alert UUID does not exist #boot #kernel #initramfs #busybox

https://askubuntu.com/q/1566364/612

Sudden Jump in initrd.img SIze Filled /boot Partition #kernel #initramfs

https://askubuntu.com/q/1566167/612

After having it just lying around, I finally took the time to set up my Raspi again. I've now got a booting Pi and my first alpine contribution (https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/215) :yayblob:

(the `usbdelay` command line parameter of alpine's initramfs `init`semms to get ignored in some cases - which is kind of an issue, if your root filesystem resides on an external USB HDD that takes some 20seconds to become available)

#alpine #alpinelinux #initramfs #mkinitfs

Remotely Unlocking an Encrypted Hard Disk

https://fed.brid.gy/r/https://hackaday.com/2026/03/06/remotely-unlocking-an-encrypted-hard-disk/

Remotely Unlocking an Encrypted Hard Disk

https://web.brid.gy/r/https://hackaday.com/2026/03/06/remotely-unlocking-an-encrypted-hard-disk/

Half of the support for the #initrd (not to be confused with #initramfs!) was removed from #Linux 7.0 through a #vfs merge from @brauner:

https://git.kernel.org/torvalds/c/996812c453cafa042f2e674738dbf8fa495661f3 and https://git.kernel.org/torvalds/c/ef12d0573a7f5e7a495e81d773ae5f3e98230cd4

""Remove the deprecated linuxrc-based initrd code path and related dead code. The linuxrc initrd path was deprecated in 2020 and this series completes its removal. If we see real-life regressions we'll revert. […]

The no-op load_ramdisk= and prompt_ramdisk= parameters are dropped, and noinitrd and ramdisk_start= gain deprecation warnings.

Initramfs is entirely unaffected. The non-linuxrc initrd path (root=/dev/ram0) is preserved but now carries a deprecation warning targeting January 2027 removal""

#Kernel #LinuxKernel

Half of the support for the #initrd (not to be confused with #initramfs!) was removed from #Linux 7.0 through a #vfs merge from @brauner:

https://git.kernel.org/torvalds/c/996812c453cafa042f2e674738dbf8fa495661f3 and https://git.kernel.org/torvalds/c/ef12d0573a7f5e7a495e81d773ae5f3e98230cd4

""Remove the deprecated linuxrc-based initrd code path and related dead code. The linuxrc initrd path was deprecated in 2020 and this series completes its removal. If we see real-life regressions we'll revert. […]

The no-op load_ramdisk= and prompt_ramdisk= parameters are dropped, and noinitrd and ramdisk_start= gain deprecation warnings.

Initramfs is entirely unaffected. The non-linuxrc initrd path (root=/dev/ram0) is preserved but now carries a deprecation warning targeting January 2027 removal""

#Kernel #LinuxKernel

Half of the support for the #initrd (not to be confused with #initramfs!) was removed from #Linux 7.0 through a #vfs merge from @brauner:

https://git.kernel.org/torvalds/c/996812c453cafa042f2e674738dbf8fa495661f3 and https://git.kernel.org/torvalds/c/ef12d0573a7f5e7a495e81d773ae5f3e98230cd4

""Remove the deprecated linuxrc-based initrd code path and related dead code. The linuxrc initrd path was deprecated in 2020 and this series completes its removal. If we see real-life regressions we'll revert. […]

The no-op load_ramdisk= and prompt_ramdisk= parameters are dropped, and noinitrd and ramdisk_start= gain deprecation warnings.

Initramfs is entirely unaffected. The non-linuxrc initrd path (root=/dev/ram0) is preserved but now carries a deprecation warning targeting January 2027 removal""

#Kernel #LinuxKernel

Half of the support for the #initrd (not to be confused with #initramfs!) was removed from #Linux 7.0 through a #vfs merge from @brauner:

https://git.kernel.org/torvalds/c/996812c453cafa042f2e674738dbf8fa495661f3 and https://git.kernel.org/torvalds/c/ef12d0573a7f5e7a495e81d773ae5f3e98230cd4

""Remove the deprecated linuxrc-based initrd code path and related dead code. The linuxrc initrd path was deprecated in 2020 and this series completes its removal. If we see real-life regressions we'll revert. […]

The no-op load_ramdisk= and prompt_ramdisk= parameters are dropped, and noinitrd and ramdisk_start= gain deprecation warnings.

Initramfs is entirely unaffected. The non-linuxrc initrd path (root=/dev/ram0) is preserved but now carries a deprecation warning targeting January 2027 removal""

#Kernel #LinuxKernel

Today, I built a cpu #kernel for a #camera again. ✨👩‍💻✨
I.e., I could do `insmod ipcam some-mod.ko` and other fun things.

It took about a minute to build an #initramfs with u-root and cpud *and* the kernel. Now that is really hard to beat.

Speaking of which, we have a demo now showing how fast u-root builds and runs:
https://htmlpreview.github.io/?https://github.com/u-root/u-root/blob/main/tools/testramfs/cinema/index.html

For more, see https://u-root.org 👀

Собираем Linux, который весит меньше, чем мем с котиком, ну или почти…

Мне всегда было интересно, насколько минимальным может быть Linux. Три года назад я уже публиковал статью , но понимание темы меняется. Сейчас хочу освежить знания и поделиться ими. В отличие от предыдущей статьи, в этой я рассматриваю Linux с более свежим ядром с минимальной конфигурацией на основе tinyconfig, оформленный в виде одного файла и загружаемый при помощи UEFI. Зачем вообще нужно создавать такие сборки Linux? Установил готовый дистрибутив или загрузился в Live — работай и изучай. Но такой подход не даёт настоящей уверенности в знаниях. Представьте: водитель и шофёр. Водитель просто ездит. Шофёр знает устройство автомобиля и может его починить. Современные автомобили сложны — починить всё самому уже нельзя. Но вы можете открыть капот, измерить уровень масла, заменить колесо в случае прокола, установить винт для буксировочного троса и т. д. Так же и с Linux: коммерческий дистрибутив вы вряд ли соберёте, но на одну ступеньку вверх по лестнице профессионализма подниметесь. На мой взгляд, описание создания минимального Linux не должно быть большим, поэтому я старался его сделать минимально возможным, вложив максимум смысла. Как минимальный Linux служит для понимания более сложных вещей, так и моя статья даёт базу для дальнейшего более глубокого изучения. В комментариях к моей предыдущей статье я видел замечания, что можно использовать buildroot или книгу Linux From Scratch . Скажу только, что я преследую другие цели: собрать минимальный Linux без использования специализированных программ и сделать это как можно проще. Всем, кого заинтересовало, добро пожаловать под кат.

https://habr.com/ru/companies/ruvds/articles/963400/

#linux #дистрибутив #минимальный_Linux #сборка_ядра #uefi #busybox #linux_from_scratch #initramfs #qemu #ruvds_статьи

If you use #btrfs on kernels ranging from 6.12 to 6.19 and get the error:

VFS: Unable to mount root fs on unknown_block(0,0)

Add the 'btrfs' and 'microcode' hooks to /etc/mkinitcpio.conf via chroot and rerun initramfs generation.

If that doesn't help install `intel-ucode.img` and add it to your grub boot parameters in the initrd list.

If that still doesn't help (happens on Intel 3770k and older) disable #zstd initramfs compression, use gzip instead.

You are welcome

#initramfs #microcode

If you use #btrfs on kernels ranging from 6.12 to 6.19 and get the error:

VFS: Unable to mount root fs on unknown_block(0,0)

Add the 'btrfs' and 'microcode' hooks to /etc/mkinitcpio.conf via chroot and rerun initramfs generation.

If that doesn't help install `intel-ucode.img` and add it to your grub boot parameters in the initrd list.

If that still doesn't help (happens on Intel 3770k and older) disable #zstd initramfs compression, use gzip instead.

You are welcome

#initramfs #microcode

If you use #btrfs on kernels ranging from 6.12 to 6.19 and get the error:

VFS: Unable to mount root fs on unknown_block(0,0)

Add the 'btrfs' and 'microcode' hooks to /etc/mkinitcpio.conf via chroot and rerun initramfs generation.

If that doesn't help install `intel-ucode.img` and add it to your grub boot parameters in the initrd list.

If that still doesn't help (happens on Intel 3770k and older) disable #zstd initramfs compression, use gzip instead.

You are welcome

#initramfs #microcode

If you use #btrfs on kernels ranging from 6.12 to 6.19 and get the error:

VFS: Unable to mount root fs on unknown_block(0,0)

Add the 'btrfs' and 'microcode' hooks to /etc/mkinitcpio.conf via chroot and rerun initramfs generation.

If that doesn't help install `intel-ucode.img` and add it to your grub boot parameters in the initrd list.

If that still doesn't help (happens on Intel 3770k and older) disable #zstd initramfs compression, use gzip instead.

You are welcome

#initramfs #microcode

I have now both an Intel 3770k and 4670k that kernel panic upon trying to load #initramfs with the error 'VFS Unable to mount root fs on unkown-block(0,0)'

I have this interesting #linux problem on an Intel 3770k where it fails to decompress #initramfs and the kernel panics on the unknown block device.

Apparently, this happens because of zstd and the Intel #uCode should fix it. But it doesn't.

It passes a SMP memtest just fine but it can't seem to do any handover past the first EFI entry, I can't even enter the EFI shell.

Perhaps I should reflash the bios because it should be able to pop a shel..

Автоматический выбор версии NVIDIA драйвера при загрузке Linux дистрибутива PocketHandyBox

Проприетарные драйвера NVIDIA для Linux по умолчанию не предполагают возможности соседства нескольких версий в одной файловой системе в классических дистрибутивах. Но эта проблема может быть легко решена в модульных дистрибутивах путем создания отдельных squashfs модулей с разными версиями NVIDIA драйверов. Таким образом получаем рабочий драйвер NVIDIA сразу после запуска и без дополнительных манипуляций.

https://habr.com/ru/articles/961400/

#nvidia #linux #debian #initrd #initramfs

#Ubuntu #BusyBox #initramfs

BusyBox v1.36.1 (Ubuntu 1:1.36.1-6ubuntu3.1) built-in shell (ash)
Enter 'help' for a list of built-in commands

(initramfs) exit
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID=b2046752-c2f9-b729-711404875fe2 does not exist. Dropping to a shell!

BusyBox v1.36.1 (Ubuntu 1:1.36.1-6ubuntu3.1) built-in shell (ash)
Enter 'help' for a list of built-in commands

(initramfs) _

Debian on encrypted LVM with Btrfs subvolumes

https://www.nixre.net/2025/09/24/debian-on-encrypted-lvm-with-btrfs-subvolumes/

Wie startet dein Linux-System und wie konfigurierst du den Boot-Prozess professionell? Genau hier kommt das Boot-Management ins Spiel – ein absolut kritischer Bereich der Linux-Administration, den du als angehender Administrator unbedingt verstehen musst.

Ohne dieses Grundverständnis stehst du bei Boot-Problemen hilflos da.

https://admindocs.de/linux-administration/linux-administration-10-boot-management-systemstart.shtml

#BootManagement #grub2 #linux #sysadmin #initramfs #linuxtutorial

Wie startet dein Linux-System und wie konfigurierst du den Boot-Prozess professionell? Genau hier kommt das Boot-Management ins Spiel – ein absolut kritischer Bereich der Linux-Administration, den du als angehender Administrator unbedingt verstehen musst.

Ohne dieses Grundverständnis stehst du bei Boot-Problemen hilflos da.

https://admindocs.de/linux-administration/linux-administration-10-boot-management-systemstart.shtml

#BootManagement #grub2 #linux #sysadmin #initramfs #linuxtutorial

Wie startet dein Linux-System und wie konfigurierst du den Boot-Prozess professionell? Genau hier kommt das Boot-Management ins Spiel – ein absolut kritischer Bereich der Linux-Administration, den du als angehender Administrator unbedingt verstehen musst.

Ohne dieses Grundverständnis stehst du bei Boot-Problemen hilflos da.

https://admindocs.de/linux-administration/linux-administration-10-boot-management-systemstart.shtml

#BootManagement #grub2 #linux #sysadmin #initramfs #linuxtutorial

New #blogpost about #initramfs and how to hijack it: https://typekmatus.blogspot.com/2025/07/initramfs-co-to-je-ako-to-zneuzit.html

#linux #initramfs

Fedora 43 to Use Zstd Compression for Faster Boot and Smaller Initrd #fedora43 #zstd #initrd #initramfs #fastboot #linux #dracut
https://ostechnix.com/fedora-43-initrd-zstd-compression/

Fedora 43 to Use Zstd Compression for Faster Boot and Smaller Initrd #fedora43 #zstd #initrd #initramfs #fastboot #linux #dracut
https://ostechnix.com/fedora-43-initrd-zstd-compression/

Fedora 43 to Use Zstd Compression for Faster Boot and Smaller Initrd #fedora43 #zstd #initrd #initramfs #fastboot #linux #dracut
https://ostechnix.com/fedora-43-initrd-zstd-compression/

Fedora 43 to Use Zstd Compression for Faster Boot and Smaller Initrd #fedora43 #zstd #initrd #initramfs #fastboot #linux #dracut
https://ostechnix.com/fedora-43-initrd-zstd-compression/

Fedora 43 to Use Zstd Compression for Faster Boot and Smaller Initrd #fedora43 #zstd #initrd #initramfs #fastboot #linux #dracut
https://ostechnix.com/fedora-43-initrd-zstd-compression/

#immich server is back online on the new machine. Double the drive size as a bonus. #clonezilla took care of cloning the old drive to the NVMe on the NUC. Had trouble booting at first until I switched to a fallback initramfs. From what I understand I might need to rebuild the existing #initramfs images. The joy and terror of #selfhosting 😬

Ubuntu 25.10 will use Dracut

While Ubuntu 25.04 is still ongoing development, there has been progress in switching from initramfs-tools to Dracut. Those tools both handle initrd generation for booting into the Linux kernel in preparation for the full system boot. The Ubuntu engineers are working hard to migrate such tool to Dracut to ensure better bootstrapping by reducing hard-coded logic as much as possible.

Initially, Ubuntu 25.04 would have used Dracut as the initrd generator, but the work wasn’t complete yet, so the Ubuntu engineers have delayed the migration to after Ubuntu 25.04 gets released so that the next version of Ubuntu uses Dracut completely.

However, you have an opportunity to try out Dracut in Ubuntu 25.04 when it gets released. This is so that you can provide feedback to the Ubuntu team about your experience with the Dracut integration.

Ubuntu 25.04 will be the last version that uses initramfs-tools as the default initrd generator, with the October release of Ubuntu being the first version that uses Dracut. This is going to be exciting news for the next year’s Ubuntu LTS release that will be out in the next April.

https://audiomack.com/aptivi/song/ubuntu-2510-will-use-dracut

#2504 #2510 #Dracut #Initramfs #InitramfsTools #Initrd #news #Plucky #PluckyPuffin #Puffin #Tech #Technology #Ubuntu #Ubuntu2504 #Ubuntu2504Plucky #Ubuntu2504PluckyPuffin #Ubuntu2510 #update

Ubuntu 25.10 will use Dracut

While Ubuntu 25.04 is still ongoing development, there has been progress in switching from initramfs-tools to Dracut. Those tools both handle initrd generation for booting into the Linux kernel in preparation for the full system boot. The Ubuntu engineers are working hard to migrate such tool to Dracut to ensure better bootstrapping by reducing hard-coded logic as much as possible.

Initially, Ubuntu 25.04 would have used Dracut as the initrd generator, but the work wasn’t complete yet, so the Ubuntu engineers have delayed the migration to after Ubuntu 25.04 gets released so that the next version of Ubuntu uses Dracut completely.

However, you have an opportunity to try out Dracut in Ubuntu 25.04 when it gets released. This is so that you can provide feedback to the Ubuntu team about your experience with the Dracut integration.

Ubuntu 25.04 will be the last version that uses initramfs-tools as the default initrd generator, with the October release of Ubuntu being the first version that uses Dracut. This is going to be exciting news for the next year’s Ubuntu LTS release that will be out in the next April.

#2504 #2510 #Dracut #Initramfs #InitramfsTools #Initrd #news #Plucky #PluckyPuffin #Puffin #Tech #Technology #Ubuntu #Ubuntu2504 #Ubuntu2504Plucky #Ubuntu2504PluckyPuffin #Ubuntu2510 #update

Ubuntu 25.10 will use Dracut

While Ubuntu 25.04 is still ongoing development, there has been progress in switching from initramfs-tools to Dracut. Those tools both handle initrd generation for booting into the Linux kernel in preparation for the full system boot. The Ubuntu engineers are working hard to migrate such tool to Dracut to ensure better bootstrapping by reducing hard-coded logic as much as possible.

Initially, Ubuntu 25.04 would have used Dracut as the initrd generator, but the work wasn’t complete yet, so the Ubuntu engineers have delayed the migration to after Ubuntu 25.04 gets released so that the next version of Ubuntu uses Dracut completely.

However, you have an opportunity to try out Dracut in Ubuntu 25.04 when it gets released. This is so that you can provide feedback to the Ubuntu team about your experience with the Dracut integration.

Ubuntu 25.04 will be the last version that uses initramfs-tools as the default initrd generator, with the October release of Ubuntu being the first version that uses Dracut. This is going to be exciting news for the next year’s Ubuntu LTS release that will be out in the next April.

https://audiomack.com/aptivi/song/ubuntu-2510-will-use-dracut

#2504 #2510 #Dracut #Initramfs #InitramfsTools #Initrd #news #Plucky #PluckyPuffin #Puffin #Tech #Technology #Ubuntu #Ubuntu2504 #Ubuntu2504Plucky #Ubuntu2504PluckyPuffin #Ubuntu2510 #update

Ubuntu 25.10 will use Dracut

While Ubuntu 25.04 is still ongoing development, there has been progress in switching from initramfs-tools to Dracut. Those tools both handle initrd generation for booting into the Linux kernel in preparation for the full system boot. The Ubuntu engineers are working hard to migrate such tool to Dracut to ensure better bootstrapping by reducing hard-coded logic as much as possible.

Initially, Ubuntu 25.04 would have used Dracut as the initrd generator, but the work wasn’t complete yet, so the Ubuntu engineers have delayed the migration to after Ubuntu 25.04 gets released so that the next version of Ubuntu uses Dracut completely.

However, you have an opportunity to try out Dracut in Ubuntu 25.04 when it gets released. This is so that you can provide feedback to the Ubuntu team about your experience with the Dracut integration.

Ubuntu 25.04 will be the last version that uses initramfs-tools as the default initrd generator, with the October release of Ubuntu being the first version that uses Dracut. This is going to be exciting news for the next year’s Ubuntu LTS release that will be out in the next April.

#2504 #2510 #Dracut #Initramfs #InitramfsTools #Initrd #news #Plucky #PluckyPuffin #Puffin #Tech #Technology #Ubuntu #Ubuntu2504 #Ubuntu2504Plucky #Ubuntu2504PluckyPuffin #Ubuntu2510 #update

Ubuntu 25.10 will use Dracut

While Ubuntu 25.04 is still ongoing development, there has been progress in switching from initramfs-tools to Dracut. Those tools both handle initrd generation for booting into the Linux kernel in preparation for the full system boot. The Ubuntu engineers are working hard to migrate such tool to Dracut to ensure better bootstrapping by reducing hard-coded logic as much as possible.

Initially, Ubuntu 25.04 would have used Dracut as the initrd generator, but the work wasn’t complete yet, so the Ubuntu engineers have delayed the migration to after Ubuntu 25.04 gets released so that the next version of Ubuntu uses Dracut completely.

However, you have an opportunity to try out Dracut in Ubuntu 25.04 when it gets released. This is so that you can provide feedback to the Ubuntu team about your experience with the Dracut integration.

Ubuntu 25.04 will be the last version that uses initramfs-tools as the default initrd generator, with the October release of Ubuntu being the first version that uses Dracut. This is going to be exciting news for the next year’s Ubuntu LTS release that will be out in the next April.

https://audiomack.com/aptivi/song/ubuntu-2510-will-use-dracut

#2504 #2510 #Dracut #Initramfs #InitramfsTools #Initrd #news #Plucky #PluckyPuffin #Puffin #Tech #Technology #Ubuntu #Ubuntu2504 #Ubuntu2504Plucky #Ubuntu2504PluckyPuffin #Ubuntu2510 #update

Eigentlich wollte ich den #Linux Kernel 6.14 testen, aber #initramfs, #btrfs und #nvidia sagen nein.

Maximizing hardware with SSD caching via Device Mapper: or, how I got my aging setup's startup time from 8 minutes to mere seconds thanks to Linux.

https://bojidar-bg.dev/blog/2025-02-07-dm-cache/

#linux #archlinux #dmcache #initramfs #performance #devicemapper #ssd

Just switched my root-on-SSD home/var-on-HDD setup over to a single-partition dm-cache setup which automatically caches useful blocks... and it all works!
Hopefully, this will speed up Docker and Firefox going forward. 🥲
...I did feel like a wizard for having to write my own mkinitcpio hook 🎩 - thankfully I had https://wiki.tnonline.net/w/Blog/dm-cache:_Linux_Accelerated_Storage to guide me!

Would anyone be interested in a longer write-up on how I got all that working? 😇
#linux #archlinux #dmcache #initramfs

Google Drive Now Bootable https://hackaday.com/2024/07/02/google-drive-now-bootable/ #googledrive #LinuxHacks #filesystem #initramfs #bootable #dracut #linux #boot #fuse

Booting Linux Off of Google Drive
https://ersei.net/en/blog/fuse-root
#ycombinator #linux #fuse #drive #google #boot #dracut #initramfs

@jrredho

Quick update. I found a solution. I couldn't rebuild the initramfs for one kernel, but I was able to rebuild it for all kernels with the following command in rescue mode:

# 𝚍𝚛𝚊𝚌𝚞𝚝 --𝚛𝚎𝚐𝚎𝚗𝚎𝚛𝚊𝚝𝚎-𝚊𝚕𝚕 --𝚏𝚘𝚛𝚌𝚎

After that I was able to log in to my machine with no issues and no data loss.

#fedora #linux #initramfs #dracut

#Festplattenverschlüsselung auf einem #Server unter #Linux:

Ist #Dropbear in der #initramfs noch das Mittel der Wahl oder gibt es andere, bessere Ansätze?