From: nospam@needed.invalid   
      
   On Wed, 2/11/2026 12:31 AM, Axel wrote:   
   > Lawrence D’Oliveiro wrote:   
   >> On Wed, 11 Feb 2026 15:52:49 +1100, Axel wrote:   
   >>   
   >>> Asked Google, and AI said run "sudo grub-update" and reboot, which I   
   >>> did. It produced this..  https://auslink.info/linux/panic.jpg   
   >> Worth trying to see if SystemRescue can make any sense of it.   
   >>   
   >> Always keep a copy handy on a bootable USB stick.   
   >   
   > so I downloaded the ISO and burnt it to a DVD on the main PC, and booted the   
   laptop from it, and I get this .. https://auslink.info/linux/security.jpg   
   >   
      
      AI Overview   
      
      A "Security Boot Fail" or "Secure Boot Violation" error usually occurs when   
   the   
      system BIOS detects unauthorized changes to the boot loader, often caused by   
      UEFI updates, new hardware, or booting from an unsigned USB drive. To fix   
   it,   
      enter the BIOS (usually F2, F12, or Del at startup), disable Secure Boot in   
      the Boot/Security menu, or set BIOS to UEFI mode.   
      
   Note that Ubuntu has screwed around with the UEFI materials in the BIOS.   
   I noted what looked like some certificates added to my Big Machine by a   
   Ubuntu install attempt. My BIOS offered an opportunity to connect a FAT32   
   USB stick and "back up" the UEFI metadata, but I had neglected to do this   
   before Ubuntu got in there. I can't say I am too happy about silent changes   
   to the machine... I have still not managed to correct this. I put the BIOS   
   in some sort of recovery mode and it still didn't clean house.   
      
   *******   
      
   Assuming you do enough about secure boot settings to allow some media to boot,   
   you can work on your boot problem of the original disk.   
      
     https://askubuntu.com/questions/41930/kernel-panic-not-syncing   
   vfs-unable-to-mount-root-fs-on-unknown-block0-0   
      
       "You are missing the initramfs for that kernel. Choose another kernel from   
   the   
        GRUB menu under Advanced options for Ubuntu and run   
      
           sudo update-initramfs -u -k version   
      
        to generate the initrd for version (replace version with the kernel   
   version string   
        such as   
      
           4.15.0-36-generic   
      
        ) then   
      
           sudo update-grub   
      
        it does have to do with the rootfs. The kernel can't mount the rootfs   
   because it   
        isn't configured correctly to do so. Instead it is assumed that the   
   kernel will   
        use an initramfs to mount the rootfs. In the days before initramfs, you   
   had to   
        configure the kernel to know a hard coded block number for the rootfs to   
   mount,   
        and this is the behavior it falls back to when it has no initramfs.   
       "   
      
       *****   
      
       "In my situation the problem was that /boot was at 100% capacity, so the   
   last   
        2 kernel updates had not completed successfully, hence on reboot when   
   GRUB2   
        selected the latest Kernel, it failed."   
      
   At a time like this, starting using the Install Media in a Live Session,   
   gives an opportunity to examine the partitions for fullness. You don't want   
   to be attempting to repair something, without space to do the repair. I'm more   
   willing to believe this all started with a space problem, than something else.   
      
   ****************************   
      
       https://help.ubuntu.com/community/Boot-Repair   
      
          https://sourceforge.net/projects/boot-repair-cd/files/   
      
              boot-repair-disk-64bit.iso 	2023-12-23 	2.6 GB   
      
   That's just the equivalent of a Live DVD plus the .ppa with the   
   Boot Repair package in it. The ISO is convenient for a person with   
   optical media capability, but you can also use your favorite ISO to USB   
   stick utility to put that media on USB. I have both that particular   
   version and a CD sized one (much older, not appropriate). So that   
   tool is in my kit bag of odds and sods and I have used it, more than   
   once (when lazy). I know how to chroot, as I was doing that back   
   in Gentoo days.   
      
   Sometimes, Boot Repair can do the thing itself, but just as often,   
   it will tell you to open a Terminal and issue forth with text   
   commands. Then, while you stare at those instructions, you think   
   about whether the syntax looks reasonable, any disk identifiers   
   are OK and so on.   
      
   One of the rules of "boot repair", is ONLY the disk with the OS and   
   the boot information should be present during the Repair. It does   
   you no good, if the Boot Repair puts the starting materials   
   on Disk 4, the OS is on Disk 1, Thursday morning you unplug   
   Disk 4 and the thing gives another boot error scenario. You need   
   simple setups, self contained ones, where boot materials are "next to"   
   the OS. When I give you advice like this, my assumption is that the   
   boot disk was *already* self contained and in perfect shape. Now   
   is not the time to be introducing additional curve balls such   
   as "I broke my boot" and "by the way, I never did this correctly   
   in the first place". We call that a "double fault"! And that   
   requires more cleverness and extra shoveling to escape.   
      
   From your Live Media, make sure you have enough space before you   
   start the repair. Make sure. We don't want to turn this into a   
   clown show, where you ask GOogle and it tells you to reinstall the OS :-)   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)