#mkinitcpio — Public Fediverse posts on home.social

Diego Córdoba 🇦🇷 @[email protected] · 2026-08-10 · 23:05 UTC

Actualicé mi @archlinux y pasó lo que tenía que pasar:

- comenzó a reiniciarse de forma random.
- actualicé de nuevo: nueva versión del núcleo.
- se apagó, se rompió el grub.
- reinicié con un live.
- no estaba el núcleo compilado en el /boot.
- hice chroot al / de mi instalación.
- reinstalé el núcleo Linux, los firmwares, el grub, su configuración, y creé el ramdisk.
- reinicié y acá está andando.

... nada del otro mundo, bah 😅

#gnu #linux #archlinux #grub #mkinitcpio #boot #upgrade

#gnu #linux #archlinux #grub #mkinitcpio #boot

Diego Córdoba 🇦🇷 @[email protected] · 2026-08-10 · 23:05 UTC

Actualicé mi @archlinux y pasó lo que tenía que pasar:

- comenzó a reiniciarse de forma random.
- actualicé de nuevo: nueva versión del núcleo.
- se apagó, se rompió el grub.
- reinicié con un live.
- no estaba el núcleo compilado en el /boot.
- hice chroot al / de mi instalación.
- reinstalé el núcleo Linux, los firmwares, el grub, su configuración, y creé el ramdisk.
- reinicié y acá está andando.

... nada del otro mundo, bah 😅

#gnu #linux #archlinux #grub #mkinitcpio #boot #upgrade

#gnu #linux #archlinux #grub #mkinitcpio #boot

Diego Córdoba 🇦🇷 @[email protected] · 2026-08-10 · 23:05 UTC

Actualicé mi @archlinux y pasó lo que tenía que pasar:

- comenzó a reiniciarse de forma random.
- actualicé de nuevo: nueva versión del núcleo.
- se apagó, se rompió el grub.
- reinicié con un live.
- no estaba el núcleo compilado en el /boot.
- hice chroot al / de mi instalación.
- reinstalé el núcleo Linux, los firmwares, el grub, su configuración, y creé el ramdisk.
- reinicié y acá está andando.

... nada del otro mundo, bah 😅

#gnu #linux #archlinux #grub #mkinitcpio #boot #upgrade

#gnu #linux #archlinux #grub #mkinitcpio #boot

Diego Córdoba 🇦🇷 @[email protected] · 2026-08-10 · 23:05 UTC

Actualicé mi @archlinux y pasó lo que tenía que pasar:

- comenzó a reiniciarse de forma random.
- actualicé de nuevo: nueva versión del núcleo.
- se apagó, se rompió el grub.
- reinicié con un live.
- no estaba el núcleo compilado en el /boot.
- hice chroot al / de mi instalación.
- reinstalé el núcleo Linux, los firmwares, el grub, su configuración, y creé el ramdisk.
- reinicié y acá está andando.

... nada del otro mundo, bah 😅

#gnu #linux #archlinux #grub #mkinitcpio #boot #upgrade

#upgrade #boot #mkinitcpio #grub #archlinux #linux

Diego Córdoba 🇦🇷 @[email protected] · 2026-08-10 · 23:05 UTC

Actualicé mi @archlinux y pasó lo que tenía que pasar:

- comenzó a reiniciarse de forma random.
- actualicé de nuevo: nueva versión del núcleo.
- se apagó, se rompió el grub.
- reinicié con un live.
- no estaba el núcleo compilado en el /boot.
- hice chroot al / de mi instalación.
- reinstalé el núcleo Linux, los firmwares, el grub, su configuración, y creé el ramdisk.
- reinicié y acá está andando.

... nada del otro mundo, bah 😅

#gnu #linux #archlinux #grub #mkinitcpio #boot #upgrade

#gnu #linux #archlinux #grub #mkinitcpio #boot

Kevin @[email protected] · 2026-05-12 · 21:56 UTC

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.

#ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd

#archlinux #bootfailure #debugging #devops #dhcp #dropbear

Kevin @[email protected] · 2026-05-12 · 21:56 UTC

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.

#ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd

#archlinux #bootfailure #debugging #devops #dhcp #dropbear

Kevin @[email protected] · 2026-05-12 · 21:56 UTC

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.

#ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd

#archlinux #bootfailure #debugging #devops #dhcp #dropbear

Kevin @[email protected] · 2026-05-12 · 21:56 UTC

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.

#ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd

#systemdnetworkd #sysadmin #serveroutage #pythoncli #postmortem #pacman

Kevin @[email protected] · 2026-05-12 · 21:56 UTC

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.

#ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd

#archlinux #bootfailure #debugging #devops #dhcp #dropbear

Luca Ruggeri @[email protected] · 2025-11-11 · 23:40 UTC

@Neffscape @linux per dire con l'update di #mkinitcpio mi sono chiuso fuori sbagliando l'hook da caricare (e che usa una diversa sintassi per la partizione root), proprio perché #archlinux è basata più su file che programmi è stato più un dare cryptsetup, mount, arch-chroot e vim vim vim, con qualche `>>` (append) da blkid

#archlinux #mkinitcpio

Trit’ @[email protected] · 2025-11-06 · 09:02 UTC

Deux nouveaux hooks pour #mkinitcpio sur #ArchLinux, suite à la MAJ faite cette nuit : [systemd] et [sd-vconsole]

Conséquence liée ? À l’allumage, ce matin, entre les écrans “Chargement de Linux…” et celui d’ouverture de session, toute la phase de démarrage de systemd se fait… en écran noir complet, à l’aveugle (il n’y a plus la ligne “/dev/sda…”, ni de simple curseur texte “_” gris) ! C’est perturbant, ce changement non sollicité… >__<

#mkinitcpio #archlinux

Trit’ @[email protected] · 2025-11-06 · 09:02 UTC

Deux nouveaux hooks pour #mkinitcpio sur #ArchLinux, suite à la MAJ faite cette nuit : [systemd] et [sd-vconsole]

Conséquence liée ? À l’allumage, ce matin, entre les écrans “Chargement de Linux…” et celui d’ouverture de session, toute la phase de démarrage de systemd se fait… en écran noir complet, à l’aveugle (il n’y a plus la ligne “/dev/sda…”, ni de simple curseur texte “_” gris) ! C’est perturbant, ce changement non sollicité… >__<

#mkinitcpio #archlinux

Trit’ @[email protected] · 2025-11-06 · 09:02 UTC

Deux nouveaux hooks pour #mkinitcpio sur #ArchLinux, suite à la MAJ faite cette nuit : [systemd] et [sd-vconsole]

Conséquence liée ? À l’allumage, ce matin, entre les écrans “Chargement de Linux…” et celui d’ouverture de session, toute la phase de démarrage de systemd se fait… en écran noir complet, à l’aveugle (il n’y a plus la ligne “/dev/sda…”, ni de simple curseur texte “_” gris) ! C’est perturbant, ce changement non sollicité… >__<

#archlinux #mkinitcpio

Trit’ @[email protected] · 2025-11-06 · 09:02 UTC

Deux nouveaux hooks pour #mkinitcpio sur #ArchLinux, suite à la MAJ faite cette nuit : [systemd] et [sd-vconsole]

Conséquence liée ? À l’allumage, ce matin, entre les écrans “Chargement de Linux…” et celui d’ouverture de session, toute la phase de démarrage de systemd se fait… en écran noir complet, à l’aveugle (il n’y a plus la ligne “/dev/sda…”, ni de simple curseur texte “_” gris) ! C’est perturbant, ce changement non sollicité… >__<

#mkinitcpio #archlinux

Arch Linux :archlinux: @[email protected] · 2025-11-05 · 09:26 UTC

[arch-dev-public] mkinitcpio v40, packaging changes and kernel-install

https://lists.archlinux.org/archives/list/[email protected]/thread/S2G5NU4YD7OL7TIGLN4GCV2T6F4RUPBJ/

#ArchLinux #Linux #mkinitcpio

#archlinux #linux #mkinitcpio

Arch Linux :archlinux: @archlinux · 2025-11-05 · 09:26 UTC

[arch-dev-public] mkinitcpio v40, packaging changes and kernel-install

https://lists.archlinux.org/archives/list/[email protected]/thread/S2G5NU4YD7OL7TIGLN4GCV2T6F4RUPBJ/

#ArchLinux #Linux #mkinitcpio

#archlinux #linux #mkinitcpio

Arch Linux :archlinux: @[email protected] · 2025-11-05 · 09:26 UTC

[arch-dev-public] mkinitcpio v40, packaging changes and kernel-install

https://lists.archlinux.org/archives/list/[email protected]/thread/S2G5NU4YD7OL7TIGLN4GCV2T6F4RUPBJ/

#ArchLinux #Linux #mkinitcpio

#archlinux #linux #mkinitcpio

Arch Linux :archlinux: @[email protected] · 2025-11-05 · 09:26 UTC

[arch-dev-public] mkinitcpio v40, packaging changes and kernel-install

https://lists.archlinux.org/archives/list/[email protected]/thread/S2G5NU4YD7OL7TIGLN4GCV2T6F4RUPBJ/

#ArchLinux #Linux #mkinitcpio

#mkinitcpio #linux #archlinux

Arch Linux :archlinux: @[email protected] · 2025-11-05 · 09:26 UTC

[arch-dev-public] mkinitcpio v40, packaging changes and kernel-install

https://lists.archlinux.org/archives/list/[email protected]/thread/S2G5NU4YD7OL7TIGLN4GCV2T6F4RUPBJ/

#ArchLinux #Linux #mkinitcpio

#archlinux #linux #mkinitcpio

Navi :blobCat_real: :therian: @[email protected] · 2025-08-20 · 11:03 UTC

If you have lots of RAM available, but need to save some space on /boot with Arch Linux :arch_linux: when using mkinitcpio (default initramfs setup): Set MODULES_DECOMPRESS in your mkinitcpio.conf to yes.

The default zstd compression will ensure the initramfs image on /boot to be smaller than if this option were not enabled, but RAM usage may be higher when booting.

#ArchLinux :arch_linux: #initramfs #mkinitcpio

#mkinitcpio #initramfs #archlinux

Kevin @[email protected] · 2025-03-22 · 15:42 UTC

🚀 How to Update GRUB and Regenerate Initramfs from a Manjaro Live USB System 🐧

Sometimes things break—it’s Linux life! 💻 Maybe your Manjaro installation isn’t booting correctly after an update or some system tweaks. Don’t panic! You can easily fix boot-related issues using your Manjaro Live USB stick.

Here’s how you can update your GRUB bootloader and regenerate your initramfs directly from a Manjaro Live USB. Let’s dive in! 🌊

🔧 Step 1: Boot into the Manjaro Live USB & Mount your System

Boot your computer with a Manjaro USB stick. Open a terminal and identify your root partition using:

sudo fdisk -l

Let’s say your root partition is /dev/sda2, then mount it:

sudo mount /dev/sda2 /mnt

If you have separate boot or EFI partitions, mount them too:

For a separate /boot partition:

sudo mount /dev/sda1 /mnt/boot

For an EFI partition:

sudo mount /dev/sdaX /mnt/boot/efi

(Replace /dev/sdaX with your actual EFI partition.)

🛠️ Step 2: Enter your Installed System with manjaro-chroot

Manjaro makes this super easy:

sudo manjaro-chroot /mnt

Now you’re working inside your actual system environment! 🚪

⚙️ Step 3: Update GRUB Bootloader

Run these commands based on your boot type:

For BIOS/Legacy boot:

grub-install /dev/sdaupdate-grub

For EFI boot:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheckupdate-grub

🔄 Step 4: Regenerate your Initramfs

Now regenerate initramfs images:

mkinitcpio -P

🎉 Step 5: Finish & Restart!

Exit the chroot environment:

exit

Unmount your partitions:

sudo umount -R /mnt

And reboot your system:

sudo reboot

That’s it! 🎯 Your Manjaro system should now boot up smoothly.

🔗 Useful Resources:

👉 Check out my original conversation with ChatGPT here for more details.

Happy Linux adventures! 🐧✨

#ArchLinux #BIOS #Bootloader #chroot #EFI #GRUB #initramfs #Linux #LinuxCommands #LinuxTutorial #LiveUSB #Manjaro #mkinitcpio #SystemRecovery #Terminal #Troubleshooting

#archlinux #bios #bootloader #chroot #efi #grub

Gabriele Musco @[email protected] · 2024-09-09 · 14:26 UTC

Can anyone explain the advantages of using #dracut over #mkinitcpio on #arch #linux ? Assuming there are any of course

#dracut #mkinitcpio #arch #linux

Gabriele Musco @gabmus · 2024-09-09 · 14:26 UTC

Can anyone explain the advantages of using #dracut over #mkinitcpio on #arch #linux ? Assuming there are any of course

#dracut #mkinitcpio #arch #linux

Gabriele Musco @[email protected] · 2024-09-09 · 14:26 UTC

Can anyone explain the advantages of using #dracut over #mkinitcpio on #arch #linux ? Assuming there are any of course

#dracut #mkinitcpio #arch #linux

Gabriele Musco @[email protected] · 2024-09-09 · 14:26 UTC

Can anyone explain the advantages of using #dracut over #mkinitcpio on #arch #linux ? Assuming there are any of course

#linux #arch #mkinitcpio #dracut

Luke T. Shumaker @[email protected] · 2024-05-08 · 16:20 UTC

#DailyStandup (2/2)

Not something I did, but something that happened:
- Friday's #mkinitcpio v39 release means that my #ARM improvements are now in a stable release. #ArchLinuxARM should no longer have to patch mkinitcpio!

What I'm doing today:
- Following up with the gotk4 prep PR
- Working through some of the #Parabola packaging backlog.
- Working through some of the Parabola email mailinglist backlog

Challenges/blockers:
- Waiting for @amerl to email me some files I'd saved on his laptop

#parabola #dailystandup #mkinitcpio #arm #archlinuxarm

Luke T. Shumaker @lukeshu · 2024-05-08 · 16:20 UTC

#DailyStandup (2/2)

Not something I did, but something that happened:
- Friday's #mkinitcpio v39 release means that my #ARM improvements are now in a stable release. #ArchLinuxARM should no longer have to patch mkinitcpio!

What I'm doing today:
- Following up with the gotk4 prep PR
- Working through some of the #Parabola packaging backlog.
- Working through some of the Parabola email mailinglist backlog

Challenges/blockers:
- Waiting for @amerl to email me some files I'd saved on his laptop

#dailystandup #mkinitcpio #arm #archlinuxarm #parabola

Luke T. Shumaker @[email protected] · 2024-05-08 · 16:20 UTC

#DailyStandup (2/2)

Not something I did, but something that happened:
- Friday's #mkinitcpio v39 release means that my #ARM improvements are now in a stable release. #ArchLinuxARM should no longer have to patch mkinitcpio!

What I'm doing today:
- Following up with the gotk4 prep PR
- Working through some of the #Parabola packaging backlog.
- Working through some of the Parabola email mailinglist backlog

Challenges/blockers:
- Waiting for @amerl to email me some files I'd saved on his laptop

#dailystandup #mkinitcpio #arm #archlinuxarm #parabola

Luke T. Shumaker @[email protected] · 2024-05-08 · 16:20 UTC

#DailyStandup (2/2)

Not something I did, but something that happened:
- Friday's #mkinitcpio v39 release means that my #ARM improvements are now in a stable release. #ArchLinuxARM should no longer have to patch mkinitcpio!

What I'm doing today:
- Following up with the gotk4 prep PR
- Working through some of the #Parabola packaging backlog.
- Working through some of the Parabola email mailinglist backlog

Challenges/blockers:
- Waiting for @amerl to email me some files I'd saved on his laptop

#parabola #archlinuxarm #arm #mkinitcpio #dailystandup

Arch Linux :archlinux: @[email protected] · 2024-05-03 · 13:54 UTC

mkinitcpio v39 has been released!

https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v39

https://lists.archlinux.org/archives/list/[email protected]/thread/REQZWKXXDVUHSPKO5ROGN5RFSL5QDZFA/

#ArchLinux #mkinitcpio

#archlinux #mkinitcpio

Arch Linux :archlinux: @archlinux · 2024-05-03 · 13:54 UTC

mkinitcpio v39 has been released!

https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v39

https://lists.archlinux.org/archives/list/[email protected]/thread/REQZWKXXDVUHSPKO5ROGN5RFSL5QDZFA/