Description of problem: This was seen doing kickstart installs on my HP Integrity servers. The install installs all the packages properly but then dies in the post install with an exception. I will attach the full debug file. Traceback (most recent call last): File "/usr/bin/anaconda", line 967, in ? anaconda.intf.run(anaconda) File "/usr/lib/anaconda/text.py", line 531, in run anaconda.dispatch.gotoNext() File "/usr/lib/anaconda/dispatch.py", line 121, in gotoNext self.moveStep() File "/usr/lib/anaconda/dispatch.py", line 198, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/packages.py", line 43, in doPostAction anaconda.id.instClass.postAction(anaconda, flags.serial) File "/usr/lib/anaconda/kickstart.py", line 808, in postAction map (lambda s: s.run(anaconda.rootPath, serial, anaconda.intf), postScripts) File "/usr/lib/anaconda/kickstart.py", line 808, in <lambda> map (lambda s: s.run(anaconda.rootPath, serial, anaconda.intf), postScripts) File "/usr/lib/anaconda/kickstart.py", line 64, in run root = scriptRoot) File "/usr/lib/anaconda/iutil.py", line 35, in execWithRedirect stdin = open(stdin) IOError: [Errno 2] No such file or directory: '/tmp/ks-script.log' Version-Release number of selected component (if applicable): rawhide-20060723 anaconda-11.1.0.62-1 How reproducible: 100% Steps to Reproduce: 1. network boot 2. serial console 3. kickstart install Actual results: Expected results: Additional info:
This should be fixed in the next build of anaconda. It was committed towards the end of last week, but anaconda didn't build on Friday.
FYI, still seeing this with anaconda-11.1.0.64-1 from the rawhide-20060725 build. Going to re-open this one. Let me know if I can provide any more details.
Created attachment 133012 [details] anaconda debug Attaching the anaconda "remote" debug info from reproducing this on anaconda-11.1.0.64-1.
Created attachment 133024 [details] debug output from updates.img from clumens Tested a potential fix from clumens. Same error seen. Attaching the debug output from this run.
Created attachment 133025 [details] kickstart file I am using to reproduce this
Ok, appears to be related to me doing an nfs mount in %post. I wasn't able to see this when I was using the serial console but thought I saw something on the screen just before the anaconda traceback. I did a VNC kickstart install and was able to see this just before the anaconda traceback: mount[5574]: NaT consumption 17179869216 [1] Modules linked in: dm_emc dm_round_robin dm_multipath dm_snapshot dm_mirror dm_zero dm_mod xfs jfs reiserfs lock_nolock gfs2 ext3 jbd msdos raid1 raid0 cciss mptspi scsi_transport_spi mptscsih mptbase qla2xxx scsi_transport_fc e1000 ohci_hcd ehci_hcd iscsi_tcp libiscsi scsi_transport_iscsi sr_mod sd_mod scsi_mod ide_cd cdrom ipv6 squashfs loop nfs nfs_acl fscache lockd sunrpc vfat fat cramfs Pid: 5574, CPU 2, comm: mount psr : 0000101008526010 ifs : 8000000000000286 ip : [<a00000010026b130>] Not tainted ip is at _atomic_dec_and_lock+0x10/0x120 unat: 0000000000000000 pfs : 0000000000000207 rsc : 0000000000000003 rnat: 0000000510ee287a bsps: e0000003d3915411 pr : 02a000101a565569 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f csd : 0000000000000000 ssd : 0000000000000000 b0 : a00000020bd76590 b6 : a0000001002121e0 b7 : a00000020bc17040 f6 : 1003e6b6b6b6b6b6b6b6b f7 : 1003e0000000000000418 f8 : 1003e000000000000000c f9 : 100098300000000000000 f10 : 1003e000000000000001e f11 : 1003e0000000000000200 r1 : a000000100b5e3c0 r2 : a00000020bc5e38c r3 : a00000020bc5e38c r8 : e000004059720000 r9 : fffffffffffff000 r10 : e0000040f10bda70 r11 : a000000100964b68 r12 : e000004059727a80 r13 : e000004059720000 r14 : 0000000000000000 r15 : 0000000000000002 r16 : ffffffffdead4ead r17 : 00000000dead4ead r18 : a00000020bdfce74 r19 : a000000100964b38 r20 : 0000000004235cc0 r21 : a0007fffbf000000 r22 : 0000000000108d73 r23 : 0000000000000002 r24 : e0000004235cf520 r25 : 0000000000052c00 r26 : e00000047fff2c90 r27 : 0000000000000000 r28 : a00000020bdfce78 r29 : 0000000000000002 r30 : a00000020bdfce80 r31 : e000004059721024 Call Trace: [<a000000100013da0>] show_stack+0x40/0xa0 sp=e0000040597274a0 bsp=e000004059721480 [<a0000001000146a0>] show_regs+0x840/0x880 sp=e000004059727670 bsp=e000004059721428 [<a0000001000335c0>] die+0x1c0/0x2c0 sp=e000004059727670 bsp=e0000040597213d8 [<a000000100033710>] die_if_kernel+0x50/0x80 sp=e000004059727690 bsp=e0000040597213a8 [<a0000001005d9d30>] ia64_fault+0x10f0/0x1200 sp=e000004059727690 bsp=e000004059721350 [<a00000010000c6e0>] ia64_leave_kernel+0x0/0x280 sp=e0000040597278b0 bsp=e000004059721350 [<a00000010026b130>] _atomic_dec_and_lock+0x10/0x120 sp=e000004059727a80 bsp=e000004059721320 [<a00000020bd76590>] nfs_put_client+0x90/0x180 [nfs] sp=e000004059727a80 bsp=e000004059721300 [<a00000020bd76800>] nfs_free_server+0x180/0x260 [nfs] sp=e000004059727a80 bsp=e0000040597212d8 [<a00000020bd78780>] nfs_create_server+0xce0/0xd20 [nfs] sp=e000004059727a80 bsp=e000004059721288 [<a00000020bd8ae20>] nfs_get_sb+0x9e0/0xa40 [nfs] sp=e000004059727b50 bsp=e000004059721238 [<a00000010014a4a0>] vfs_kern_mount+0x160/0x2e0 sp=e000004059727be0 bsp=e0000040597211e0 [<a00000010014a6e0>] do_kern_mount+0x60/0xa0 sp=e000004059727be0 bsp=e0000040597211a0 [<a000000100180d20>] do_mount+0xda0/0xea0 sp=e000004059727be0 bsp=e000004059721138 [<a000000100180f10>] sys_mount+0xf0/0x1a0 sp=e000004059727e10 bsp=e0000040597210a8 [<a00000010000c560>] ia64_ret_from_syscall+0x0/0x20 sp=e000004059727e30 bsp=e0000040597210a8 [<a000000000010620>] __start_ivt_text+0xffffffff00010620/0x400 sp=e000004059728000 bsp=e0000040597210a8
This appears to be related to the fact that portmap is not running. I can reproduce this issue by killing portmap on a running system and trying a mount. I will close this BZ and open a new one for the kernel. So, looks like the "right" way to do it anyway would be to do a "mount -o nolock" so it doesn't have to wait for the connection to portmap to fail.
OK, turns out that I am seeing 2 bugs (at almost the exact same time) but they appear to not be related. I added a -o nolock to the mount command in my %post and I no longer get the mount error but I still get the anaconda traceback about not finding ks-script.log. Sorry, have to re-open this one (again).
I'm able to reproduce this, but not if I'm using the updates.img I provided yesterday. Does your latest test include this or not?
Chris, good catch. I just re-ran a kickstart install with mount -o nolock to avoid the nfs mount failure AND your updates.img and I did still get the error. Just to be absolutley sure I am doing this right here is the full append= line I am booting with: append="updates=http://people.redhat.com/clumens/updates.img ks=nfs:10.12.11.1:/export/10.12.11.11-kickstart ksdevice=eth0 selinux=0"
As of the rawhide-20060727 tree this problem appears to have gone away. I wonder if for some reason I needed a full tree with the fix instead of an updates.img for this issue? Either way, appears to be resolved, thanks for all your attention on this one.