Bug 1146101
| Summary: | when boot partition have another systems and not enough space, the installer "succeed" and break all previous iniramfs | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | jiri vanek <jvanek> | ||||
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 21 | CC: | anaconda-maint-list, awilliam, dshea, g.kaviyarasu, jonathan, jvanek, mkolman, robatino, vanmeeuwen+fedora | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | RejectedBlocker | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-10-10 18:16:52 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
jiri vanek
2014-09-24 13:00:57 UTC
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 *** |