Hello Friends
For Fedora Workstation and Server, when the OS itself is being installed
For example
sudo command is mandatory)Therefore what is the official philosophy in Fedora?
Thank You
It’s down to personal choice. Personally, I don’t create a root user on my home / personal devices, but I still create a root user for remote servers. Though I disable password logins on those servers and use keys instead.
The root user always exists. The only question is whether you want to set a password for the root account. I do because it can be useful in some cases where problems occur while booting the system. If you do not have a root password set, you will not be able to get into the recovery console.
The main reason for not setting one was that, once upon a time, sshd defaulted to allowing remote password-based sign-ins with the root account. That has not been true for a long time though, so you shouldn’t have to worry about that, unless perhaps you’ve been upgrading your Fedora Linux for well over a decade. (Make sure PermitRootLogin is either commented out or set to something like prohibit-password or without-password.)
You can configure a ubuntu/debian system to allow root login with password and ssh . It is not encouraged in favour of sudo.
There is no need to set up a root password on desktop systems in advance, just to be prepared to enter the recovery console if something would go wrong, as that can be done when needed.
There really need to be a solution to that problem when the official policy is not to set a password for the root account.
Mike just linked the solution in his post above.
That is not a solution. You need to be able to access the emergency shell to analyze the log files, and perhaps to run file system repairs. Once you need to reboot in a special way to set the root password, the log files is no longer available. These log files are only held in memory until the system is properly booted and the normal login is enabled.
The instructions you shared will work for resetting the root password. However, if you really need to get into the emergency shell (e.g., for filesystem repairs), you would also need to run dracut -f to update the passwd database in the initramfs. Paradoxically though, none of that is likely to be possible if you need to repair your filesystem.
$ sudo lsinitrd | grep passwd
-rw-r--r-- 1 root root 170 Nov 26 2024 etc/passwd
The Dracut emergency shell (accessed via rd.break=pre-mount) is also a very useful place for ZFS users to clone and swap around their root volumes from time to time.
Can’t that be performed by booting with a live ISO and chroot-ing?
In most cases, yes (though getting all the chroot mounts right can be a bit of a Herculean task for most people). There are some cases and environments, however, where using a Live image is not an option. For example, if a sysadmin needs to do repairs remotely.[1]
Many servers support remote connections to their serial port which can be used to get into the Dracut emergency shell if the root password is set. ↩︎
I would say not because you need not remember 2 separate passwords for your PC.
(Considering you avoid setting same passwords for the home user and root user, terrible idea)
Right, that’s why I was suggesting the linked Quick Docs article for desktop systems only.
It would be interesting to compare the advantages vs risks of enabling root on such systems. Personally I haven’t met any scenario on desktop systems with local access where root was needed.
Every time you use sudo, you use root. It’s just a question of how you access root – via /usr/bin/sudo or via /usr/bin/login.
I don’t believe there is much added risk to setting root’s password as long as remote access is disabled. Arguably, it would be better to have a separate password for root versus using sudo which allows accessing the root account with the same password as the unprivileged user.
Edit: 2FA might be a factor to consider. If you enable 2FA for your normal user, but not your root account, would you really have 2FA enabled?
You could probably call that 2.5FA. In addition to knowing the first and second factors, the account name must be known in order to gain privileged access. 
In a round-about way, that is sort of my point. Do you really gain anything security wise by keeping the account name semi hidden? As long as you have a decent pass phrase set on your root account, I don’t think there is a big gain in jumping through the extra hoop of pre-authenticating with another account. (The 2FA on the root account is a definite improvement. I’m just not sure about what is really gained with the indirect authentication.)
The difference is accountability. This is a relevant on systems with multiple users, some of which have administrative tasks to do on the system. With sudo, you don’t need to give the root password to every administrator, because they can use their own individual password. Also, with sudo you can configure exactly which privileged command may be performed by each user rather than general super user access.
Now, with single user systems where the user is also administrater, this is less of an issue.
What you could do: Create a password for root, write it on a piece of paper and store it in a sealed envelope, and hide this envelope where only you can find it. Then, when you need it you know where to find it.
Really huge thanks to all for each reply and thought
I am going to read each one soon as I can.
A cold beer to all 
Hi All
I read that if your system refuses to boot and let you log on because the root account doesn’t have a password, what you can do is: -
I have never had to try it, but it came from a trusted source.
What if the Live image doesn’t have the right drivers or software to access your filesystem (e.g. expensive RAID cards and/or non-standard filesystems like ZFS)?