Michael, did you follow the Andras->Tom Horsley link?
Yes. See my previous reply. done some experimenting since. My machine can still boot from my FC13 installation disk. I let it get as far as offering to test the media. I can't find my F14 disk. I copied FC13's vmlinuz to a hard drive and tried again with the grub command line. The kernel command segfaulted again. I even did a yum reinstall grub, but it didn't help. The kernel command still segfaulted.
I don't follow you at all; You are evidently even having trouble on your existing F!3 (or F14), exactly how I don't understand. You do need a working linux to do the hdinstall.
--you are evidently not using a grub.conf but rather running grub from the cmdline, which in my opinion just further makes it likely to make errors.
--you are evidently using a kickstart ks.cfg, about which I know nothing, but ks.cfg is not used in the Horsley prescription
--why are you using the 'find' cmd in grub? You should know _exactly_ where you put the vmlinuz,initrd.img files extracted from the iso. And that info should be easily placed into a grub.conf stanza. You can also rename those files to vmlinuz-install, initrd.img-install which is recommended in the fedora project info, and which makes clear that they are intended for an "install" stanza, not to be confused with normal vmlinuz,....
Jack
On Thu, 22 Mar 2012, jackson byers wrote:
Michael, did you follow the Andras->Tom Horsley link?
Yes. See my previous reply. done some experimenting since. My machine can still boot from my FC13 installation disk. I let it get as far as offering to test the media. I can't find my F14 disk. I copied FC13's vmlinuz to a hard drive and tried again with the grub command line. The kernel command segfaulted again. I even did a yum reinstall grub, but it didn't help. The kernel command still segfaulted.
I don't follow you at all; You are evidently even having trouble on your existing F!3 (or F14), exactly how I don't understand. You do need a working linux to do the hdinstall.
I have F14 installed, but F13 is the most recent DVD I can find.
--you are evidently not using a grub.conf but rather running grub from the cmdline, which in my opinion just further makes it likely to make errors.
I've done it both ways. The constant rebooting and logging in gets tedious. I don't type into the grub comand line, I use a file as standard input.
--you are evidently using a kickstart ks.cfg, about which I know nothing, but ks.cfg is not used in the Horsley prescription
In the interest of ease of diagnosis, I've left it off this time.
--why are you using the 'find' cmd in grub?
Documenting that the files were there.
You should know _exactly_ where you put the vmlinuz,initrd.img files extracted from the iso. And that info should be easily placed into a grub.conf stanza.
I wanted to demonstrate to potential helpers that I gave grub the correct information.
You can also rename those files to vmlinuz-install, initrd.img-install which is recommended in the fedora project info, and which makes clear that they are intended for an "install" stanza, not to be confused with normal vmlinuz,....
I was following the Andras->Tom Horsley link somewhat slavishly.
Here is my most recent effort. The last stanza in grub.conf is: title Install Fedora from iso root (hd0,2) pause have rooted find /isolinux/vmlinuz pause have finded kernel /isolinux/vmlinuz repo=hd:LABEL=/home1:/ pause have kerneled find /isolinux/initrd.img pause have finded initrd /isolinux/initrd.img pause have initrded #The /boot/f15x directory is where I extracted the vmlinuz #and initrd.img files from the isolinux directory on #the iso image, and /zooty/salvage/iso-images/Fedora-15-Beta-x86_64-DVD/ #is the directory where I saved the iso image (where #the /zooty mountpoint mounts a partition with the label ZOOTY).
All the pauses happened. The last line before catatonia ended: BUG: unable to handle kernel.
The kernel is the one I copied from the installation iso. [root@localhost isolinux]# sha256sum vmlinuz 73ca29c9e5d819b238f872fc8321c61720abdb4df04c714456c8b1ce5c174419 vmlinuz
Also, the DVD iso is where I told the kernel it was: [root@localhost ~]# e2label /dev/sdb1 /home1 [root@localhost ~]# df /homes Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb1 38456308 28798716 7704092 79% /homes [root@localhost ~]# ls /homes F13 Fedora-14-i386-DVD.iso.gz hennebry F16 Fedora-16-i386-DVD.iso lost+found
2012/3/22, Michael Hennebry hennebry@web.cs.ndsu.nodak.edu:
[...]
#The /boot/f15x directory is where I extracted the vmlinuz #and initrd.img files from the isolinux directory on #the iso image, and /zooty/salvage/iso-images/Fedora-15-Beta-x86_64-DVD/ #is the directory where I saved the iso image (where #the /zooty mountpoint mounts a partition with the label ZOOTY).
Just a shot in the dark: aren't you by any chance trying to install 64-bit Fedora on a 32-bit computer?
Andras
On Thu, 22 Mar 2012, Andras Simon wrote:
2012/3/22, Michael Hennebry hennebry@web.cs.ndsu.nodak.edu:
[...]
#The /boot/f15x directory is where I extracted the vmlinuz #and initrd.img files from the isolinux directory on #the iso image, and /zooty/salvage/iso-images/Fedora-15-Beta-x86_64-DVD/ #is the directory where I saved the iso image (where #the /zooty mountpoint mounts a partition with the label ZOOTY).
Just a shot in the dark: aren't you by any chance trying to install 64-bit Fedora on a 32-bit computer?
No. I'm using Fedora-16-i386-DVD.iso and files from it.
2012/3/22, Michael Hennebry hennebry@web.cs.ndsu.nodak.edu:
On Thu, 22 Mar 2012, Andras Simon wrote:
2012/3/22, Michael Hennebry hennebry@web.cs.ndsu.nodak.edu:
[...]
#The /boot/f15x directory is where I extracted the vmlinuz #and initrd.img files from the isolinux directory on #the iso image, and /zooty/salvage/iso-images/Fedora-15-Beta-x86_64-DVD/ #is the directory where I saved the iso image (where #the /zooty mountpoint mounts a partition with the label ZOOTY).
Just a shot in the dark: aren't you by any chance trying to install 64-bit Fedora on a 32-bit computer?
No. I'm using Fedora-16-i386-DVD.iso and files from it.
OK, so the directory name Fedora-15-Beta-x86_64-DVD above is accidental. Too bad. It would've been a nice and easy solution.
Andras
On Thu, 22 Mar 2012 17:01:25 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Thu, 22 Mar 2012, Andras Simon wrote:
2012/3/22, Michael Hennebry hennebry@web.cs.ndsu.nodak.edu:
[...]
#The /boot/f15x directory is where I extracted the vmlinuz #and initrd.img files from the isolinux directory on #the iso image, and /zooty/salvage/iso-images/Fedora-15-Beta-x86_64-DVD/ #is the directory where I saved the iso image (where #the /zooty mountpoint mounts a partition with the label ZOOTY).
Just a shot in the dark: aren't you by any chance trying to install 64-bit Fedora on a 32-bit computer?
No. I'm using Fedora-16-i386-DVD.iso and files from it.
Is it possible that the kernel isn't relocatable? i.e. it expects to run from a specific address, and that address isn't available. I'm not sure how to check that, but the boot directory usually has the config files for each installed kernel, and maybe you could grep it for the appropriate switch. Again, I don't know the name of that switch, I just know that I've seen it while configuring a kernel.
Another idea. Maybe you can run dracut on the vmlinuz from the DVD, and generate a custom (I think that is the -h option) initramfs for your system. Use it instead of the one from the DVD when you boot from grub.
On Thu, 22 Mar 2012, stan wrote:
Is it possible that the kernel isn't relocatable? i.e. it expects to run from a specific address, and that address isn't available. I'm not
Do you mean a RAM address? How would a RAM address not be available?
sure how to check that, but the boot directory usually has the config files for each installed kernel, and maybe you could grep it for the appropriate switch. Again, I don't know the name of that switch, I just know that I've seen it while configuring a kernel.
Since the iso didn't have them, I suspect that the install kernel doesn't use them.
It might be difficult for me to fight the switch with the erroneous default, ascertain that the default is erroneous, find the right value for the switch and persuade the install kernel to use it.
I have noticed that all my kernels end in .PAE . Could that be significant?
Another idea. Maybe you can run dracut on the vmlinuz from the DVD, and generate a custom (I think that is the -h option) initramfs for your system. Use it instead of the one from the DVD when you boot from grub.
I've no idea how I would improve the initram already there. I don't even understand: dracut [OPTION]... <image> <kernel-version> <image>? <kernel-version>?
On Thu, 22 Mar 2012 18:04:16 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Thu, 22 Mar 2012, stan wrote:
Is it possible that the kernel isn't relocatable? i.e. it expects to run from a specific address, and that address isn't available. I'm not
Do you mean a RAM address? How would a RAM address not be available?
Perhaps Grub2 is using it somehow? These suggestions are longshots. You've already eliminated the simple and obvious things, it seems.
sure how to check that, but the boot directory usually has the config files for each installed kernel, and maybe you could grep it for the appropriate switch. Again, I don't know the name of that switch, I just know that I've seen it while configuring a kernel.
Since the iso didn't have them, I suspect that the install kernel doesn't use them.
It might be difficult for me to fight the switch with the erroneous default, ascertain that the default is erroneous, find the right value for the switch and persuade the install kernel to use it.
I have noticed that all my kernels end in .PAE . Could that be significant?
If you are trying to install a 64 bit version, it *could* be. Is it possible that the system in question isn't 64 bit? PAE is the extension that means that a kernel is 32 bit, but has an extension to allow it to address more than 2 (?) Gb of memory. It means you've been running 32 bit systems up to now.
Another idea. Maybe you can run dracut on the vmlinuz from the DVD, and generate a custom (I think that is the -h option) initramfs for your system. Use it instead of the one from the DVD when you boot from grub.
I've no idea how I would improve the initram already there. I don't even understand: dracut [OPTION]... <image> <kernel-version> <image>?
initramfs
<kernel-version>?
vmlinuz version
This is an example of the command I use to generate a custom initramfs for my system.
/sbin/dracut -f -H -v --debug custom-2.6.42.10-1.20120315.fc15.x86_64.img 2.6.42.10-1.20120315.fc15.x86_64 > dracut_output 2>&1
You should name the custom part whatever you want to call the initramfs, and put the version of the vmlinuz in the second part. It doesn't need the vmlinuz on the front. If there are any errors, they will be in the dracut_output. You could split the output so errors go to their own file, > dracut_output 2> dracut_error, if you want. I've never tried this with a DVD image, so it might not work.
On Thu, 22 Mar 2012, stan wrote:
On Thu, 22 Mar 2012 18:04:16 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Thu, 22 Mar 2012, stan wrote:
Is it possible that the kernel isn't relocatable? i.e. it expects to run from a specific address, and that address isn't available. I'm not
Do you mean a RAM address? How would a RAM address not be available?
Perhaps Grub2 is using it somehow? These suggestions are longshots.
grub2 is not installed on my machine. If it's packaged with the install kernel, then I would expecct them to be a matched set.
You've already eliminated the simple and obvious things, it seems.
sure how to check that, but the boot directory usually has the config files for each installed kernel, and maybe you could grep it for the appropriate switch. Again, I don't know the name of that switch, I just know that I've seen it while configuring a kernel.
Since the iso didn't have them, I suspect that the install kernel doesn't use them.
It might be difficult for me to fight the switch with the erroneous default, ascertain that the default is erroneous, find the right value for the switch and persuade the install kernel to use it.
I have noticed that all my kernels end in .PAE . Could that be significant?
Oops. I should have written .PAE.img
If you are trying to install a 64 bit version, it *could* be. Is it possible that the system in question isn't 64 bit? PAE is the extension that means that a kernel is 32 bit, but has an extension to allow it to address more than 2 (?) Gb of memory. It means you've been running 32 bit systems up to now.
My machine is 32 bit. Its cpu is a pentium 4. [hennebry@localhost ~]$ uname -a Linux localhost.localdomain 2.6.35.14-106.fc14.i686.PAE #1 SMP Wed Nov 23 13:39:51 UTC 2011 i686 i686 i386 GNU/Linux
Another idea. Maybe you can run dracut on the vmlinuz from the DVD, and generate a custom (I think that is the -h option) initramfs for your system. Use it instead of the one from the DVD when you boot from grub.
I've no idea how I would improve the initram already there. I don't even understand: dracut [OPTION]... <image> <kernel-version> <image>?
initramfs
A sequence of bytes representing one partition containing the root file system?
<kernel-version>?
vmlinuz version
The name of a kernel?
This is an example of the command I use to generate a custom initramfs for my system.
/sbin/dracut -f -H -v --debug custom-2.6.42.10-1.20120315.fc15.x86_64.img 2.6.42.10-1.20120315.fc15.x86_64 > dracut_output 2>&1
You should name the custom part whatever you want to call the initramfs, and put the version of the vmlinuz in the second part. It doesn't need the vmlinuz on the front. If there are any errors, they
What does the version do?
will be in the dracut_output. You could split the output so errors go to their own file, > dracut_output 2> dracut_error, if you want. I've never tried this with a DVD image, so it might not work.
Are you suggesting that I make the DVD filesystem part of the initial ramdisk image? Wouldn't I also need whatever was in the prepackaged initial ramdisk image? How might the new ramdisk help me?
On Thu, 22 Mar 2012 22:23:54 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Thu, 22 Mar 2012, stan wrote:
Perhaps Grub2 is using it somehow? These suggestions are longshots.
grub2 is not installed on my machine. If it's packaged with the install kernel, then I would expecct them to be a matched set.
Then grub might be using it, and anaconda might not expect that from the DVD. As I said, this seems unlikely, but possible.
I have noticed that all my kernels end in .PAE . Could that be significant?
Oops. I should have written .PAE.img
Kernels don't end in .img, that's the initrd / initramfs. Here is a sample kernel name: vmlinuz-2.6.42.12-1.20120323.fc15.x86_64 Here is the rpm initramfs file name for that kernel: initramfs-2.6.42.12-1.20120323.fc15.x86_64.img
My machine is 32 bit. Its cpu is a pentium 4. [hennebry@localhost ~]$ uname -a Linux localhost.localdomain 2.6.35.14-106.fc14.i686.PAE #1 SMP Wed Nov 23 13:39:51 UTC 2011 i686 i686 i386 GNU/Linux
I think pentium 4 is fairly old hardware. I doubt either the kernel developers or Fedora developers are using such hardware, and so you could be hitting a regression that wasn't caught during kernel development because no one is running that hardware.
Another idea. Maybe you can run dracut on the vmlinuz from the DVD, and generate a custom (I think that is the -h option) initramfs for your system. Use it instead of the one from the DVD when you boot from grub.
I've no idea how I would improve the initram already there. I don't even understand: dracut [OPTION]... <image> <kernel-version> <image>?
initramfs
A sequence of bytes representing one partition containing the root file system?
From the man page, "dracut creates an initial image used by the kernel for preloading the block device modules (such as IDE, SCSI or RAID) which are needed to access the root filesystem." In your case, this will be the drivers for the hard drives you have.
<kernel-version>?
vmlinuz version
The name of a kernel?
No, the version of a kernel. In the kernel line from /boot vmlinuz-2.6.42.12-1.20120323.fc15.x86_64 vmlinuz is the name, and the rest is the version.
This is an example of the command I use to generate a custom initramfs for my system.
/sbin/dracut -f -H -v --debug custom-2.6.42.10-1.20120315.fc15.x86_64.img 2.6.42.10-1.20120315.fc15.x86_64 > dracut_output 2>&1
You should name the custom part whatever you want to call the initramfs, and put the version of the vmlinuz in the second part. It doesn't need the vmlinuz on the front. If there are any errors, they
What does the version do?
It tells it which kernel to create the initramfs for.
will be in the dracut_output. You could split the output so errors go to their own file, > dracut_output 2> dracut_error, if you want. I've never tried this with a DVD image, so it might not work.
Are you suggesting that I make the DVD filesystem part of the initial ramdisk image? Wouldn't I also need whatever was in the prepackaged initial ramdisk image? How might the new ramdisk help me?
No. I am suggesting you create a custom initramfs for the DVD kernel for your system. Use it instead of the generic DVD initramfs. I am suggesting this because it might allow the boot process to bypass the problem it is having running the DVD kernel. It should still find the ISO image because of the kernel line parameters. And you could be right above. I don't know if it requires the DVD ISO9660 fs or not in the initramfs. I think it should be able to get that from the kernel, as it is probably compiled in or a module. I don't know if this will work, as this too is a long shot, but long shots seems to be all you have left to try.
On Fri, 23 Mar 2012, stan wrote:
On Thu, 22 Mar 2012 22:23:54 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Thu, 22 Mar 2012, stan wrote:
I have noticed that all my kernels end in .PAE . Could that be significant?
Oops. I should have written .PAE.img
Kernels don't end in .img, that's the initrd / initramfs. Here is a sample kernel name: vmlinuz-2.6.42.12-1.20120323.fc15.x86_64 Here is the rpm initramfs file name for that kernel: initramfs-2.6.42.12-1.20120323.fc15.x86_64.img
Oops. Right the first time. The kernels end in .PAE . The ramdisk images end in .PAE.img .
I think pentium 4 is fairly old hardware. I doubt either the kernel developers or Fedora developers are using such hardware, and so you could be hitting a regression that wasn't caught during kernel development because no one is running that hardware.
Any idea how I would find out for sure?
No. I am suggesting you create a custom initramfs for the DVD kernel for your system. Use it instead of the generic DVD initramfs. I am suggesting this because it might allow the boot process to bypass the problem it is having running the DVD kernel. It should still find the
That also means that I would have to generate the image somehow. I've no idea how I would do that.
On Fri, 23 Mar 2012 16:30:19 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Fri, 23 Mar 2012, stan wrote:
I think pentium 4 is fairly old hardware. I doubt either the kernel developers or Fedora developers are using such hardware, and so you could be hitting a regression that wasn't caught during kernel development because no one is running that hardware.
Any idea how I would find out for sure?
Sorry, I don't, and doing so is likely to be difficult - you could try searching. But you seem to be a rare case having a problem installing from the DVD, and you have rare hardware; correlation isn't causation, but... To see if it was introduced with the branch from 2.6.3x to 3.x, which seems like a logical assumption, you could try using the F15 install DVD. It still used the 2.6.3x kernels, though it is now updated to 3.2.x kernels as 2.6.42.x.
No. I am suggesting you create a custom initramfs for the DVD kernel for your system. Use it instead of the generic DVD initramfs. I am suggesting this because it might allow the boot process to bypass the problem it is having running the DVD kernel. It should still find the
That also means that I would have to generate the image somehow. I've no idea how I would do that.
That's the command I posted a few posts ago. /sbin/dracut -f -H -v --debug custom-2.6.42.10-1.20120315.fc15.x86_64.img 2.6.42.10-1.20120315.fc15.x86_64 > dracut_output 2>&1 You use dracut. Whatever name you use where I've used custom, you need to use it in the grub boot stanza for booting the ISO from the hard drive. In the stanza you posted before, initrd /isolinux/initrd.img replace initrd.img with whatever you call the new image you create with dracut.
On Fri, 23 Mar 2012 16:30:19 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Fri, 23 Mar 2012, stan wrote:
I think pentium 4 is fairly old hardware. I doubt either the kernel developers or Fedora developers are using such hardware, and so you could be hitting a regression that wasn't caught during kernel development because no one is running that hardware.
Any idea how I would find out for sure?
This bugzilla seems especially pertinent to your problem. https://bugzilla.redhat.com/show_bug.cgi?id=730007
I managed to boot from the F13, F14 and F15 install isos. Still no go with F16.
To boot F13, I needed to point at a partition that was a copy of the F13 iso. To boot F14 and F15, I needed to point at a filesystem that had their respective isos as files.
For F15, I did the install. F16 seems to be impossible. I've still got crap. Here is the grub stanza: title Install Fedora15 from iso root (hd0,2) pause have rooted find /isolinux15/vmlinuz pause have finded kernel /isolinux15/vmlinuz askmethod pause have kerneled find /isolinux15/initrd.img pause have finded initrd /isolinux15/initrd.img pause have initrded # ks=http://www.cs.ndsu.nodak.edu/~hennebry/anaconda-ks.cfg
I couldn't use the kickstart file. I kept getting messages like this: Unable to read package metadata. This may be due to a missing repodata directory. Please ensure that your install tree has been correctly generated.
Cannot retrieve repository metadata (repomd.xml) for repository: Fedora 15-i386. Please verify its path and try again.
The kickstart file is attached.
The old /boot was /dev/sdb2 . The new one is /dev/sda2 . When asking where to put the bootloader, the choices were the mbr of /dev/sdb or the first sector of /dev/sdb2 . I chose the latter. I'm not sure why the other mbr was not an option.
When I first tried what was supposed to be the initial reboot, my old /boot , now called /shoe , was used. I pushed reset, went into setup and reversed the hard drive boot order. The result was not quite the blue screen of death. It also had the word GRUB. I pushed reset again, went into setup and reversed the hard drive boot order. This time I went into the grub command line and chainloaded into (hd0,1). I am currently using the result.
How do I make my machine boot with the new /boot ?
At the moment, I do not have vim or gvim. Here is what happened when I tried to get them: [root@localhost ~]# yum install gvim rpmdb: __db_meta_setup: /var/lib/rpm/Name: unexpected file type or format error: cannot open Name index using db3 - Invalid argument (22) rpmdb: __db_meta_setup: /var/lib/rpm/Providename: unexpected file type or format error: cannot open Providename index using db3 - Invalid argument (22) Loaded plugins: langpacks, presto, refresh-packagekit Adding en_US to language list rpmdb: __db_meta_setup: /var/lib/rpm/Name: unexpected file type or format rpmdb: __db_meta_setup: /var/lib/rpm/Name: unexpected file type or format fedora/metalink | 24 kB 00:00 Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=... error was No repomd file Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again
How do I get gvim?
-- Michael hennebry@web.cs.ndsu.NoDak.edu "On Monday, I'm gonna have to tell my kindergarten class, whom I teach not to run with scissors, that my fiance ran me through with a broadsword." -- Lily
On Sat, 24 Mar 2012 21:28:43 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
I managed to boot from the F13, F14 and F15 install isos. Still no go with F16.
To boot F13, I needed to point at a partition that was a copy of the F13 iso. To boot F14 and F15, I needed to point at a filesystem that had their respective isos as files.
For F15, I did the install. F16 seems to be impossible. I've still got crap. Here is the grub stanza: title Install Fedora15 from iso root (hd0,2) pause have rooted find /isolinux15/vmlinuz pause have finded kernel /isolinux15/vmlinuz askmethod pause have kerneled find /isolinux15/initrd.img pause have finded initrd /isolinux15/initrd.img pause have initrded # ks=http://www.cs.ndsu.nodak.edu/~hennebry/anaconda-ks.cfg
I couldn't use the kickstart file. I kept getting messages like this: Unable to read package metadata. This may be due to a missing repodata directory. Please ensure that your install tree has been correctly generated.
Cannot retrieve repository metadata (repomd.xml) for repository: Fedora 15-i386. Please verify its path and try again.
The kickstart file is attached.
Thanks for the blow by blow, good for future reference.
The old /boot was /dev/sdb2 . The new one is /dev/sda2 . When asking where to put the bootloader, the choices were the mbr of /dev/sdb or the first sector of /dev/sdb2 . I chose the latter. I'm not sure why the other mbr was not an option.
I think it depends on the BIOS setting. Whichever disk is set as boot disk in the BIOS gets the mbr (so you can boot from it). If you want the other disk to get the mbr, it needs to be the boot disk. Hmmm, that seems to be sort of a catch-22. You probably need to boot a recovery disk and install the second disk before you can make it the boot disk. Or install it with grub directly when you boot it as below.
When I first tried what was supposed to be the initial reboot, my old /boot , now called /shoe , was used.
It must the default in the BIOS.
I pushed reset, went into setup and reversed the hard drive boot order. The result was not quite the blue screen of death. It also had the word GRUB.
I can't give you the commands off the top of my head, but I think from past reading of the grub manuals (pinfo grub), you could have fixed everything right then using grub.
I pushed reset again, went into setup and reversed the hard drive boot order. This time I went into the grub command line and chainloaded into (hd0,1). I am currently using the result.
How do I make my machine boot with the new /boot ?
Here is the grub stanza I use to boot a version on another boot partition, where the /boot is a separate partition. If your boot is under /, you will need to prepend /boot to the configfile line.
title Fedora 15 sata 1 boot 2 root (hd1,1) configfile /grub/menu.lst
If you use the above in your original grub, you will boot from the original disk, and then choose this stanza, and it will give you another menu for the boot partition on the second drive, and you can choose your kernel there.
At the moment, I do not have vim or gvim.
No vim? Are you sure the install was successful? I didn't think it was possible to install Fedora without at least vim-minimal linked as vi.
Here is what happened when I tried to get them: [root@localhost ~]# yum install gvim rpmdb: __db_meta_setup: /var/lib/rpm/Name: unexpected file type or format error: cannot open Name index using db3 - Invalid argument (22) rpmdb: __db_meta_setup: /var/lib/rpm/Providename: unexpected file type or format error: cannot open Providename index using db3 - Invalid argument (22) Loaded plugins: langpacks, presto, refresh-packagekit Adding en_US to language list rpmdb: __db_meta_setup: /var/lib/rpm/Name: unexpected file type or format rpmdb: __db_meta_setup: /var/lib/rpm/Name: unexpected file type or format fedora/metalink | 24 kB 00:00 Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=... error was No repomd file Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again
How do I get gvim?
There is something wrong with your install.
You can try rebuilding your rpm database as root. rpm --rebuilddb This will take a while, depending on your package count.
Do you have internet access? You can go directly to the Fedora website, go to one of the repositories, and download all the vim and gvim RPMs directly. Then do a yum -C install <list of RPMs here> in the directory where they are located.
While you are there, get the F15 repository RPM, fedora-release-15-3.noarch and re-install it to try to fix your yum problem.
On Sun, 25 Mar 2012, stan wrote:
On Sat, 24 Mar 2012 21:28:43 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
I couldn't use the kickstart file. I kept getting messages like this: Unable to read package metadata. This may be due to a missing repodata directory. Please ensure that your install tree has been correctly generated.
Cannot retrieve repository metadata (repomd.xml) for repository: Fedora 15-i386. Please verify its path and try again.
The kickstart file is attached.
Thanks for the blow by blow, good for future reference.
The old /boot was /dev/sdb2 . The new one is /dev/sda2 . When asking where to put the bootloader, the choices were the mbr of /dev/sdb or the first sector of /dev/sdb2 . I chose the latter. I'm not sure why the other mbr was not an option.
I think it depends on the BIOS setting. Whichever disk is set as boot disk in the BIOS gets the mbr (so you can boot from it). If you want the other disk to get the mbr, it needs to be the boot disk. Hmmm, that seems to be sort of a catch-22. You probably need to boot a recovery disk and install the second disk before you can make it the boot disk. Or install it with grub directly when you boot it as below.
When I first tried what was supposed to be the initial reboot, my old /boot , now called /shoe , was used.
It must the default in the BIOS.
I pushed reset, went into setup and reversed the hard drive boot order. The result was not quite the blue screen of death. It also had the word GRUB.
I can't give you the commands off the top of my head, but I think from past reading of the grub manuals (pinfo grub), you could have fixed everything right then using grub.
The almost blue screen of death wasn't completely blue, but it was completely death. Once upon a time I could boot from sda. sdb was an add-on. I'd have thought that making sda number one again would let me boot from it.
I pushed reset again, went into setup and reversed the hard drive boot order. This time I went into the grub command line and chainloaded into (hd0,1). I am currently using the result.
How do I make my machine boot with the new /boot ?
Here is the grub stanza I use to boot a version on another boot partition, where the /boot is a separate partition. If your boot is under /, you will need to prepend /boot to the configfile line.
title Fedora 15 sata 1 boot 2 root (hd1,1) configfile /grub/menu.lst
If you use the above in your original grub, you will boot from the original disk, and then choose this stanza, and it will give you another menu for the boot partition on the second drive, and you can choose your kernel there.
I'd need (hd0,1) . hd1 is the new disk. It holds the old /boot for F14, /shoe for F15. hd0 is the disk that came with my machine. It holds /boot for F15. It seems to me that I really should be able to boot from hd0 again.
At the moment, I do not have vim or gvim.
No vim? Are you sure the install was successful? I didn't think it was possible to install Fedora without at least vim-minimal linked as vi.
Here is what happened when I tried to get them: [root@localhost ~]# yum install gvim rpmdb: __db_meta_setup: /var/lib/rpm/Name: unexpected file type or format error: cannot open Name index using db3 - Invalid argument (22) rpmdb: __db_meta_setup: /var/lib/rpm/Providename: unexpected file type or format error: cannot open Providename index using db3 - Invalid argument (22) Loaded plugins: langpacks, presto, refresh-packagekit Adding en_US to language list rpmdb: __db_meta_setup: /var/lib/rpm/Name: unexpected file type or format rpmdb: __db_meta_setup: /var/lib/rpm/Name: unexpected file type or format fedora/metalink | 24 kB 00:00 Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=... error was No repomd file Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again
How do I get gvim?
There is something wrong with your install.
You can try rebuilding your rpm database as root. rpm --rebuilddb This will take a while, depending on your package count.
That did it. I can use yum now. Of course that does not explain what happened in the first place.
Also, I clilcked on at least three desktop environments. gnome is the only one that seems to be installed.
On Sun, 25 Mar 2012 18:04:47 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Sun, 25 Mar 2012, stan wrote:
There is something wrong with your install.
You can try rebuilding your rpm database as root. rpm --rebuilddb This will take a while, depending on your package count.
That did it. I can use yum now.
Excellent, sounds like you are in business.
Of course that does not explain what happened in the first place.
The database wasn't written properly because of hard drive or power problems? Faulty power supply levels can do really flaky things to a computer.
Also, I clilcked on at least three desktop environments. gnome is the only one that seems to be installed.
It sounds like the install really had issues. You should be able to groupinstall with yum now.
Well, I screwed up royally again.
On Sun, 25 Mar 2012, stan wrote:
On Sun, 25 Mar 2012 18:04:47 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Sun, 25 Mar 2012, stan wrote:
There is something wrong with your install.
You can try rebuilding your rpm database as root. rpm --rebuilddb This will take a while, depending on your package count.
That did it. I can use yum now.
Excellent, sounds like you are in business.
Of course that does not explain what happened in the first place.
The database wasn't written properly because of hard drive or power problems? Faulty power supply levels can do really flaky things to a computer.
I really hope not. That would mean that fixing it would require cracking the case. The last time I did it, I zapped my video card. Even if everything went perfectly this time, I wouldn't know that.
I didn't know enough to trust the install, so I tried again, twice. The last time, I apparently told anaconda something bad about booting. Now, if I boot from disk sda, all I get is the grub command line. I can use the configfile to boot from that, but I would rather not. I've tried to use super-grub to fix it, but to know avail. Where is the magic spell to boot using sda2 as /boot ? I've been RTFM, but I've not been able to find it. super-grub didn't help.
Device Boot Start End Blocks Id System /dev/sda1 63 28676024 14337981 c W95 FAT32 (LBA) /dev/sda2 * 28676025 28871576 97776 83 Linux /dev/sda3 28871577 45668888 8398656 83 Linux /dev/sda4 45668889 78165359 16248235+ 5 Extended /dev/sda5 45668952 49574888 1952968+ 82 Linux swap / Solaris /dev/sda6 49574952 62856296 6640672+ 83 Linux /dev/sda7 62856360 78165359 7654500 83 Linux
Here is /grub/grub.conf from /dev/sda2 : # 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/sdb3 # initrd /initrd-[generic-]version.img #boot=/dev/sdb2 default=0 timeout=0 splashimage=(hd1,1)/grub/splash.xpm.gz hiddenmenu title Fedora (2.6.35.6-45.fc14.i686) root (hd1,1) kernel /vmlinuz-2.6.35.6-45.fc14.i686 ro root=UUID=f38145b3-1424-4162-8c93-2640827ba4b5 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet initrd /initramfs-2.6.35.6-45.fc14.i686.img
Note the 14's. Despite trying to install F15, I seem to have gotten F14. sda is the hard disk listed first in the BIOS.
Also, I clilcked on at least three desktop environments. gnome is the only one that seems to be installed.
On Wed, 28 Mar 2012, Michael Hennebry wrote:
Well, I screwed up royally again.
On Sun, 25 Mar 2012, stan wrote:
On Sun, 25 Mar 2012 18:04:47 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Sun, 25 Mar 2012, stan wrote:
There is something wrong with your install.
I think the problem was that I booted with F15 images, but it found an F14 DVD iso in the same directory. This time I made sure that the F15 DVD iso had its own directory. No problem except that since I didn't use kickstart, all the non-fedora stuff has to be intsalled by hand.
This time I let anaconda do what it wanted the bootloader. I was afraid not to. It says it put the bootloader on sda. It offered me the choice of changing it on sdb3, which is my / filesystem. /boot is sdb2 . Since /boot and / are on disk sdb, I'd like the bootloader there also. Frustration is bad for my brain. Ignore my previous request on this subject. I know how to change the boot hard disk in my BIOS. What else do I need to do? Is it written in TFM somewhere?
On Wed, 28 Mar 2012 23:33:49 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
Since /boot and / are on disk sdb, I'd like the bootloader there also. Frustration is bad for my brain. Ignore my previous request on this subject. I know how to change the boot hard disk in my BIOS. What else do I need to do?
You need to install the mbr on sdb. Then change your BIOS to make it the first boot disk, and you will boot sdb.
Is it written in TFM somewhere?
F15 still uses legacy grub as default. So, you can boot a rescue CD and install grub to the mbr on sdb, or boot onto sda, umount sdb, and use grub directly on the unmounted disk (I think I've seen this in the manual). The grub documentation is an info manual, and I find using pinfo (yum install pinfo?) best for reading these because it allows arrow key navigation instead of emacs key navigation like info itself. i.e. pinfo grub
On Thu, 29 Mar 2012, stan wrote:
On Wed, 28 Mar 2012 23:33:49 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
Since /boot and / are on disk sdb, I'd like the bootloader there also. Frustration is bad for my brain. Ignore my previous request on this subject. I know how to change the boot hard disk in my BIOS. What else do I need to do?
You need to install the mbr on sdb. Then change your BIOS to make it
I've tried to do this before. The best result was a grub command line on boot.
the first boot disk, and you will boot sdb.
Is it written in TFM somewhere?
F15 still uses legacy grub as default. So, you can boot a rescue CD and install grub to the mbr on sdb, or boot onto sda, umount sdb, and use grub directly on the unmounted disk (I think I've seen this in the
"Use grub" is not all that helpful. I really need more detail. TFM has not been my friend. It's not even clear to me why I would need to unmount the disk. I expect that unmounting the disk means to unmount all its partitions.
manual). The grub documentation is an info manual, and I find using
On Thu, 29 Mar 2012 12:16:11 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Thu, 29 Mar 2012, stan wrote:
On Wed, 28 Mar 2012 23:33:49 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
Since /boot and / are on disk sdb, I'd like the bootloader there also. Frustration is bad for my brain. Ignore my previous request on this subject. I know how to change the boot hard disk in my BIOS. What else do I need to do?
You need to install the mbr on sdb. Then change your BIOS to make it
I've tried to do this before. The best result was a grub command line on boot.
Then something isn't right. I have several disks with mbrs on them, and when I switch to them, they boot. As I said below, I'm rusty because everything has just worked for so long. I vaguely recall running a map command in grub so it enumerated the disks as it saw them. And installing the various stages, I think.
the first boot disk, and you will boot sdb.
Is it written in TFM somewhere?
F15 still uses legacy grub as default. So, you can boot a rescue CD and install grub to the mbr on sdb, or boot onto sda, umount sdb, and use grub directly on the unmounted disk (I think I've seen this in the
"Use grub" is not all that helpful. I really need more detail. TFM has not been my friend.
It's been years since I actually had to install an mbr. Perhaps someone else will have done it recently, but I would have to do research and experimentation in order to tell you what to do. Even then that would be on my system, not yours, and so might be inapplicable (your system seems to have many 'gotchas').
It's not even clear to me why I would need to unmount the disk. I expect that unmounting the disk means to unmount all its partitions.
Maybe you don't; it is probably my excessive addiction to prevention of problems. Umounted disks have no read write activity to interfere with the grub mbr write process. It shouldn't matter, and in fact grub2 seems to explicitly allow this on mounted disks, but I'm erring on the side of caution. Hey, breaking things and then fixing them is a great way to learn, but I'll pass.
-
Andras Simon -
Jackson Byers -
Michael Hennebry -
stan