AI Mode conversation: CentOS 7 Manual Pages Access in Browser

You said: there are some tutorial, when forget root password, append "single init=/bin/bash" to linux16, it also worrks, it is different from what you said

12:29 am

AI Mode reply for there are some tutorial, when forget root password, append "single init=/bin/bash" to linux16, it also worrks, it is different from what you said

You are completely right, and that method absolutely works!

The reason it seems different from what I described is that using init=/bin/bash is a completely separate strategy for breaking into a system. While both methods give you a root shell to reset a password, they hijack the Linux boot engine at two different stages of the timeline.

Here is the exact difference between how they work and why both exist:

The Technical Difference: The Timeline

text

 [Power On] ──> [GRUB Menu] ──> [initramfs / RAM Disk] ──> [Real Storage Root Mounted] ──> [Systemd / PID 1 Startup]
                                       │                                                       │
                                       ▼                                                       ▼
                         Method 1: "rd.break" halts here                        Method 2: "init=/bin/bash" halts here

Use code with caution.

1. The rd.break Method (Earlier Stage)

Where it stops: It halts the system inside the temporary RAM disk (initramfs) before the real operating system root filesystem is fully mounted or handed over.
State of the system: Highly safe, minimal, and pristine. The real OS hasn't loaded any configurations or custom storage drivers yet.
Why /sysroot is needed: Because it stops so early, your real hard drive is just sitting in a temporary holding folder named /sysroot. You have to manually chroot into it.

2. The init=/bin/bash Method (Later Stage)

Where it stops: The kernel successfully passes control over to your real hard drive. Normally, the kernel starts systemd (Process ID 1) to fire up services and the login screen. By adding init=/bin/bash, you tell the kernel: "Do not start systemd. Start a raw bash shell as Process ID 1 instead."
State of the system: Your real filesystem is already mounted as your root (/) directory. You are already sitting inside your actual operating system files.
Why it feels different: You do not need to type /sysroot or use chroot at all! You are already "inside" the real system.

Comparison of the Password Reset Workflow

Because of where they stop in the timeline, the commands you type are slightly different:

Feature	Using `rd.break`	Using `init=/bin/bash`
Remount Command	`mount -o remount,rw /sysroot`	`mount -o remount,rw /`
Chroot Needed?	Yes (`chroot /sysroot`)	No (You are already at `/`)
Password Command	`passwd root`	`passwd root`
SELinux Fix	`touch /.autorelabel`	`touch /.autorelabel`
Reboot Method	Type `exit` twice	Must force it: `exec /sbin/init` or hard reboot

Why does the tutorial add single?

In the parameter string single init=/bin/bash, the word single is actually redundant and ignored by the kernel. The init=/bin/bash flag is so powerful that it overrides everything else, completely bypassing all standard runlevels (including single-user mode) to force the shell open immediately.

Summary: Which one should you use?

init=/bin/bash is faster and easier to type because it saves you from having to use the chroot step.
rd.break is the official Red Hat/CentOS recommended standard because it isolates the recovery process inside the RAM disk, avoiding potential filesystem initialization bugs or systemd lockups on complex corporate storage arrays.

Are you currently practicing these password recovery techniques on a virtual machine or a live production server? If you'd like, I can show you how to password-protect your GRUB menu so that unauthorized users cannot use these tricks to break into your system.