Bug 1084400

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