#grub — Public Fediverse posts

@ubuntu i recently tried installing kubuntu resolute with encryption and the installer has an error there:

It uses LUKS2 instead of LUKS1

Grub is by default only compartible with LUKS1

For LUKS2 ist a maunal configuration witch dracut neccecary which can be very annoying

I tried that with the help of deepseek and failed i can upload the german AI chats if someone is interested

Please fix that ubuntu team

==============

#ubuntu #kubuntu #luks #linux #grub

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.

So. After deleting and rebuilding my `ESP`partition I don't even know how many times and trying out so many different ways of setting up either #rEFind or #GRUB and messing with the `mkinitcpio.d/linux.preset` files, I finally got my original #Arch partition and new #Artix partition booting.

I could not, for the life of me, figure out how to segregate the Arch and Artix boot loaders and initramfs. But since they appear to be the same, both being Arch under the hood...

#Linux

Hm, neuerdings reagiert mein PC während der Boot-Phase, einschließlich GRUB, nicht mehr auf die Funkmaus oder Funktastatur.

Erst, wenn der Anmeldebildschirm von Kubuntu auftaucht, funktionieren Maus und Tastatur.

Bin mir nicht bewusst, im BIOS irgendetwas geändert zu haben.

Kennt jemensch das Phänomen?

Kubuntu 25.10

:boostplease:

#Ubuntu #Linux #GRUB

Wie schafft Windows das eigentlich immer wieder, das Grub-Menü, das mir beim Start des PC eigentlich auch die Option Linux zu Booten anbieten soll, so kaltzustellen, dass Windows durchbootet und man vom Grub-Menü gar nichts mehr sieht?
Ich muss dann jedesmal ins UEFI-Setup, manchmal sogar zweimal, um das wieder zu richten. 🤯
Und Nein, kein Windows ist leider keine Option. Vorerst.

#windows11 #grub #dualboot #uefiboot

Wie schafft Windows das eigentlich immer wieder, das Grub-Menü, das mir beim Start des PC eigentlich auch die Option Linux zu Booten anbieten soll, so kaltzustellen, dass Windows durchbootet und man vom Grub-Menü gar nichts mehr sieht?
Ich muss dann jedesmal ins UEFI-Setup, manchmal sogar zweimal, um das wieder zu richten. 🤯
Und Nein, kein Windows ist leider keine Option. Vorerst.

#windows11 #grub #dualboot #uefiboot

Wie schafft Windows das eigentlich immer wieder, das Grub-Menü, das mir beim Start des PC eigentlich auch die Option Linux zu Booten anbieten soll, so kaltzustellen, dass Windows durchbootet und man vom Grub-Menü gar nichts mehr sieht?
Ich muss dann jedesmal ins UEFI-Setup, manchmal sogar zweimal, um das wieder zu richten. 🤯
Und Nein, kein Windows ist leider keine Option. Vorerst.

#windows11 #grub #dualboot #uefiboot

Wie schafft Windows das eigentlich immer wieder, das Grub-Menü, das mir beim Start des PC eigentlich auch die Option Linux zu Booten anbieten soll, so kaltzustellen, dass Windows durchbootet und man vom Grub-Menü gar nichts mehr sieht?
Ich muss dann jedesmal ins UEFI-Setup, manchmal sogar zweimal, um das wieder zu richten. 🤯
Und Nein, kein Windows ist leider keine Option. Vorerst.

#windows11 #grub #dualboot #uefiboot

Well. After like 3 or 4 failed attempts at installing #Artix, #FreeBSD installed on the first attempt. Struggled for a little trying to get #Grub to boot it. Switched to #rEFInd and booted right up.

I guess I'm trying out FreeBSD for now.

Antes de que se me olvide...

Ayer, no quiso arrancar #Fedora en mi máquina

Qué pasó?

Quise editar un video, instalé #KDEnlive, menú 'inicio' tecleo eso mismo, y dice 'obtener' abre discover, lo instalo, al parecer es nativo el paquete, me da confianza eso, abro el programa y me desespero por no poder hacer rápido lo que pensé, reinicio la PC a Windows para que la use mi pareja

Al regresar, arranca, pantalla de #Plymouth, acaba con el inicio y un cursos de terminal estático

No aparece el inicio de sesión

Raro

Olvidé que había instalado dicho editor, no era relevante

Sí lo fue

Reinicio a recuperación de Fedora, shell, desinstalo los drivers de #Nvidia (pensando era eso), reinicio, arranque en baja resolución, feito pues, nada, sigue igual

Vuelvo a rescue, desinstalo KDEnlive, reinicio, nada

Agoté las búsquedas en #Searx, sale lo mismo de siempre, que #grub esto, que Nvidia lo otro, que si secure boot, que checar los registros, que formateo, que todo menos lo que me pasa

El sudor caliente (por el calor) habita mi piel

Otra vez a reinstalar todo (pensé)

Arranco de nuevo, cursor estático, duro ahí mismo

Se me ocurre hacerle #SSH desde mi teléfono

Shell con root o mi usuario, respiro hondo (osea sí había sistema pero no pantalla de login)

Checo los logs de arranque, plymouth ok, todo ok, excepto... #sddm, 'Unknown Symbol on bla bla bla'

Mi cerebro de pechuga de pollo conecta

Discover de seguro actualizó una dependencia para instalar ese mugroso editor y se rompió algo, sí lo hizo

Por qué sucedió? Bueno, uso Fedora 42, y no he (había) actualizado desde enero, desde que compré mi gráfica RTX5070 Ti, lo dejé así porque en ese tiempo sólo había soporte #CUDA para 42, así que decidí no actualizar nada para no romper nada, me había funcionado bien

Hasta ayer

Así que aprovechando la shell por SSH, un dnf upgrade se encargó de actualizar todo, 16GB de actualizaciones atrasadas

Reinicio, por fin login!

Procedo a reinstalar los drivers de video, reinicio otra vez, arranca bien

Y así termina un sustote, descuido o lo que sea

Pero sucedió algo raro

Al hacer upgrade, regresó el mugroso firefox, y se fue chromium-browser, también necesito una explicación de por qué ocurrió eso, por suerte hacer la inversa funcionó, y no perdí mis perfiles del chrome esterilizado

Bueno banda, a veces Fedora (Discover) hace cosas raras, opacas para el usuario, segunda y última vez que uso una GUI para instalar software, y con prisas...

Fin.

#Linux #Historia #MePasó #Debug

Antes de que se me olvide...

Ayer, no quiso arrancar #Fedora en mi máquina

Qué pasó?

Quise editar un video, instalé #KDEnlive, menú 'inicio' tecleo eso mismo, y dice 'obtener' abre discover, lo instalo, al parecer es nativo el paquete, me da confianza eso, abro el programa y me desespero por no poder hacer rápido lo que pensé, reinicio la PC a Windows para que la use mi pareja

Al regresar, arranca, pantalla de #Plymouth, acaba con el inicio y un cursos de terminal estático

No aparece el inicio de sesión

Raro

Olvidé que había instalado dicho editor, no era relevante

Sí lo fue

Reinicio a recuperación de Fedora, shell, desinstalo los drivers de #Nvidia (pensando era eso), reinicio, arranque en baja resolución, feito pues, nada, sigue igual

Vuelvo a rescue, desinstalo KDEnlive, reinicio, nada

Agoté las búsquedas en #Searx, sale lo mismo de siempre, que #grub esto, que Nvidia lo otro, que si secure boot, que checar los registros, que formateo, que todo menos lo que me pasa

El sudor caliente (por el calor) habita mi piel

Otra vez a reinstalar todo (pensé)

Arranco de nuevo, cursor estático, duro ahí mismo

Se me ocurre hacerle #SSH desde mi teléfono

Shell con root o mi usuario, respiro hondo (osea sí había sistema pero no pantalla de login)

Checo los logs de arranque, plymouth ok, todo ok, excepto... #sddm, 'Unknown Symbol on bla bla bla'

Mi cerebro de pechuga de pollo conecta

Discover de seguro actualizó una dependencia para instalar ese mugroso editor y se rompió algo, sí lo hizo

Por qué sucedió? Bueno, uso Fedora 42, y no he (había) actualizado desde enero, desde que compré mi gráfica RTX5070 Ti, lo dejé así porque en ese tiempo sólo había soporte #CUDA para 42, así que decidí no actualizar nada para no romper nada, me había funcionado bien

Hasta ayer

Así que aprovechando la shell por SSH, un dnf upgrade se encargó de actualizar todo, 16GB de actualizaciones atrasadas

Reinicio, por fin login!

Procedo a reinstalar los drivers de video, reinicio otra vez, arranca bien

Y así termina un sustote, descuido o lo que sea

Pero sucedió algo raro

Al hacer upgrade, regresó el mugroso firefox, y se fue chromium-browser, también necesito una explicación de por qué ocurrió eso, por suerte hacer la inversa funcionó, y no perdí mis perfiles del chrome esterilizado

Bueno banda, a veces Fedora (Discover) hace cosas raras, opacas para el usuario, segunda y última vez que uso una GUI para instalar software, y con prisas...

Fin.

#Linux #Historia #MePasó #Debug

Fixed! Somehow #Grub doesn't automatically detect the resolution anymore.

~$ sudo editor /etc/default/grub

* Remove the # in front of GRUB_GFXMODE
* Change the listed resolution in your desired resolution
* Save the file

~$ sudo update-grub

Reboot your system

#ubuntu

Upgrade #Ubuntu 24.04 to 26.04 went well. Some solvable issues, like Gnome shell extensions that needed an upgrade, and removing the Firefox snap. Only real issue is the low resolution during boot and on the login screen. Resolution is fine when starting a Gnome session. Is this a #GDM3 or a #Grub issue?

Upgrade #Ubuntu 24.04 to 26.04 went well. Some solvable issues, like Gnome shell extensions that needed an upgrade, and removing the Firefox snap. Only real issue is the low resolution during boot and on the login screen. Resolution is fine when starting a Gnome session. Is this a #GDM3 or a #Grub issue?

Upgrade #Ubuntu 24.04 to 26.04 went well. Some solvable issues, like Gnome shell extensions that needed an upgrade, and removing the Firefox snap. Only real issue is the low resolution during boot and on the login screen. Resolution is fine when starting a Gnome session. Is this a #GDM3 or a #Grub issue?

Upgrade #Ubuntu 24.04 to 26.04 went well. Some solvable issues, like Gnome shell extensions that needed an upgrade, and removing the Firefox snap. Only real issue is the low resolution during boot and on the login screen. Resolution is fine when starting a Gnome session. Is this a #GDM3 or a #Grub issue?

Upgrade #Ubuntu 24.04 to 26.04 went well. Some solvable issues, like Gnome shell extensions that needed an upgrade, and removing the Firefox snap. Only real issue is the low resolution during boot and on the login screen. Resolution is fine when starting a Gnome session. Is this a #GDM3 or a #Grub issue?

Grub boot screen in MX Linux in text mode

#grub #boot #screen #BIOS #no #Linux #OpenSource #bootManager #programming #POSIX

Grub boot screen in MX Linux in text mode

#grub #boot #screen #BIOS #no #Linux #OpenSource #bootManager #programming #POSIX

Grub boot screen in MX Linux in text mode

#grub #boot #screen #BIOS #no #Linux #OpenSource #bootManager #programming #POSIX

Grub boot screen in MX Linux in text mode

#grub #boot #screen #BIOS #no #Linux #OpenSource #bootManager #programming #POSIX

🩲 Ubuntu Looks To Strip GRUB To The Bare Minimum For Better Security

https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069

#linux #ubuntu #grub #bootloader #security #software #goodnews

Es ist zwar nicht möglich in #GRUB ein Bootmenu mit LMDE7 und Windows 7 einzurichten, aber mit den im #UEFI eingetragenen Bootoptionen bootet das #T470 wieder ganz von vorne, so dass auch wieder #MBR Boot möglich ist. Die Optionen kann man sich im Terminal mit sudo efibootmgr anzeigen lassen. Bei mir sind es derzeit 24; sie sind im #NVRAM hinterlegt. Zum Vergleich auf meinem billigen HP Notebook sind es nur die 5, die auch angezeigt werden, wenn man gleich beim Start in die #Bootoptionen geht.

Es ist zwar nicht möglich in #GRUB ein Bootmenu mit LMDE7 und Windows 7 einzurichten, aber mit den im #UEFI eingetragenen Bootoptionen bootet das #T470 wieder ganz von vorne, so dass auch wieder #MBR Boot möglich ist. Die Optionen kann man sich im Terminal mit sudo efibootmgr anzeigen lassen. Bei mir sind es derzeit 24; sie sind im #NVRAM hinterlegt. Zum Vergleich auf meinem billigen HP Notebook sind es nur die 5, die auch angezeigt werden, wenn man gleich beim Start in die #Bootoptionen geht.

Es ist zwar nicht möglich in #GRUB ein Bootmenu mit LMDE7 und Windows 7 einzurichten, aber mit den im #UEFI eingetragenen Bootoptionen bootet das #T470 wieder ganz von vorne, so dass auch wieder #MBR Boot möglich ist. Die Optionen kann man sich im Terminal mit sudo efibootmgr anzeigen lassen. Bei mir sind es derzeit 24; sie sind im #NVRAM hinterlegt. Zum Vergleich auf meinem billigen HP Notebook sind es nur die 5, die auch angezeigt werden, wenn man gleich beim Start in die #Bootoptionen geht.

Mit dieser Schwierigkeit hatte ich tatsächlich nicht gerechnet aber #GRUB muss ja in einem der beiden Modi starten, hier in #UEFI und dann wird das Umschalten in den #Legacy Modus als Sicherheitsrisiko betrachtet. Ich hatte gedacht, dass der MBR Start so simpel ist, das wird man schon irgendwie hinkriegen. Aber weder GRUB noch #rEFInd schaffen das, obwohl es #CSM gibt. Hier kommt dann aber auch die Lösung, total anders als gedacht: im UEFI des #T470 hat Lenovo sehr viele Bootoptionen eingetragen

grub on Guix now asks password only once for LUKS encrypted disk! It took quite some time, but I'm happy we are finally here! :D

https://codeberg.org/guix/guix/commit/b90597b98d46767207a0e92a84fb39c344472b69

Kudos to Danny Milosavljevic for fixing it!

#guix #grub

We were visited by this little fella today at our front door. I think it wanted to sell us something, but I wasn't buying. #insect #grub

Gestire GRUB non deve essere rischioso: GrubForge porta sicurezza, chiarezza e una TUI moderna per configurare il bootloader su Linux. #Linux #GRUB #OpenSource #SysAdmin #ArchLinux #Software

https://www.linuxeasy.org/grubforge-interfaccia-tui-sicura-e-moderna-per-gestire-grub-su-linux/?utm_source=mastodon&utm_medium=jetpack_social

I'm reluctantly coming to the conclusion that I should try to learn a bit more about bootloader configuration. Maybe even read the source code. #grub #uboot #rtfm

Benvinguts a Grub!

#grub #humor

@brauner no, this is clearly the wrong approach. Bootloaders like #GRUB run before the kernel, so clearly they should be responsible. I suggest adding DNA-based verification. Simply send a saliva sample to your nearest lab when booting the computer. This simple process only takes 60-90 business days, so the usability impact would be minimal.

Ubuntu 26.10 plans to strip ZFS, Btrfs, LVM, and LUKS encryption from the signed GRUB bootloader to improve security.

Full details here: https://ostechnix.com/ubuntu-26-10-may-drop-zfs-lvm-and-luks-support-from-grub/

#Ubuntu2610 #Grub #Bootloader #Security #Proposal #Linux

#Electron
يعطي تفاصيل دعمو ل
#Wayland
https://www.electronjs.org/blog/tech-talk-wayland
#Mozilla #Firefox 149
فيه تحسينات كبيرة
https://linuxiac.com/firefox-149-now-available-for-download-brings-split-view/
#Canonical
تخدم على
#GRUB
في
Ubuntu
لتحسين الحماية
https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069
https://www.omgubuntu.co.uk/2026/03/ubuntu-security-center-ubuntu-pro
خروج
Ubuntu 26.04 #beta
https://documentation.ubuntu.com/release-notes/26.04/changes-since-previous-interim/
#Plasma 6.6
يغلب
#GNOME 50
في ال
#Graphical #Performance
https://www.phoronix.com/review/ubuntu-2604-gnome-kde/4

RE: https://mastodon.social/@doingfedtime/116296239356028847

This is the single most important reason to stop supporting #Ubuntu. For Heaven's sake why does this guy feel the urge to undermine such a fundamental project such as #Grub ?

Canonical Plans Controversial GRUB Changes for Ubuntu 26.10 Secure Boot

｢ The proposed signed GRUB for Secure Boot would remove support for features such as LUKS disk encryption, LVM, most md-raid modes, ZFS, Btrfs, and various filesystem and image parsing capabilities. Systems would be expected to boot from a simpler layout, typically a plain ext4 /boot partition on GPT or MBR ｣

https://linuxiac.com/canonical-plans-controversial-grub-changes-for-ubuntu-26-10-secure-boot/

#grub #ubuntu #opensource

https://linuxiac.com/canonical-plans-controversial-grub-changes-for-ubuntu-26-10-secure-boot/

Canonical wants to remove LUKS disk Encryption, LVM, most mid-raid modes, ZFS, BTRFS and many other file systems and image parsing abilities from GRUB in a recently announced, Planned change to Secure Boot, Supposedly for "security"

In order to retain these features the system would need to not use secure Boot.

Systems that don't use Secure Boot, or rely on the above features, can not upgrade to Ubuntu 26.10

#Linux #OpenSource #Canonical #Ubuntu #Foss #Grub

Ubuntu 26.10 cambia rotta: il GRUB firmato verrà ridotto al minimo per migliorare la sicurezza. Addio a Btrfs, ZFS, XFS, LVM e LUKS nel boot firmato. Una scelta che farà discutere. #Ubuntu #GRUB #SecureBoot #Linux

https://www.linuxeasy.org/ubuntu-26-10-prepara-un-grub-firmato-ridotto-per-aumentare-la-sicurezza/?utm_source=mastodon&utm_medium=jetpack_social

A Way To Make A PC Startup With The Pokemon PC Noise
isithran on Mastodon came up with a grub boot line that can make your PC's speaker (or whatever substitute it may have) play the classic Pokémon PC startup noise (3 seconds). A demo can be tested here. "PC" obviously stands for "Pokémon Container."

https://www.youtube.com/watch?v=fwEzOeeZxUE
This sound right here.
https://setsideb.com/a-way-to-make-a-pc-startup-with-the-pokemon-pc-noise/
#retro #grub #linux #pokemon #retro #startup

Streamlining secure boot for 26.10 - Project Discussion / Foundations - Ubuntu Community Hub
https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069

#ubuntu #linux #grub

This seems borderline asinine to me.

"Reducing the signed GRUB builds to the minimum support necessary they feel would "[substantially] improve security"

Really? I'm thinking it's more about getting reports than ACTUAL security.

Especially removing btrfs support, since surely that's the default FS nowadays in many dists?

https://www.phoronix.com/news/Ubuntu-26.10-Lighter-GRUB

#GRUB

Some excellent news today! #GRUB has moved to #FreeDesktop and has adopted contemporary/modern contribution workflows leveraging the GitLab instance hosted there.

https://gitlab.freedesktop.org/gnu-grub/grub/

#Linux #Refind salternativen #Bootloader installieren wenn #GRUB nicht alles anzeigt.

Kenntnis im Anpassen der Scripte sind unbedingt erforderlich.
Hintergründe und Icons können individuell nach eigenem Wunsch angepasst werden.

Die verschiedenen Themes verlangen eine individuelle Anpassung der "refind.conf" und Erstellung von verschiedenen Ordnern. Die zu erstellenden Ordner und Pfade stehen jeweils in der Datei "theme.conf"....

#SYSFORMIT
@sysform-it

https://m.youtube.com/watch?v=w-lUbEPNC-I