Sometimes while booting, it goes wrong.
Now, what can you do?
Well, first, you can boot into one
of the troubleshooting targets, like systemd.unit
is emergency.target or systemd.unit
is rescue.target, just the way we have just seen.
It's also possible to use init is bin bash as an alternative.
That dives in before you even get to your systemd.
But if a bootloader no longer shows,
a rescue disk can be used.
Now, the good news is that normally,
any Linux installation disk can be used as a rescue disk.
Before showing you, let me draw an overview
of the different options of what you can
use in which specific case.
So before we explore the boot procedure,
what can you do if things go wrong?
Well, if you don't see grub at all, there's only one option,
and that is going to be the rescue disk.
So you need to boot from an external media
to get access to your system.
If you do see grub, but your kernel doesn't load,
there's another option, and that is the rescue kernel.
The rescue kernel is offered in the grub boot menu,
and it offers an alternative.
Then your kernel and your init ramfs are loading,
and you can jump into the system
directly after loading the init ramfs.
On Red Hat, there is an option rd.break,
but that option is Red Hat only, and for that reason,
not so very powerful.
On generic Linux, you can also use the boot argument,
init is slash bin slash bash.
So both of these options are added as kernel arguments,
and the most generic kernel argument is init is bin bash.
It skips your systemd, it throws you a bash shell,
and you don't even have to provide a root user password.
Once systemd is loaded, things are getting more complicated.
So you would use systemd.unit equals emergency.target,
and this emergency target will get you in right
before early boot.
So you really have a minimum of services
which maximizes the chance of you getting back
in a normal operational state.
Now, in troubleshooting, it's always good to get into
as much of your system as you can,
and that is why there is also the rescue target.
And a rescue target is bringing you all the way
up to the early boot,
you just don't load the services here.
So these are your different options for troubleshooting,
and in most cases, using one of them
will get you back into your system.
All right, let me demonstrate,
and I'm going to demonstrate how you can use a rescue disk.
In order to do so, I need to connect my disk,
and I'm doing that in VMware.
Your virtualization software is where you present your disk,
and normally, it will find the disk
that you have used for installation,
as you can see right here, grayed out,
and when you use connect CD, DVD,
it should be connected.
And then you need to make sure that you boot from it.
Now, there are different ways to boot
into your specific environment.
I am going to use sudo minus I,
and I'm going to show you the EFI boot manager.
So EFI boot manager is showing me what?
Showing me all these different options,
and I want to boot from option number one.
So EFI boot MGR minus N0001,
and then I'm going to reboot,
and as you can see, I'm booting from my rescue disk.
So the alternative of using EFI boot manager
is to press escape at the right moment,
and let's face it, the reason you are going to a rescue disk
is probably because you don't get
into a fully operational environment anymore,
and then you need to press escape
at the right moment while booting,
or F2, F10, or F12.
The key that you are using depends
on the hardware that you are using.
Now, for rescue disk,
the option that we need is troubleshooting.
So in troubleshooting,
you select a rescue CentOS stream system,
in case it is CentOS, of course,
with the other rescue disks, Ubuntu and Red Hat,
and other distributions are offering similar solutions.
So the idea is that you are going to load
your operating system from the installation disk,
and then while booting from the installation disk,
you are going to try to address your hard disk.
Some distributions require you
to do a completely manual procedure
where you need to find your information.
Some distributions are making it a lot easier for you.
Now, I want to show you in a generic way
how you can access your hard disk
from the rescue disk.
And there, well,
the rest of the troubleshooting would follow.
Let's not dive into that.
Let's just see if we can access the hard disk again.
So here, CentOS is telling me what it is doing.
It's attempting to find the installation
and mount it on the directory, mnt-sysroot.
I don't want to do that.
I want to do option number three,
because not all distributors are giving
a nice option like this.
Option number three, that is where you go to a shell,
and that is where you can try to find your hardware.
So LSBLK is what I'm using, and what do I see?
I see my block devices.
So that's good news already to start with.
So I have my SCA1, 2, and 3.
Now, I'm going to use VGScan.
VGScan is LVM Volume Group Scan.
This is going to try to find LVM information
on your system.
Now, when I use LSBLK again, I still see the same thing.
But when I use VGS, I see my volume group.
And when I use LVS, I see my logical volumes.
And with that, there is my root logical volume.
So let's try to give it a mount dev cs slash root on slash mnt.
That's a temporary mount.
And, uh-oh, we have a cannot lookup block device.
DMessage may have more information about it.
What is going on?
It doesn't know about dev cs root yet.
Now, if we get back to LSBLK, that's
understandable because LSBLK can't show it as well.
And if we use LS on slash dev slash cs,
we see no such root or directory.
And also, LS on dev mapper is showing no LVM information.
Now, what do we need to do next?
We need LVChange.
Now, it's maybe wise to use LVChange minus minus help
to find out how to use it.
And here in the help, we can see that, oh my goodness,
there are so many options.
And in this so many options, I'm looking for the minus A.
Minus A is activate.
And that has a Y. And we need the volume group name.
Aha.
So LVChange cs minus A Y.
That's what I'm looking at.
And now I'm using LSBLK again.
And what do we see?
We see the LVM logical volumes.
Because of the VG scan first and the LVChange volume group
name minus A Y, I now have my volume group available.
And I should be able to mount dev cs root on MNT.
And now I'm in my MNT directory.
And from there, I can continue working
and try to recover my system.
Now that we are here, let's do the next step as well.
And the next step would be that we make the other file systems
available as well.
My problem is that the proc file system in MNT is empty.
The sys file system is empty.
And the dev file system is empty.
But we do have these guys on the rescue system.
Now the thing with these file systems
is that they are automatically created while booting.
And I need to make sure that the file systems on the rescue
system are present in my recovered system.
And in order to do so, I'm using mount minus O bind.
That's a bind mount.
And in a bind mount, you can connect a directory
to another directory.
I do it for proc on MNT proc.
I do that for dev on MNT dev.
And I do that for sys on MNT sys.
And there we are a bit further.
Now I'm going to use chroot on slash MNT.
And that brings me into the root of my normal operational
system.
I can even write.
And that means that I can do my troubleshooting commands.
Let's just try one common troubleshooting command
to reset the root user password.
Does that work?
That's the only thing I care about.
And yes, it works.
So this concludes my demo about rescuing.
Final step, use exit to exit the chroot environment.
And use reboot to reboot in your normal operational system.