Hi guis.
I have a system with Slackware 10.2 installed on it.
I have a 80GB disk with 25GB free. I would install another Slack 10.2 for testing using the free space on disk without using previous partitions.
Can I do this? LILO is a minor problem.
More important questions are about swap, boot and root partitions.
Thanks
Best regards
Michele

Yep, this is perfectly doable, and should cause you no more problems than any dual boot system. It's been covered a thousand times, so do some searches and have a think about it, but I'll quickly run over the basics here. Also, if you're going to be messing with kernels in your test setup I suggest you investigate grub since you'll have a bit of a cludge on your hands with lilo.

So, It sounds like you have a similar setup to the following:

If you have 4 primary partitions on your drive already, then you will need to consider breaking one of them to insert an extended partition to contain your logical partitions. Google for more information on partition limitations if none of that made sense, you'll see what I'm talking about.

Assuming your setup is as above, you need to do something like the following:

Install Slack into the freespace (after adding a new partition, of course):
1) Add hda3 as your swap space - you can happily share swap between the two.
2) Add your old slackware install to a mount point somewhere (you will need this to get your old lilo.conf)
3) DO NOT mount your /boot partition unless you want both installs running from the same kernel. I have found that there is just no point having a separate /boot partition unless your PC is old enough to have boot problems beyond the 1024th sector (is this the right number? it should be ~8GB into the disk).
4) Go through with the lilo installation as usual.

Once the install is completed, you should do a few more things to tidy up and be ready for the testing.

1) Backup your new lilo.conf, then copy your old one into the new /etc/lilo.conf
2) Merge the two lilo.conf files, and then run lilo. You should now be able to boot from both old-slack and new-slack installations.

Finally, copy the newest lilo.conf (located on new-slack, it's the merged file) back to your old-slack install and you should now be able to use both installs without needing to worry about loosing boot priviledges.

Good luck!
- Piete.

I run my box with a complete separate testing setup where I can snork around. In addition to piete's advice, a separate /home and /boot partition helps a lot. You can share swap, /tmp, /opt, /usr/local. I do. If you want additional partitions, be sure to use separate /var, /usr, and / (root) partitions. Of course, those directories can all go on one partition, but if you divide them you should not share them with your good OS partitions.

I like GRUB as my boot loader for playing with multiple OSs and a separate /boot partition helps that process too.

A separate /boot partition also easily allows you to configure different kernels.

For my GRUB booting, I never use the vmlinuz soft link in my GRUB menu.lst. I always use the actual files (e.g., vmlinuz-ide-2.4.31). That way, if I have to reinstall everything in my testing partitions, the Slackware setup process cannot hose my boot loader menu options when it creates that confounded soft link.

You CAN do this. Two of these that you may not WANT to share are /tmp and /usr/local. With /tmp (and this can vary widely depending on setup) being shared, you run the risk of stale lockfiles, inconsistent ownership (non-matching UID and/or GID), etc. With /usr/local, you may run into dependency issues if you have different packages installed.

I only bring this up because most use a second Slackware install to experiment with. Sharing those directories can lead to weirdness. Then one is left thinking thatr the weirdness is due to whatever they are experimenting with. I would recommend sharing only swap in this type of setup.

I couldn't agree more. I acutally have two installs of Slackware (one for Dropline Gnome and the other has Freerock Gnome) on my PC and the ONLY partition I share is /swap. Sharing /usr/local could cause major grief, IMHO.

Later,
MMYoung

I would really recommend qemu. Basicly vmware but free. If you use it with the kqemu(non-free as in freedrom) module for acceleration you can get almost native performance with it. It's a great tool for testing kernels, livecd's, distro's, etc. Pretty much anything you don't want to do on a production system.

That probably is good advice. I did not add that with my own boxes I tend to be rather strict with housekeeping and I run scripts to routinely delete garbage files. Been doing that even in Windows going back to the early 90s.

One file that I see causing possible problems on a shared /tmp is the KDE ksycoca files. But if running a separate testing partition(s), one could easily adapt the "cleanup" scripts to delete or temporarily rename those files. Of course, deleting those files causes no harm and KDE will rebuild those cache files the next boot.

Regarding /usr/local, I don't know why this mount point would cause problems. This has never happened with my boxes. However, currently all I have located there are my personally written scripts in /usr/local/bin and sbin. Possibly people more experienced with 'nix systems store far more in /usr/local than my modest efforts, and in that case possibly sharing /usr/local might cause problems.

Perhaps distros other than Slackware make sharing /usr/local partitions a dangerous proposition. I don't know, but I never have had a problem with Slackware. PV installs nothing in /usr/local except the directory tree, thereby preserving the concept that /usr/local is to be modified only locally by the end-user. Thus far, I never have downloaded any packages that tried to store anything there. I also use only KDE for my graphical environment and perhaps that plays a role too. Regardless, I'd like to read some specifics from people about why they do not share /usr/local.

Anybody advancing sufficiently in their efforts to begin thinking about sharing partitions in a multi-boot environment should be able to answer such related questions for themselves. If they are unsure about sharing specific partitions then the safe route is don't.

All fine and well for people running boxes with Concorde engines installed. For us folks running older boxes, such emulation environments is out of the question.

This is correct. This has no bearing on the issue. The issue has to do with user compiled software. Many stick with the default prefix of /usr/local when compiling software on their system. If you share /usr/local, you need to be aware of the library requirements for all compiled software, adjusting BOTH installations as needed. You can easily cause dependency issues in one of your systems otherwise. As your installations show, this is a specific situation that doesn't always occur (for instance if you only store shell scripts in /usr/local). If all you use /usr/local for is to store shell scripts, the worst you need to watch out for is that you have all the commands used in the script installed on both systems.

On the issue of lockfiles in /tmp; sure, the issues can be worked around. You have to be aware of the issues to work around them, though. Just wanted to point that out so the guy didn't go crazy wondering why his desktop went "blah".

This is correct. This has no bearing on the issue. The issue has to do with user compiled software. Many stick with the default prefix of /usr/local when compiling software on their system. If you share /usr/local, you need to be aware of the library requirements for all compiled software, adjusting BOTH installations as needed. You can easily cause dependency issues in one of your systems otherwise. As your installations show, this is a specific situation that doesn't always occur (for instance if you only store shell scripts in /usr/local). If all you use /usr/local for is to store shell scripts, the worst you need to watch out for is that you have all the commands used in the script installed on both systems.

On the issue of lockfiles in /tmp; sure, the issues can be worked around. You have to be aware of the issues to work around them, though. Just wanted to point that out so the guy didn't go crazy wondering why his desktop went "blah".

Part of the reason I gave the caution. the OP indicated that they did not wish to use current partitions. It was then suggested that he could share partitions. I gave him warning. If he is knowledgeble enough to already be aware of possible issues, he will simply disregard the warning.

As I understand your issue, sharing partitions would let you save time configuring your "testing" install, but would give compatibility issues. I am also going with two Slackware installations and share nothing but the swap partition between them.
If you don't mind losing your (temporary?) modifications on your testing rsync is a very speedy and easy way to synchronize both and to easily get a working configuration. For example to copy my "stable's" seperate home partition to the "current" (also seperate) home partition I do just a

right after booting into stable and I do this for all my partitions (/, /home, /var, /tmp). This allows me to test like hell and have the same nice setup for "testing" the next day after doing this rsync My exclude file consists only of fstab and lilo.conf, the rest will be synchronized.

A /boot partition is completely unnecessary with LILO. I don't know about Grub, but as long as you have different names for different kernels, you can boot all you want with LILO. You don't waste a partition on /boot! It's just another management burden. I boot Winbloze and 5 more OS on one machine with LILO and nobody has a /boot partition.

Personally, I use totally separate areas for my multi-boots, except swap. That way, since I'm using my second install as an experiement area, I NEVER run the chance of 'cross contamination'. I even have different fs on the second install that the first cannot read (disabled in kernel), and vice-versa, just in case... Also, my second install is on a different physical HDD, just in case. What can I say, I wear a belt and suspenders.

As far as partitions go, do as you wish. Everybody does theirs different. If you ask 5 different users what their partition scheme is, you'll get 17 answers.

The advantage to my 'experiment setup'? I have never lost ANY data on my primary due to what I've done on my secondary. Not one byte. I have trashed my entire secondary many times, and would have lost my primary too, if not for the precautions I've taken.

And lilo vs grub? Who cares? Use what you are most comfortable with. I use lilo, but I don't mind typing 'lilo' after installing a new kernel. But I have used grub. Just use what you feel best about.

You can "share" /tmp on both machines if they are really just tmpfs.