2009/10/11 David Henningsson
> I can reproduce the bug by starting rythmbox in the original session
> (and have it play something) and then try to switch to a guest session.
> At that point, my system locks up hard and I can't do anything but doing
> a hard reset (Ctrl-Alt-F1, Ctrl-Alt-REISUB doe
Interesting. Could you report another bug about that crash in xserver-
xorg? That's probably the place where the bug occurs. See
https://wiki.ubuntu.com/X/Troubleshooting/Freeze.
This report can be kept to determine why crashing while a guest session
is open will leave those files. That's a real i
I can reproduce the bug by starting rythmbox in the original session
(and have it play something) and then try to switch to a guest session.
At that point, my system locks up hard and I can't do anything but doing
a hard reset (Ctrl-Alt-F1, Ctrl-Alt-REISUB does not work). After the
reboot the lock
2009/10/10 Milan Bouchet-Valat
> We need to track down the program that has left those locks when
> crashing. Is it gdm-guest-session itself, or is it using a program to
> change /etc/passwd (possibly usermod itself)?
>
As of now, guest-session doesn't leave any locks behind.between the
command
We need to track down the program that has left those locks when
crashing. Is it gdm-guest-session itself, or is it using a program to
change /etc/passwd (possibly usermod itself)?
** Also affects: gdm-guest-session (Ubuntu)
Importance: Undecided
Status: New
--
usermod fails: "cannot l
2009/10/10 David Henningsson
> I have also encountered this bug and tried to nail it down. It seems
> like the following files have been left:
>
> /etc/passwd.lock
> /etc/passwd+
> /etc/shadow.lock
>
> I renamed these files and now I can successfully create users again.
>
Confirmed.
By removing
I have also encountered this bug and tried to nail it down. It seems
like the following files have been left:
/etc/passwd.lock
/etc/passwd+
/etc/shadow.lock
I renamed these files and now I can successfully create users again.
Out of curiosity, I checked what was in the passwd+ file, the result
w
2009/9/26 Tuomas Aavikko
>
> Tried to add new user:
> t...@dv5:~$ sudo adduser test
> [sudo] password for tta:
> Adding user `test' ...
> Adding new group `test' (1001) ...
> Adding new user `test' (1001) with group `test' ...
> useradd: cannot lock /etc/passwd; try again later.
> adduser: `/usr/s
2009/9/23 Milan Bouchet-Valat
> Just an idea: do you happen to be using some strange file system on your
> root partition, or specific mount option? I don't know whether that
> could affect file locks, but...
Ext4 for all my partitions, /home encrypted, nothing else special.
t...@dv5:~$ mount
/
Just an idea: do you happen to be using some strange file system on your
root partition, or specific mount option? I don't know whether that
could affect file locks, but...
--
usermod fails: "cannot lock /etc/passwd"
https://bugs.launchpad.net/bugs/432964
You received this bug notification becaus
My understanding of your comment is that you tested KDE and GNOME on two
different machines. That easily explains why one can work and not the
other, ignoring the desktop environment difference.
The difference with ",,," should not be a problem, it simply comes from
the code in the backends that a
2009/9/20 Milan Bouchet-Valat
> This bug does not seem to be GNOME specific since the problem happens in
> usermod. Maybe KDE does not use usermod.
>
Tested usermod in KDE setup in konsole, it worked.
This computer is running Karmic upgraded from Jaunty
> Have you tried running the usermod com
This bug does not seem to be GNOME specific since the problem happens in
usermod. Maybe KDE does not use usermod.
Have you tried running the usermod commandline from a fresh boot, i.e.
before you tried to edit the user with users-admin? Maybe that's the
program that is locking /etc/passwd (via the
13 matches
Mail list logo
