Looks like you are in a hardware paradise with 30 processors. I get confused when starting to work on the 3rd system.
The Solaris Container for Linux, is it a open source?
You are my idol!
After reading this, I've learned enough to try Grub next time instead of Lilo. I've been using Lilo out of habit all this time. Thanks for this thread, saikee.
Welcome to JustLinux.
Lilo is about 2 to 3 times harder than Grub to deploy. Operational wise there is little to choose between the two. Grub does have the following advantages over Lilo.
(1) Lilo needs a revalidation every time its /etc/lilo.conf is amended. Grub never needs such attention.
(2) Lilo checks every partition it is asked to boot and refuses to implement it if there is an error. Grub is totally different. The above thread shows that none of the operating systems needs to be installed before Grub's menu.lst is written out.
(3) Lilo is "Linux Loader". As such it cannot survive outside Linux. Grub can be installed without any operating system attached to it.
(4) Lilo works only after a Linux has been booted. Grub can operate as a mini operating system before any operating system is booted and hence can be used to boot any system manually.
(5) Lilo uses a static screen which has space for just 27 entries. Grub uses a scrolling screen and the sky is the limit as far as the number of booting entries is concerned.
(6) To restore Lilo one has to use another Linux to change root to the original Linux to access its Bash shell, although using a different Bash shell is also possible. Grub can be restored by a Grub prompt without booting up an operating system. Thus one can restore Grub for several distros in one operation regardless the location of the distros which could be in any internal or external disk or even USB device.
(7) Lilo works only on hard disks but Grub has component (stage2_eltorito) for booting from a CDrom too. Grub is equally at home booting USB thumb drives.
Lilo does have the advantage of being a lot smaller and able to fit into the boot sector. Thus if one nuke the Linux Lilo can be still operational from the boot sector for booting other systems. Grub is very big and nuking the Linux will cripple Grub.
I have seriously considered to write an alternative Lilo booting menu system for the above 145 systems as I am pretty sure we can do relays with any boot loaders. This is to say menu1 boots the first 27 images with the 27th Linux opens up another 27 images and so on. The work will be at least 50 times more than using one Grub. Thus I did NOT think the effort worth to pursue.
Last edited by saikee; 09-17-2007 at 08:11 AM.
Uh.....I could always use more processors/systems.
Originally Posted by saikee
Whether power, cooling, space, (and finances) will support it is a whole 'nother question.
Solaris Containers for Linux IS an open source project (via OpenSolaris.org) http://www.opensolaris.org/os/community/brandz/.
It has been officially rolled into the "mainstream" Solaris (the part open-part closed source Solaris now) although more and more stuff is being rolled in from the OpenSolaris initiative.
I don't think of it as proprietary/non-proprietary - but more along the lines of OpenSolaris and Solaris Express are like beta Solarises (and they'd constantly be in beta stage for various projects), while the official releases are the stable builds, and rolled in with the rest of the OS/installer, which makes it easy for non-programmers like me to use/install/configure, etc.
It isn't "bad". With regards to Linux, it probably (still, almost certainly) has it's limitations. For Apache, MySQL, PHP (AMP), it's supposed to be great. I don't know, I've only used it for Apache and Samba (SMB) before (still using it for SMB and as my giant file servers with ZFS). (Even then, ZFS has it's own quirks). Ultimately, it depends on what you use it for I guess. To each their own.
----An update 17 Sep 2007 ----
Since Feb 2007 Linux kernel 2.6.20 and later have incorporated the Pata disk names into the SCSI/Sata/USB disk family and so in future Pata disks will all be called sda, sdb, sdc... etc. This makes a Pata disk incapable of having more than 15 partitions.
The current thread was written in Dec 2006 when the kernel version was 2.6.18 and 63 partitions in a Pata disk were supported. With the new kernels a hard disk with more than 15 partitions could be ignored by Linux and may be treated as a raw disk. Some new kernels still support Pata names but the trend is to go with the SCSI/Sata/USB convention controlled by the libATA driver.
The implication is unless you use a set of old distros that have kernels older than 2.6.20, you may now need a lot more hard disks to repeat what I have done in this thread, because I could use 63 partitions in a Pata disk then but not now.
However I have been working on a method to get as many partition out of a hard disk and 44 partitions out of a SCSI/Sata/Pata/USB disk is technically possible. I have reported it in this thread. The other alternative is to use a LVM to accomondate the large number of Linux. I am currently runing satisfactorily a 44-partition Sata nearly filled with Linux.
The 44-partition thread also shows how to "nest" a group of Grub menus together. Thus BSD and Solaris can be booted together with Dos, Windows and Linux in the same PC. If there is any conflict just use the Grub menus to hide the partitions that causes problems before booting up the chosen distro. One can hide the entire extended partition in the same way of hiding a logical or primary partition. I have summarized a few tips of partition hiding in this thread.
The latest Grub menu system of this thread has been posted in Post #32 to #34 where Solaris and BSD systems have since been included.
Last edited by saikee; 09-20-2007 at 06:05 AM.
Question: MUST the individual Linux installs be on separate partitions?
Originally Posted by saikee
For example, is it possible to clump all Linuxes that work/run on ext3 into one giant ext3 partition, and only separate the boot information/files by moving them into different directories?
Fedora Core 2
Fedora Core 3
??? Just thinking out loud...
If it works, it would eliminate the need for LVM, and the OSes would be grouped by fstype.
As far as Grub is concerned there are two hard disk addresses needed to boot a Linux. One is in the "root" statement to find the Linux kernel. The other one is for the kernel to find the root filing system. The latter is a kernel parameter to be passed during boot time.
The basic deal is Grub load the kernel with the first hard disk address and buggers off.
The loaded kernel will then fetch files according to the specified root location. The syntax of the latter is "root=/dev/sda?". Therefore it is always a device name and not a folder name. This does not get changed if the partition is identified by the by-label or by-uuid method.
Therefore I don't think storing several Linux in a same device or partition is acceptable to the Linux boot loader because Lilo also use the similar "root=" statement for a device.
At a working level, say if one does manage to put several Linux into the same root filing system the structure of Linux will prohibit mixing of system pararmeters with another distro. In fact if a Linux user re-installs the newer version of the same distro over an existing filing system there is a risk the kernel panics over some parameters not properly updated. Therefore adding additional different Linux to the same root filing system would be inadvisble even if it is technically possible.
Furthermore sharing even the same /home directory over several Linux is a difficult feat because different ways the different distros use the common programs and storing their own different settings.
I have avoided the LVM up to now because I could see extra maintenance work but little if any real benefit. May be I should exhaust this option. I know for a fact that we can't house non-Linux systems inside and managing different kernel and initrd files is going to be pig's job in one per /boot.
In the 145 systems above one does have the benefit of keeping the kernel, initrd and boot loader intact for each system in the location arranged by the original installer. The availablity of 145 boot loaders and how they were arranged taught me how I can simplify and standardise every system with Grub.
Putting one system in one partition is "a lot" easier to control, to boot, to mount, to remove, to maintain, to resize and ultimately to migrate.
Good point. I'm probably worse off than you are because I prefer to separate different OSes at the BIOS level. There'd be no way that I'd be able to convince my BIOS to take 145 (different) installations.
Luckily, I don't use more than 2 on any given system.
As a joke often after solving a problem and receiving thanks I would ask the Linux user to chop his/her hand and send it to me after he/she got into the trouble by fiddling with the booting queue in the Bios. I would tell him I have collected enough meat to open a sauage factory.
Both Lilo and Grub can alter the Bios setting "on-the-fly" during the booting process and to me that is a boot loader's job. Example of Grub and Lilo using "map" statement for this purpose are showed in Section A here.
In the 3 Dos and 5 Winodws I run in the 145 systems I always installed each MS system on its own into a "C" drive and moved the disk to the final position by using Grub to "re-map" its original installed booting position. To keep one MS system interfering with another I hide all MS systems ahead of the booting queue to the one I wish to boot.
I truly believe fiddling with the Bios for the purpose of booting is a worst respect a Linux user can show to a Linux boot loader because it is a lack of truct of what a Linux boot loader is made for.
However, the idea behind using the BIOS to control the boot order also means that the installations are completely independent of each other. Therefore, even if LILO or GRUB fails (and/or the hard drive with the LILO/GRUB dies), it does not prevent the other OS (on a physically separate drive) from booting, espectially if told to do so via the BIOS.
Also as far as I know, most Linux distros cannot write to NTFS partitions, which is almost a requirement for partitions > 32 GB (IIRC). (My smallest NTFS partition (on a boot drive) is 73 GB and largest is 146 GB). Therefore, using GRUB (unless GRUB for Windows is explicitly available) (or Linux with LILO/GRUB) for the sole purpose of controlling boot order may not work for partitions > 32 GB, and also makes it dependent on the host system/drive with the bootloader.
If, for example, in Windows, and the Windows and/or the drive dies, (presuming that user data resides on a separate drive), then it is a simple matter of reinstalling (the drive) and Windows.
For a dead Linux drive, booting may become tricky, if at all possible pre- or post-boot drive resuscitation.
(Yes, I've had GRUB die on my WITH the OS (and data) installed into a 4-drive RAID5 array. And no, I have absolutely no idea how to bring it back to life. (Host OS is Redhat 9, I forget the kernel version). I was planning on building a test system such that nearly identical, and performing tests/practicing how to bring it back to life while leaving the data intact because on that system, being able to bring the array safely back online is of the utmost importance. I just lack the experience on disaster recovery with Linux.
Personally I have not run into any partition size-related problem from the Linux boot loader Lilo and Grub. If Lilo and Grub can address to the 63th partition of a 500Gb Pata disk it would be booting to the last 10Gb of that disk and I have used one 320Gb fat32 partition for data is accessible by all systems. In fact I am stilling using one 500Gb ntfs partition for storing iso files and even use Linux, with ntfs-3g support, to write the download files onto this disk.
I would say even when I started entering Linux some 3.5 years ago Lilo had already no problem addressing large hard disk, as I was reading the 1024 cylinders barrier in the Lilo related literature but could not find it in practice with the kernel versions then. I have tested the oldest Grub 0.91 in my possession and found it didn't has any fear of large hard disk either.
If a Windows dies in my system I can remove all the other hard disks in seconds, as they are all mounted on mobile racks and caddies, and reinstall the system if needed. For booting, as long as I know the disk it was installed, normally the first one and known to Grub as (hd0) I can sert it anywhere say as the 4th disk (hd3) and boot it with two extra statements in Grub
This procedure works for every Windows of Win9x, Win2k, XP and Vista.
map (hd0) (hd3)
map (hd3) (hd0)
For simplicity I have satyed away from the Raid systems. The last time I used a stripped Raid (Raid 0 I think) I believe the boot loader was actrually located in first disk. Thus if the Raid is arranged by Bios then any Grub should be able to boot it but I do not have practical experince to back this up. It depends on how the Raid is set up and can be transparaent to the OS by a management layer. If I remember it correctly Grub is in only on one disk and the loaded kernel looks after the filing systems in the Raid (from information off the Bios).
You may consider starting a thread on this problem. Some of the forum members are pretty switched on with Raids.
Someone has too much time on his hands :-D
Hah! Well done!
(registered only to congratulate, and mayhap later bother the local residents with anoying newbie questions on ubuntu)
zheepeez: Well, you should be asking the question Why not? ;-)
Oops, *edit*. FAT32 partitions is a cannot address more than 127 GB. I guess that it's different if Linux configures the FAT32 partition rather than Windows.
For the current generation Windows to run with FAT32 isn't as good as if it were to run on NTFS.
I may start the thread at a later time. I don't know yet. Waiting for my 9th system to arrive so that I would be able to test the procedure with that.