Created attachment 1132553 [details] rdsosreport.txt Description of problem: f24 network installation needs more than 1GB ram, tested with a VM and bare metal. Version-Release number of selected component (if applicable): anaconda-24.13-1.fc24 How reproducible: Every time Steps to Reproduce: 1. Create a VM with 1GB ram, using the latest f24 2. Fails when grabbing stage2 Actual results: 93 342M 93 319M 0 0 4955k 0 0:01:10 0:01:06 0:00:04 3326k [ 117.030748] dracut-initqueue[629]: curl: (23) Failed writing body (10176 != 16176) [ 118.551988] dracut-initqueue[629]: mount: wrong fs type, bad option, bad superblock on /dev/loop0, [ 118.553728] dracut-initqueue[629]: missing codepage or helper program, or other error [ 118.557054] dracut-initqueue[629]: In some cases useful info is found in syslog - try [ 118.558610] dracut-initqueue[629]: dmesg | tail or so. [ 118.572160] dracut-initqueue[629]: umount: /run/initramfs/squashfs: not mounted [ 118.607805] dracut-initqueue[629]: /lib/anaconda-lib.sh: line 110: printf: write error: No space left on device Expected results: Successful installation. Additional info: Succeeds when using 1.5+ GB ram.
The bad news: you probably just need to use more RAM. Loading the stage2 from the network requires more memory than installation using a local stage2, since the squashfs has to be downloaded to the initramfs. The good news: This may already be fixed in rawhide, and may be fixed in post-alpha F24. There a couple of changes in the pipeline that should reduce the size of the stage2 by a fair chunk: bug 1318408 drops the last python2 dependency, and bug 1317692 drops the gtk2 dependency and a 40MB binary in /usr/libexec. There's also pending changes in https://github.com/rhinstaller/lorax/pull/99 which shaves another 30MB or so off the compressed stage2 size. The policycoreutils+python2 change (1318408) should hit f24 after the alpha freeze is lifted, so if that doesn't do it, I suggest you re-open the webkitgtk4 bug (1317692) to have that updated to f24, and if that still isn't enough, please open a bug against lorax for *those* changes.
I hit this with Alpha-1.7 with 1.5GiB ram allocated to the VM
Reopenning, I also had failures with 1.5GiB ram on rawhide. I used https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20160322.n.0/compose/Cloud/armhfp/os/ as well as https://kojipkgs.fedoraproject.org/compose/24/Fedora-24-20160322.4/compose/Cloud/armhfp/os/
Dennis, can you link/attach the logs from your failure?
Could've sworn I set needinfo. Anyway: the logs from the 1.5 GB failure may be helpful, if you could include those.
I will reproduce and grab them. I did find one piece interesting. after some extra testing I was able to install in 11.5GiB ram if I used the Everything tree, I had been using the Cloud tree, the difference is that there is a product.img for cloud. maybe its pushing it over in memory or maybe it is corrupt.
Interesting. product.img does also need to be downloaded which will consume space in the initramfs, but the ones in comment 3 are 12 bytes, and, as you suspect, corrupt. I'd be curious to see where things wrong.
The issues in comment 3 were a problem with xz blowing out the address space on 32-bit systems, and has been fixed in lorax. Now that everything is in the new lorax, http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/armhfp/os/images/install.img is down to 308MB, and since the original failure bombed out at 319, I'm going to close this again.
This issue is still persistent. However I tried kickstarting a CentOS 7 not a Fedora, but I guess its based on the same issue. How to reproduce: Simply use 1024M as available memory and kickstart your installation dracut-initqueue bugs out with the message "mount wrong fs type /dev/loop0" Change the available memory to 2048 and kickstart your installation again - works perfectly!
I face the same problem in RHEL 7.5, while installing through a PXE boot server and the PXE client has 1 GB memory. Follow the advice of Paul Whalen to workaround the issue. Thanks,