[gentoo-user] Re: Re: can one tell me: gentoo vs opensuse
Dale wrote: I came to Gentoo from Linux From Scratch because I wanted something more user friendly when it came to keeping track of package dependencies and compilation procedures. That is how I describe Gentoo, Linux from Scratch with a package manager and other neat tools. I think Gentoo is about as close to that as it gets. We all know portage is getting really good and full of features over the past few years. I may not agree with Zac on some recent default settings but he sure has pushed portage a long long ways forward. If only Gentoo could wash dishes now. File a feature request on b.g.o? LOL I just came across a perfect example of why I started using Gentoo rather than LFS in the src_prepare() function of the openssh ebuilds. Look at all that complexity that someone else dealt with for you so that emerge Just Works.
[gentoo-user] Re: can one tell me: gentoo vs opensuse
Michael Mol wrote: This. Very much this. My dive into Gentoo came as I was fed up with Debian and Ubuntu having buggy and/or outdated versions of multimedia encoding packages while trying to configure a box specced for live transcoding of h.264 to something my PS3 would like. I came to Gentoo from Linux From Scratch because I wanted something more user friendly when it came to keeping track of package dependencies and compilation procedures.
[gentoo-user] Re: Full disk encryption
czernitko wrote: I would like to have only one partition with all home directories on it, and I would like to avoid usage of initrd as I don't use it now and I would like to keep it that way if possible. You don't need an initramfs but you might want to reconsider not using one at some point. I avoided them for a long time but when I wanted to do whole disk encrypted I learned how to make my own (not particularly difficult) and later started using dracut which basically just works.
[gentoo-user] Re: Re: Full disk encryption
Dale wrote: Did you use a howto for Dracut? If so, have a link you could post? I tried making a init thingy and after about 20 failed reboots, I scraped the idea. I was trying to follow the howto on the Gentoo wiki I think. The unofficial wiki. I had some difficulties because the way I was doing things before with my homebrew solution was... non-standard. The problem areas that I remember from the transition were: setting the USE flags correctly to build the modules I needed, initially confusing dracutmodules and add_dracutmodules in dracut.conf (actually you probably don't even need to edit that file at all), making sure to have a sane /etc/fstab line for the root file system and passing the right root= kernel command line. root=UUID=... works the best in my experience.
[gentoo-user] Re: Re: Full disk encryption
David W Noon wrote:
I have a working initramfs layout, but currently it is too large
(32MiB) for my /boot partition. The problem package is e2fsprogs, as
it requires dynamic linkage and, consequently, a full-sized glibc.
This sucks, so I need to patch the Makefile(s) to build a more sensible
set of executables for an initramfs.
All of the code I have written myself compiles and links statically,
typically using klibc, so my finished code is tiny.
I haven't been working on this for a couple of months now, because the
need for it is not really pressing. The assertion that udev would
require /usr and /var (plus the kitchen sink) really soon is unfounded,
at least for those of us who run more elderly hardware.
Anyhow, when I'm finished there will be a zsh script that will build an
initramfs image, and even install it to /boot, with a single command.
When I made my own initramfs I was operating under the RAM and disk space
are cheap assumption and did it the easiest way possible:
I included the *entirety* of /etc, /bin, /lib{32,64} and /sbin
Then I wrote a small bash script for /init
Throw the kernel and initramfs on a USB stick, install GRUB on said USB
stick and call it a day. If anything breaks, well I've got all the command
like repair tools included so it's no big deal to fix as long as the bash
script sends me to a command line if it has any problems.
[gentoo-user] Re: Re: Re: Full disk encryption
Dale wrote: Jack Byer wrote: Dale wrote: Did you use a howto for Dracut? If so, have a link you could post? I tried making a init thingy and after about 20 failed reboots, I scraped the idea. I was trying to follow the howto on the Gentoo wiki I think. The unofficial wiki. I had some difficulties because the way I was doing things before with my homebrew solution was... non-standard. The problem areas that I remember from the transition were: setting the USE flags correctly to build the modules I needed, initially confusing dracutmodules and add_dracutmodules in dracut.conf (actually you probably don't even need to edit that file at all), making sure to have a sane /etc/fstab line for the root file system and passing the right root= kernel command line. root=UUID=... works the best in my experience. I did change the USE flags for the packages it said to. I think some things have changed or something, maybe openrc?, and the script I was copying and working with just didn't work. Maybe it needs updating or something. I'm hoping to see a up-to-date howto or someone will post a good up-to-date howto for dracut. Something even a idiot could follow. I think it will work for me then. lol Dale :-) :-) I can tell you how mine is set up. emerge -v dracut These are the packages that would be merged, in order: [ebuild R ~] sys-kernel/dracut-013-r2 USE=-debug (-selinux) DRACUT_MODULES=btrfs crypt lvm -biosdevname -caps -crypt-gpg -dmraid - dmsquash-live -gensplash -iscsi -livenet -mdraid -multipath -nbd -nfs - plymouth -syslog -xen 0 kB I don't use any of the other modules so all I enable are btrfs, crypt and lvm. /etc/dracut.conf has no changes from the default except for the line: add_dracutmodules+=crypt dm lvm but I'm about 80% sure even that isn't necessary and you could just leave the default values alone. One of these days I'll get around to testing that. I make an initramfs with the following command: dracut --lzma hostname.dracut.lzma kernel version (obviously change --lzma to whatever type of compression your kernel expects to use and name the file whatever you want. Make sure to include the kernel version just like it appears in your /lib/modules/ directory so that dracut includes the correct kernel modules) Then I make grub.conf look something like this: root (hd0,0) kernel /hostname root=UUID=08b00d7f-b633-4c03-98fe-dd5942a8fb7e initrd /hostname.dracut.lzma I like to name my kernels and initramfs files by the hostname of the computer since I have three that I manage but use whatever you want and just make sure you put the right filenames in grub.conf. You can obtain the UUID of your root filesystem by a number of methods, but the easiest is to use ls -l /dev/disks/by-uuid/ That's really all there is to it. Dracut will boot up and load the modules it is compiled with and search through the disks, logical volumes, and dmcrypt containers until it finds a filesystem with the UUID you specify. Once it finds the root filesystem it mounts it with whatever options you've specified in /etc/fstab and then hands control over to OpenRC. If it has the necessary modules (kernel and dracut) and you pass the right root= option then it Just Works.
[gentoo-user] Re: dmraid, mdraid, lvm, btrfs, what?
Florian Philipp wrote: Another thing you can think of is whether you want encryption. I've done this for my laptop. The usual setup would by md-lvm-crypt. I've done it crypt-lvm (an LVM physical volume on top of an encrypted partition). This way, I only need to enter the password once. You can enforce a specific order between lvm, md and dmcrypt by putting stuff like this in /etc/rc.conf: rc_dmcrypt_before=lvm rc_dmcrypt_after=udev I like to use whole disk encryption so I'll format each drive with LUKS and then use Dracut for an initramfs when I boot so that it takes care of setting up dmcrypt/lvm/md before OpenRC ever starts up.
[gentoo-user] Re: emerge -j, make -j and make -l
Pandu Poluan wrote: On Nov 28, 2011 6:24 AM, Neil Bothwick n...@digimed.co.uk wrote: On Mon, 28 Nov 2011 00:56:17 +0700, Pandu Poluan wrote: I don't know where the 'blame' lies, but I've found myself standardizing on MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS=--jobs --load-average=1.6*num_of_vCPU (Yes, no explicit number of jobs. The newer portages are smart enough to keep starting new jobs until the load number is reached) The problem I found with that is the ebuilds load the system lightly to start with, before they enter the compile phase, to portage starts dozens of parallel ebuilds, then the system gets completely bogged down when they start compiling. Yes, sometimes that would happen if at the beginning there are network-bound ebuilds all downloading their respective distfiles. The load stays low until they all start ./configure-ing roughly at the same time. Then all hell breaks loose. I successfully mitigate such load-explosion by doing a --fetchonly step first, and keeping MAKEOPTS at low -j (which, in my case, is actually required). Just to add more info: I use USE=graphite (with some CFLAGS, uh, 'enhancements') with gcc-4.5.3. IIRC, I could push MAKEOPTS up to -j5 (and even more, but I ran out of cores) when I was still using gcc-4.4.x and no USE=graphite. Won't file a bug report, though. I have a feeling that my bug report re: emerge failure will be marked WONTFIX thanks to the 'ricer special' CFLAGS :-P Rgds, It would be nice if there were some way to mark particular packages that should never be compiled in parallel (like the trick for using a using a separate, non-tmpfs build directory for large packages). The load-explosion you describe is bad enough with regular packages but when firefox, xulrunner, chromium and libreoffice all decide to start compiling at the same time it turns into a complete nightmare.
