Okay, here is my question -
I have slack 9 installed and am beginning on my LFS journey. I was wondering - since I would only boot into one (Slack, LFS) at once, could i have them share swap space? Or is that a linux no-no.

Thanks a bunch!

sharing swap partitions b/n linux distros is completely acceptable. Don't know why you would need seperate ones, since the data is not very permanent.

you could also think of sharing /home and whatnot.

Thanks a bunch for your help. I never thought of sharing /home (though sharing /usr would be a bad/impossible idea, rite?)

Not necessarily 'impossible', but bad yes. You'd probably want to share at least 1 (besides swap and /boot) for data, and /home seems to be the most common. The only draw back is that because of the same reason to share home, is the same reason to not share /home. The personal files (see . files). If you have different versions of the same application on the 2 different distros, the . files might not be compatible, and you'd run into a world of troubleshooting only to find it was a small setting in a . or hidden file that was causing the problem all along.

That's why I suggest sharing a data partition, maybe /mnt/share or something along those lines that personal files are not kept in.



Cool

a) Thanx for pointing me to sharing of /boot too. Didn't know I could do that
b) Good point about the . files - I didn't know that that could be a poblem but what you're saying makes sense.

Thanks to you both - I may get this working yet ~~

EDIT: Is there anything in particular that I should watch out for in the LFS build when sharing boot - that is, will the normal course of LFS creation interfere with anything slack specific in /boot?

Thanks again.

Nope. Sharing /boot is just sharing the common kernel container. So when you copy your kernel to your /boot directory, you will just be copying it to a general /boot directory which is the same partition mounted on each distro at the mount point /boot (hope that makes sense). Just make sure it's mounted is all...
Oh, and that it exists in your /etc/fstab file for every distro, otherwise it won't get automounted, and you'll get kernel panics if you don't have backups.

Cool

Gracias.


Why am I doing this and not my term paper? I don't know...

EDIT: I'm really sorry and don't want to keep pestering you with questions, but I have one more. :sheepishgrin:
So when I get to the appropritate part of LFS where it says "compile the kernel now," do I a)
just continue on through 'cause the kernels already there in boot or b) recompile the kernel to set up dependencies and such... i've never recompiled the kernel so I don't know how many dependencies there are to setup...

I'm really sorry to keep asking q's, but I'm just trying to be extra sure...

I don't know how LFS does its thing (yeah...I know I should try it sooner or later), but you will do everything as usual. The only difference is after the kernel compile, you will move the resulting images to your general /boot partition, where lilo can find them.

btw, no 'dependencies' in kernel - this is only to make the correct hardware work, and remove any drivers that you don't need (remember that the kernel sits in your memory, so the smaller it is, the better)

Okie dokie - thanks a bunch...

When you get to the very bottom, right before the part where you reboot, simply mount up the partition you created to have as your /boot partition at the mount point /boot; then you copy the kernel over, and are done. You will either later (or if you are using the lilo.conf from LFS then now) edit your boot loader to show the new kernel, or add it to your boot loader that you are syncing up and save it:
/sbin/lilo -v



Trust me, once you get to that part, it will seem more obvious; if not, go ahead and post up.

Cool

Well, I guess I'll check back then...

I run a rather large network, with a hodgepodge of RedHat, Gentoo, Solaris, and (gasp) windows. I use the same /home directory for everything, and haven't run into an major issues with software versions. Most of them are pretty good about making sure mutually exclusive settings for different versions live in different directories.

I do periodically wipe all of my . directories out of principle though.

In my environment, I have a lot of file system shared through NFS between a bunch of computers.

As long as you have machines with roughly the same architecture (say all x86), you can share the /usr/local and /opt drives with impunity. I use that for all the custom-built software that
a) I want all of the installations to have
and
b) I can control what libraries they are linked against (or statically link them better still)

If you compile everything the put information in a consistent place, /var is also a good candidate for sharing.

/tmp is a no brainer.

Big ticket, or very generic items, like JDK and Open Office work well in these environments. I'll deliberately compile them to sit in /usr/local or /opt.

YMMV

Of course, since only one OS will be reading the software at a time, you don't have the file locking issues that plague NFS.