Re: Yum update chnages BIOS setting
On 11/25/2012 03:08 PM, Michal Jaegermann wrote:
On Sun, Nov 25, 2012 at 11:06:32AM -0800, Chuck Forsberg WA7KGX
N2469R wrote:
> ...
>> is it possible the BIOS is changing the drive order for some reason and
>> you're not noticing?
> I have Fedora 18 on sdf and Fedora 16 on sda.
> Which version gets booted is a function of the boot order.
> This allows me to fall back to Fedora 16 if needed.
>
> If the BIOS boot order changes I get a different Version
> of Linux when I boot.
BIOS order does not change by itself but how devices are enumerated
by a Linux kernel may change depending on what and from where you
booted. Check if /boot/grub2/device.map from both installations
are the same. Most likely they are not.
> Anyway, why would update change the boot order to a drive
> it *<HAS NOT>* written its bootloader to?
With a "wrong" device.map I would expect that you are not writing a
bootloader where you think you are writing but a boot order did not
really change. That would explain also crashes you previously mentioned
with XP. With multiple boot disks I would be very reluctant to allow
any "automatic" tools to do boot sector rewrites.
Michal
Here are the two device.map files.
When I installed F18 I disabled the other drives so Anaconda couldn't
mess with them.
[root@omen grub2]# cat dev*map
# this device map was generated by anaconda
(hd0) /dev/sdf
[root@omen grub2]# cat /f16/boot/grub2/de*map
# this device map was generated by anaconda
(hd0) /dev/sdf
(hd1) /dev/sde
(hd2) /dev/sda
(hd3) /dev/sdb
(hd4) /dev/sdc
(hd5) /dev/sdd
(hd2,2) /dev/sda2
Does Fedora or Anaconda mess with anything in the BIOS other than
date/time? If so, why?
--
Chuck Forsberg WA7KGX N2469R caf(a)omen.com www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430