Description of problem: I have f20i686, f20x86_64, rhel7x86_64, each of them several kernels and shared /boot only 500mb. Before installing f21 alpha I have not checked and have not realised that there is just few space left (less then 10nmb). Anyway - booted live workstation iso, lunched anaconda, created new partition, mounted my boot as /boot, created new lvm partition for new f21 x86_64 system, allowed to install installer, and started. After the (successful!) installation rebooted. Nothing from new grub.cfg worked[1], but it is nothing new. Booted liveimage again, removed new grub.cfg and replaced by old grub.cfg which I have backuped before install. Here I have realised that on boot partition is 0b (literally). Again *nothing*[2] booted (not from new cfg, nor backuped one) S I looked into /boot, and noted following: new initramfs is only 8mb big (afaik not copied whole?) new system.map and config looks ok vmlinuz size was similar to older vmlinuzes here Until now. Ok. I'm stupid. However expected behaviour would be: - when boot is selected, I shoudl be warned that there should be at leas 40mb of free space - when copying of anything to boot fails, the instalaltor will not "finish successfully" Now the more terrifying part. Why nothing booted? - To my surprise *all* initramfses on boot partition were *modified* after install - the size was slightly bigger then in original files and of course md5sum changed. I did not make binary diff ( I can grant access to this machine nearly any time) - I noted all the items in new grub.cfg have linux16 and initrd16. I played with those, nothing helepd. Not n old cfg, not in new. However expected behaviour would be: - if the error is caused by no space on /boot, then - grub2 shold not be installed - the old iniramfs should not be touched - the previous grub.cfg should bekept/should work (at least after human merge with new one) - if it is unrelated to no space on boot, then I'm probably missing something (aka why should old initramfses should be touched???) [1] died on kernel pannic [2] died "strangely" : found Mapper/blahbla, but nothing else and several timeouts, reached basi ssytem, then few more timouts and ti was all. It mostly means that systemis at least reading initramfs, but something else went wrong. But I ron out of experences here.
One more update - It seems that the touches to initramfses were correct, to make them work with "initrd16 and linux16" With all initrd changed to initrd16 and same for linux, old cfg file booted. Howewer, try to imagine if there was even less space, and so the "touch" to old ramfses would notbe successful
Actually, one hint from my collegue. How wil this behave, once I update one of previous f20? The initramfs will be configured to work with initrd and linux. Not with 16' variants. How this is expected to work? Also, what if I have more diferent systems then fedora? How it will behave? This thing, touching initramfs - seems extremly dangerous tome.
Proposed as a Blocker for 21-beta by Fedora user jvanek using the blocker tracking app because: it seems that on machines with older fedoras in parallel with f21, the updates of kernels (older then f21) will not work properly. I would like to see anaconda guys explanations to this before release.
Nother confirmation - yes, not all touches to initramfs were correct (probably due to lack of space :( )
creap. Only one initramfs is booting. Is there some way how to rescuethe corrupted ones?
All of the initramfs files being modified sounds like the same as bug 1074358. Please attach the log files from the install, available in /tmp in the install environment and copied to /var/log/anaconda in the installed system.
Created attachment 940817 [details] logs Yes. The bug looks quite similar. f16? crap crap :( Here are the requested logs.
By my reading, this report covers two bugs: 1. anaconda does not check for sufficient free space in /boot when re-using an existing partition (it does check the absolute size of the partition, but not the free space in it) 2. something during installation touches existing initramfs files and apparently can render them unbootable issue 2 appears to be a duplicate of #1074358. I don't think it's really related to the free space issue? If this is correct, I'd say we should consider this report as covering only issue #1, and cover issue #2 in the other bug. Is that OK?
Discussed at 2014-09-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-09-24/f21-blocker-review.2014-09-24-15.59.html . We rejected the 'anaconda doesn't check for sufficient free space in /boot when it's being reused' part of this as it seems a bit too far into 'well, you should've known that' territory - we do assume a certain amount of knowledge on the part of people doing custom partitioning, and you ought to know a new OS install to an existing /boot is going to need space to write its kernel and initramfs. The issue doesn't clearly violate any of the release criteria. We agreed to consider the 'modifies existing initramfs' part of this bug as bug 1074358 - I'm going to add that one to the proposed blocker list.
Thank you for taking care. Yes, your conclusions sounds perfectly reasonable. >issue 2 appears to be a duplicate of #1074358. I don't think seem like that. > it's really related to the free space issue? I don't know. Maybe after touch with enough space, they are bootbale. However, in my case, when there were no space, and all were touched. only one (first?) touched one was bootable. And the others were probably not touched correctly. When comapring with other machines,m it seems that they grow a bit, somybe the modification was not sucessfull because of lack of space... So maybe the conection is more close.
the reporter of #1074358 doesn't mention anything about space on the partition being tight, but perhaps we can ask.
The free space half of this bug is fixed in bug 1129629. *** This bug has been marked as a duplicate of bug 1129629 ***