Bug 721676

Bug report https://bugzilla.novell.com/show_bug.cgi?id=721670 may be similar, but I can not tell from the description in that bug report.

I can verify the same behaviour with the _64 DVD  12.1 beta 1

Grub was not written, though a menu.lst was as I was able to add a menu.lst entry to my existing 11.4 grub and it would boot 12.1
But the install was missing the defined user. 
It booted to the login UI but had 'not defined'
Ctri+Alt+F1 to console and login still failed as user and or root.

I had the same problem with the Net-Install-CD for the first two attempts. The third attempt worked somehow. The only difference in the third was, that I formatted the /home-partition, that contained the files and settings of milestone 5; but I am not sure, if this made the success.

I have the same behavior.... but
1. I have installed in a Virtualbox machine and in the same where OP milestone 5 was installed. 
2. I will test in a new virtualbox machine... report soon.

No solution. 
when I install Opensuse 12.1 beta 1 in a new virtualbox machine, fails installation immediately after software installation complete, but before 1st reboot. 
I can not recognize the error message. 
Host system is Opensuse 11.4. KDE. 

The OS 12.1 Milestone 5 was installed OK. 
I hope it will be different at the Beta 2

I have done installs from a USB stick using DVD_64 and net_64. the results that I get are the same as reported bugs 721680, 721676, 721670, 721815. The install hangs just after the installation of the files. I used the second option where I selected the /, /home and /swap. Then I edited the setup to format the /home partition. After I enable the /home drive via the "enable drive" utility in partedmagic, I see that there is no /home/user directory; just /lost+found.

I mounted my 12.1 beta1 / and see that there is in fact a /var/lib/rpm/.rpm.lock
of zero bytes.

(In reply to comment #7)
> I mounted my 12.1 beta1 / and see that there is in fact a
> /var/lib/rpm/.rpm.lock
> of zero bytes.

From the original post, it looks like it's looking for: 
/var/lib/rpm/ .rpm.lock (notice the space before .rpm.lock). It may just be a typo on the OP's part, but if it's not, then there is an extra space in there breaking the installation. 

Time to DL and check in KVM.

I tested the DVD 12.1 beta 1 32 bit in VMware Workstation 7.1.4, using the default virtual machine configuration for openSUSE 32 bit OS and the installation completed successfully.

This looks like bug #721815, can you please check Xorg logs whether X segfaults during installation?

Tried install 64 bit version onto Acer Iconia W501P tablet. Ensured a complete format of partitions take place before installing of packages.

Fails just after "Updating kernel module dependencies...", with top progress sitting at 50%.

error: can't create transaction lock on /var/lib/rpm/.rpm.lock (No such file or directory)

Error always reproducible.

https://bugzilla.novell.com/show_bug.cgi?id=721680 is likely a dupe.  I get the exact same error.

721671, 721676, 721680 bugs seem to be similar. In virtualized environment (virtualbox) I've tried to install the beta with a personal bootloader configuration in relation to default one (auto-configuration), and the install failed. With default bootloader option, everything was fine.

Tomorow I'll tried it (both, personal and auto-configure bootloader configuration) with a hard install, to compare.

I have 12.1 beta1 x86_64 KDE 4.6.0 and Gnome installed and updated before build 315 which is where beta1 is announced. It is running kernel 3.1.0-rc6-2-desktop quite nicely. it even has /bin/systemd, /bin/systemd-ask-password, /bin/systemd-loginctl, /bin/systemd-machine-id-setup and 3 other systemd-whatevers.

On the other hand all installs since build 315 and later stop at: "error: can't create transaction lock on /var/lib/rpm/.rpm.lock (No such file or directory)" at which point the installation hangs. /home only has /lost+found and nothing else. /var/log only has:
beebubz/var/lib/rpm # ls -l /r5/var/log/*
-rw-r----- 1 root root     0 Oct  5 00:20 /r5/var/log/acpid
-rw-r--r-- 1 root root  7125 Oct  5 00:17 /r5/var/log/alternatives.log
-rw------- 1 root root     0 Oct  5 00:04 /r5/var/log/btmp
-rw------- 1 root root  3456 Oct  5 00:21 /r5/var/log/faillog
-rw-r----- 1 root root     0 Oct  5 00:20 /r5/var/log/firewall
-rw-r--r-- 1 root root 31536 Oct  5 00:21 /r5/var/log/lastlog
-rw-r----- 1 root root     0 Oct  5 00:20 /r5/var/log/mail
-rw-r----- 1 root root     0 Oct  5 00:20 /r5/var/log/mail.err
-rw-r----- 1 root root     0 Oct  5 00:20 /r5/var/log/mail.info
-rw-r----- 1 root root     0 Oct  5 00:20 /r5/var/log/mail.warn
-rw-r----- 1 root root     0 Oct  5 00:20 /r5/var/log/messages
-rw-r----- 1 root root     0 Oct  5 00:20 /r5/var/log/NetworkManager
-rw-r--r-- 1 root root     0 Oct  5 00:20 /r5/var/log/ntp
-rw-rw-r-- 1 root utmp     0 Oct  5 00:04 /r5/var/log/wtmp

/r5/var/log/cups:
total 0

/r5/var/log/krb5:
total 0

/r5/var/log/news:
total 0
-rw-r----- 1 news news 0 Oct  5 00:20 news.crit
-rw-r----- 1 news news 0 Oct  5 00:20 news.err
-rw-r----- 1 news news 0 Oct  5 00:20 news.notice

/r5/var/log/samba:
total 0

/r5/var/log/YaST2:
total 136
-rw-r--r-- 1 root root   5961 Oct  5 00:15 mkinitrd.log
-rw-r--r-- 1 root root 129496 Oct  5 00:16 perl-BL-standalone-log

/r5/var/log/zypp:
total 188
-rw-r--r-- 1 root root 184564 Oct  5 00:24 history


As indicated by the bug reports the install has not entered the next phase.

Aside from the logs that are generated is there a trace that can be turned on to indicate which lines of code from which executable is issuing which messages? 
If any of you are interested, I can provide attachments.

(In reply to comment #14)
> On the other hand all installs since build 315 and later stop at: "error: can't
> create transaction lock on /var/lib/rpm/.rpm.lock (No such file or directory)"
> at which point the installation hangs. /home only has /lost+found and nothing

That is not the cause of the failed installation.

> Aside from the logs that are generated is there a trace that can be turned on
> to indicate which lines of code from which executable is issuing which
> messages? 

Yes, either check vt8 (switch via alt+f8) or /var/log/Xorg.0.log for a backtrace indicating a segfault in the evdev driver. That is the likely cause of this report and a number of other potential dupes of bug #720571.

(In reply to comment #0)
> Above noted failure occurs every time, with PC install halting at "error: can't
> create a transition lock on /var/lib/rpm/ .rpm lock (no such file or
> directory)" error. Pressing <enter> does not help.  Pressing <ctrl><c> aborts
> the install, giving ansi menu's to install or reboot. GRUB is already setup,
> but rebooting results in a hang at the log in menu with no users recognized.

Can you please check vt8 or /var/log/Xorg.0.log to verify that this is bug #720571?

(In reply to comment #15)
> (In reply to comment #14)
> > On the other hand all installs since build 315 and later stop at: "error: can't
> > create transaction lock on /var/lib/rpm/.rpm.lock (No such file or directory)"
> > at which point the installation hangs. /home only has /lost+found and nothing
> 
> That is not the cause of the failed installation.


In other words: all installs that I performed on my PC from build 315 on stop at "transaction lock"... I was illustrating the only events that made themselves visible. Surely someone with familiarity with the code and scripts would look for completed events that may lead to the visible ones.


> 
> > Aside from the logs that are generated is there a trace that can be turned on
> > to indicate which lines of code from which executable is issuing which
> > messages? 
> 
> Yes, either check vt8 (switch via alt+f8) or /var/log/Xorg.0.log for a
> backtrace indicating a segfault in the evdev driver. That is the likely cause
> of this report and a number of other potential dupes of bug #720571.

No. I am talking about a trace similar to what compilers offer. 

A check into the /var/log of the involved partitions show NO Xorg*.* none. If you look at the ls -l /r5/var/log/* in comment 14 you will see that.

The hard drive that I used for the failed installs of builds 315-319 uses a GPT partition table. So I thought I would try an install 12.1 beta1 build 323 onto partitions on my older WD1600AAJS hard drive with msdos partition table. Success. I must add that I had successful installs of 12.1 milestones onto the GPT drive.

(In reply to comment #17)
> > > Aside from the logs that are generated is there a trace that can be turned on
> > > to indicate which lines of code from which executable is issuing which
> > > messages? 
> > 
> > Yes, either check vt8 (switch via alt+f8) or /var/log/Xorg.0.log for a
> > backtrace indicating a segfault in the evdev driver. That is the likely cause
> > of this report and a number of other potential dupes of bug #720571.
> 
> No. I am talking about a trace similar to what compilers offer. 

I don't know what you mean, however the backtrace is what matters here.

> A check into the /var/log of the involved partitions show NO Xorg*.* none. If
> you look at the ls -l /r5/var/log/* in comment 14 you will see that.

Yeah, that's because the installer system runs in tmpfs and you're looking at the root fs of the half-installed system. You need to check /var/log/Xorg.0.log (or look at vt8) when this happens, the log will be gone after rebooting.

(In reply to comment #18)
> The hard drive that I used for the failed installs of builds 315-319 uses a GPT
> partition table. So I thought I would try an install 12.1 beta1 build 323 onto
> partitions on my older WD1600AAJS hard drive with msdos partition table.
> Success. I must add that I had successful installs of 12.1 milestones onto the
> GPT drive.

Likely a coincidence of the evdev driver not crashing.

I have just tried installing openSUSE-DVD-Build0315-i586 (12-1 Beta 1) on a VirtualBox 4.1.4 in Windows 7 32-bit.

I'm getting the same problem - all packages are installed and just before the first restart the machine hangs. Unfortunately, in my case the display gets corrupted so I can't move to text console and extract any logs.

Created attachment 454707 [details]
Hardware Information

Hardware information for crashing system.

Created attachment 454709 [details]
Xorg Log

Xorg log as requested.

Created attachment 454710 [details]
YaST Logs

YaST logs as requested.

I have provided similar information in bug 721680: https://bugzilla.novell.com/show_bug.cgi?id=721680

Created attachment 454766 [details]
Xorg Logs

My Yast logs with a hard disk install on F8Va ASUS Laptop.

Everythings by default except bootloader option:
from
 "activate":"true", "boot_extended":"true", "boot_root":"false 
to
"activate":"false", "boot_extended":"false", "boot_root":"true", 

(my Yast logs is too big so I couldn't share it)

Symptom :
*** Starting YaST ***
error: can't create a transition lock on /var/lib/rpm/ .rpm lock (no such file
or directory)

and

Xorg (0x400000+0x2756d)
Segmentation fault at address (nil)
Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting

Created attachment 454774 [details]
hwinfo

hwinfo, ASUSE F8Va.

Just a side note, the installation works OK when using the text mode and graphical mode starts OK afterwards.

Unfortunately 'text installation' on the 32-bit DVD is not an option when I attempted the install, at the grub installation selection menu as all the Fx keys function except for the F3 key, which has no effect and does not function.  Possibly another 'bug' ( ? ) impacting only certain PC hardware.  The F3 key works fine in an openSUSE-11.4 install from the desktop (but also does not function from the grub menu).  But that's not relevant to this thread, other than it prevents a 'potential work around'.

Using 64 version.

Managed to start installation in text mode, and it does manage to get beyond the point of displaying "Updating kernel module dependencies ...", and reboots.

Only problem is that it immediately crashes on starting stage 2 GUI part, due to the crap ATI driver that is used. To get around this problem, during the stage 1 installation I had to also add nomodeset to the boot kernel options of the default boot choice, and also change runlevel to 3.

This allowed me to at least get to login, though stage 2 does not take place in text mode, not sure if there is a text mode stage 2. Unless someone knows how to get stage 2 to continue.

At least I can install the half decent proprietary ATI driver and change runlevel to 5, and reboot. Rebooting, results in stage 2 trying to continue, now at least I get the openSUSE splash screen and busy mouse pointer. Nothing else appears, only thing you can do is move the busy mouse pointer around or reboot.

The default rubbish ATI prevents even installing completely using text mode for stage 1.

Lee and Alun's reports appear to be in error.

I have no idea why Lee's F3 key isn't working - I had no issue.  Perhaps he is on a laptop?  

I had no trouble using a text mode install.  Phase 1 completed normally, and phase 2 started on reboot (also normally).  The install remained in text mode, and did not go to graphical mode at the start of phase 2 as Alun suggests.  

I will note however, that weird graphical glitches are shown when dragging icons around in desktop folder view mode.  It's hard to explain, and too brief to capture in a photo.  Marcin's suggested workaround is fine for now.

> I have no idea why Lee's F3 key isn't working - I had no issue.  
> Perhaps he is on a laptop?  

Its an old desktop PC, but I think the non-functioning of my F3 key is a 'red herring' and not relevant to bug 721676. The F3 key could be a hardware issue with an old keyboard and I need to check out a different keyboard separately with this PC.

Its good to read there is a TEXT mode work around (which I can't unfortunately test until I plug in a different keyboard), but still, this 12.1 beta1 DVD install should be working with the FBDEV video driver (which it does not).  I did manage to install 12.1 beta1 on same PC from a KDE liveCD, and so this Bug-721676 appears to be DVD specific.

see bug 724713

Seems to be related to Xorg (see comment #26).
Bug 723777 also reports similar problems.

.

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

A vital '7' missed off the end of the bug that this duplicates. :)

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

Further to this CLOSED bug report, the F3 keyboard problem I had has been confirmed to be hardware, and was a red herring to this thread. I replaced my old keyboard with a newer one, and F3 works fine upon boot with the new keyboard.  My apologies to those involved with this bug report for that 'red herring'.