I successfully created an install media on a USB flash drive, but now I have a minor problem installing from it. Whenever I run the installer, it insists on installing grub on /dev/sdb (the flash drive) rather than /dev/sda (the hard drive where I'm installing everything).
Is there a way to convince the installer to put grub in the right place? Should I just tell it not to install grub and then do a grub-install from a rescue prompt afterwards?
Bowie Bailey wrote, On 05/26/2010 10:59 AM:
I successfully created an install media on a USB flash drive, but now I have a minor problem installing from it. Whenever I run the installer, it insists on installing grub on /dev/sdb (the flash drive) rather than /dev/sda (the hard drive where I'm installing everything).
Is there a way to convince the installer to put grub in the right place?
If you are installing from a kickstart, or at least preparing the install using KS, yes. In my case it was easy, target of install was an IDE and source usb drive was detected as SCSI, in the kickstart file I was using I set: bootloader --driveorder=hda,sda granted I put that in a file that kickstart included, by building the file in the %pre section of the kickstart, i.e., I ran some detection routines to be sure of what I was putting in there.
however for yours, because both show up as sd? you will need to be aware of BIOS/kernel detection order. The detection order may be different between booting the install media bootloader and booting the final system grub.
Assuming you are using a kickstart file, you could probably program the %pre to figure out which is which by looking for a known UUID of the USB flash or its file system label and tell grub use anything else it finds first.
I believe the final file you would need to look at is /boot/grub/device.map grub and grub-install take options for this file.
Should I just tell it not to install grub and then do a grub-install from a rescue prompt afterwards?
painful, but possible.
Hopefully enough clues to be helpful.
Bowie Bailey wrote, On 05/26/2010 10:59 AM:
I successfully created an install media on a USB flash drive, but now I have a minor problem installing from it. Whenever I run the installer, it insists on installing grub on /dev/sdb (the flash drive) rather than /dev/sda (the hard drive where I'm installing everything).
Is there a way to convince the installer to put grub in the right place?
If you are installing from a kickstart, or at least preparing the install using KS, yes.
<snip> So, if you're *not*, and you just want to install on a new drive, then the Grand Unified Boot Loader religiously won't let you do what you want, since, it's *sure* (the same way M$ is), that it knows how to do this *so* much better than you do, and if you want to do it any other way, why that's the *wrong* way, and will do everything it can to keep you from doing it the "wrong" way.
Next time I bounce my system at home, I really ought to plug in /dev/hda again, and maybe I can access stuff on it - I had to physically unplug it, because a straight install *refused* to install the boot record in the MBR on /dev/sda....
mark
m.roth@5-cent.us wrote:
Bowie Bailey wrote, On 05/26/2010 10:59 AM:
I successfully created an install media on a USB flash drive, but now I have a minor problem installing from it. Whenever I run the installer, it insists on installing grub on /dev/sdb (the flash drive) rather than /dev/sda (the hard drive where I'm installing everything).
Is there a way to convince the installer to put grub in the right place?
If you are installing from a kickstart, or at least preparing the install using KS, yes.
<snip> So, if you're *not*, and you just want to install on a new drive, then the Grand Unified Boot Loader religiously won't let you do what you want, since, it's *sure* (the same way M$ is), that it knows how to do this *so* much better than you do, and if you want to do it any other way, why that's the *wrong* way, and will do everything it can to keep you from doing it the "wrong" way.
Next time I bounce my system at home, I really ought to plug in /dev/hda again, and maybe I can access stuff on it - I had to physically unplug it, because a straight install *refused* to install the boot record in the MBR on /dev/sda....
Agreed. It's truly obnoxious that we can specify which drive to install the OS onto, but we can't specify where to put the boot loader.
What I did was skip the grub install and then install it from the rescue prompt. Unfortunately, this left me with no grub.conf at all, so I had to look at another machine to get the proper format and manually create grub.conf. After that, however, it booted normally. I'm doing a 'yum update' now, which includes a new kernel. I'm keeping my fingers crossed that it will update my grub.conf properly.
Bowie wrote:
m.roth@5-cent.us wrote:
Bowie Bailey wrote, On 05/26/2010 10:59 AM:
I successfully created an install media on a USB flash drive, but now I have a minor problem installing from it. Whenever I run the installer, it insists on installing grub on /dev/sdb (the flash drive) rather than /dev/sda (the hard drive where I'm installing everything).
Is there a way to convince the installer to put grub in the right place?
<snip>
Agreed. It's truly obnoxious that we can specify which drive to install the OS onto, but we can't specify where to put the boot loader.
What I did was skip the grub install and then install it from the rescue prompt. Unfortunately, this left me with no grub.conf at all, so I had to look at another machine to get the proper format and manually create grub.conf. After that, however, it booted normally. I'm doing a 'yum update' now, which includes a new kernel. I'm keeping my fingers crossed that it will update my grub.conf properly.
Once it's on, it's fairly stable... though the update of the kernel does *not* always work correctly. With nearly 200 machines that I'm rolling out updates to, not infrequently, I'll see that the default= line in /etc/grub.conf is reset... to the last kernel,rather than the current, or to the debug kernel. I always have to check to verify that it's pointing correctly before rebooting.
mark
m.roth@5-cent.us wrote:
Bowie wrote:
Agreed. It's truly obnoxious that we can specify which drive to install the OS onto, but we can't specify where to put the boot loader.
What I did was skip the grub install and then install it from the rescue prompt. Unfortunately, this left me with no grub.conf at all, so I had to look at another machine to get the proper format and manually create grub.conf. After that, however, it booted normally. I'm doing a 'yum update' now, which includes a new kernel. I'm keeping my fingers crossed that it will update my grub.conf properly.
Once it's on, it's fairly stable... though the update of the kernel does *not* always work correctly. With nearly 200 machines that I'm rolling out updates to, not infrequently, I'll see that the default= line in /etc/grub.conf is reset... to the last kernel,rather than the current, or to the debug kernel. I always have to check to verify that it's pointing correctly before rebooting.
And, in fact, that is exactly what happened. The default= line was set to 1, so it booted the old kernel instead of the new one. Other than that, it seems to be fine. I wonder what causes that? I've never noticed that behavior in my other systems. (But maybe I should go check now...)
Bowie wrote:
m.roth@5-cent.us wrote:
Bowie wrote:
<snip>
Once it's on, it's fairly stable... though the update of the kernel does *not* always work correctly. With nearly 200 machines that I'm rolling out updates to, not infrequently, I'll see that the default= line in /etc/grub.conf is reset... to the last kernel,rather than the current, or to the debug kernel. I always have to check to verify that it's pointing correctly before rebooting.
And, in fact, that is exactly what happened. The default= line was set to 1, so it booted the old kernel instead of the new one. Other than that, it seems to be fine. I wonder what causes that? I've never noticed that behavior in my other systems. (But maybe I should go check now...)
I have *no* idea. I've even seen it pointing to 2, or 4. Anyone here have any idea why it wouldn't *always* change the default to 0?
mark
On Wed, 2010-05-26 at 14:57 -0400, m.roth@5-cent.us wrote:
Bowie wrote:
m.roth@5-cent.us wrote:
Bowie wrote:
<snip> >> Once it's on, it's fairly stable... though the update of the kernel does >> *not* always work correctly. With nearly 200 machines that I'm rolling >> out >> updates to, not infrequently, I'll see that the default= line in >> /etc/grub.conf is reset... to the last kernel,rather than the current, >> or >> to the debug kernel. I always have to check to verify that it's pointing >> correctly before rebooting. >> > And, in fact, that is exactly what happened. The default= line was set > to 1, so it booted the old kernel instead of the new one. Other than > that, it seems to be fine. I wonder what causes that? I've never > noticed that behavior in my other systems. (But maybe I should go check > now...)
I have *no* idea. I've even seen it pointing to 2, or 4. Anyone here have any idea why it wouldn't *always* change the default to 0?
mark
---- Where did you get the kernel from? There is a reason why I ask this because all installed kernels I have installed that were built by CentOS do the right thing. As in update the boot sequence for you.
The exception is The Upstream Real Time Kernel does not do this and is docoed.
Now the PAE Kernel I can not speak for because I do not use it. I only utilize the pae form for 32 bit under the RT Kernel which pae is built into for 32bits.
John
JohnS wrote:
On Wed, 2010-05-26 at 14:57 -0400, m.roth@5-cent.us wrote:
Bowie wrote:
m.roth@5-cent.us wrote:
Bowie wrote:
<snip>
Once it's on, it's fairly stable... though the update of the kernel does *not* always work correctly. With nearly 200 machines that I'm rolling out updates to, not infrequently, I'll see that the default= line in /etc/grub.conf is reset... to the last kernel,rather than the current, or to the debug kernel. I always have to check to verify that it's pointing correctly before rebooting.
And, in fact, that is exactly what happened. The default= line was set to 1, so it booted the old kernel instead of the new one. Other than that, it seems to be fine. I wonder what causes that? I've never noticed that behavior in my other systems. (But maybe I should go check now...)
I have *no* idea. I've even seen it pointing to 2, or 4. Anyone here have any idea why it wouldn't *always* change the default to 0?
mark
Where did you get the kernel from? There is a reason why I ask this because all installed kernels I have installed that were built by CentOS do the right thing. As in update the boot sequence for you.
The exception is The Upstream Real Time Kernel does not do this and is docoed.
Now the PAE Kernel I can not speak for because I do not use it. I only utilize the pae form for 32 bit under the RT Kernel which pae is built into for 32bits.
The kernel came from the updates repo. I just did "yum update" on a newly installed 5.5 system. The only oddity is that the original grub.conf file was created by hand rather than by anaconda. (Due to anaconda NOT doing "the right thing" when installing from a USB install media)
My theory is that the script that updates grub.conf is somehow detecting that the file is not stock and therefore updating the default= line to avoid changing the active kernel.
I looked through some of my other machines and was not able to find a single one that had anything other than default=0.
On Wed, 2010-05-26 at 14:57 -0400, m.roth@5-cent.us wrote:
Bowie wrote:
m.roth@5-cent.us wrote:
Bowie wrote:
<snip> >> Once it's on, it's fairly stable... though the update of the kernel >> does *not* always work correctly. With nearly 200 machines that I'm >> rolling out >> updates to, not infrequently, I'll see that the default= line in >> /etc/grub.conf is reset... to the last kernel,rather than the >> current, or to the debug kernel. I always have to check to verify >> that it's pointing correctly before rebooting. >> > And, in fact, that is exactly what happened. The default= line was > set to 1, so it booted the old kernel instead of the new one.
<snip>
I have *no* idea. I've even seen it pointing to 2, or 4. Anyone here have any idea why it wouldn't *always* change the default to 0?
Where did you get the kernel from? There is a reason why I ask this because all installed kernels I have installed that were built by CentOS do the right thing. As in update the boot sequence for you.
We build our own repository directly from an upstream CentOS mirror; in this case, mirror.cc.vt.edu::centos/5.5. The exact same thing happened with 5.4, and with some updates.
The exception is The Upstream Real Time Kernel does not do this and is docoed.
Nope. 64 bit plain, mostly, with an occasional 32 bit, and fewer PAE. No real time. <snip> mark
On 5/26/2010 2:37 PM, JohnS wrote:
And, in fact, that is exactly what happened. The default= line was set to 1, so it booted the old kernel instead of the new one. Other than that, it seems to be fine. I wonder what causes that? I've never noticed that behavior in my other systems. (But maybe I should go check now...)
I have *no* idea. I've even seen it pointing to 2, or 4. Anyone here have any idea why it wouldn't *always* change the default to 0?
mark
Where did you get the kernel from? There is a reason why I ask this because all installed kernels I have installed that were built by CentOS do the right thing. As in update the boot sequence for you.
The exception is The Upstream Real Time Kernel does not do this and is docoed.
Now the PAE Kernel I can not speak for because I do not use it. I only utilize the pae form for 32 bit under the RT Kernel which pae is built into for 32bits.
I think this fails where you initially install a non-PAE kernel and later add RAM and change to the PAE version.
On Wed, 2010-05-26 at 15:07 -0500, Les Mikesell wrote:
On 5/26/2010 2:37 PM, JohnS wrote:
And, in fact, that is exactly what happened. The default= line was set to 1, so it booted the old kernel instead of the new one. Other than that, it seems to be fine. I wonder what causes that? I've never noticed that behavior in my other systems. (But maybe I should go check now...)
I have *no* idea. I've even seen it pointing to 2, or 4. Anyone here have any idea why it wouldn't *always* change the default to 0?
mark
Where did you get the kernel from? There is a reason why I ask this because all installed kernels I have installed that were built by CentOS do the right thing. As in update the boot sequence for you.
The exception is The Upstream Real Time Kernel does not do this and is docoed.
Now the PAE Kernel I can not speak for because I do not use it. I only utilize the pae form for 32 bit under the RT Kernel which pae is built into for 32bits.
I think this fails where you initially install a non-PAE kernel and later add RAM and change to the PAE version.
--- How on Gods Green Earth is a STICK OF RAM going to change the damn BOOT Order? PFt my RAID 1ed Memory Just changed my boot order of my grid rack. Let me fix it back in the bios.
John
On 5/26/2010 3:17 PM, JohnS wrote:
And, in fact, that is exactly what happened. The default= line was set to 1, so it booted the old kernel instead of the new one. Other than that, it seems to be fine. I wonder what causes that? I've never noticed that behavior in my other systems. (But maybe I should go check now...)
I have *no* idea. I've even seen it pointing to 2, or 4. Anyone here have any idea why it wouldn't *always* change the default to 0?
mark
Where did you get the kernel from? There is a reason why I ask this because all installed kernels I have installed that were built by CentOS do the right thing. As in update the boot sequence for you.
The exception is The Upstream Real Time Kernel does not do this and is docoed.
Now the PAE Kernel I can not speak for because I do not use it. I only utilize the pae form for 32 bit under the RT Kernel which pae is built into for 32bits.
I think this fails where you initially install a non-PAE kernel and later add RAM and change to the PAE version.
How on Gods Green Earth is a STICK OF RAM going to change the damn BOOT Order? PFt my RAID 1ed Memory Just changed my boot order of my grid rack. Let me fix it back in the bios.
It's not the stick of RAM - it's the fact the the grub conf editing is set up to match your initial kernel type and isn't triggered by the install of the PAE kernel or it's subsequent updates. Look in /etc/sysconfig/kernel.
On Wed, 2010-05-26 at 15:29 -0500, Les Mikesell wrote:
It's not the stick of RAM - it's the fact the the grub conf editing is set up to match your initial kernel type and isn't triggered by the install of the PAE kernel or it's subsequent updates. Look in /etc/sysconfig/kernel.
---
Exceuse the spamming of the list please. Just a point to point out. POC Proven.
Maybe add kernel-pae for default. Not to hard to do. Installing one then the other should have no effect in updateing or going back to 'kernel' should have no problem and just update. Mine updated from RT back to Mainline but to go back to defacto RT I will have to edit it. Make any sense?
For others that are saying it want update the boot config then you may have something wrong somewhere because it should plain out update it.
Repo Mirrored Local
yum list kernel ### CentOS Kernel ONLY REPO. I have several repos. CentOS is the defacto repo here.
Loaded plugins: downloadonly, fastestmirror, kmod, versionlock Loading mirror speeds from cached hostfile Reading version lock configuration Installed Packages kernel.i686 2.6.18-164.9.1.el5 installed kernel.i686 2.6.18-164.10.1.el5 installed kernel.i686 2.6.18-164.11.1.el5 installed Available Packages kernel.i686 2.6.18-194.3.1.el5 updates
## BEFORE ##
[root@XXXX ~]# cat /boot/grub/grub.conf # 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 (hd0,0) # kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title JE2 Enterprise Linux (realtime) (2.6.24.7-149.el5) root (hd0,0) kernel /vmlinuz-2.6.24.7-149.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.24.7-149.el5.img title JE2 Enterprise Linux (2.6.24.7-149.el5trace) root (hd0,0) kernel /vmlinuz-2.6.24.7-149.el5trace ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.24.7-149.el5trace.img title JE2 Enterprise Linux (2.6.24.7-149.el5vanilla) root (hd0,0) kernel /vmlinuz-2.6.24.7-149.el5vanilla ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.24.7-149.el5vanilla.img title JE2 Enterprise Linux (2.6.24.7-146.JonE2trace) root (hd0,0) kernel /vmlinuz-2.6.24.7-146.JonE2trace ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.24.7-146.JonE2trace.img title JE2 Enterprise Linux (realtime) (2.6.24.7-146.JonE2) root (hd0,0) kernel /vmlinuz-2.6.24.7-146.JonE2 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.24.7-146.JonE2.img title CentOS (2.6.18-164.11.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-164.11.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-164.11.1.el5.img title CentOS (2.6.18-164.10.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-164.10.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-164.10.1.el5.img title CentOS (2.6.18-164.9.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-164.9.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-164.9.1.el5.img ********************************************************
Install:
[root@ethies ~]# yum update kernel Loaded plugins: downloadonly, fastestmirror, kmod, versionlock Loading mirror speeds from cached hostfile Reading version lock configuration Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package kernel.i686 0:2.6.18-194.3.1.el5 set to be installed --> Finished Dependency Resolution Excluding to be erased: kernel-2.6.18-164.9.1.el5.i686 --> Running transaction check ---> Package kernel.i686 0:2.6.18-164.9.1.el5 set to be erased --> Finished Dependency Resolution
Dependencies Resolved
============================================================================================================================================================= Package Arch Version Repository Size ============================================================================================================================================================= Installing: kernel i686 2.6.18-194.3.1.el5 updates 17 M Removing: kernel i686 2.6.18-164.9.1.el5 installed 41 M
Transaction Summary ============================================================================================================================================================= Install 1 Package(s) Upgrade 0 Package(s) Remove 1 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s)
Total download size: 17 M Is this ok [y/N]: y Downloading Packages: kernel-2.6.18-194.3.1.el5.i686.rpm | 17 MB 00:03 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing : kernel 1/2 Cleanup : kernel 2/2
Removed: kernel.i686 0:2.6.18-164.9.1.el5
Installed: kernel.i686 0:2.6.18-194.3.1.el5
## New Kernel ##
[root@XXXX ~]# cat /boot/grub/grub.conf # 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 (hd0,0) # kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-194.3.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-194.3.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-194.3.1.el5.img title JE2 Enterprise Linux (realtime) (2.6.24.7-149.el5) root (hd0,0) kernel /vmlinuz-2.6.24.7-149.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.24.7-149.el5.img title JE2 Enterprise Linux (2.6.24.7-149.el5trace) root (hd0,0) kernel /vmlinuz-2.6.24.7-149.el5trace ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.24.7-149.el5trace.img title JE2 Enterprise Linux (2.6.24.7-149.el5vanilla) root (hd0,0) kernel /vmlinuz-2.6.24.7-149.el5vanilla ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.24.7-149.el5vanilla.img title JE2 Enterprise Linux (2.6.24.7-146.JonE2trace) root (hd0,0) kernel /vmlinuz-2.6.24.7-146.JonE2trace ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.24.7-146.JonE2trace.img title JE2 Enterprise Linux (realtime) (2.6.24.7-146.JonE2) root (hd0,0) kernel /vmlinuz-2.6.24.7-146.JonE2 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.24.7-146.JonE2.img title CentOS (2.6.18-164.11.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-164.11.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-164.11.1.el5.img title CentOS (2.6.18-164.10.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-164.10.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-164.10.1.el5.img
John
JohnS wrote:
For others that are saying it want update the boot config then you may have something wrong somewhere because it should plain out update it.
We know that it should update the boot config. And under most circumstances, it does. The problem is that under some conditions, while the boot config is updated with the new kernel information, the default= line is changed so that it points at the old kernel rather than the new one. So far, we don't fully understand why this happens. My theory is that it has something to do with manually creating the config file. I have not tested this yet, but I would guess that if you removed the comments at the top of the grub.conf file and then did a kernel update, you would see this behavior.
On 05/26/2010 11:57 AM, m.roth@5-cent.us wrote:
Bowie wrote:
m.roth@5-cent.us wrote:
Bowie wrote:
And, in fact, that is exactly what happened. The default= line was set to 1, so it booted the old kernel instead of the new one. Other than that, it seems to be fine. I wonder what causes that? I've never noticed that behavior in my other systems. (But maybe I should go check now...)
I have *no* idea. I've even seen it pointing to 2, or 4. Anyone here have any idea why it wouldn't *always* change the default to 0?
Look at /etc/sysconfig/kernel - it specifies the default kernel type.
-
Benjamin Franz -
Bowie Bailey -
JohnS -
Les Mikesell -
m.roth＠5-cent.us -
Todd Denniston