The first error is Your EFI System Partition (ESP) is not mounted at /boot/efi
The current latest kernel doesn’t boot, it gives me error kernel panic VFS unable to mount root fs on unknown block (0,0)
Relevant System Information:
I had to revert back to older kernel Linux 6.17.0-19-generic to boot into ubuntu
Google AI tells me that you need to rebuild initramfs. It recommends booting into the older Linux kernel and running some commands that work in Ubuntu. But different commands for Redhat. Why the difference?
Rehat uses Dracut to build initramfs. Ubuntu does not use Dracut until we get to Ubuntu 25.10 and later. It all depends if your Ubuntu 25.10 is an online upgrade from 25.04 or earlier. It will not use Druct. If your 25.10 is a fresh install then it will use Dracut.
Google AI did not show me anything on using Ubuntu to repair initramfs using Dracut It only showed with using Redhat. I would be happier if a Ubuntu user with Dracut experience would provide the commands for you to use than giving you the Google AI answers.
So, I am agreeing with the suggestion to upgrade to Ubuntu 26.04.
While I don’t disagree with the sentiment that the time is better spent on a release upgrade, it glosses over the fact that upgrading to the latest versions of all packages is a prerequisite of doing that. So, we’ve got ourselves a Catch 22 here.
@anmac1789, what happened prior to that error? As @graymech hinted at, the initial ram disk (initrd) might not have been created properly. One reason for that happening can be space constraints on the /boot partition, so how much space is left there?
df -hT /boot
(please post the output in a CODE block; click </> on an empty line and paste.) EDIT: If /boot is on a BTRFS that output does not show the whole picture; one can get into a “no space left” situation with gigabytes “free”, at least as far as df is concerned and can know.
(EDIT2: added the -T switch)
There may be other reasons why the initrd wasn’t created, but those require additional research. You should also check the state of packages; usually when this sort of stuff happens the respective kernel package ends up in a half-installed state. See the last entries in /var/log/apt/history.log to see if it contains a clue; if so, see the corresponding entries in /var/log/apt/term.log.
Assuming your system was trying to upgrade to the latest linux-generic version, this command forces the recreation of the initrd from scratch for the 6.17.0-35 kernel:
sudo update-initramfs -ck 6.17.0-35-generic
But I suspect it will fail; there was a reason for the initial failure, after all. It should provide a meaningful error message, tough.
BTW, since this is possibly related to unattended security upgrades, it’s not the worst of ideas to have the system send you a local email, when it does such an upgrade. It probably does that already and you just don’t know; see /var/mail/root — one can even direct Thunderbird and friends to also check that mailbox, so you get a nice event-based notification of sorts.
Unless you compiled it yourself you’ve made NO changes “in the new kernel” or any other
No, not a Catch 22.
If you can boot with an earlier kernel then you can and should fully update the system irrespective of the kernel version. Here’s the one-liner that does just that: sudo apt update && sudo apt full-upgrade. It’s this simple and, assuming no errors, you can sudo do-release-upgrade right then and there. A fully updated system (including kernels) is a requirement; running the latest kernel is not!
And by fully updating all the packages with the aforementioned concatenated commands there’s a good chance we end up with an even newer and non-problematic kernel version.
Sorry, I strongly disagree, for that could result in the same kind of error, just with the newer kernel of 26.04. If the already running system can’t upgrade the kernel as it is, how do you expect it to lift the whole release to the newer version?
That’s a bold assumption, given the state the OP’s /boot is in. I assume unattended-upgrades has failed to upgrade the kernel — probably because of an out-of-space condition — and it essentially just runs apt upgrade --update for the subset of packages it is configured for; by default those are the security upgrades only.
/boot typically isn’t its own partition but just a folder inside root so it won’t run out of space unless root is nearly full.
IMO, you’re overthinking this situation. Unfortunately there were (too many) cases in the recent past where certain kernel (sub-)versions created all sorts of issues, among them the case reported by the OP.
Again…
If the previous kernel version boots successfully make sure to use that session to fully update the system as mentioned. Troubleshoot from there, i.e., if there are errors with apt we go from there (indeed there’s a chance other stuff not being quite right but not really what you’re concerned about). If not, then definitely the OP can either 1. Test the newest kernel (default boot) and/or release upgrade.
That’s neither here nor there; even though I said “partition” the same applies for /boot just being a sub-directory of /, which can run out of space just the same, you know? (also note my comment about BTRFS)
We need more info, to really know what went wrong; and wrong something went, for sure.
Sorry, you are underthinking it.
Maybe the cause was ultimately something much more mundane, but nobody bothered to look closely enough. If this is caused by a corrupted/non-existent initrd — the underlying assumption of all my comments so far — the reason needs to be found, otherwise the newer kernel could just as well end up without one, too.
The system has already demonstrated that it couldn’t do that.
@graymech’s hint that this is what a missing initrd looks like. A kernel upgrade requires a post-install update-initramfs to generate one, which presumably failed here. Since the initrd is mounted as / in the boot environment /boot/efi can’t be mounted on top of it, hence the message the OP reported.
P.S.: I am not saying that is the actual issue, just that it’s the assumption I operate under with the info at hand; OP update still pending.
If that were the case it wouldn’t boot with any kernel and yet it does… So, Occam’s razor means the problem is with the newest kernel the OP has which, BTW, is NOT the latest one released for 25.10. That it can’t install and test a newer kernel is just a wrong assumption. Many similar situations in the recent past do NOT validate such assumption.
And the reason you’re overthinking is obvious: Do you really think the same person asking this Error: Your EFI System Partition (ESP) is not mounted at /boot/efi is using BTRFS or any deviation from the the standard automated installation and partitioning? Really?
On top of that you misundertsood @graymech ‘s post that was about trying to “fix” 6.17.0-19-generic… We don’t need to worry about it. A “full-upgrade” will install the current version - 6.17.0-23-generic or newer -; if not then there are OTHER issues (with apt) that need to be fixed and the only way to know them is to do a “full-upgrade”. This is not an isolated incedent. Again, it happened recently with a few 6.14 and 6.18 (sub-)versions, regardless of the Ubuntu release, and ALL were solved simply by booting and earlier kernel and fully updating the OS which more often than not actually installed an even newer kernel that just worked.
Well, what if that is the actual issue? unattended-upgrades tried to upgrade the kernel to 6.17.0-35 and failed at some stage.
How is one related to the other? Plenty of HowTos around for doing just that; put / and thus /boot on BTRFS. I am not assuming anything in that regard, just trying to cover all bases, because the output of df is deceiving; I, for one among many others, have found out the semi-hard way — I knew it could happen, just not so soon with >10G “free” according to df. (I don’t have /boot on BTRFS, BTW; it’s a separate ext4, as is best practice for bootstrapping more sophisticated filesystems; just so people don’t get any ideas of me suggesting to put everything on one BTRFS /)
And what if the initrd is only half-finished but just enough so it mounts but fails at stuff that was supposed to be written later but never did.
I won’t discuss any more hypotheticals until more info from OP arrives.
My advice is to backup your data and create space on the drive and then dual boot with a fresh install of Ubuntu 26.04 LTS. Now you can experiment with your install of 25.10. It will be a learning experience.
Take note of the warning to use code with caution. In my opinion, caution is thrown to the wind once we write code in a terminal and press Enter.
To rebuild your initramfs, the exact command depends on your Linux distribution. For Debian/Ubuntu-based systems, use update-initramfs; for RHEL/Fedora/Rocky use dracut; and for Arch/Manjaro use mkinitcpio. [1, 2, 3, 4, 5]
Review the steps for your specific system below:
Debian, Ubuntu, and Derivatives
Update the initramfs for the currently running kernel: [1]
bash
sudo update-initramfs -u -k all
Use code with caution.
Alternatively, to generate a fresh image for the currently running kernel, replace -u with -c. [1, 2]
RHEL, Fedora, and Rocky Linux
Rebuild the initramfs for the active kernel using dracut: [1]
bash
sudo dracut --force
Use code with caution.
To rebuild for a specific older kernel version, specify the version number at the end of the command (e.g., sudo dracut --force /boot/initramfs-5.14.0.img 5.14.0). [1]
That information can be found by anyone asking Google AI the appropriate question. I do not offer it as something I learned through experience. It is information to be used as an experiment on a broken installation.
If an older kernel boots fine, the problem is likely with the newer kernel. Boot into the working one, check logs, and update or reinstall the faulty kernel. This is usually fixable without reinstalling the whole system.
Thank you all for the informative replies, I was at my cousin’s baby shower yesterday so I will need to give you all screenshots and logs and more in depth information about what took place. Please allow me some time to provide more information. Thanksss
Before the corrupted kernel, I was trying to put some image files into a .zip archive which was on ubuntu but it stalled with winrar so i cancelled it. I hadn’t used my external ubuntu ssd in a long time (approx 2 or 3 months) so I booted into my ubuntu and got a notification that it’s upgradable to 26.04 so I clicked to upgrade and received that initial boot error (which I dont understand why because it worked perfectly fine before without issues).
azeem@azeem-desktop:~$ df -hT /boot
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda2 ext4 219G 133G 76G 64% /
You should probably have waited with that and installed the latest upgrades first.
Those shouldn’t cause the boot problem, though. You need to go further back in history, because the actual installation of kernel version 6.17.0-35 isn’t in these logs.
How did that even work? Your last log entries show that 6.17.0-35 got purged.
