Hi,
How do I determine if the bootloader in the system is lilo or grub when both the config files are present ?
:D
Printable View
Hi,
How do I determine if the bootloader in the system is lilo or grub when both the config files are present ?
:D
Good question. Basically when you update your boot loaders config file and write the MBR, then that boot loader takes over. I know that's not the answer you're looking for, but maybe it helps.
You could always reboot the machine and watch the boot process through a remote console device.
You could copy the boot sector to a file, using a command like this:
dd if=/dev/hda of=/tmp/boot-img.mbr bs=512 count=1
then download that file locally and use dd to write it to a floppy.
boot off the floppy at your local workstation.
I haven't tried it yet myself, but ran into the same problem before and thought of doing this to check.
Interesting idea with dd.
Last time a client asked us to check we got an on-site tech to watch the display output when we rebooted the box remotely ;)
I would ask the person who installed it. :)
Just a question:
When you do: cat /root/anaconda-ks.cfg | grep bootloader
and get
bootloader
as result, then you are using GRUB, right?
I would ask the person who installed it.
This person didn't have a clue which was installed ;)
That seems like a good way to tell, if that file is there.Quote:
Originally posted by Angel78
When you do: cat /root/anaconda-ks.cfg | grep bootloader
and get
bootloader
as result, then you are using GRUB, right?
I would just do a less on the file though, it's not like it's that long. It should indicate whether you specified a different bootloader. Smart thinking. :)
Lets play devils advocate :)
Why does it matter?
I use LiLo. It rules.
You can test a new kernel without fear of hosing your system that is 1500 miles away:
lilo -R <new_image_name>
Try that with grub! Mffff!
But with grub you can define a fall-back kernel (the last working one for example) in the grub conf. This one would boot if there would be a problem with the current one for whatever reason. As far as I know this doesn't work with lilo.
Thank you all for responding.
This is not a kernel upgrade issue, but just a question that someone asked me [to check my admin skills I guess, which in turn, all yours for this particular one.. :D]
[b]cat /root/anaconda-ks.cfg | grep bootloader
bootloader
bootloader --useLilo
Is this the result of which it was at boot time, or at the current.
err.. what exactly am I looking at ?
The question is to tell him what bootloader will be used on his next reboot.
still waiting for that magic answer...
:rolleyes:
Use the dd method I suggested earlier - that will tell what is currently installed on the mbr, which will be the one that will be used on next boot.
Checking the anaconda-ks.cfg file just tells you what got installed. Your's looks like it was told to use Lilo - but that could have been changed.
Lilo ALSO can use a "fallback" kernel.
Lilo -R <kernel image>
That kernel will ONLY be loaded at next boot. Therefore lets say your kernel is built wrong, you messed up, whatever. Cal the DC and ask for a hard reboot, and it will reboot with your ORIGINAL kernel in place.
Check the current running kernel with
uname -a
Check both config files - see which one (LILO or GRUB) has the correct kernel listed as default boot. If BOTH do - screw it. Run lilo -v, then tell the customer they use LILO.
Hey there,
To identify if you're using lilo or grub.
1) dd if=/dev/hda of=/tmp/boot.img bs=512 count=1
2) cat /tmp/boot.img
It's lilo if it has something about "Missing io.sys". It's GRUB if it mentions GRUB. :)
Stuart
It works :) Stuart the man :)
Yeah Stuart - that's good, saves a step (and a big doh!).
But cat corrupted my terminal.
strings /tmp/boot.img is nicer.
I'll give stuart 35% credit and heyzuess 65% credit for that one. :)
Though in theory, looking at the kickstart file would have worked in many circumstances.
Heyzuess's idea started out good, but then I was thinking, "and put it on a floppy and boot from it"? That's just too hard. Which is why I initiallly disregarded his or her idea.
EDIT: WWIT?
That's interesting. I had no problems when pulling up an SSH session within an xterm. :rolleyes:Quote:
Originally posted by heyzuess
Yeah Stuart - that's good, saves a step (and a big doh!).
But cat corrupted my terminal.
strings /tmp/boot.img is nicer.
Were you using Windows at the time?
Stuart
No, a gnome-terminal on the local box (not ssh'd into anywhere) so it's not too big of a deal - mother always said not to cat binary files....
I always seem to go about things the odd way - but it was a recycled tip anyways.
Everyone gets 1000 points!
Ctrl-V, Escape, C, Enter.
That should reset your terminal if you've garbled it.
Regards,
Robert.