From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.77) (envelope-from ) id 1SqTtv-0000bs-Mx for garchives@archives.gentoo.org; Sun, 15 Jul 2012 18:50:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9A18AE0693; Sun, 15 Jul 2012 18:50:06 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 24FE9E075C for ; Sun, 15 Jul 2012 18:48:55 +0000 (UTC) Received: by bkwj4 with SMTP id j4so3887710bkw.40 for ; Sun, 15 Jul 2012 11:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=uiCoLGrhXeG+NPcug9eYMtyGjbWvVZ1Oau+pfbJiDOo=; b=TfzkqGqRmwjljEAjlKSgnTP6JrEBSTDW01fDriOVRbhMpq2b63HXk+2BB/bMpY/bWR OtC9NxSgMahIES7kgL/PUTEs9xH5EJYCNhoKQlxNFSZWtugmZ23aSW0KgefC8+nD0KtT LfHYtmJCiHMPh+/gi0ynzFXxcPV32pFm4WaK7GLwLxv5UR/vhee8eUQksQHDNHeA8mIG Gnro5a1TFUVvR55p3mr/vLg1o2w61TBC0OpEbcuvl9fFmQOEoSz4xZHX5Fg4z95iwnkd uGGVvvfF0aDwJa90KIRpKgR+BwXOl8lAo9zTas09UgUWSqimo6TobhfnSOORvuViE/je UUag== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.133.194 with SMTP id g2mr3706784bkt.13.1342378135179; Sun, 15 Jul 2012 11:48:55 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.205.35.79 with HTTP; Sun, 15 Jul 2012 11:48:55 -0700 (PDT) In-Reply-To: References: <20120712200741.GB3723@waltdnes.org> <20120712222931.GA3044@linux1> <20120713200449.GA6292@waltdnes.org> <50008143.3050708@gentoo.org> <20120714001343.GA6879@waltdnes.org> <20120714031327.GA8799@linux1> <20120714210221.30059.qmail@stuge.se> Date: Sun, 15 Jul 2012 14:48:55 -0400 X-Google-Sender-Auth: xKE4hOuqwtU3swtschaZWHms0Dw Message-ID: Subject: Re: [gentoo-dev] Re: udev <-> mdev From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 1d2773fd-6733-4b1a-ae9a-ea2153c1b0ec X-Archives-Hash: 8c7ac38d5c422989aae4199c65d63710 On Sun, Jul 15, 2012 at 2:25 PM, Duncan <1i5t5.duncan@cox.net> wrote: > So I have the general idea, > but doing it from an initr* with limited tools available will be > interesting. > Dracut modules can specify any tools they need, and they will be loaded into the initramfs. Obviously you'll want to use some discretion here. > As for the tmpfs rootfs itself, I have the vague idea that I'd > "simply" (note the scare-quotes) use what's normally the initial root > that's essentially thrown away, only I'd not throw it away, I'd just > mount everything on top, keep using it, and /somehow/ ensure that > anything running from it directly terminates one way or another, so that > I don't have old processes stuck around using the mounted-over points. I suspect you could do that, but you'd probably have to change the cleanup code, and you need to keep in mind that the initramfs runs on ramfs and not tmpfs. While similar there are a few important differences. Ramfs does not support size limits, so you can extinguish all of your ram easily enough. Ramfs also does not swap, which means that any actual content in that filesystem will waste ram, whether it is used or not. Anything that writes to it could wipe out all your memory even if you have swap available. The design of ramfs is designed for simplicity rather than robustness (you can support an initramfs on a system that otherwise lacks the drivers for tmpfs. > Which is why I keep /usr (and /lib64 and /usr/lib64) on rootfs currently, > tho the traditional /usr/src/, /usr/local, and /usr/portage are either > pointed elsewhere with the appropriate vars or mountpoints/symlinks to > elsewhere. Of course that'd have to change a bit for a tmpfs rootfs, > since /lib64, /usr and /etc would obviously be mounted from elsewhere, > but they could still be either symlinked or bind-mounted to the > appropriate location on the single (read-only) system-filesystem. Giving it a little thought, the simplest tmpfs-based root would be one that defines a tarball as a the root. The system would create a tmpfs, extract the tarball to it, and then use the existing fstab-sys module to mount stuff on top of that. This gives you the option of actually putting some content in the tarball, or just storing an empty directory structure in it. A tarball would let you set permissions/etc and be a bit more generic than writing a custom script. If you wrote a module to do this I wouldn't be suprised if upstream let you merge it. You'd just need to define some kind of sane syntax for it (root=TAR=path...to...tarball - though how a path works with nothing mounted you'd have to define). Maybe you define the tarball at initramfs creation (as is done with fstab.sys and mdadm.conf). > > FWIW I remember being truly fascinated with the power of symlinks when I > first switched from MS. Now I consider them normal, but the power and > flexibility of bind-mounts still amazes me, especially since, as with > symlinks, it's possible to bind-mount individual files, but unlike > symlinks (more like hard-links but cross-filesystem), it's possible to > have some of the bind-mounts read-write (or dev, exec, etc) while others > are read-only (or nodev, noexec...). Yup, my /usr and /var are bind-mounts - I was following the pre-initramfs raid guide and had my root on a raid1, and wanted to keep it minimal. However, rather than having 47 individual filesystems in lvm I only defined a few and bind-mounted half the tree off of one of them. Fstab.sys seems to handle that just fine (mounting the main mountpoint first, and the bind mounts afterwards). Rich