SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Please educate this old man as to how you would use a inode in the 'lilo.conf' to specify what partition to boot? Maybe I've missed something all these years. 'man lilo' and 'man lilo.conf' don't seem to refer to your use of the 'inode'. Now if your talking about a 256 byte vs a 128 byte inode for a filesystem then that definition still won't affect the way you boot the system via the present bootloaders. BTW, the default is 256 byte inode.
I think you are mis-using the terminology.
Code:
# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
# Append any additional kernel parameters:
append="Linux vt.default_utf8=0"
boot = /dev/sda
# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
bitmap = /boot/slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used. We don't specify it here, as there's just one column.
bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
bmp-timer = 65,27,0,255
# Standard menu.
# Or, you can comment out the bitmap menu above and
# use a boot message with the standard menu:
#message = /boot/boot_message.txt
# Wait until the timeout to boot (if commented out, boot the
# first entry immediately):
prompt
# Timeout before the first entry boots.
# This is given in tenths of a second, so 600 for every minute:
timeout = 1200
# Override dangerous defaults that rewrite the partition table:
change-rules
reset
# VESA framebuffer console @ 1024x768x256
vga = 773
# Normal VGA console
# vga = normal
# VESA framebuffer console @ 1024x768x64k
# vga=791
# VESA framebuffer console @ 1024x768x32k
# vga=790
# VESA framebuffer console @ 1024x768x256
# vga=773
# VESA framebuffer console @ 800x600x64k
# vga=788
# VESA framebuffer console @ 800x600x32k
# vga=787
# VESA framebuffer console @ 800x600x256
# vga=771
# VESA framebuffer console @ 640x480x64k
# vga=785
# VESA framebuffer console @ 640x480x32k
# vga=784
# VESA framebuffer console @ 640x480x256
# vga=769
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz
root = /dev/sda1
label = Linux
read-only
# Linux bootable partition config ends
"boot = /dev/sda"
"root = /dev/sda1"
The entire /dev directory is full of inodes!
mknod
Create a device special file with the given parent, name, mode, and device number. Then d_instantiate the new inode into the dentry.
So block devices and other nodes are treated like a file how are they not inodes? They correctly divide your hardware up into parts just like inodes do, there the same thing! You can call them different all you wish, but when it comes down to the wire nodes in the /dev directory are inodes!
These ARE inodes! This is what grub lacks it replaces these with hd0,(0) instead witch if you had a PATA which happends to be primary master grub will also think it's hd0,(0) if i where to replace all the values in my /etc/lilo.conf with there PATA equals and assuming i had a partition on /dev/hda called /dev/hda1 lilo would see it and use that instead of /dev/sda because is what it was told to do, unlike grub.
Last edited by ProtoformX; 10-05-2008 at 10:17 AM.
Ahh no they can't when you setup grub you can't tell it to use /dev/sda1 to boot something you have to translate it into grubs stupid system of telling drives appart, while lilo if i tell lilo I want to put lilo in the MBR and tell it to load /dev/sda1 as the root partition it will, it won't see the swap drive as the first disk in my case because I had already told the drive to boot.
This is getting odd.
First thing: grub is not supposed to be a "LINUX ONLY BOOTLOADER". Why should it abide the linux or posix syntax at all?!? Why not the BSD names? Why not the windows ones? Grub can work with any OS, so, why would it abide the linux syntax over any other? These are just labels, I don't see how they affect the functionality of grub at all.
Second: lilo and grub just see the drives as the BIOS identifies them, there's no difference, and the chipset here is irrelevant. Neither of them include drivers for chipsets, they just query the BIOS and identify the drives on a given order.
Quote:
I know because I have tried to install Kubuntu and slackware, slackware works because I can tell it what drive to boot, Kubuntu won't because grub doesn't know the differnece between /dev/sda and /dev/hda it sees both as hd0(0) which is wrong, they might be both primary masters but they are very differnt drives.
No. I have IDE and SATA drives on this very same computer where I am writing now. And it definitely booted without problems. Grub gives a different number to each drive, it doesn't matter if it's an IDE, SATA, SCSI or whatever kind of drive.
Quote:
Thats just the thing /etc/lilo.conf will let you use inodes to specify what partition you want to boot, Grub won't allow that, so instead it comes up with it's own flawed drive detection that doesn't work when you have 2 primary masters in the same computer even though the BIOS and everything else can see them as seprate drives (even WIndows XP and Vista can but grub won't)
I have absolutely no idea what are you talking about.
EDITED: The stuff under /dev are not i-nodes, they are just device nodes, and entirely different thing. Read about the ext3 filesystem, which is well documented, to see and understands what i-nodes are. They are an fs structure, entirely unrelated to what we are talking about. And entirely irrelevant for the issue as well. Refer to the first part of my post to see why grub doesn't need to respect the linux/posix namings.
No. I have IDE and SATA drives on this very same computer where I am writing now. And it definitely booted without problems. Grub gives a different number to each drive, it doesn't matter if it's an IDE, SATA, SCSI or whatever kind of drive.
Tell me are both SATA and PATA set to be the primary masters?
Tell me are both SATA and PATA set to be the primary masters?
Well, the PATA drive is master, the slave is a dvd burner. The SATA drives (two) are just SATA, there's no master/slave distinction in SATA. I can boot from any of them without problems.
The mapping of the devices is specified usually in /boot/grub/device.map, maybe the problem is that your device.map file got messed somehow.
and
this:http://forums.whirlpool.net.au/forum...fm/873809.html
EDIT: (-repeated url- never mind this i miss-copied the second link , doesnt matter though, this can be searched by anyone interested in lilo on 64bit systems).
lilo presented problems with lots of things, and people used 32 bit versions instead, thing where complicated specially with issues around raid it seems...
but honestly, in the gentoo community we just have a heads up, dont use lilo with 64bit.
And, personally, i recommend grub.
you can read around more if you like, today things aren't as problematic i hear, but still... id say 64bit=use grub.
I am not running a 64-bit system and know very little about running 64-bit systems, but Bluewhite64 (a fully 64-bit system with no 32-bit compatibility libs) uses LILO. What is the problem with LILO and 64-bit systems?
It should be noted that I prefer the functionality of GRUB but prefer the simplicity of LILO, and since I ultimately run a single OS system, LILO is my choice (mostly since it's simple, I understand it and it came with Slackware by default). However, I am of the opinion that both bootloaders are good, and I don't understand the needless bashing without any evidence to back up claims.
[edit]I should have refreshed the page before posting, but I'll comment now on what you posted. Both links lead to the same page. The ONLY thing that suggests GRUB is better than LILO for 64-bit systems is this comment:
Quote:
Originally Posted by Sirikan
I will say GRUB mainly because its graphical and seems to be updated more then LILO. Plus it is meant to have better hardware support for 64bit systems if you ever install a 64bit Operating System.
There is no evidence to back up that claim whatsoever and no one else comments further. How on earth is that considered reliable information? You would fail in school if you used sources like that for any kind of essay or report (well, maybe you could get away with it in high school, but not college/university).[/edit]
I prefer grub by all means, but to be honest, I don't think that the 64 bits support is any better or worse.
The first thing to note is that the bootloader runs before the OS, so, it doesn't really matter in which mode it runs. Once you pick up a kernel the bootloader dissapears from your memory, and the kernel starts booting the OS in whichever mode. Another thing are the userland tools, but, in any case, you can always run lilo from a chroot, or just boot a livecd to install it on your MBR.
Also, note that grub doesn't compile on x86_64 mode. You can run it perfectly on 64 bits systems (userland tools included) but it will only compile as a 32 bits application as far as I know. You shouldn't have a problem to compile grub on a 64 bits system, as long as you have a multilib setup. Grub2 is supposed to address that "problem" and many others, but I haven't tried it.
So block devices and other nodes are treated like a file how are they not inodes? They correctly divide your hardware up into parts just like inodes do, there the same thing! You can call them different all you wish, but when it comes down to the wire nodes in the /dev directory are inodes!
These ARE inodes! This is what grub lacks it replaces these with hd0,(0) instead witch if you had a PATA which happends to be primary master grub will also think it's hd0,(0) if i where to replace all the values in my /etc/lilo.conf with there PATA equals and assuming i had a partition on /dev/hda called /dev/hda1 lilo would see it and use that instead of /dev/sda because is what it was told to do, unlike grub.
No they are not! An inode is a 'index node' which is a data structure such as a filesystem. The inode stores the information about a file, directory or a file system object.
When you are speaking of '/dev/hda1' you are indicating the device node for partition1 on device hda.
The '/dev' directory has 'device nodes'.
Look at the links for definition.
I am not running a 64-bit system and know very little about running 64-bit systems, but Bluewhite64 (a fully 64-bit system with no 32-bit compatibility libs) uses LILO. What is the problem with LILO and 64-bit systems?
It should be noted that I prefer the functionality of GRUB but prefer the simplicity of LILO, and since I ultimately run a single OS system, LILO is my choice (mostly since it's simple, I understand it and it came with Slackware by default). However, I am of the opinion that both bootloaders are good, and I don't understand the needless bashing without any evidence to back up claims.
[edit]I should have refreshed the page before posting, but I'll comment now on what you posted. Both links lead to the same page. The ONLY thing that suggests GRUB is better than LILO for 64-bit systems is this comment:
There is no evidence to back up that claim whatsoever and no one else comments further. How on earth is that considered reliable information? You would fail in school if you used sources like that for any kind of essay or report (well, maybe you could get away with it in high school, but not college/university).[/edit]
well thats a big flame on, but yeah sorry i had 2 different links, and one of them led to a bug complain/problem inside of the gentoo forum, dont really know why i posted 2 equal ones... o.O
but anyhow, given the level of your response i remove myself from this argument. if you want 'evidence' its out there, you can find it on your own...
and about compiling grub on 64bit... well i have done that on my gentoo install so...
i really dont think i needed multilib for this, and i may be wrong but i dont think so.(not that it matter much anyways, in my experience like i said, grub is simply more reliable under 64bit systems).
well thats a big flame on, but yeah sorry i had 2 different links, and one of them led to a bug complain/problem inside of the gentoo forum, dont really know why i posted 2 equal ones... o.O
but anyhow, given the level of your response i remove myself from this argument. if you want 'evidence' its out there, you can find it on your own...
and about compiling grub on 64bit... well i have done that on my gentoo install so...
i really dont think i needed multilib for this, and i may be wrong but i dont think so.(not that it matter much anyways, in my experience like i said, grub is simply more reliable under 64bit systems).
I will not research about LILO or GRUB on 64-bit systems because I have no need to. I run 32-bit Slackware and no 64-bit OSes. I don't want to waste my time (which is unfortunately more limited than I would like). I don't think my response was flame-bait, and if I imply something else the mods will probably step up. Methinks the level of your response suggests that you don't have any evidence and you don't want to admit defeat, so you withdraw from the debate. Fine with me -- I couldn't care less whether or not LILO sucks on 64-bit OSes. I stand by my statement that, without evidence, you shouldn't make claims like that. I could claim that GRUB can't boot 32-bit Linux, and I'm sure I could find a comment similar to the one you posted. However, it doesn't make it true.
A quick search (without actually reading the links) for "LILO 64-bit" and "GRUB 64-bit" turned up results of confusion with both. I still don't see how GRUB is better with 64-bit than LILO. Again, I don't care either way and I like GRUB (but use LILO) -- but claims like this with no evidence...bother me, let's say.
and about compiling grub on 64bit... well i have done that on my gentoo install so...i really dont think i needed multilib for this, and i may be wrong but i dont think so.(not that it matter much anyways, in my experience like i said, grub is simply more reliable under 64bit systems).
Grub can't be compiled as a 64 bits binary. Unless you are using some custom patch to achieve so (I never saw a working one for that purpose). You can compile on a 64 bits installation: yes, but as a 32 bits object file (hence you need multilib). You could check easily with this:
The first thing to note is that it's a 32 bits elf object file. This is from my amd64 sempron desktop machine, on a 64 bits install.
The second relevant thing is that it's a dynamically linked executable. That means that it's not an static binary file, which in turn means you need a 32 bits glibc installed. Which, in turn, means you definitely need a multilib setup (or a pure 32 bits installation, of course).
And if you check inside the grub ebuild, you will also see a conditional dependency on x86 compatibility libs only if you are in amd64 architecture. So, there you have one more proof.
Of course, you could just install it on the mbr using a 32 bits livecd if you don't want to use a multilib installation. But that will just cut down the options you have (no 32 bits browser for flash, no wine, no grub...). There's literally no downside on having a multilib system (and it's the default profile).
About reliability, as I said, it's irrelevant if you use a 32 or 64 bits machine. Once it's in the mbr, the bootloader is OS-agnostic, it doesn't run under a 64 bits environment, since it runs outside the OS, before the kernel is loaded. I can't see how a 32 vs. a 64 bits installation could be a problem at all. To have a 64 bits linux install is like having a 64 bits windows xp install. Grub doesn't care about it, nor does lilo. The only bit of your system that interacts with the bootloader is the file system from where you will be reading the kernel, and the fs is architecture-agnostic as well. Ext3, for example, is exactly the same under 32 or 64 bits.
The only problem that could theoretically happens is about user land tools. But the bootloader itself resides on the MBR, outside the scope of your kernel.
You don't have to update grub -just the menu entry.
The program which turns up when you run `which grub` is not the same thing as what gets written to the MBR. The program grub is a user-land utility written in C. What gets written tho the MBR is a bootsector which is written in assembly -it needs no libs at all.
It is not possible to have two Primary Masters. The BIOS will always distinguish between two drives. The problem with both lilo and grub is getting them to see things the same way as the BIOS does. This is why grub sometimes gets it wrong when both PATA and SATA drives are installed. When you run the grub program it uses an internal routine to create the device map. This routine does not always report the same way as does the BIOS. Grub used to depend on the kernel to figure out the geometry, but doesn't any longer. Even the kernel will not always 'see' the drives the same way as the BIOS -unless you have the kernel compiled with the option of using the BIOS info instead of its' own. The kernel can sometimes recognize drives which are not recognized by the BIOS -for instance old BIOS's which can't handle large drives/partitions can still be used because the kernel can handle them.
My main point is that neither lilo nor grub will always see the drives in the same order as the BIOS presents them. Even the grub utility(program) will not always report the same info as the grub MBR. This is why you sometimes need to edit the device.map in order to get the MBR grub to do what you want.
As far as the naming scheme, the fact that lilo names the drives the same way as the kernel (hda, hdb, etc) is just the lilo convention. Most distros now use persistent device naming in the kernel. Under that system, PATA and SATA drives use the same naming scheme. The hda-type naming with partitions staring at number one is *maybe* a little more intuitive for Windows refugees. The grub-style naming with drives and partitions starting wiht 0 is more consistent with other usage under linux, where the first whatever is usually 0 -not 1.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
, doesnt matter though, this can be searched by anyone interested in lilo on 64bit systems).
