And hello, and welcome to the world of panic.
We're going to learn to control a Linux kernel panic,
understanding both what it is and how we can try to recover from a kernel panic.
The first thing that we want to be able to do is log on from a
normal console with a username and password. Using Vagrant,
we're used to using SSH authentication,
which we won't be able to do when we're looking at our recovery system.
So we're going to add a password for our Vagrant account.
With that done,
we can take a little bit of care remembering that we are
here trying to destroy our system.
We're going to delete the initramfs. Now, a word of caution here.
If you're working with a virtual machine such as I am,
which is just a play system,
it doesn't really matter what we do. But if you're dependent on the
Linux system that you're working with, then take a little bit more care
or perhaps find another system to work with.
We're going to go through and as root delete the initramfs for our current
running kernel. This won't cause a problem whilst we boot it, but when we go
through and reboot, we're going to try and load the initialization ramfs.
That's going to give us access to our root filesystem for the kernel to load
other drivers, but the system is going to panic because we cannot access our
root filesystem.
We can recover from this by rebooting our system and choosing a recovery
or rescue image. If we boot to the same rescue image,
we're going to have the correct kernel version number, which
just saves us checking on the kernel versions.
We can then create an initialization RAM disk or initramfs,
either using the mkinitrd command, but we can also do something
similar using the dracut command.
Now with that done, we should be back up and running, and this is exactly what
we want to be able to see working on Alma Linux 8 and recovering from a kernel
panic, albeit one that we created ourselves. And here we are back on our Alma
Linux 8 system working as the root user, and we're going to create a little
bit of panic in the realms of our kernel. Let's see how much damage we can go
through and cause.
So let's say I want to be able to log on via password‑based authentication
for my Vagrant account, so let me just set a password.
Normally, we've been using key‑based authentication. So there you go,
a password has been set. And thankfully, I do know what that password is.
Now the next step, as I say, only do this if you're working
with a play system and you're happy that you might be
destroying your system forever.
Hopefully we can recover it, but we can't guarantee it, so do take care. But
we're going to go ahead now into our boot directory. And I'm going to go
through into the initramfs, and I want to then delete the initialization RAM
filesystem for my current running kernel. Again, uname ‑r is going to give me
the kernel release, but don't forget, we have .img, and that should be .img at
the end of the file name.
That's going to warn me that is deleting it.
And I say take care.
We are doing something fairly stupid to our system, but we want to
create a kernel panic, but only on systems that you are prepared to
lose if it all goes pear shaped. Nothing is going to happen whilst my
operating system is running.
I don't actually need this file or the kernel whilst it's running. A
kernel is loaded into memory, and it's got access to the root
filesystem. But powering off and then returning to VirtualBox itself so
I can manage it directly from the console,
we can allow it to boot up. And look at this.
We've tried through GRUB to load the initialization ramfs.
It does appear that we could continue, but in doing so, we load the kernel,
but the kernel now is panicking because we can't mount the root filesystem,
and we can't mount the root filesystem because the initialization ramfs we
couldn't load, and that has the drivers.
So this is really one of the ways we can cause a kernel panic. But
don't worry, we should be able to recover from it. Let me just power it
off and boot again. And we can see then our GRUB menu. Now to be
honest, I could boot to any of my other kernels, but we'll boot the
normal way to a rescue system.
The rescue system will have its own kernel, but its own initialization
RAM filesystem as well that it will be pointing to, and this is then
going to allow me to boot up to a working system and as such repair
the disaster that I've created.
So it's always a good idea to have our rescue systems, but
also, when we upgrade the kernels to keep the previous kernels
so we can go through and have a fallback system that we can use
in the event of disasters.
Now as I log on then as my Vagrant user with the password that we've just set,
we're able now to gain our root privileges. And then quite
simply, it's a matter of creating a new RAM disk, so the
mkinitrd command, or the dracut command, ‑‑force because it will
be looking for a ramfs to update,
there won't be one, and we're going through and specifying the
name of the file that we want to create.
So this is where GRUB will be pointing to,
so /boot/initramfs‑, then the release of our kernel,
.img. Don't forget the .img at the end.
And we're building it based on, again, our current running kernel. We
booted to the rescue system that was for our running kernel, so we
should have exactly the same kernel release. So we can then go through
and specify for the kernel based on this release. Now after a little
while, that will have created, so I'm going to just power off my
system. I'll start it up again from Vagrant. But with the system then
shut down,
I can bring it up with Vagrant and then connect using my standard vagrant
ssh command, and I'm back up and running. And of course, listing the boot
directory, I'm going to have the four initialization RAM filesystems. The
one that we deleted has been recreated,
plus the three others that we were working with.
But there you go.
We've recovered from a little bit of a panic attack, but let's make sure we summarize what we've looked at regarding booting Linux.