Beso <givemesug...@gmail.com> posted d257c3560901221103l4f11f220mc9f2b7598f7c3...@mail.gmail.com, excerpted below, on Thu, 22 Jan 2009 20:03:55 +0100:
> as for the / i'm considering using / + /boot on a usb disk (nowadays > booting from usb devices is no pain) and would prevent me from > exposing ciphered luks data. it's true that loosing the key would > mean a total disaster, but it's simpler to have 2-3 2gb usb keys (which > mean about 20-30€) as root and have an entire luks+raided partition. Something I found out the hard way, and why I have everything that portage touches on the same partition, is the trouble one goes thru when the /var/db/pkg database doesn't match what's actually installed, due to say /, /usr, and /var being on different partitions/volumes, then losing one and having to revert to a backup, while still having the others at "current". So here, that's all on the same partition. I break off /usr/src, /usr/local and /var/log, and have the Gentoo tree living somewhere other than on /usr as well, but anything that portage touches including its database is all on the same partition, so it all stays in sync if I have to revert to a backup. When I setup this system, since / and its backup are not in LVM, I wanted to give them even more room for growth than I thought I'd need, so I doubled what I was using for growth, and then nearly doubled that again, 10 gig partition size. I currently have both kde3 and kde4 installed so am running rather more than I would otherwise, but I'm running 4.3 gig on /. So a 4 gig USB stick would do it in most cases, an 8-gig stick would be plenty and to spare, but a 2 gig stick wouldn't cut it. Not that anyone else necessarily needs to use my "everything portage touches on one partition" strategy, but I certainly learned /my/ lesson, and don't intend on screwing /that/ one up here again. It's worth considering, anyway. YMMV. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
