Re: Preupgrade with multiboot: can't find right target (solved?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 12/11/10 22:04, John Pilkington wrote:
> Hi: I'm new to this list and haven't found a searchable archive, but I
> haven't seen this topic in Google.
> My box came with MS Vista and I initially added f10, which was fully
> updated until near EOL.  Later I added a second disk and f12, and
> recently I used preupgrade for f12-to-f13.  That went well, and I
> decided to try f10-to-f14.  The packages were identified and put into
> cache and after I had copied the new lines in grub.conf from disk 1 to
> disk 2 the upgrade entry appeared in the Grub menu.  The kernel boots
> but I don't think it sees the preupgrade cache and the only option
> offered is to upgrade the f13 system.  I don't want to do that.
> I've tried various modifications to grub.conf without success.  One
> recent iteration is below.  The f10final and f13 entries, and the MS
> related ones, all work and I've left the f10release entry in case it
> holds useful data.  I downloaded the f14 installer and when I specify
> its location on disk 2, (/dev/sdb1  /install.img) it runs.  Again, the
> location specified in grub.conf apparently doesn't get used, although
> it's there too.
> TIA,  John P.
> -----------------
> # grub.conf generated by anaconda
> #
> # Note that you do not have to rerun grub after making changes to this file
> # NOTICE:  You have a /boot partition.  This means that
> #          all kernel and initrd paths are relative to /boot/, eg.
> #          root (hd1,1)
> #          kernel /vmlinuz-version ro root=/dev/mapper/VolGroup-lv_root
> #          initrd /initrd-[generic-]version.img
> #boot=/dev/sda
> default=1
> timeout=15
> splashimage=(hd1,1)/grub/splash.xpm.gz
> # hiddenmenu
> title Upgrade to Fedora 14 (Laughlin)
>           root (hd0,2)
>           kernel /upgrade/vmlinuz preupgrade
> root=UUID=db9d32af-2d48-42bc-beed-2ed149eb21a1
> repo=/var/cache/yum/preupgrade stage2=/var/cache/yum/install.img
>           initrd /upgrade/initrd.img
> title Fedora (
> 	root (hd1,1)
> 	kernel /vmlinuz- ro
> root=/dev/mapper/VolGroup-lv_root  LANG=en_US.UTF-8
> SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=uk rhgb quiet
> elevator=deadline
> 	initrd /initramfs-
> title Fedora10final (
>           root (hd0,2)
>           kernel /vmlinuz- ro
> root=/dev/VolGroup00/LogVol00 rhgb quiet elevator=deadline
>           initrd /initrd-
> title Fedora10release (
>           root (hd0,2)
>           kernel /vmlinuz- ro
> root=UUID=db9d32af-2d48-42bc-beed-2ed149eb21a1 rhgb quiet
>           initrd /initrd-
> title Vista_sp1
>           rootnoverify (hd0,1)
>           makeactive
>           chainloader +1
> title GatewayRecovery
>           rootnoverify (hd0,0)
>           makeactive
>           chainloader +1
> -----------------------
I had several responses to this, all essentially saying that skipping 
releases in preupgrade was likely to cause grief.  That's probably true, 
but I thought I would persevere and tried f10 > f12; in doing so I found 
the reason why my previous attempt had failed when it did, which was, as 
I suspected, that the right partitions were not being accessed.  Partly 
I wasn't clear which system was active at each stage.

The box has two /boot partitions, one on each disk.  Preupgrade  writes 
to only one, and in this case the active version of grub.conf was the 
other one, so some editing was needed.  The f10 > f12 preupgrade created 
different addressing information and I was able to piece together a 
working grub.conf entry as follows:
title Upgrade to Fedora 12 (Constantine)
         root (hd0,2)
         kernel /upgrade/vmlinuz preupgrade 
         initrd /upgrade/initrd.img

Here the repo UUID was that of the target /root partition, and the 
stage2 and ks UUIDs were that of the target /boot partition (aka 
(hd0,2)), which this time also (just) held the downloaded install.img. 
I hadn't been able to create a working syntax for the earlier attempt, 
and it rather looks as if ks.cfg got lost somewhere.

The system booted and the upgrade went ahead, but didn't update either 
of the grub.conf files, so I modified the old f10 entries to identify 
the new kernel.

The new system works, but not yet perfectly - I still have some 
nouveau/nvidia conflicts to sort out.  It looks hopeful but there may 
still be trouble ahead.  I shall never know whether f10 > f14 could have 

John P

users mailing list
[email protected]
To unsubscribe or change subscription options:

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux