slackware boot from hdd2 without lilo
 

hello all, i have installed slack 14.2 on my second hdd which is a laptop hdd but i can take it out and bring with me everywhere, at my home i can plug in to the pc via the sata cable, but at work on the usb interface.
my question is when i install lilo to the mbr, it will boot, but can i set on the portable hdd where the linux is, a boot so i can choose from any pc/laptop at the start to boot from my hdd ?
i have tried to install to the superblock method but wont boot
and is any difference to boot with sata cable plugged or usb interface?
thanks!

You should be able to do that by selecting the MBR of the drive to which you want to install Lilo. The link below has detailed instructions with the standard Lilo screen images. After selecting the option "Use the Master Boot Record", you should get a new window where you can enter the drive name, probably "/dev/sdb" depending upon the number of drives you have. Read through carefully so you are sure you understand it as the default will be to the MBR of the first drive, same as Grub.

http://bamafolks.com/randy/students/...xpertlilo.html

Not sure what exactly you mean in your thread title, boot without lilo. Either Lilo or Grub or some other bootloader will be needed. This information applies only to machines using MBR and not an EFI system.

i'd say yes, just install Lilo to the hard drive that Slack is installed on. Being that it is the 2nd ary drive on your laptop at home, that primary drive should have that slack on its listings grub or lilo. therefore when you plug it into a different inter-phase, ie USB as an external drive to boot off it. that system will use whatever boot loader you are using for that drive, lilo or grub or anything thing else.

Since the drive could be plugged into computers with varying numbers of devices, it isn't guaranteed that it will always be /dev/sdb (or /dev/sdc, or whatever it was when you installed it). Because of that, you need to reference the drive by a persistent name, usually a UUID. I have written up an article on the SlackWiki covering the process in depth.

good point UUID

unless you know the spin up order that will take place.

In OP's case we this is not known. And even if it did using UUIDs won't hurt. That's why other distributions name the partitions by UUID in /etc/fstab.

S/He specifically stated this would be going in multiple computers which would prevent him/her from knowing the spin up order (and it is likely the two computers could differ).

I was just stating a fact not a they have to know. IF they knew scenario is all. But if one sets the BIOS to boot where first then what are we looking at here then?

what effects would that have on using just the /dev/sdxx if the BIOS is set to look at the USB port first then go down the list if no boot is found.
think about it.

I agreed hence good point UUID that takes care of any situation if that BIOS does not look to the USB port first that the HDD that has a boot OS installed on it. yes?

If the BIOS boot list is
no matter what spins up first will it (the BIOS) still not wait for the USB PORT if it sees that something is plugged into it so it can check to see if it is bootable?

That works fine if you're doing it on one system, but when you start throwing multiple systems in there, especially work computers who may have things like the bios locked down, there's no way to know for sure that you're able to ensure the drive will have the drive assignment you specify. This is why it is needed to use persistent naming, whether that be UUID, label, or some other method.

And just because the bios may be set to boot a USB drive first, that doesn't necessarily mean that the bios will assign the usb drive /dev/sda. You can't know that until you try booting, and you'll probably end up with a kernel panic. In this situation, persistent naming is a must.

That works fine if you're doing it on one system, but when you start throwing multiple systems in there, especially work computers who may have things like the bios locked down, there's no way to know for sure that you're able to ensure the drive will have the drive assignment you specify. This is why it is needed to use persistent naming, whether that be UUID, label, or some other method.[/quote]

BIOS lock down : good point and Point taken.

which would require having to go in and hack it. it being the fstab by another means. Which is just a bit of hassle on company computers. UUID yeah UUID would eliminate a lot of everything about worriing will this boot if I plug this in to this computer.

But at the same thought, well never mind, taking it back to BIOS lock down messes everything up.

too if the bios is set to boot HDD first then how would one expect to get it to look at the USB port if that whateverkey to get into BIOS Boot selection too is hindered?

I think you're missing that just because you have the bios set to boot a particular drive or USB first, that doesn't mean that drive will still be assigned /dev/sda. In fact, it's likely it won't. Most of my bioses will assign the number one SATA port as /dev/sda. All my usb devices fall in after all my internal sata ports, no matter how I have the boot order specified in the bios.

yeah, well I am not actaully referring to /dev/sda per se'.

As usb ports are usually not that, they are anything but /dev/sda
I am referring to boot order against the assignment of the "dir letters" due to spin up first gets number 1 etc,

The external drives I've done where installed /dev/sdc due to two internal drives. next letter is 'c'.

boot list controls where it look to first to see if there is a bootable drive present, if no move to next on list.


the /dev/sdxx no longer matters to the computer only to the Operating system it is installed on in conjunction with its grub and fstab mount points matching what that system is telling it is.

if you set the BIOS or use the whateverkey to get to the BIOS boot list option to tell the BIOS where to look first then the USB ports are the only thing one should need to worry about. Because even they have a set order.
for example from what I understand my laptop it has 4 usb ports, going from let to right. port1 left side back, port2 left side front, port3 right side back, port4 right side front.

The Bios sees what in pluged into the usb ports, if more then one is being used it is going to look at every usb port that is being used until it finds a bootable disk if yes, then it will attempt to boot whatever os in installed on it.

therefore the grub or lilo and fstab will only have to have whatever "address" is assigned to that port in the file.

I've already stated mine was always /dev/sdcx where this works out if my bios is set to look at usb port first the addresses match because I have two hdds in my system and the the next falls to sdc being a usb port where my fstab and boot (grub) match.


how we got to having it say /dev/sda I do not know. I just said to install lilo on the hdd that os is installed on.


if he has it installed into his laptop and installs lilo it should say /dev/sdbx then when he pulls it out to plug it into a usb port then if that Computer has more than one hdd within it attached yes that is differently going to cause problems because for one, the other internal drives using up the sda sdb sdc sdd etc... depending on how many are installed and two, in conjunction with spin up order.

now we go back to UUID good point.

I think I explained that well enough .. I hope.

This whole thing was based on this post. Even if you know the "spin up order", that won't help if your boot drive is not configured properly for the OS to understand what the drives are. The bios is completely inconsequential in the boot process other than pointing at a particular harddrive and saying "boot this one". But if that drive has its lilo.conf and fstab using /dev/sdc, but the computer adds drives that makes it /dev/sdb, then you end up with a kernel panic and no OS booting.

Yes, the bios will have a specific order it is set to try and boot the drives, many times, this can be overriden by using the F11 key (or something similar, depending on your computer), but without persistent names (something like UUID), you're likely not going to boot if you use it on multiple computers.

You're going on about something that was never even discussed in this thread until you brought it up...

it was about where to install lilo first then how to /dev/sdxx vs UUID
but now I hopefully am now putting it to rest, UUID good point!

i am relinquishing myself from this post/thread. have a nice day :D