To reproduce: 1) Install 20090120 rawhide into an x86_64 KVM guest using virt-manager 2) Select "Fedora 9" as the OS type (to avoid bug #480822) 3) Pass "console=ttyS0 vnc" as the kernel command line 2) Use a non-existent file as the disk, de-select the "pre-allocate" toggle you get as far as "activating partitions" and it hangs a bit before, boom!: mini-wm: Fatal IO error 11 (Resource temporarily unavailable) on X server :1.0. The application 'anaconda' lost its connection to the display :1.0; most likely the X server was shut down or you killed/destroyed the application. install exited abnormally [1/1] disabling swap... /dev/mapper/vg_test-lv_swap unmounting filesystems... /mnt/runtime done disabling /dev/loop0 LOOP_CLR_FD failed: 16 /proc done /dev/pts done /sys done /selinux done sending termination signals...done sending kill signals...done you may safely reboot your system
Okay, this appears to because the guest only had 512Mb of RAM - it works fine with 1Gb Is there a "you need at least XMb of RAM to install" warning we need to update?
Were you doing an http based install, booting from vmlinuz/initrd, thus putting stage2 into ram? I could see that not working right in x86_64 land right now, with graphical installs. This is something we'd like to see get better for F11, but it's not an Alpha issue.
(Sorry, thought I'd replied) (In reply to comment #2) > Were you doing an http based install, booting from vmlinuz/initrd, thus putting > stage2 into ram? Yep, it was a method=http:// install
Isn't this yet another case of python-x86_64 using up a whole lot of memory for objects?
(In reply to comment #4) > Isn't this yet another case of python-x86_64 using up a whole lot of memory for > objects? Maybe, I don't know - but my point is that if we need >512Mb, we should warn users if they have less than that
> Isn't this yet another case of python-x86_64 using up a whole lot of memory for > objects? All the test I've done with yum would suggest not. But doing a Fedora 10 => rawhide update I get: % yum update --enablerepo=rawhide The other application is: yum Memory : 22 M RSS (285 MB VSZ) Started: Thu Mar 26 17:44:12 2009 - 00:06 ago State : Uninteruptable, pid: 16616 [...wait for pkg scroll to start...] The other application is: yum Memory : 152 M RSS (415 MB VSZ) Started: Thu Mar 26 17:44:12 2009 - 01:06 ago State : Running, pid: 16616 [...end (failed deps, openssl+flash)...] The other application is: yum Memory : 239 M RSS (502 MB VSZ) Started: Thu Mar 26 17:44:12 2009 - 03:02 ago State : Running, pid: 16616 % yum update --disablerepo='*' --enablerepo=rawhide The other application is: yum Memory : 50 M RSS (312 MB VSZ) Started: Thu Mar 26 17:52:52 2009 - 00:02 ago State : Running, pid: 16800 [...end (failed deps, openssl+flash)...] Another app is currently holding the yum lock; waiting for it to exit... The other application is: yum Memory : 134 M RSS (395 MB VSZ) Started: Thu Mar 26 17:52:52 2009 - 00:34 ago State : Running, pid: 16800 ...rawhide is 15,972 pkgs and the rest are 20,442. But even 250MB should be fine on 512MB, but rpm takes more than it's fair share (esp. with F9) ... and gtk takes a bit to do the UI. So I don't think this is a python thing, and I've thought about putting something into yum that says something like "you are using X% of RAM, and rpm hasn't run yet ... so we do decide to warn in anaconda I think it's worth adding a similar check to yum itself.
In case anyone is wondering the first run was without the rawhide metadata, which is why it took the extra 2:30
A recent change to anaconda causes us to use tmpfs instead of ramfs for certain filesystems now, which means we have the ability to swap those things out and therefore use less memory. It's quite likely this lowers the memory requirements and fixes this bug. If you could test with F11 when released and let us know if you are still seeing this problem. Thanks.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping