Multi-Distro Booting - How do you setup yours?
|
| Author | Content |
|---|---|
| techiem2 Feb 25, 2008 11:27 AM EDT |
So my ZaReason UltraLap SR should be here Wednesday - yay! - and I'm trying to decide what the best method is for booting multiple distros.
It's been quite a while since I've done so, so I figured I'd ask how you guys/gals do it to get some ideas. Shared /boot with single mbr grub configured to boot each? Grub on each using a chainload from mbr grub like kicking over windows? Other? What's your method? Mark II |
| jdixon Feb 25, 2008 11:43 AM EDT |
Install VMWare Server or VirtualBox on your primary distro and run virtual machines for the others. :) |
| azerthoth Feb 25, 2008 11:46 AM EDT |
I keep a seperate /home and have each distro point back to it, then everything else goes into a single partition. I do not allow the second, third, etc distro overwrite grub, instead I take a few minutes to hand hack a new entry in. I should say also that the first install gets a seperate /boot so that in case of changing my production distro I wont loose anything if I wipe that partition. |
| Steven_Rosenber Feb 25, 2008 11:51 AM EDT |
While I don't recommend dual- or triple-booting, I do it all the time. (Yes, I don't follow my own recommendation). For Linux and BSD, I let one of the Linux distros control the MBR and put entries for all the others in that distro's /boot/grub/menu.lst. I've tried shared /home partitions, but I've run into trouble with config. files working in one distro and not so well in another. So I do have separate /home partitions, but I tend not to share them among the two (or three) distros on the box. But I do/will read/save files from one distro into another's /home partition. I also tend to run Puppy Linux as a live CD (you can do the same with Knoppix, Damn Small Linux, Wolvix, etc.) and create a save file for it on one of the partitions. Some people do prefer chainloading. If I install Slackware 12 again, I will install LILO in its partition but boot to it via GRUB and a chainloader, because I've never had any luck with Slack 12 and GRUB ... BSDs are blissfully easy to boot from a Linux's GRUB, but I've never been able to figure out how to add a Linux distro to a BSD bootloader ... |
| tracyanne Feb 25, 2008 12:02 PM EDT |
I don't dual boot these days. I use a second machine or a Virtual machine for testing distros, and I don't run Windows on my personal machines. |
| Abe Feb 25, 2008 1:59 PM EDT |
It depends on what you have in hardware and what you want to do with the the multiple distros. VirtualBox or VMWare Server gives you the best flexibility to run any multiple distros and even Windows if you have enough hardware resources (Memory, disk space, etc). If you don't go this route, and you are planing to run XP, Create a partition and install Windows first (you don't have to but it is the easiest). I do that on my work laptop. Create / (root) partitions and a shred home partition. You have to be careful about the home partition in regards to the owner group & user. If they are different in different distros, you would have to make sure to change them to be the same. Other than that, it shouldn't be a problem. If you have enough hardware, use VirtualBox or VMWare. I have several old computers without enough resource for VB/VM, so I use multiple machines with dual boots as described above. [Added] You might want to look into running some distros from a USB drive if you have one. I like to explore this option myself. |
| Steven_Rosenber Feb 25, 2008 2:32 PM EDT |
What I didn't say above was that I'm all in favor of single-booting with a separate /home partition. that way, if you want to swap distros, you can keep the same /home and not reformat it (but be sure you have a backup before you roll in a new OS). I'd probably delete all the dot files before installing the new OS, just so I don't end up with configurations from the old distro on the new one. However, it might be OK to leave them (or, at least, move them into a directory in /home so you can swap them in if you want or need to. Even if you won't be doing a lot of distro-hopping, a separate /home partition is a good idea -- you never know when you'll have to do a reinstall, and this takes some of the trouble out of the equation. |
| tuxtom Feb 25, 2008 2:40 PM EDT |
I've switched to the VM route for my main workstation, but still dual-boot a couple laptops for testing and an issue on a Vista-native laptop where ndiswrapper (Broadcom 802.11...sorry tuxchick) has a DHCP bug in the current Gutsy kernel (I'm too lazy to work on that one as it isn't my main machine). I do get most of my Windows client testing done in a VM, though. It's also a lot faster than constantly rebooting live CD's or grubbing different partitions. Plus...and it's a real plus...you can move the same image around and run it on different hardware to your heart's content. I need to try VirtualBox. I'm about VM"Warez"d out. |
| gus3 Feb 25, 2008 10:17 PM EDT |
At my last job, we used swappable IDE disk brackets with cheap (old) hard drives. Beat the pants off multi-boot partition maintenance, when it was an option. |
| number6x Feb 26, 2008 5:50 AM EDT |
Any opinions on Xen vs. Virtual Box Vs. VMware? Is the OS version of VB still a cut down version of the pay version? |
| jdixon Feb 26, 2008 6:24 AM EDT |
I've only used VMWare, and it seems to work well. VirtualBox is a much smaller package and probably lacks some of VMware's features, but for the average desktop user I doubt there's a significant difference. There have been a couple of recent reviews on the LXer newswire you might want to look at. From what I've read, Xen seems to be a lot more DYI than the other two. |
| Sander_Marechal Feb 26, 2008 6:36 AM EDT |
I've played with Xen when Etch came out. My conclusion back then was that it was great for servers. Anything that runs off a machine with a CPU., harddisk and a network connection will work great in Xen. As soon as you need more, like perepials (CD-ROM, printer, sound card) then it becomes a lot less attractive. From what I understand, VirtualBox's main benefit is that it can hide your Windows desktop and put only the application windows on your Linux desktop. This makes it feel much more integrated then when you're staring at a desktop-on-a-desktop. More like Wine. Just my $0.02 of course. |
| wjl Feb 26, 2008 8:38 AM EDT |
Quoting:Any opinions on Xen vs. Virtual Box Vs. VMware? That's a bit like comparing apples to oranges IMHO - Xen is the perfect hypervisor for servers, VB is the perfect thing for a workstation where you like to test around, VMware is the 800-pound-gorilla which got a tad too heavy for my personal taste and use... I'm dual-booting on the machine I'm writing this (the home TV server), because I want to try Mythbuntu against my proven Etch/Myth setup. I'm also having several virtual machines here. On another machine (with Intel 915 chipset, P4, 512MB, 80GB), I have quad-booting of Etch, Lenny, Sid, and Ubuntu Gutsy. I'm using a single mbr and /boot partition, shared swap, separate small /homes, and a bigger common /exthome (extended home) for sharing. That's my home, at the moment. Oh, almost forgot: my wife dual-boots Debian Lenny and sometimes Etch, when something is broken in Lenny. HTH, Wolfgang P.S.: thanks for buying a ZaReason machine... sorry - couldn't resist ;-) |
| techiem2 Feb 26, 2008 8:56 AM EDT |
:)
I'm going to have a shared /home, but I think I'm not going to actually share the user home dir on it due to the possibility of conflicts that has been mentioned.
I'll probably do something like mount the partition on /mnt/homes
Then symlink /home to like /mnt/homes/home-ubuntustudio (the preinstall), /mnt/homes/home-gentoo (the gentoo install I'm of course doing alongside it), etc (I'll probably use some disk space for testing other distros to see how they run on the laptop - or just to show off.). I've never played with Xen. Virtualbox is great for testing stuff and using in general, though it's kind of a pain to use with livecds (have a testing vm defined, add the iso into the list, set vm to use that iso...). VMware server is nice...when it works (haven't played with vmware player and it's been years since I used vmware workstation - have they released that free yet?). I always had problems with it breaking randomly on me. I use qemu for testing livecds (and resort to virtualbox if the livecd doesn't like qemu). I'm using qemu in headless mode on one of my boxes for my two virtualized servers (quite nice. works well, and qemu has built in vnc so I can connect directly to the vms if I want). |
| tuxtom Feb 26, 2008 9:43 AM EDT |
techiem2: Shared home is tough, I've found. There are so many hidden directories that start to conflict with each other that your configuration from one distro to another goes haywire. Perhaps some people here have had better experiences with it. If you just want to share data in the different OS's then why not just use a USB hard drive? That could be tapped by any OS running native or in a VM. |
| number6x Feb 26, 2008 10:16 AM EDT |
Shared home can work if you have two installations of the same distro with exactly the same mix and version of installed apps. Applications of different version number might be expecting different layouts for config files. The same goes for different distros. Even using the same distro, a red hat 4.x .profile script probably will not work on a fedora 8 install (fvwm v. gnome). Things may 'mostly' work and then go wonky. If you want to share data across logins, set up a partition and mount it as a directory under /mnt/datashare and give each of your separate login id's in each distro read/write access to it. (Thanks for the advice on VM stuff, I think I'll start w/ Virtual Box) |
| techiem2 Feb 26, 2008 10:21 AM EDT |
tuxtom: Yeah, that's why I'm thinking a shared home partition, but separate dir for each distro on it (easy to back it up then). As for sharing gobs of data, that's what the 750GB external hdd is for. :) And the UltraLap SR has an esata port so I can take advantage of that (hopefully) instead of tying up a USB port. |
| Sander_Marechal Feb 26, 2008 11:06 AM EDT |
It would be nice if there was a way to have a shared home but still have per-distro configuration/dotfiles. It would be useful for example if the LSB stadards required that all configuration and dotfile go in $CONFIG/application-name where $CONFIG is an environment variable that defaults to ~/.config. That way you could simply export $CONFIG as ~/.config-ubuntu, ~/.config-debian-etch, etcetera based in some logic in your .bashrc, depending on the distro you're loading. |
| tuxtom Feb 26, 2008 12:54 PM EDT |
It would be nice, but ~ is ~ and everything will look there for your dot files. I'm not sure how much of a demand there would be for your config idea, however. Dual-booting is really becoming obsolete with VM technology maturing the way it has. But hey, where there's a will there's a way! |
| jdixon Feb 26, 2008 3:48 PM EDT |
> ...and it's been years since I used vmware workstation - have they released that free yet? No, and apparently have no plans to. VMware Server is their equivalent free product. And yes, I agree that the installation is fragile. Something as simple as a power failure or forced reboot while a virtual machine is powered on can crash VMware to the point where you have to perform a complete reinstallation. |
| tuxtom Feb 26, 2008 3:54 PM EDT |
Quoting:Something as simple as a power failure or forced reboot while a virtual machine is powered on can crash VMware to the point where you have to perform a complete reinstallation.I lost a very important image that way. My bad for not backing it up. |
| hkwint Feb 26, 2008 4:19 PM EDT |
If you used Klik, you could use the same apps + app data (like bookmarks) in every distro; no need to re-install those apps. So instead of only keeping your /home dir, you'd also keep all your applications, installed at the non-root level in /home too. http://klik.atekon.de/wiki/index.php/Klik2 Work is being done on Suse-support of Klik2, but it is already provided as a package in other distro's. |
| Sander_Marechal Feb 26, 2008 10:20 PM EDT |
Klik is nice in some cases, but usually it just bloats your system. Think about it: Each and every application needs to contain all their dependencies -- all the way down the stack to glibc -- in order to function. It has to do that or you'll quickly get dreaded messages like "Can't find GLIBC_2.4" which I get when I to install a daliy build ofe Blender on my Etch machine (Etch ships with glibc 3.6). How many copies if the KDE libs do you want on your system? How many copies of the Gnome libs? That all has to be statically linked in the application and/or put in the Klik package. To add to the complexity, upgrading a library on your system does not upgrade the libraries in the Klik packages of course. Klik is a nice concept if you need some application to be portable (like on an USB stick) but for regular applications I'll stick to regular distro packages. |
| wjl Feb 27, 2008 12:03 AM EDT |
Good point, Sander - and thanks for sharing it, so I don't have to look into it further ;-) |
| hkwint Feb 27, 2008 11:31 AM EDT |
Quoting:Each and every application needs to contain all their dependencies -- all the way down the stack to glibc -- in order to function Hehe, you should have gone to the KLIK presentation, then you'd have known that's simply not true. Klik expects / requires a working base system, which includes glibc, qt and gtk, but it doesn't include Mono. So those are only loaded once. It is the intention for the KLIK apps to use backports: They should be compiled using as old glibc / gtk as possible. That way users of several versions of gtk etc. should be able to use KLIK. Of course this could present dependency problems, but until now it has not been I understood. Klik aims to put everything 'not found on a common Linux system' in the image, which is for example why it doesn't expect Mono, and Mono is indeed part of the image file of apps needing it. Everything is provided by the Linux distro (common stuf) or the image. Klik is great for testing software or using software not available on your distro. I could'n get csound compiled, because it needed acient stuff conflicting with my base system (my Gentoo build-environment was to up-to-date to compile it). Klik was just 1 click (like the name suggested) and it worked. By the way: the OpenOffice for the KLIK-sytsem is several 10s of Megs smaller than a normal installation, so it saves disk-space too. Not too mention your insecure Firefox-add-ons can't touch your office documents. I remember writing an article, and indeed, I found it, dated oct '05: "Browser security: why an insecure browse-only account doesn't work" http://lxer.com/module/newswire/lf/view/45624/ KLIK is a simple and convenient solution for the problem I presented there. It's the thing Dell must have envisioned when talking about 'virtual throw-away browser environments'. A KLIK program takes two clicks (and confirmation maybe) to throw away, and both installing / removing it can be done without root-privileges. I heard some other rumours about upcoming KLIK improvements, making it possibly even far more secure in the near future. Simply put it presents a way of putting all your applications + application data on portable media, and then plugging that portable media in to whatever distro you like (as long as the KLIK client runs on it) in a safe way; impossible to screw up the installation because it's read only (unless you throw away the image file, but it's simple to get a new one). If you left your USB-stick home, hell, you could mount your apps over the net using Samba or something like it - if the network connection is quick enough which means the used program shouldn't be too big. It also makes it very convenient to test alpha-versions. Developers could package it once (.deb, .rpm or .tgz), and after it is made KLIKable users of all distro's could test it without SVN-checking and compiling. Yeah, I'm definitely pro KLIK. For the time being, it's the Linux killer app* Windows doesn't have (yet), and which is not easily portable to Windows (AFAIK). It's a wonderful package manager (probably even more than than) for the 90% of the Linux users out there who don't have the high demands like 90% of the LXer readers, and a solution to a lot of security problems. *It is dependent on several Linux-killer apps like (fake)chroot; a way to make chroot 'overlays', a kind of zisofs with write-support, .deb Debian packages, a portage system building the image at the client side, and FUSE. Because it builds the image at the client side - a bit like the way Gentoo does, it can support non-freely-(re)distributable stuff like Google Earth. It will probably work - without too much efforts - on Mac and Free/NetBSD too; I have to check the status of it however. That means you could switch from Lin to BSD or Mac while still having the same apps and user data. |
| Sander_Marechal Feb 27, 2008 2:14 PM EDT |
Quoting:Klik expects / requires a working base system, which includes glibc, qt and gtk, but it doesn't include Mono. Ah, so klik doesn't allow package-once-run-everywhere. It still doesn't solve my glibc problem. And the things that are not part of the base system still get repackaged in every package, duplicating them all over the place. Klik is still an interesting concept but I feel that it's trying to solve a problem that doesn't exist. Not anymore anyway. It looks like a way to solve dependency hell but we've already solved that by creating vast repositories and doing dependency resolving. I don't have to go on the internet and find a specific application. Everything I can possibly want is just an apt-get away. Or an "Applications >> Add/remove software" if you're the GUI kind of guy. For me, Linux's #1 feature is that my OS and it's applications are integrated. I get it all from the same source: my distro. It's all set-up to work with each other. If I update, I update *everything* and not just the OS or an application. That's a killer feature that I've impressed many newbies with, after they recovered from the shock of seeing vista-esque effects on their desktop that could barely run XP. Software repositories and distro packaging are far, far ahead of anything you'll find in the WIndows world. I feel klik is a step back to Windows in that regard. |
| tracyanne Feb 27, 2008 7:02 PM EDT |
Check this one out http://www.andlinux.org/index.phpQuoting:andLinux is a complete Ubuntu Linux system running seamlessly in Windows 2000 based systems (2000, XP, 2003, Vista; 32-bit versions only). This project was started for Dynamism for the GP2X community, but its userbase far exceeds its original design. andLinux is free and will remain so, but donations are greatly needed. |
| hkwint Feb 28, 2008 7:29 AM EDT |
Quoting: Quoted: Klik expects / requires a working base system, which includes glibc, qt and gtk, but it doesn't include Mono. Ah, so klik doesn't allow package-once-run-everywhere. [quote] That's not the problem it aims to solve. As you suggest that problem seems gone, even my home-brew Gentoo system doesn't have more than one dep-problem per month, if it has any at all. It was a way of solving other problems: -To solve the problem of ISV's (packaging software for different distro's; with Klik only once) which is why a lot of ISV's don't want to support Linux currently, -To solve the inconveniences of plug-in / add-on developers (faster development as developers don't have to SVN / compile the newest sources), -To solve the problem of developers wanting to let users test their new version and wanting to distribute that new version in binary form (they only have to package their new alpha version once and it runs on any distro) and testers. -It aims to provide the Linux users with a distro-agnostic way of package management and an easier way of testing development versions. I'm not sure about Debian, but using two versions of the same package is a hassle most of the times. -It addresses the great annoyance of the user to provide a (root) password when installing new software, -Because of the virtualization, it can't touch your other documents. -If a Linux user wants to throw away an application including all the files it is dependent on (remove the dependencies and config-files too), it's very hard to find those deps and find out if they are needed by other software. Therefore, a lot of files on a typical Linux-user system are not used at all, and just are garbage. -Linux doesn't currently have portable apps like 'even' Windows does, meaning it's hard to share a program you like. -At this moment it's hard to remove software which you installed out of your normal package management system -Currently it's hard to use the same package twice but with different configurations. -Because of the ports-like structure it also enables distributing software of which the binaries cannot be mirrored by a distro Just like with normal distro's, it has a repository (only one is allowed at this time, more may follow), so you don't need to surf the web. It also aims to make Linux. |
| hkwint Feb 28, 2008 7:30 AM EDT |
Quoting:Check this one out HYPERLINK@www.andlinux.org Sounds nice. You have experiences with it? |
| tracyanne Feb 28, 2008 11:50 AM EDT |
Quoting:You have experiences with it? No I was going to try it on my work computer, if I get the time, or, as the boss wants me to study for a Microsoft certification, on the machine I set up at home with the copy of Windows he's going to give me. |
| Sander_Marechal Feb 28, 2008 2:34 PM EDT |
Quoting:Check this one out [e-mail:HYPERLINK@www.andlinux.org] There's something wrong with that link. Quoting:To solve the problem of ISV's (packaging software for different distro's; with Klik only once) which is why a lot of ISV's don't want to support Linux currently That's binary/closed software most likely. The universally accepted cross-distro package standard for FOSS is still a .tar.gz which you can configure && make && make install. My gnome-hearts game is in at least a dozen distro's and I get good downloads from my site as well. I have no idea how the various mirrors are doing. I only make two packages: The .tar.gz upstream source and a .deb for Debian Sid, to be uploaded to Sid by the pkg-gnome team. From there it's picked up by the distro's themselves. WIth FOSS you don't have to package for umpteen different distros. They do it for you. This is a closed-source software problem, so "Meh". Quoting:To solve the problem of developers wanting to let users test their new version and wanting to distribute that new version in binary form (they only have to package their new alpha version once and it runs on any distro) and testers. You can't make patches for binaries. Testing should be done from source, preferably straight from CVS or Subversion. That way the tester can not only report a bug, but find it's cause as well and perhaps even send in a patch. That's what makes FOSS "tick". Debian has some *great* tools for that, like Debuild and svn-buildpackage. They can build a .deb for you straight from the upstream SVN repository, merge it with your local changes and add the /debian package from the Debian SVN repositories. With one command I get an installable .deb fresh from the latest SVN. My own patches (if any) included. Quoting:It aims to provide the Linux users with a distro-agnostic way of package management and an easier way of testing development versions. I explained in my post above what I think about distro-agnostic packaging. Quoting:I'm not sure about Debian, but using two versions of the same package is a hassle most of the times. Usually on Debian it works fine. It depends on how the application was packaged. Pretty much everything that you'd want to run two versions of has been packaged in such a way that it "just works". Quoting:It addresses the great annoyance of the user to provide a (root) password when installing new software, I consider it a *good* thing that you need to have the root password to install software. Being annoyed by it is just Windows-itis. Quoting:If a Linux user wants to throw away an application including all the files it is dependent on (remove the dependencies and config-files too), it's very hard to find those deps and find out if they are needed by other software. Therefore, a lot of files on a typical Linux-user system are not used at all, and just are garbage. In Debian, aptitude (an apt-get alternative) can do this apparently. Sorry if I sound harsh. I'm not attacking you :-) Klik is nice in some aspects and does have it's uses. But IMHO using it generally and liberally takes away too many of the advantages of the current way of distro packaging in exchange for pleasing the people who like the "Windows way". There are good reasons why the current distro-repository way has prevailed so far. It fosters FOSS development, experimentation, customization, integration and cross-breading on the distro level. With distro-agonistic packaging your only recourse is upstream, from which the Klik package was created. You loose a very big development playground: The distro. |
| tracyanne Feb 28, 2008 4:02 PM EDT |
The original link that I posted works fine http://www.andlinux.org/index.php |
| Sander_Marechal Feb 28, 2008 4:29 PM EDT |
Ah, thanks tracyanne :-) Somehow I didn't register that Hans was posting a quote. |
| hkwint Feb 29, 2008 8:38 AM EDT |
Well, Sander, you are just pointing at the reasons why other people might use Klik, and the reasons you don't need it at this moment. You can use it next to your normal package manager, so as an add-on it can help someone out in case there's no package available for some distro. The partial virtualization (what is what this thread should be about before I came in probably) makes the applications more secure and portable without the overhead of a full virtualization like running your browser in a VMWare image for security reasons only; though that's another option of course. Even without Klik, I should look at the 'partial virtualization' options, as I think this might be the big thing for Linux now virtualization becomes commodity.
Back to Klik: At this moment, you are dependent of your distro when it comes to packaging, and that's the problem those people are trying to address (I wasn't really clear about this). If you use Debian, that's not a problem at all; it probably has the best packages out there. Klik by the way uses the Debian packages most of the time, which indicates when it comes to Debian, packages are handled fine.
However, maybe there's only an rpm available? Or maybe the people developing Debian would like to do something different than making .debs out of rpms and .tar.gz's? Maybe some users are not 'capable enough' to use SVN but still want to help testing? Maybe an OpenSuse user tried to help these people out by making a package from SVN but only made it available as an rpm including Suse's quirks? Maybe people don't want to compile and try programs which are indicated to pose a security risk to their system? Maybe you need two versions of a package which just does not work? Maybe you want to e-mail
the newest SVN checkout of gnome-hearts to a user who doesn't have Debian (me for example :) ) and gcc? Or maybe you want to make it available to people over an SSH-filesystem without people having to download it; just running it from a server?
Indeed, as indicated, most current users don't have a problem using Linux package management, but you don't want to feed all the people (mainly rusted Windows and Apple users indeed) not understanding it. Also, for people developing a new distro (or the ones working on a rather new distro) this could be a timesaver since they don't have to care about package management if Klik is supported and can work on GUI's of their distro instead.
My conclusion is; if you're happy with your current package management system, and I can understand most rpm/deb users are, you don't need Klik, but it could be a nice add-on for those few programs for which a deb is not available (rpm / tar.gz can be put into a Klik image too), or if you want to try software which may pose a security risk to your system, or just to try partial virtualization. For Gentoo users, the benefits are clear: For example there's no ebuild for Gnome-hearts, but probably if there would be I'd have to built tons of Gnome-software because I don't have Gnome installed, but I do have the 'basic' Gnome-libs (needed by Klik). I could turn it into an ebuild so Gentoo users can use it, but I also could try to turn it into a Klik package. That would be probably easier for me to do, since making ebuilds is not simple I discovered a while ago (even changing them was not to be learned within an hour). Also, users from a lot of other distro's could benefit too.
Sure, I could use a way of running .debs in Gentoo, I once installed an rpm, but it's not easy to learn two or three package systems. So the current solution is workable, but completely dependent on your distro or yourself. If the package maintainers of your distro for some reason don't have the time to release new versions, are to busy arguing or are gone, you're on your own.
Independence of the distribution is what the presentation started with BTW, but which I forgot. I'm glad all this comes up now; so I can address this comments in my article (to be written as soon as X starts again on this box or I know how to cut and paste in Links) |
| Sander_Marechal Feb 29, 2008 2:29 PM EDT |
Quoting:Maybe you want to e-mail the newest SVN checkout of gnome-hearts to a user who doesn't have Debian (me for example :) ) and gcc? I really don't think that there's a Gentoo box out there that doesn't have GCC. Not even yours :-P |
| techiem2 Mar 07, 2008 2:12 PM EDT |
Well, my shiny laptop is up and running.
:)
I've been working on my Gentoo setup on it.
So I have the stock Ubuntu Studio install, then my Gentoo install.
I use the stock grub install to boot the appropriate distro.
I have the home partition mounted as /mnt/homes under each distro.
/home on each is a symlink to /mnt/homes/homes-distro (/mnt/homes/homes-us, /mnt/homes/homes-g32). I have a little review of the machine written up on my blog now. http://www.techiem2.net/index.php?/archives/8-ZaReason-Ultra... Next I need to do a writeup about using Gentoo on it. |
You cannot post until you login.