By default, grub on Fedora Linux use rhgb boot (or kernel?) option, what does this do? This is a kernel parameter, right? Why I can’t find this from the Git repository of Linux?
cat /proc/cmdline
BOOT_IMAGE=... rhgb ...
I searched this and apparantely rhgb refer to Red Hat Graphical Boot, but that component is replaced with Plymouth for years now.
Information from 20 years ago 
:
What is "rhgb" on the grub, kernel line?
rhgb = redhat graphical boot - This is a GUI mode booting screen with
most of the information hidden while the user sees a rotating activity
icon spining and brief information as to what the computer is doing.quiet = hides the majority of boot messages before rhgb starts. These
are supposed to make the common user more comfortable. They get alarmed
about seeing the kernel and initializing messages, so they hide them for
their comfort.
I read that, but Red Hat Graphical Boot doesnt exist anymore, so what that option does today?
And why I can’t find rhgb from source code of Linux? rhgb is kernel parameter, right?
Although rhgb is being passed on the kernel command line, as it isn’t a valid kernel option the kernel will ignore it but make it available for user space programs to respond to - which is why it then appears in /proc/cmdline
In this case:
In order for the configured default plymouth theme to be loaded during boot, the option ‘splash’ (or ‘rhgb’ for backward compatibility with the RHGB boot splash) must be provided at the kernel command line. With this command line option, plymouth will default to showing detailed boot output.
(From the plymouth manual page - run “man 8 plymouth” in a terminal on a Fedora machine or online at https://linux.die.net/man/8/plymouth )
So you need to have “splash” or “rhgb” on that commandline for plymouth to activate, and I suspect Fedora has stuck with rhgb as inertia - it still works, so why change it?
Just to make sure, entirely “linux /boot/vmlinuz-linux root=UUID=0a3407de-014b-458b-b5c1-848e92a327a3 rw quiet splash” string is passed to the kernel, but the kernel ignore invalid options. The kernel store the whole string in /proc/cmdline and other user space programs read them from there. Is that right?
Then to questions:
splash string for itself it will broke excepted behaviour; if someone have put that to the grub options for certain userland program(s) and not for the kernel.Pretty much. I think technically it’s everything after “/boot/vmlinuz-linux” that would be passed as an argument in that example.
I can’t answer the “why” question - you’ll need someone with much more insight into the history than me
I don’t know of any general documentation for these extra flags - I suspect you have to look at the manual pages for the individual software involved. On that note you might find the systemd list of parameters interesting/useful - see the kernel command line section of the systemd man page.
If you do find a list of common parameters somewhere, I’d be curious to see what else is on it!
In this case I’m pretty sure it’s plymouthd that handles the splash screen itself, and a brief search turns up https://gitlab.freedesktop.org/plymouth/plymouth/-/blob/main/src/main.c?ref_type=heads#L888 if you feel like digging deeper into how it’s handling things.
Thank you for answers. I maybe repeat myself (sorry…), but a few question still comes my mind.
Okay, so not linux part, but everything after it. Anyway the core of my question, arguments that are passed to kernel as cmdline will be readable to all userland programs?
All cmdline arguments that are not kernel options are passed by the kernel to userland for use there.
An example from my dmesg output
[ 0.034257] Unknown kernel command line parameters "BOOT_IMAGE=(hd5,gpt2)/vmlinuz-6.7.5-200.fc39.x86_64", will be passed to user space.
Okay, thank you
I have one program idea, so the last question: I see dmesg (and proc filesystem, right?) passes parameters to userland, but that is error message. Is it stable API or are there any syscall etc. interface that I should use?
Userland reads /proc/cmdline to get the command line. systemd does that, plymouth does that. And some systemd service files reads the command line.
Most of the message in dmesg are informational messages and not errors or warnings. To see the error messages only, run journalctl -b -p err.
Since that has been used during boot for many years I don’t understand your concern about stability nor reliability of the API. The system already handles it so nothing is needed from the user.
That is not an error message, but informational in nature, simply telling the user exactly what is being passed on.
Two opposing opinions. Would there be some docs about which one (cmdline file or dmesg) userland should use?
Wait, your dmesg says:
[ 0.034257] Unknown kernel command line parameters “BOOT_IMAGE=(hd5,gpt2)/vmlinuz-6.7.5-200.fc39.x86_64”, will be passed to user space.
This dmesg is notification to the user that the kernel is passed command line parameters to userland. The question is, through what it does that?
Do you consider these 2 comments to be conflicting? They are the same with one being more general in nature.
If you really want to know, read the source code, for example the plymouth code.
static const char *
ply_get_kernel_command_line (void)
{
const char *remaining_command_line;
char *key;
int fd;
if (kernel_command_line_is_set)
return kernel_command_line;
ply_trace ("opening /proc/cmdline");
fd = open ("/proc/cmdline", O_RDONLY);
if (fd < 0) {
ply_trace ("couldn't open it: %m");
return NULL;
}
ply_trace ("reading kernel command line");
if (read (fd, kernel_command_line, sizeof(kernel_command_line) - 1) < 0) {
ply_trace ("couldn't read it: %m");
close (fd);
return NULL;
}
... etc
I questioned using dmesg as API for the cmdline and Villy answered:
In other hand, you said:
Your comment as a whole suggest that dmesg is reliable API, but Villy says that userland reads /proc/filesystem to get cmdline. So how is it? Is the right way read /proc/cmdline or dmesg? I also want to repoint this quote from the example dmesg: Unknown kernel command line parameters "BOOT_IMAGE=(hd5,gpt2)/vmlinuz-6.7.5-200.fc39.x86_64", will be passed to user space. To where dmesg refer by saying “passed to user”? If to the message itself the wording is weird I think.
I think you misunderstood.
dmesg is not an API. It is a tool for reading the kernel message buffer and nothing more. It has nothing to do with altering anything, merely reading the outputs and displaying that in human readable form.
The way the kernel passes arguments into user space is what I referred to. What I posted was one example of an information message that tells the user what was done by the kernel as related to the cmdline arguments.
@vekruse provided some examples of apps in userspace that use the cmdline passed in by the kernel to obtain necessary values for configuring the system, but dmesg was not one of them.
Sorry 
, I misunderstood your comments. Now I get what you meant.
@vekruse thank you for the good example. It clearly shows how plymouth reads /proc/cmdline file.
I swear, this is the last question:
dmesg says “Unknown kernel command line parameters … will be passed to user space.”. Does dmesg mean /proc/cmdline file by using wording “passed to user space”? Or is there something else way to passing them? And does /proc/cmdline contain a whole string that the bootloader passes to the kernel or only the parts that the kernel ignoring?