TLDR: BIOS flashing resulted in kernel panic missing init, including for liveUSB, i.e. no way to address with BootSectorFix / BootRepair. How to find init / rebuild MBR?
having a nightmare today. Attempted to update flash my BIOS using file from motherboard manufacturer website, which 'worked' but then bootlooped. I then tried to flash back to my previous BIOS version but that's not available on the site so I had to go back a few versions then back up. The BIOS manager seemed to save one of the later versions, preventing updating, blah blah, it's a mess. Anyhow, I was at v42a, then 50a, then 31, 42d, and now finally 41 stable.
If I try to boot into my normal install (xubuntu 5.6.5-050605-generic) it hangs at:
killed run-init: can't execute '/bin/init': no such file or directory /bin/sh: 0: can't access tty; job control turned off
for a while then
end kernel panic - not syncing: Attempted to kill the idle task! kernel offset: # from # (relocation range: #)
This is AFTER I added "init=/init" to the kernel options in grub, during the previous boot attempt, but I didn't add anything this time.
Trying the same kernel with recovery mode (again, no init specified), hangs at new serial device found, my 5 year old mouse. This is the first time I've seen this issue.
Trying kernel 184.108.40.206 nonrecovery: black screen, nothing happens. Rebooted. No response. Power cycled.
5.6.5-050605 recovery: sits at "Loading initial ramdisk..." indefinitely.
5.6.5-050605 recovery, "init=/init" at end of linux line: gets past ramdisk line,
end Kernel panic - not syncing: Requested init /init failed (error -2).
So I guess my init line is wrong.
5.6.5-050605 recovery, "init=/usr/lib/systemd/systemd" at end of linux line:
kernel panic: attempted to kill idle task error
Various threads recommend disabling secure boot but I don't see that it's enabled. Many more suggest options which require booting into the system (!) or into a liveCD. I made a liveUSB of xubuntu 20.04, try Xubuntu without installing (safe graphics):
end kernel panic - not syncing: No working init found. Try passing init= option to kernel
But this is a liveUSB?? Prior lines of interest were
Initramfs unpacking failed: no cpio magic
This suggests that the problems are from windows trying to fix itself and messing up grub/mbr but I'm not sure. I don't know why that would affect a liveUSB...
This suggests it might be a problem with my liveUSB build & I should try Rufus not Tuxboot. Just tried that:
Some bad messages (went by too fast), then gets to xubuntu splash screen with rotating circle which stops at maybe 15%. This happened before with my previous liveUSB attempt (17.04). Then upon retry it hangs at the same message as before, no cpio magic, no working init. Other options include inspecting UEFI firmware which hangs and reboots. Before I had the chance to select a different option in the third try it had selected the default option (try xubuntu).
Initramfs unpacking failed: decoding failed. sda no caching mode page found BUG: bad page state in process plymouthd general protection fault 0000 #1 SMP NOPTI Comm plyouthd not tainted 5.4.0-26-generic 30-ubuntu (& lots more)
I don't have 220.127.116.11 kernel installed on the machine though maybe that's the liveUSB kernel.
Other grub2 options bkpbootx64.efi:
Failed to open \EFI\BOOT\grub64.efi - Not found Failed to load image \EFI\BOOT\grub64.efi Not found Start_image returned Not Found
System BootOrder not found. initializing defaults
fwupx64.efi: reverts to grub2 menu
Trying linux 4.14 generic recovery mode:
fixing recursive fault but reboot is needed
Possibly from "unable to handle kernel null pointer deference at (null)"
Rebooted, same kernel recovery mode: panic not syncing fatal exception in interrupt, kernel offset.
Retried liveUSB recovery mode:
Comm swapper/8 tainted 5.4.0-26-generic
then pauses for ages. Not sure if it's doing anything. Eventually rebooted. While waiting I looked into the Initramfs unpacking decoding issue, some recommend adding nomodeset to the kernel entry but it's enabled by default in the liveUSB's safe graphics entry.
Trying that again:
Bug: unable to handle page fault for address: # PF supervisor write access in kernel mode pf: error_code(0x)003) - permission violation not tainted kernel this time kernel panic not syncing attempted to kill the idle task, kernel offset
Found out that csm was secure boot. Disabled that, tried booting into normal ubuntu (non liveUSB). Pauses for ages at [end trace] then continues; made some progress:
gave up waiting for root file system device. Common problems: ... ALERT! uuid=# does not exist. Dropping to a shell! (initramfs)
I didn't touch anything & looked back over and it was back at the idle task kernel panic error. Rebooted, missing init kernel panic error. Tried default xubuntu without installing liveUSB, blackscreened before I could hit enter (BIOS still buggy?). Rebooted. Tried the same, faster. No working init error. So maybe the csm/secure boot has fixed the initramfs error but dropped it down to only the missing init issue which still affects the liveUSB. Trying liveUSB safe graphics just to be sure, blackscreened. Powercycled, tried again, no working init bug.
AHCI already enabled for SATA (i.e. not RAID). Disabled csm AGAIN in bios (not sure why it reverted) and tried normal boot again. Gets further (coloured text),
FAILED to mount NFSD config filesystem Dependency failed for NFS mount daemon, NFS server & services, NFSv4 ID_name mapping services.
Waits for ages after "reached target local encrypted volumes". Ages like forever. Rebooted. So maybe this is my final bug? Edit: liveUSB (inc safe graphics) fails with init location error still; normal ubuntu with recovery mode waits ages after "attached scsi disk" then "gave up waiting for suspend/resume device" then kill init error.
If anyone has any ideas I would be very grateful indeed. LiveUSB solutions & Installed solutions fail because of the init location bug.
I can't enter commands anywhere other than kernel options and (once) an initramfs busybox.
Thanks so much in advance.
This also killed my dualboot win10 install but I figure if I can get xubuntu installed, I can worry about windows then.
I also tried Boot Repair liveUSB (tested working on another machine):
Unable to handle null pointer dereference at #
Oops: 0002 [#1] SMP
Tainted 4.13.0-16-generic ubuntu (& lots more output)
Kernel panic, not syncing, fatal exception in interrupt, shutting down cpus with MMI
Trying BootRepair with ide=noidma:
Trying BootRepair again with default settings, says BootRepairDisk for a second in blue then:
(A bit part of why this bug report/help request is such a nightmarish mess is that the error message is regularly different the second time I do the same thing).
Same again, blackscreen, no output, twice. Power cycled. Again, back to default error:
Retrying default ubuntu, which has these settings:
Results in the "attempted to kill init" flavour of init fail:
Retrying, hung in BIOS. Has blackscreened a few times rebooting & not getting to BIOS. Given these issues were almost certainly caused by me flashing the BIOS and scrambling MBR?init locations, I'm loathe to suspect hardware issues, but could this be a motherboard issue? I've had rare but intermittent hangs since I built the machine, have RMAd a few memory stcks but maybe it's other hardware?
Default ubuntu, safe mode ("kill idle task" fail):
Ubuntu 4.14.174 recovery:
Completely out of ideas. Bounty added. Please help, anyone.
I bought a SATA connector, plugged the SSD (which is the booter for linux & win10 on 2 partitions) into my working laptop, backed up files, and can investigate the drive. But I'm not really sure what I'm looking for in terms of signs that things are wrong. grub.cfg's root UUID matches the drive name listed in Thunar. /sbin/init is a symlink to lib/systemd/systemd which doesn't open with mousepad for investigation. No reason to assume this is 'wrong'? With gparted I can 'check' the boot partition: check and repair filesystem (fat32). Not sure whether this is a good idea? Did it, performed fine. Ran TestDisk:
Looks fine? Installed Boot Repair, but it doesn't look like there's an option to analyse the secondary drive's boot sector, and I don't want to risk messing with my laptop's boot sector. Pastebin for boot-repair check. Perhaps the most important looking bit:
=> No boot loader is installed in the MBR of /dev/sdb.
Note: sda = working laptop without separate boot partition. sdb = external SSD from the failed machine with separate boot partition (sdb1). sdb2=xubuntu, sdb3=win10. But:
Boot sector info: No errors found in the Boot Parameter Block.
However the UUID that I believe the boot process is looking for is aeb0822c-0854-4d06-aa9d-33986c319666 which is sdb2, the xubuntu partition, and NOT 34CA-81B4, the sdb1 boot partition. But I could be, and probably am, 100% wrong about this. But sdb1's grub says to look for the long UUID on sdb2 so that's probably fine.
Windows not detected by os-prober on sdb3
Sounds bad. But a later problem. However:
OS#2: Ubuntu 19.10 on sdb2
OS#3: Windows on sdb3
In partitions, sdb1 says "notbiosboot"
Suggested repair: The default repair of the Boot-Repair utility would purge (in order to fix packages) and reinstall the grub-efi-amd64-signed of sda1, using the following options:
sdb1/boot/efi, Additional repair would be performed: unhide-bootmenu-10s fix-windows-boot use-standard-efi-file restore-efi-backups
I REALLY don't want to mess with sda1 AT ALL.
Final advice in case of suggested repair: Please do not forget to make your BIOS boot on sdb1/efi/.../grub*.efi file!
Edit: later that night
In putting the SSD back in I noticed that the CPU/DRAM lights were blinking on some boot attempts. After some googling, this and the above regular changes in boot problems, sluggish booting, regular hangs at bios, blackscreens etc, get me thinking maybe it's a hardware fault concealed by my boot flashing. Indeed I'd had intermittent hangs since I built the rig. Removed 2 mem sticks & it booted, very sluggishly, stopping for long periods at random periods in the boot log. Now typing from that machine. Will attempt to debug hardware. I suspect it's the motherboard.