#grub — Public Fediverse posts

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.

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?

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.

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

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

#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

And, that isn't all, as it also opens up potential to replace #GRUB with modern #bootloader options like #rEFInd or #SystemDBoot, at least for my #UEFI machines.

@ekimia pour les personnes dans le même cas que moi : impossibilité de redémarrer sans plantage d'ordi + kernel panic, cette page m'a sorti de l'ornière : https://ubuntuhandbook.org/index.php/2024/12/os-kernel-boot-default-ubuntu-linux/ et surtout l'option 2, très simple et avec très peu de commandes à copier dans le terminal pour installer Grub Customizer. En moins de 2 minutes mon MacBook Air redémarre automatiquement sur l'ancien kernel en attendant une mise à jour compatible ! #ubuntu #Grub Customizerkernel #kernelpanic #kernelbootdefault #linux :)

@phillo I'd like to keep the LTS kernel. The current behaviour is the #EndeavourOS default but I don't understand why it the exactly is the reverse order of the #GRUB defaults. 😅

I just want that behaviour in #systemdboot.

It would be great to have a something like a "Open Multi-boot Native Interface", OMNI, to replace #GRUB.

- UEFI only
- Graphical
- Multi-kernel support

I'm asking to basically marry GRUB with #rEFInd, and bring things like multi-kernel or OCI support dead simple rather thant bound to the terminal.

#Linux #FOSS #OSS #OpenSource #Boot #BootLoader

The February #GNU Spotlight by Amin Bandali is now available! Read it here: https://u.fsf.org/4ab #FSF #GRUB #Units #GNUGuix

Se viene un nuevo video de Hardening GNU/Linux en el canal de Youtube de #JuncoTIC!!

Y sí, parte de una nueva clase para el curso que estamos preparando 😉

Jugando con la seguridad del GRUB 🔑

No olviden suscribirse para verlo recién salido del horno!

👇

https://youtube.com/juncotic?sub_confirmation=1

#gnu #linux #hardening #curso #infosec #ciberseguridad #grub

Как заставить китайскую механическую клавиатуру работать в Linux

Как заставить китайскую механическую клавиатуру (Zifriend, SAMA, Gamestop, Cyberlinx) работать в Linux, хотя производитель этого не обещал. История о том, как я «подружил» свою Cyberlinx ZA63 с Linux Ubuntu, когда официально поддержки нет. Для всех, кто думал, что клавиатуры «просто работают» везде или столкнулся с такой же проблемой.

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

#linux_kernel #ubuntu #keyboard #механические_клавиатуры #grub

I am powering up my self-assembled NAS for the first time and, of course, it is not working. I am panicking because I cannot return any of the components I am using… 🤯

The absolute first time I powered it up, it stayed on but the HDMI did not output anything, so I brutally unplugged the power (I am starting to regret I did this), and connected a USB with a Proxmox image on it.

Now, every time I plug in the power supply, the NAS powers for one second, than shuts off for two seconds, then it tries to boot again… It goes like this on and on and on…

Any tips to troubleshoot this?

Here are the components I am using:

• Case: Jonsbo N3
• 6× SATA 6 cables
• PSU: Chieftec CSN-450C 450W SFX 80 Plus Gold
• Topton N18 + Intel N150
• 2× RAM 16GB DDR5
• 2× HDD Seagate Ironwolf NAS 10TB
• UPS: BlueWalker Power Basic VI 1000 STL

#help #NAS #selfHosting #Proxmox #sysAd #homelab #Linux #VM #virtualMachine #grub #boot #bootloop #aiuto #MastoAiuto #MastoHelp #support #techSupport

So maybe someone on fedi can help me here, but after updating my #ThinkPad #T14 #BIOS to 1.17, #fedora can no longer #suspend normally and freezes and requires a hard power-off each time. I tried some #grub stuff, many suggested fixes I found on the internet and a newer kernel (6.18 instead of 6.17) but nothing worked. So I think it may be a #Lenovo issue.

#Unix #Linux #followerpower #askfedi #gnome #AMD #LVFS #laptop

https://discussion.fedoraproject.org/t/suspend-broken-s2idle-on-thinkpad-t14-gen-6-amd-after-bios-1-17-fedora-43/

Thanks! :BlobhajSadReach:

Edit: Solved!

Super. Auf dem ersten #server läuft das #proxmox #upgrade fluffy durch.

Dann #reboot.

Es folgt

#grub
#bums
#peng
#exit

Kein #system erkannt.
#freude

@Doppellhelix