preupgrade grub2 failed: now can't boot

Reindl Harald h.reindl at thelounge.net
Wed Feb 8 18:45:30 UTC 2012



Am 08.02.2012 19:36, schrieb sean darcy:
> On 02/08/2012 12:48 PM, Michael Cronenworth wrote:
>> Greg Woods wrote:
>>> This is the area at the beginning of the disk, before the first
>>> partition. Grub2 needs the first partition to start at 2048, but default
>>> partition layouts from Grub-1 systems start at 63. I have run into this
>>> several times and it is a royal pain. There may be some games you can
>>> play with gparted (shrink the partition, then move it), or you can do
>>> like I did, which is to dump the first partition, change it to start at
>>> 2048 (shrinking it a bit), making a new file system on the new
>>> partition, and restoring it.
>>
>> There is a way to force grub2 to install on systems with small starting
>> areas. I have a system with only 64 sectors (0-63) running grub2 just fine.
>>
>> Yes, preupgrade should catch these cases before doing any work. Since
>> I've gone through all the pain on several systems I'm too tired to file
>> an RFE.
> 
> The more I think about this the more bizarre it is that preupgrade doesn't catch this.
> 
> Almost all (all?) users of preupgrade are using grub1.

yes

> As I understand it, most (all?) grub1 systems have the first partition starting at 63.

no, only the one who survived fedora some time :-)
with F14 a new install started at 2048 (my currently physical hardware)

but i have no understanding for changes / replacemenets brikcing well
running systems installed years ago because for me the main benefit
of a OS with package-managment is that it does not die slowly

if upgrade on perfect running virtual servers installed 2008 with F9
and survived until F15 will be bricked with F16 (GRUB2) or F17 (usrMove)
then the contributors should start to be much more careful or they will
sooner or later left alone and then they can do and brick what they want

but i have a little hope this is not the intention

yes i am not soo positive becasue the quality of the distribution
at release state is going down with each new version instead better

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120208/cdf4a784/attachment.sig>


More information about the users mailing list