Description of problem: Unable to install F11 from CDs due to anaconda crash. Anaconda aborts during transfer of install image to disk saying probably out of disk space. Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. Boot from F11 install CD disc 1 2. Select defaults (except custom disk layout) 3. Actual results: Installer quits as described Expected results: Successful installation Additional info: Using 16 GB SSD with three partitions: sda1 /boot 100 MB sda2 swap 1 GB sda3 / 14 GB Log file attached
Created attachment 351411 [details] Anaconda dump
This is not a bug. It might should be an RFE instead. The problem was 100 MB is too small for /boot during the install process. Increasing to 500 MB fixed it. Two notes: 1. The install guide recommends 100 MB for /boot. This worked up to F10, but not for F11. The documentation should be changed. 2. Ideally, anacondo would warn at the time of partitioning if /boot is too small for the install to succeed.
Release note at least for F12 Beta - also Install Guide fix!
Added to https://fedoraproject.org/wiki/Fedora_12_Alpha_release_notes
Fixed the obvious typo causing the traceback. We still need to address the underlying cause, I suppose.
So, 100 Mb is too small, and 500 Mb is plenty, what is the right number for the Install Guide?
anaconda currently defaults to 250 MB for /boot.
I've increased the suggested minimum in the Installation Guide to 250 MB; this will become visible the next time that we republish the guide.
*** Bug 515379 has been marked as a duplicate of this bug. ***
The only bug in this bug report is, that /boot has to be 250 or 500 MB, that is (sorry for the clear wording) totally crap for a couple of installed Linux kernels having ~ 50 MB in the end in total. Please fix Anaconda or whatelse, that ~ 100 MB for /boot are much enough...
Just to add something forgotten here: /dev/cciss/c0d0p1 97M 20M 73M 21% /boot Even ~ 50 MB for /boot should work and be much enough when looking to my own system right now.
This is all because of dract. See bug 516230.
Excuse me; dracut and preupgrade.
If I got Harald correct during LinuxTag, dracut should be more efficient compared to current mkinitrd - otherwise there's IMHO no real benefit...
The extra size is required by preupgrade to store the install image for use after rebooting during the upgrade process.
(In reply to comment #14) > If I got Harald correct during LinuxTag, dracut should be more efficient > compared to current mkinitrd - otherwise there's IMHO no real benefit... You mean no real benefit other than: - replacing mkinitrd/nash, which is very difficult to maintain - modular - easy to extend - one image can boot everything
We've already got a bug against dracut tracking the initrd file size, so there's really no point in keeping this bug open too. We'd like to handle this by making sure the initrds are appropriately sized, not by just increasing /boot every time someone requests it.
id.backend._loopbackFile: /mnt/sysimage/boot/rhinstall-install.img Any reason for backend.py to copy install.img from the cd/dvd to "/boot" rather than using "/" for the rhinstall-install.img on the target system? That is what triggered this bug to begin with, not enough room in /boot.
Shall I take all my servers offline before yum upgrade because all of them have 100M /boot?
(In reply to comment #19) > Shall I take all my servers offline before yum upgrade because all of them have > 100M /boot? Install dracut in F-11... edit /etc/dracut.conf and enable the host-only option. This will make the image ~5MB instead of 10MB.
*** Bug 529551 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > anaconda currently defaults to 250 MB for /boot. I had to check that: bug 530555
initrd's are _not_ created by dracut.
I'm not entirely following this. Is the effect that anyone with F11 and a 200MB /boot partition simply won't be able to upgrade to F12? If so, that will hit thousands of people. All of my machines have a 200MB /boot because that's what the default was when I first installed. (Some machines were fresh F11 installs; some were upgraded from earlier releases.)
James Heather is right, HOW is this not regarded as a bug? and a serious one at that? I have come from Fedora 10, through to Fedora 11. The setup in Fedora 10 was as was recommended by the installer, I did not make any changes to the partition configuration at all. So I was left with a 200mb /boot partition, just like James Heather, above. So I have just ran preupgrade and, sure enough, during the anaconda run after the reboot, I get "you need more space on the following file systems: 21mb on /mnt/sysimage/boot " Am I missing something, or can someone tell me how this is NOT going to affect many many people like myself? For now, I have just had to boot back into my Fedora 11 PC, waiting for a response. I do not expect to have a do a full re-install. Note: The auto-setup for my Fedora 10 was a 200mb /boot partition. Now this is not enough for preuprade upgrade from Fedora 11 to Fedora 12. Is this not a massive fail ?
(In reply to comment #7) > anaconda currently defaults to 250 MB for /boot. That has not always been the case. There will be many people out there, like myself and James Heather who used the partitioner at Fedora install, which left a 200mb partition for /boot. This is now causing me a problem, as it will come next week when other users try to run the preupgrade.
update: Note that this problem was openly acknowledged here: http://meetbot.fedoraproject.org/fedora-meeting/2009-11-13/fesco.2009-11-13-17.00.log.html But an update to preupgrade is pending in the updates repository for version 1.1.3 which come up with the more useful message: "Low disk space detect in /boot" ... "we recommend that you free up xMB by deleting old kernels or the upgrade may not run". It's not ideal (prevention better than the cure), but this warning at least prevents users from slipping into the Anaconda installer to find it fails.
> Note that this problem was openly acknowledged here: > http://meetbot.fedoraproject.org/fedora-meeting/2009-11-13/fesco.2009-11-13-17.00.log.html Looks as though you can still upgrade if you have a wired ethernet connection. (I wonder whether anaconda could include wifi support--that would make things rather easier.) But none of this is mentioned on the 'Common F12 bugs' page! The entry there is very sparse, and not even consistent. The title is /boot must be a minimum of 300MB and the description reads If you use a separate /boot partition, it is highly recommended that it be at least 300MB in size. There's quite a difference between 'must' and 'highly recommended'! This badly needs updating before tomorrow. Does it have to be 300MB, or doesn't it? If not, what is the thinking behind the recommendation? Does it apply to DVD upgrades, or just preupgrade?
Hi all ! What do you mean James by "Looks as though you can still upgrade if you have a wired ethernet connection." ? Is it linked to wwoods statement in the related fesco meeting : "17:23:38 <wwoods> dgilmore: happily your case will hit the existing disk-space check and offer to download install.img over the internet" ? Will anaconda detect the missing stage and offer to download it to another place than the already full filled /boot partition (/tmp or somewhere else). Will anaconda be able to download the stage to a LVM partition (everything but /boot is inside a LVM on my system) ? Thank you very much for your help on this subject : I think that all the users having a too small /boot partition will be very happy to know about a workaround different from resizing the partition. Thanks again, Cheers, Chicha
> What do you mean James by "Looks as though you can still upgrade if you have a > wired ethernet connection." ? > > Is it linked to wwoods statement in the related fesco meeting : > "17:23:38 <wwoods> dgilmore: happily your case will hit the existing disk-space > check and offer to download install.img over the internet" ? Yes, that's how I read it. I don't have any info beyond what's logged in that FESCo meeting. > Will anaconda detect the missing stage and offer to download it to another > place than the already full filled /boot partition (/tmp or somewhere else). > Will anaconda be able to download the stage to a LVM partition (everything but > /boot is inside a LVM on my system) ? Same here. I am very much assuming that it's being downloaded to RAM. The 'Common F12 bugs' page seems to have been updated now. The inconsistent entry is still there and unmodified, but there's another entry further up, which describes the issues in a little more detail. But bizarrely it doesn't mention the possibility of downloading the relevant files over the net. So I hope we don't find tomorrow that that's gone out the window! James
I have a patched anaconda to workaround the not enough space in /boot issue, looking for feedback. If you would like to try my workaround place the updates.img into /boot/upgrade for preupgrade or pull it down with updates= from http://members.shaw.ca/jvonau/pub/F12/ Jerry
(In reply to comment #31) > I have a patched anaconda to workaround the not enough space in /boot issue, > looking for feedback. If you would like to try my workaround place the > updates.img into /boot/upgrade for preupgrade or pull it down with updates= > from http://members.shaw.ca/jvonau/pub/F12/ Didn't sort out how to use updates.img but was able to apply "preupfix2.diff" patch (http://members.shaw.ca/jvonau/pub/F12/preupfix2.diff) and successfully upgrade my system with /boot of 200 Mb with only the last F11 kernel and preupgrade stuff on it. Jerry, thanks for your patch, it worked for me
(In reply to comment #18) > id.backend._loopbackFile: /mnt/sysimage/boot/rhinstall-install.img > > Any reason for backend.py to copy install.img from the cd/dvd to "/boot" rather > than using "/" for the rhinstall-install.img on the target system? That is what > triggered this bug to begin with, not enough room in /boot. This has nothing to do with preupgrade, that is a different issue. This bug should be reopened, the original issue: "Unable to install F11 from CDs due to anaconda crash. Anaconda aborts during transfer of install image to disk saying probably out of disk space." has everything to do with having to transfer the install.img from the cdrom to the hard-drive in order to unmount the first cdrom. The question is why it is using /boot to hold the image. https://www.redhat.com/archives/anaconda-devel-list/2009-November/msg00373.html "You are on to something here, the old code is using the first element of anaconda.id.storage.fsFreeSpace, which is sorted by size, but that is the element with the smallest size! I think this is a bug and the code should use the last element" Please reopen.
(In reply to comment #33) > > https://www.redhat.com/archives/anaconda-devel-list/2009-November/msg00373.html > > "You are on to something here, the old code is using the first > element of anaconda.id.storage.fsFreeSpace, which is sorted by size, but > that is the element with the smallest size! I think this is a bug and the > code should use the last element" > > Please reopen. As author of the quoted text, let me correct this, please do not re-open this bug, file a new bug instead.
a) the problem situation is poorly handled: error message and shutdown need improvement b) choice of filesystem to put these upgrade images on is suboptimal.
https://bugzilla.redhat.com/show_bug.cgi?id=544774
(In reply to comment #36) > https://bugzilla.redhat.com/show_bug.cgi?id=544774 <sigh> Re-opening 2 bugs for issue is *really* bad style, esp. as I've written in comment #34 of this bug: "let me correct this, please do not re-open this bug, file a new bug instead." Note though that the filing of a new bug is no longer necessary. As I already fixed the original issue of this bug (poor choice to store install.img with multiple CD install), see: http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=632fa16c6c8bb21252fc7792afc2e80734100efe
Trying to update the Common Bugs page with the resolution. It looks like this issue is "fixed" for Fedora 13, but what does that imply the minimum /boot size should be? Is whatever is documented in the Installation Guide and whatever the installer now defaults to sufficient?
I should say that what the installer *now* defaults to isn't the end of the story--that would only help people who make fresh installs of F12 to make future upgrades. It won't help people whose /boot was created long ago by a previous Fedora version. The default from time immemorial has been 200MB, so the issue is only properly fixed for F13 if 200MB is sufficient. Otherwise, those of us with machines dating back to F11 or earlier will still have trouble upgrading, and it'll still need to appear in some form on the F13 Common Bugs page.
/boot should not be abused -ever- for installation/upgrade purposes. If /boot can hold one kernel it should be sufficient for starting the system. Demanding bigger sizes is not justified.