Bug 697670

why do you think this is a bug? I have the same behavior everywhere when I keep the same password for user and root at install time - I don't do that on production but I had to do installing for complete newbie.

to change passwd, do su then passwd

please read the bug report:

password is set, yet its not used, you can login as root or as user typing in what ever password you want or even leave it blank.   

passwd returns an errors.

so that is why I think its a bug as there is a password, it's not used and I can't change it.

I received two same reports and I read only the first :-(.

Seems strange. did you also let the "automatic login" selected?
Is the install completely default? did you receive any message saying that the passwd is too small or is included in the dictionary (I receive always these two)?

did the first reboot run as expected? it's a kexec one and frequently fails (on my desktops)

can you create an other user (can you simply launch YaST?)

yes automatic login was selected.  But as far as I know that is for the DE and should not effect a login at init 3

yes, did receive password was a bit easy and if I still wanted to use it.

yes, yast asks for password, I can enter what I want or leave it blank and it will startup just fine.

yes, install went as expected, its my 5th system and all installs when identical except this problem on this laptop

yes, can make a new user via yast, gave it a password, when logging in as that user I can enter what ever password I want or no password and it will log in.

well. If this reproduce evry time on this computer, it's weird! I just did a fresh 11.4 install on virtualbox with the same settings and when doing su, it asks for a pass (either my memory fails when I remember don't having to give one or I confuse with live dvd).

Do you have any special device on this laptop as fingerprint reader? I installed an HP laptop last month without problem.

If no of these suggestions have meaning, I giveup :-(. Probaly it could be of some use to have a YaST log (run "save_y2logs" and attach to the bugreport) - but not for me, I did my best, sorry!

Okay, I been searching into this PAM error and found the /etc/pam.d, here I noticed a difference between the pam.d on the laptop and that on the desktops, it had a few files more like common-auth-rpmnew and some files where different in size by a few bytes

so I made a backup of pam.d on the laptop and copied the pam.d over from the desktop, and low and behold  passwords now work !!!

Now I know little of pam.d and how the installation of opensuse works but I can be sure I did not touch that directory.   Maybe opensuse uses diffrent images if its laptop vs desktop ?

anyway I will attach the pam.d from the laptop as a tar to this bugzilla, hopefully it will help us understand why it was installed ?

Created attachment 432671 [details]
pam.d as originaly installed on laptop

this is what was originally installed on the laptop, replaced it with pam.d from a desktop which was installed with the same dvd and password work again

pam_unix2 is missing from common-auth. There's a common-auth.rpmnew that contains it. Was gnome-keyring-pam installed before pam for some reason?
Please attach y2logs.
http://en.opensuse.org/openSUSE:Report_a_YaST_bug#I_reported_a_YaST2_bug.2C_and_now_I_am_asked_to_.22attach_y2logs.22._What_does_that_mean.2C_and_how_do_I_do_that.3F

The install was a normal KDE with the exception of removing pulse and adding gcc, make, kernel-desktop-devel, yakuake and realcrypt, just as I did on the other machines who did not have this behavior

so if gnome-keyring-pam was installed before pam then maybe the yast2 logs will show. will attach them as you requested using the save_y2logs script.

Created attachment 433070 [details]
yast2 logs from laptop using save_y2logs script

something weird going on here. According to y2log-2 images got deployed but then the whole system was reinstalled using rpms. Somewhere in between there must have been a modification or deletion of /etc/pam.d/common-auth etc.
If I deploy the images manually and then run zypper in -f pam_apparmor pam I can't reproduce that.

Reassiging to YaST people.

the rpm db is empty after image deployment:

2011-06-02 12:17:09 <1> linux(2895) [zypp] RpmDb.cc(initDatabase):322 Calling initDatabase: '(/mnt)/var/lib/rpm'
2011-06-02 12:17:09 <1> linux(2895) [zypp] librpmDb.cc(unblockAccess):336 Unblock access
2011-06-02 12:17:09 <1> linux(2895) [zypp++] librpmDb.cc(DbDirInfo):542 '(/mnt)/var/lib/rpm':
2011-06-02 12:17:09 <1> linux(2895) [zypp++] librpmDb.cc(DbDirInfo):542   Dir:    /mnt/var/lib/rpm{d 0755 0/0}
2011-06-02 12:17:09 <1> linux(2895) [zypp++] librpmDb.cc(DbDirInfo):542   V4:     /mnt/var/lib/rpm/Packages{does not exist}

Michael, could you tell from zypp side if anything wrong happened there?

I just see the errors when trying to download /images/x11-meta-i386.tar.xz and /images/x11-i386.tar.xz (Input/output error, search for 'Can't hardlink/copy' in the log). But as Yast just logs the error and continues, this might be ok?

  <3> linux(2895) [YCP] ImageInstallation.ycp:244 
      File /images/x11-meta-i386.tar.xz not found on media


As Ludwig said, when initTarget(/mnt) is called, no database exists below /mnt, so a new one is created:

  2011-06-02 12:17:09 <1> linux(2895) 
  [zypp] ZYppImpl.cc(initializeTarget):96 initTarget( /mnt)

  '(/mnt)/var/lib/rpm':
  Dir:    /mnt/var/lib/rpm{d 0755 0/0}
  V4:     /mnt/var/lib/rpm/Packages{does not exist}
  V3:     /mnt/var/lib/rpm/packages.rpm{does not exist}
  V3ToV4: /mnt/var/lib/rpm/packages.rpm3{does not exist}

  Creating new rpm4 database in /mnt/var/lib/rpm{d 0755 0/0}

(In reply to comment #14)
> I just see the errors when trying to download /images/x11-meta-i386.tar.xz and
> /images/x11-i386.tar.xz (Input/output error, search for 'Can't hardlink/copy'
> in the log). But as Yast just logs the error and continues, this might be ok?
> 
>   <3> linux(2895) [YCP] ImageInstallation.ycp:244 
>       File /images/x11-meta-i386.tar.xz not found on media


Coolo, can you confirm the image is not corrupted?

*** Bug 700954 has been marked as a duplicate of this bug. ***

I see a /images/x11-meta-i386.tar.xz on the i586 DVD of 11.4 if that's what you want me to verify

To me the bug looks as if yast ignores errors during image deployment and then gets suprising results.

So, does it help to turn the installation from images off? There's an option for that at the beginning of the installation...

Any info? See comment 18...

I have not had access to the laptop on which is happened all the time after I given it back to the user with 11.4 on it working, I did try a quick install on a virtualbox a while ago using the same DVD but could not replicate it then.  I will give it another go, either this week or else this weekend.  I got all the steps of the installation on the laptop written down.

I done 2  more installs on a virtualbox using the exact same dvd and steps as with the laptop but I can not reproduce it that way and thus now check the turn of the installation from images.

I will try to get my hands on that laptop again but can't promise when.

Jumping on the bandwagon since this bug appears stuck.  I can reproduce this problem at will on four separate systems, so I can hopefully provide more information and someone can hopefully provide me steps for a fix (aside from finding a working pam.d).

My installation (salient details):
- non-virtual installation, Dell R410 server
- automatic configuration turned *off*
- admin account created, same root password *off*, receive system e-mails *on*, automatic login *off*
- was prompted for separate root password, it is different
- only added development packages with install (c/c++, kernel, java, perl, python)

Install completed without errors.  I thought it my be related to online updates, but the problem appears even if I skip the networking/updates.

Exact behaviour of the problem:

- for either root or admin account, logins through console, display manager or ssh succeeds with *any* password.  Starting YaST (where it asks for a password) also succeeds

- attempting to change either password with the 'passwd' command fails with 'Permission denied'

(In reply to comment #24)
> Jumping on the bandwagon since this bug appears stuck.  I can reproduce this
> problem at will on four separate systems, so I can hopefully provide more
> information and someone can hopefully provide me steps for a fix (aside from
> finding a working pam.d).

See comment #18, did you use image based installation? If so does turning the option off help?

(In reply to comment #25)
> (In reply to comment #24)
> > Jumping on the bandwagon since this bug appears stuck.  I can reproduce this
> > problem at will on four separate systems, so I can hopefully provide more
> > information and someone can hopefully provide me steps for a fix (aside from
> > finding a working pam.d).
> 
> See comment #18, did you use image based installation? If so does turning the
> option off help?

Ok, based on the previous information I had managed to confirm that updating common-auth, common-password and common-session from another system fixed the problem.

I did a reinstall with the same options except for turning off install from images as described in #18.  The problem did not reappear and I just confirmed that the correct common-* files are in /etc/pam.d

(In reply to comment #24)
> Jumping on the bandwagon since this bug appears stuck.  I can reproduce this
> problem at will on four separate systems, so I can hopefully provide more
> information and someone can hopefully provide me steps for a fix (aside from
> finding a working pam.d).

What's last modification time of those currupted  /etc/pam.d files?

+ Please attach YaST log files from the same test, so we can compare it with the logging times in the log.

I guess fix for bug 723339 helps here as well.
Please test with new version.

*** This bug has been marked as a duplicate of bug 723339 ***

(In reply to comment #6)
> Okay, I been searching into this PAM error and found the /etc/pam.d, here I
> noticed a difference between the pam.d on the laptop and that on the desktops,
> it had a few files more like common-auth-rpmnew and some files where different
> in size by a few bytes
> 
> so I made a backup of pam.d on the laptop and copied the pam.d over from the
> desktop, and low and behold  passwords now work !!!
> 
> Now I know little of pam.d and how the installation of opensuse works but I can
> be sure I did not touch that directory.   Maybe opensuse uses diffrent images
> if its laptop vs desktop ?
> 
> anyway I will attach the pam.d from the laptop as a tar to this bugzilla,
> hopefully it will help us understand why it was installed ?

This worked for me too.
Just replace files under /etc/pam.d/ with the same files of a working 11.4 installation.
Updating my system didn't worked. Should this be a security update?