I was manually changing the /etc/passwd and /etc/group file since my users were incorrectly assigned UID/GIDs, I manually corrected the UID/GID in /home for each user, rebooted and noticed that I would get a hang just after udev.
I tried ^D and noticed that something complaining about /var/run/anacron was not removable and that user anacron did not exist, and the system would then shutdown and reboot.
On rebooting, I stopped grub and added -s and single user boot was successful.
In single user, I checked what I could and finding nothing, and proceeded with ^D and noticed several things:
1) There was a message to the effect that several important users (root, anacron, and others) was not able to be retrieved from dbus's database. The message appears too fast for me to write it all down exactly.
2) Repeated messages of: "Unknown username "root" in message bus configuration file, for each important users.
Is there some way to repair the dbus database?
Thanks! Dan
Dan Thurman wrote:
I was manually changing the /etc/passwd and /etc/group file since my users were incorrectly assigned UID/GIDs, I manually corrected the UID/GID in /home for each user, rebooted and noticed that I would get a hang just after udev.
I tried ^D and noticed that something complaining about /var/run/anacron was not removable and that user anacron did not exist, and the system would then shutdown and reboot.
On rebooting, I stopped grub and added -s and single user boot was successful.
In single user, I checked what I could and finding nothing, and proceeded with ^D and noticed several things:
There was a message to the effect that several important users (root, anacron, and others) was not able to be retrieved from dbus's database. The message appears too fast for me to write it all down exactly.
Repeated messages of: "Unknown username "root" in message bus configuration file, for each important users.
Is there some way to repair the dbus database?
Thanks! Dan
I forgot to add:
3) The system fails to start dbus, anacron, and a couple of other services but continues on to the text login prompt. Attempts login as root or any normal user will fail.
Dan
Dan Thurman wrote:
Dan Thurman wrote:
I was manually changing the /etc/passwd and /etc/group file since my users were incorrectly assigned UID/GIDs, I manually corrected the UID/GID in /home for each user, rebooted and noticed that I would get a hang just after udev.
I tried ^D and noticed that something complaining about /var/run/anacron was not removable and that user anacron did not exist, and the system would then shutdown and reboot.
On rebooting, I stopped grub and added -s and single user boot was successful.
In single user, I checked what I could and finding nothing, and proceeded with ^D and noticed several things:
There was a message to the effect that several important users (root, anacron, and others) was not able to be retrieved from dbus's database. The message appears too fast for me to write it all down exactly.
Repeated messages of: "Unknown username "root" in message bus configuration file, for each important users.
Is there some way to repair the dbus database?
Thanks! Dan
I forgot to add:
- The system fails to start dbus, anacron, and a couple of other services but continues on to the text login prompt. Attempts login as root or any normal user will fail.
Dan
Um... interesting....
When I added selinix=0 to the grub command line for the kernel, I was able to get my qui and logins to work.... seems there is something going on with SELinux and dbus....
Can someone help me fix this issue?
Should I remove and reinstall SELinux/DBUS? I will wait until I get advice here before attempting this step....
Thanks again, Dan
Dan Thurman wrote:
Dan Thurman wrote:
Dan Thurman wrote:
I was manually changing the /etc/passwd and /etc/group file since my users were incorrectly assigned UID/GIDs, I manually corrected the UID/GID in /home for each user, rebooted and noticed that I would get a hang just after udev.
I tried ^D and noticed that something complaining about /var/run/anacron was not removable and that user anacron did not exist, and the system would then shutdown and reboot.
On rebooting, I stopped grub and added -s and single user boot was successful.
In single user, I checked what I could and finding nothing, and proceeded with ^D and noticed several things:
There was a message to the effect that several important users (root, anacron, and others) was not able to be retrieved from dbus's database. The message appears too fast for me to write it all down exactly.
Repeated messages of: "Unknown username "root" in message bus configuration file, for each important users.
Is there some way to repair the dbus database?
Thanks! Dan
I forgot to add:
- The system fails to start dbus, anacron, and a couple of other services but continues on to the text login prompt. Attempts login as root or any normal user will fail.
Dan
Um... interesting....
When I added selinix=0 to the grub command line for the kernel, I was able to get my qui and logins to work.... seems there is something going on with SELinux and dbus....
Can someone help me fix this issue?
Should I remove and reinstall SELinux/DBUS? I will wait until I get advice here before attempting this step....
Thanks again, Dan
Ok, I solved this problem but it is interesting to note...
1) Boot in single user mode 2) touch /.autorelabel 3) reboot 4) When grub comes up, stop and edit the kernel line and add -s (single user mode) 5) Booting in single user mode ensures that selinux will be able to relabel the files. If you do not boot in single user mode, then normal booting will not allow selinx to work and to relabel these files!
Dan
Dan Thurman wrote:
I was manually changing the /etc/passwd and /etc/group file since my users were incorrectly assigned UID/GIDs, I manually corrected the UID/GID in /home for each user, rebooted and noticed that I would get a hang just after udev.
Aren't we meant to use vipw and vigr to edit these files? On editing from vigr one is asked to run "vigr -s" to edit the shadow file.
Timothy Murphy wrote:
Dan Thurman wrote:
I was manually changing the /etc/passwd and /etc/group file since my users were incorrectly assigned UID/GIDs, I manually corrected the UID/GID in /home for each user, rebooted and noticed that I would get a hang just after udev.
Aren't we meant to use vipw and vigr to edit these files? On editing from vigr one is asked to run "vigr -s" to edit the shadow file.
Interesting! I had NO IDEA if this is the case, being a user of older Unix systems. Thanks for the tip, I'll know better now!
Dan
On Sun, 2008-10-26 at 14:16 -0700, Dan Thurman wrote:
Timothy Murphy wrote:
Dan Thurman wrote:
I was manually changing the /etc/passwd and /etc/group file since my users were incorrectly assigned UID/GIDs, I manually corrected the UID/GID in /home for each user, rebooted and noticed that I would get a hang just after udev.
Aren't we meant to use vipw and vigr to edit these files? On editing from vigr one is asked to run "vigr -s" to edit the shadow file.
Interesting! I had NO IDEA if this is the case, being a user of older Unix systems. Thanks for the tip, I'll know better now!
IIRC vipw dates back to (at least) 4.0bsd, over 25 years ago.
poc
Patrick O'Callaghan wrote:
On Sun, 2008-10-26 at 14:16 -0700, Dan Thurman wrote:
Timothy Murphy wrote:
Dan Thurman wrote:
I was manually changing the /etc/passwd and /etc/group file since my users were incorrectly assigned UID/GIDs, I manually corrected the UID/GID in /home for each user, rebooted and noticed that I would get a hang just after udev.
Aren't we meant to use vipw and vigr to edit these files? On editing from vigr one is asked to run "vigr -s" to edit the shadow file.
Interesting! I had NO IDEA if this is the case, being a user of older Unix systems. Thanks for the tip, I'll know better now!
IIRC vipw dates back to (at least) 4.0bsd, over 25 years ago.
poc
Also, if you have an editor you would rather use for editing, instead of VI, you can set EDITOR to the editor of your choice. Both vipw and vigr honor it.
Mikkel
Dan Thurman wrote:
I was manually changing the /etc/passwd and /etc/group file since my users were incorrectly assigned UID/GIDs, I manually corrected the UID/GID in /home for each user, rebooted and noticed that I would get a hang just after udev.
Did you forget gshadow? A common mistake for us old farts.
I always try to use usermod for that kind of stuff. Yes, I still use vipw regularly, but I don't dare modify group info that way any more.
gshadow has bitten me more than once, hence the motivation to use usermod more often.
Good Luck!
Dan Thurman wrote:
Dan Thurman wrote:
Dan Thurman wrote:
Dan Thurman wrote:
I was manually changing the /etc/passwd and /etc/group file since my users were incorrectly assigned UID/GIDs, I manually corrected the UID/GID in /home for each user, rebooted and noticed that I would get a hang just after udev.
I tried ^D and noticed that something complaining about /var/run/anacron was not removable and that user anacron did not exist, and the system would then shutdown and reboot.
On rebooting, I stopped grub and added -s and single user boot was successful.
In single user, I checked what I could and finding nothing, and proceeded with ^D and noticed several things:
There was a message to the effect that several important users (root, anacron, and others) was not able to be retrieved from dbus's database. The message appears too fast for me to write it all down exactly.
Repeated messages of: "Unknown username "root" in message bus configuration file, for each important users.
Is there some way to repair the dbus database?
Thanks! Dan
I forgot to add:
- The system fails to start dbus, anacron, and a couple of other services but continues on to the text login prompt. Attempts login as root or any normal user will fail.
Dan
Um... interesting....
When I added selinix=0 to the grub command line for the kernel, I was able to get my qui and logins to work.... seems there is something going on with SELinux and dbus....
Can someone help me fix this issue?
Should I remove and reinstall SELinux/DBUS? I will wait until I get advice here before attempting this step....
Thanks again, Dan
Ok, I solved this problem but it is interesting to note...
- Boot in single user mode
- touch /.autorelabel
- reboot
- When grub comes up, stop and edit the kernel line and add -s (single
user mode) 5) Booting in single user mode ensures that selinux will be able to relabel the files. If you do not boot in single user mode, then normal booting will not allow selinx to work and to relabel these files!
Just as a note, I have never had to boot in single user mode to get a relabel so I think your particular problem is that the "regular" boot just flat-out was hanging and not doing relabel along with the many other things.
My recollection is that when shadow passwords were first invented (was that Eric Raymond?) vigr and vipw followed in a very short time.
Question for selinux gurus, would relabel run if the kernel had been booted with selinux=0 specified?
-
Bill Davidsen -
Dan Thurman -
Mikkel -
Patrick O'Callaghan -
Phil Meyer -
Timothy Murphy