Description of problem: I'm teaching Linux and need being able to reset the root password in case some students don't set it accordingly to my will. So I can always recover the access to the computers without the need of reinstalling the complete OS. Changing it with init=/bin/bash always ever worked on any distributions I ever used: slackware, gentoo, archlinux, RedHat 5 and 6, SLES 10 and 11, Ubuntu, Debian. Fedora 20 is the first distribution I known that don't behave the same way (I didn't tested previous Fedora). Version-Release number of selected component (if applicable): Fedora 20 64 bits on x86_64. Latest versions of all components from stable repositories as of the date of the 3rd of April 2014. How reproducible: Steps to Reproduce: 1. At boot time, edit grub and add to the kernel options init=/bin/bash 2. After booting, remount the root filesystem in rw: mount -o remount,rw / 3. Change the root password with passwd: passwd root 4. Enter the new password 5. reboot the system in default runlevel 6. The boot process hangs and Fedora can't boot anymore Actual results: The system is corrupted in some way and can't boot anymore. Expected results: The root password is changed and the system is not corrupted. Additional info: Currently, I don't know how to reset the root password if I don't know it with Fedora 20. Starting with kernl option 1 or s asks for the root password to get access to the shell. In RHEL 5 and 6, runlevel 1 doesn't asks for the root password, but according to another bug request (628929) you don't want to change that behavior. As the options with init=/bin/bash doesn't work either, I don't see any other options.
Unfortunately I have no idea what could cause the breakage. Does the boot breakage happen also if you avoid the step 4 above? I do not think pam is the culprit here.
Hello Tomas, I don't think either pam is the culprit but I really don't know what it can be and so I had to choose a component. I read in a forum that another user had the same problem but I can't find it again... The user talked about policykit but it was only a guess. A fact: in text mode, the last thing which is printed on the screen when booting after the manipulation is : "Started Authorization Manager." Then it hangs.
I didn't tried without changing the password since it is the point ;)
I want to add, but maybe it is out of topic: in my knowledge, giving the argument init=... means that the kernel, after booting, start the PID 0 to the executable according to the given path. When I set init=/bin/bash in Fedora 20, I can see a lot of things printed on the screen, even the progress bar for a short time in quiet mode, before going to the shell. So it should means that something is still started between the kernel and /bin/bash and I don't understand why and how. Usually, on more traditional Linux (without systemd), straight after the kernel logs, I get the shell and it's really fast. So I have to say that I feel lost in my knowledge with systemd (if it is the cause) because a lot of things don't behave like before anymore. And I feel lost in face of the root changing password problem because I don't understand how it really works, what I usually ever has been feeling since I'm on Linux.
I can share your sentiment that transparency in various things in Linux OS related to system and service startup deteriorated with introduction of systemd and other related things. However Fedora Bugzilla is probably not a place where this problem can be solved.
Of course Bugzilla is not the place talking about systemd ;) But the root password change that fails should be, in my opinion.
Have you tried for example booting with selinux=0 ?
Hello Tomas, I just tried with selinux=0 but the behavior didn't changed. If you're not the right person for managing this bug request, can you assign it to the right team please? You have to understand that this is a stop-go for me. I can't have as main system installed on my students'desktop a one for which I can't modify the root password if necessary. It is a fact from my point of view. From the point of view of Fedora, it is a behavior different from any other known distribution, so I think the right team at Fedora should be concerned about it. I just found a comment about the same problem that was already there on Fedora 19: 2nd comment of the first post: http://unix.stackexchange.com/questions/85558/how-to-reset-forgotten-root-password-in-fedora-19-from-grub "I just encountered an issue with FC19 root password reset. As OP mentions, single-user mode asks for the root password. Further issue - using the 'init=/bin/sh', 'mount -o remount,rw /', 'passwd' method - It not only failed to update the root password properly, but also broke something (I think in policykit) which kept the windowmanager from fully loading on subsequent reboots. Totally baffled about how to fix it now without a reinstall." Best regards,
Tentatively reassigning to polkit.
"Started ..." means that the start has finished, so that's not pointing to polkit AFAICT. We do need more information; "the boot process hangs" is just not enough to go on. I'll try reproducing this locally, but getting data from the actual problematic system would be useful as well. https://fedoraproject.org/wiki/How_to_debug_Systemd_problems has some starting points. Also, in single-user mode, (restorecon -vr /) might be useful, both as a debugging step, and as a possible workaround; if you do run this, please make sure to capture the output.
Tried to reproduce this... What happens is that with init=/bin/bash, selinux is disabled, causing passwd(1) to change the context of /etc/shadow to file_t. After reboot, naturally unix_chkpwd, accounts-daemon and the like are prevented from accessing /etc/shadow , and things fall apart. (It's still possible to switch to a different console, but not log in.) (Rebooting into permissive mode and using it to initiate a relabel works around the problem.) Considering that using init=/bin/sh is the documented procedure for replacing root's password in https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/System_Administrators_Guide/ch22s06.html reassigning to systemd: either this procedure is supposed to work, or the documentation will need changing.
So, comment #1 talks about system hanging... Dunno, everything is possible, but wrong selinux context of /etc/shadow does not seem to have this effect. It is true that relabel is necessary to restore the context on /etc/shadow. It probably is required for *any* file that is touched in init=/bin/sh mode, so it seems like a thing to instruct people to do generally. I'll reassign this to the docs team at redhat.
@documentation: It seem that it is necessary to do a selinux relabel after running in init=/bin/sh mode to change password. Otherwise, login might be disabled because /etc/shadow has wrong selinux mode. In https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/System_Administrators_Guide/ch22s06.html, please add another step between steps 6 and 7: touch /.autorelabel
I went ahead and modified https://fedoraproject.org/w/index.php?title=How_to_reset_a_root_password too.
I just tested the procedure in the updated wiki (touch /.autorelabel after changing the password) and it's working ;)
Thank you all for raising and working on this bug. Hello Eliska Can you add the step as per comment 13 ? Thank you
Zbigniew Jędrzejewski-Szmek, the wiki page for Fedora should be re-written a little because the procedure is not clear: https://fedoraproject.org/w/index.php?title=How_to_reset_a_root_password It is not clear because of this warning (below the GRUB 2 section): Rescue Mode changes This method should work to change the root passwords up until Fedora 18, i.e. after the system finishes booting you would get a root prompt (#) which you can use to change the root password. However starting from F19 booting to the rescue mode (single user mode) will prompt you to enter the root password (this is a change in systemd upstream, now booting to the rescue target (mode) invokes /sbin/sulogin which will prompt you to enter the root password to login); this obviously means you can't use this method to reset the root password, instead you can use an installation CD/DVD to reset the root password. So, the rest of the procedure below taht statement, including the touch /.autorelabel that you added, is intended to be applied for Fedora up to version 18, which is started in single user mode (not init=/bin/bash), and so, don't need a selinux context relabel. Instead, you should reorganize the procedure in function of the Fedora version 1) From Fedora X to X : GRUB LEGACY 2) From Fedora X to 18 : GRUB 2 in single mode 3) From Fedora 19: GRUB 2 with init=/bin/bash and with selinux relabel
Hello My colleague eslobodo confirms that the procedure works fine on RHEL 7 if SELinux is disabled. If SELinux is enabled, however, the system won't boot. Running touch /.autorelablel as suggested in this bug solves it. I need to update Fedora 20 System Administration Guide. Thank you
(In reply to sylock from comment #18) > Zbigniew Jędrzejewski-Szmek, the wiki page for Fedora should be re-written a > little because the procedure is not clear: > https://fedoraproject.org/w/index.php?title=How_to_reset_a_root_password Yeah, using rescue mode for password changes is pointless in F19+. I've rewritten the section describing only init=/bin/bash, as this should work on all machines.
Please try this: 1. Start the system and, on the GRUB 2 boot screen, press the e key for edit. 2. Remove the rhgb and quiet parameters from the end, or near the end, of the linux16 line, or linuxefi on UEFI systems. Press Ctrl+a and Ctrl+e to jump to the start and end of the line, respectively. On some systems, Home and End might also work. Important The rhgb and quiet parameters must be removed in order to enable system messages. 3. Add the following parameter at the end of the linux16 line, or linuxefi on UEFI systems: init=/bin/sh The Linux kernel will run the /bin/sh shell rather than the system init daemon. Therefore, some functions may be limited or missing. 4. Press Ctrl+x to boot the system with the parameter. The shell prompt appears. 5. To preserve the SELinux context of the files that are to be modified, load the SELinux policy into the kernel. Use the -i option as this is the first time the policy is being loaded since boot: ~]# /usr/sbin/load_policy -i 6. The file system is mounted read-only. You will not be allowed to change the password if the file system is not writable. Remount the file system as writable: ~]# mount -o remount, rw / 7. Run the passwd command and follow the instructions displayed on the command line to change the root password. Note that if the system is not writable, the passwd tool fails with the following error: Authentication token manipulation error 8. Remount the file system as read only: ~]# mount -o remount, ro / 9. Run the exec /sbin/init command to resume the initialization and finish the system boot. Running the exec command with another command specified replaces the shell and creates a new process; init in this case. ----------------------------------------------------------------------- Thank you
I have a fedora 20 install, more or less default on a laptop + encrypted disk. I tried the above instructions in all possible variations and none of them worked. Eventually I found this http://tower.voleg.info/fc19_boot_grub2_systemd.html and the key comment was to use rd.break instead of single; init=/bin/sh or all the other variants. * interrupt boot * edit boot entry * delete "silent" and "rhgb" * add "rc.break" * ctrl-x to execute * wait for boot (type password for disk encryption when asked; n.b. sometimes prompt gets overwritten) * mount -o rw,remount /sysroot * chroot /sysroot * passwd * give new password twice * touch /.autorelabel * sync * exit
Thank you for testing that.
Michaël: According to the link you mentionned: http://tower.voleg.info/fc19_boot_grub2_systemd.html It is rd.break and not rc.break Here I found some references to rd.break: http://fedoraproject.org/wiki/How_to_debug_Dracut_problems#Additional_dracut_boot_parameters Do you confirm it?
Hello Re comment 24: Yes, its rd.break Re comment 23: I tested this rd.break procedure on Fedora 20. It seemed to hang during the boot after entering "exit" twice. When I forced a reboot it then did the SELinux auto relabel tasks. I was aware that the rd.break method was required for certain virtual systems, but did not realise it is also required for encrypted systems. I'll ask around for any further useful info. Regards Stephen
(In reply to Stephen Wadeley from comment #25) > Re comment 23: > I tested this rd.break procedure on Fedora 20. It seemed to hang during the > boot after entering "exit" twice. When I forced a reboot it then did the > SELinux auto relabel tasks. > That "hang" was in fact a constantly updating message to say: (1 of 2) A start job is running for dev-mapper-luks (2 of 2) A start job is running for Crytography Setup for luks-<UUID> If you press and hold the backspace key you can see the prompt. Just ignore it and enter the password.
(In reply to Stephen Wadeley from comment #26) > That "hang" was in fact a constantly updating message to say: That's unfortunate. It was (at least partially) fixed in http://cgit.freedesktop.org/systemd/systemd/commit/?id=e46b13c8c7, but this hasn't been backported to F20.
Hello After lots of testing, I decided to drop the init=bin/sh method in favour of the boot from installation disk or image method and have the rd.break method as an alternative for those without boot media. Please see: http://docs.fedoraproject.org/en-US/Fedora/21/html/System_Administrators_Guide/sec-Changing_and_Resetting_the_Root_Password.html Thank you