FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-15-2012, 12:30 PM
Rich Freeman
 
Default udev <-> mdev

On Sat, Jul 14, 2012 at 9:02 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted:
>>
>> I doubt anybody has tried it, so you'll have to experiment.
>
> "Anybody" /anybody/, or "anybody" on gentoo? FWIW, there are people
> running it in general (IIRC much of the discussion was on Debian, some on
> Fedora/RH), but I didn't see anything out there written from a gentoo
> perspective.

I'd think that a source vs binary distro wouldn't matter much as far
as a tmpfs-based root goes. That is, if you're taking about an empty
root that you just mount stuff on top of.

>> I imagine you could do it with a dracut module. There is already a
>> module that will parse a pre-boot fstab (/etc/fstab.sys). The trick is
>> that you need to create the root filesystem and the mountpoints within
>> it first. The trick will be how dracut handles not specifying a root
>> filesystem.
>
> While I do know dracut is an initr* helper, you just made me quite aware
> of just how much research I'd have to do on the topic. =:^ I wasn't
> aware dracut even /had/ modules, while you're referring to them with the
> ease of familiarity...

See:
http://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/

Much of dracut's power comes from its modules. Again, I'm not sure
how it handles not being given a root at all. You'd have to build a
root, or extract it from a tarball/etc.

Looking at the docs it seems like you'd need a hook for the cmdline
stage that sets rootok (assuming it gets that far without a root, or
if you set it to something like root=TMPFS). Then you'd install a
hook to mount to mount the tmpfs, and then use the fstab-sys module to
mount everything else. You'd need to create mountpoints for
everything of course, and not just the boot-critical stuff, since
otherwise openrc won't be able to finish mounting mounting everything.

>
> The big problem with btrfs subvolumes from my perspective is that they're
> still all on a single primary filesystem, and if that filesystem develops
> problems... all your eggs/data are in one big basket, good luck if the
> bottom drops out of it!

Maybe, but does it really buy you much if you only lose /lib, and not
/usr? I guess it is less data to restore from backup, but...

The beauty of btrfs subvolumes is that it lets you manage all your
storage as a single pool, even more flexibly than LVM. Sure, chopping
it up does reduce the impact of failure a bit, but I'd hate to have to
maintain such a system. Filesystem failure should be a very rare
occurance for any decent filesystem (of course, this is why I won't be
using btrfs in production for a while).

Rich
 
Old 07-15-2012, 06:25 PM
Duncan
 
Default udev <-> mdev

Rich Freeman posted on Sun, 15 Jul 2012 08:30:31 -0400 as excerpted:

> Looking at the docs it seems like you'd need a hook for the cmdline
> stage that sets rootok (assuming it gets that far without a root, or if
> you set it to something like root=TMPFS). Then you'd install a hook to
> mount to mount the tmpfs, and then use the fstab-sys module to mount
> everything else. You'd need to create mountpoints for everything of
> course, and not just the boot-critical stuff, since otherwise openrc
> won't be able to finish mounting mounting everything.

The last bit I had already anticipated, as I'm doing something similar
with my tmpfs-based /tmp and /var/tmp (symlinked to /tmp). Nothing
mounted on top, but I'm creating subdirs inside it, setting permissions,
etc. A critical difference is that this is on a full rootfs so I don't
have to worry about not having the necessary tools available yet, but I
do have the general ideas down. And I'm doing some bind-mounts as well,
which require a remount to let all the options take effect, and of course
there's mount ordering to worry about, etc. So I have the general idea,
but doing it from an initr* with limited tools available will be
interesting.

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.

>> The big problem with btrfs subvolumes from my perspective is that
>> they're still all on a single primary filesystem, and if that
>> filesystem develops problems... all your eggs/data are in one big
>> basket, good luck if the bottom drops out of it!
>
> Maybe, but does it really buy you much if you only lose /lib, and not
> /usr? I guess it is less data to restore from backup, but...

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.

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...).

> The beauty of btrfs subvolumes is that it lets you manage all your
> storage as a single pool, even more flexibly than LVM. Sure, chopping
> it up does reduce the impact of failure a bit, but I'd hate to have to
> maintain such a system. Filesystem failure should be a very rare
> occurance for any decent filesystem (of course, this is why I won't be
> using btrfs in production for a while).

Very rare, yes. Hardware issues happen tho. I remember the a/c failing
at one point, thus causing ambient temps (Phoenix summer) to reach 50C or
so, and who knows how much in the computer. Head-crash time. But after
cooling off, the unmounted-at-the-time filesystems were damaged very
little, while a couple of the mounted filesystems surely had physical
grooves in the platter. Had that been all one filesystem, the damage
would have been far less confined. That's one example.

Another one, happened back when I was beta testing IE4 on MS, was due to
a system software error on their part. IE started bypassing the
filesystem and writing to the cache index directly, but it wasn't set
system attribute, so the defragger moved the file and put something else
in that physical disk location. I had my temp-inet-files on tmp, which
was its own partition and didn't have significant issues, but some of the
other betatesters lost valuable data, overwritten by IE, which was still
bypassing the filesystem and writing directly to what it thought was its
cache index file.

So it's not always filesystem failure, itself. But I tried btrfs for a
bit just to get an idea what it was all about, and agree totally with you
there. I'm off of it entirely now, and won't be touching it again until
I'd guess early next year at the earliest. The thing simply isn't ready
for the expectations I have of my filesystems, and anybody using it now
without backups is simply playing Russian Roulette with their data.

--
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
 
Old 07-15-2012, 06:48 PM
Rich Freeman
 
Default udev <-> mdev

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
 
Old 07-15-2012, 10:34 PM
"Walter Dnes"
 
Default udev <-> mdev

On Fri, Jul 13, 2012 at 05:58:25AM +0000, Duncan wrote

> They're seriously thinking about (and may be planning on) removing
> that option from the kernel entirely, to keep people configuring
> their first kernels from getting themselves in trouble, but of
> course that's now part of the kernel/userspace interface, so it
> isn't allowed to just disappear like kernel/kernel interfaces can.

A couple of points...
1) Your "argument" applies to just about anything in the kernel
configuration process. If you don't follow instructions, the kernel
will encounter anything from partial loss of functionality to possibly
failing to boot at all. I'm a big boy. If I foul up, I'll admit that I
goofed.

2) Full disclosure; I do have an interest in retaining the hotplug
pointer mechanism. I have mdev set up on my machines as per
https://wiki.gentoo.org/wiki/Mdev

Going one step further, I have auto(un)mount working on my machines
as per https://wiki.gentoo.org/wiki/Mdev/Automount_USB and
https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount This has been
working OK for me for a few weeks, and I've asked others to test on
their machines. I'll still consider it beta (Work In Progress) until
other people confirm it works for them. Once that's done, my next
project might be "custom mdev rules", similar to "custom udev rules".

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 07-16-2012, 12:30 AM
Duncan
 
Default udev <-> mdev

Rich Freeman posted on Sun, 15 Jul 2012 14:48:55 -0400 as excerpted:

> 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).

Tarball is an interesting idea I hadn't considered. At first blush I
like it. =:^)

Thinking in that direction does stimulate yet another idea, tho. What
about a squashfs root? AFAIK squashfs is read-only at use time, thus
enforcing actually mounting something else to write anything, eliminating
many of the down sides of sticking with the initial ramfs root, but it
would allow the same flexibility in terms of sticking whatever into it at
create-time, while only taking the memory necessary for what's actually
stuck in it at create-time. I /think/ it's swappable, too, which would
give me some flexibility in terms of letting more stuff be added at
create-time without having to worry about it being locked in memory. And
I think squashfs is reasonably tested territory for this sort of thing,
given its use for live-media, etc. And it's in mainline now, too, which
is nice. =:^) I'll have to do some research and think about that a bit
more...

Definitely thanks for the tarball idea, as otherwise I'd probably have
not got out of my "box" and thought about squashfs. I'm probably missing
its downsides ATM, but you still broke my thinking out of the box!

--
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
 
Old 07-16-2012, 12:57 AM
Michael Mol
 
Default udev <-> mdev

On Sun, Jul 15, 2012 at 8:30 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Rich Freeman posted on Sun, 15 Jul 2012 14:48:55 -0400 as excerpted:
>
>> 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).
>
> Tarball is an interesting idea I hadn't considered. At first blush I
> like it. =:^)
>
> Thinking in that direction does stimulate yet another idea, tho. What
> about a squashfs root? AFAIK squashfs is read-only at use time, thus
> enforcing actually mounting something else to write anything, eliminating
> many of the down sides of sticking with the initial ramfs root, but it
> would allow the same flexibility in terms of sticking whatever into it at
> create-time, while only taking the memory necessary for what's actually
> stuck in it at create-time. I /think/ it's swappable, too, which would
> give me some flexibility in terms of letting more stuff be added at
> create-time without having to worry about it being locked in memory. And
> I think squashfs is reasonably tested territory for this sort of thing,
> given its use for live-media, etc. And it's in mainline now, too, which
> is nice. =:^) I'll have to do some research and think about that a bit
> more...
>
> Definitely thanks for the tarball idea, as otherwise I'd probably have
> not got out of my "box" and thought about squashfs. I'm probably missing
> its downsides ATM, but you still broke my thinking out of the box!

This is sounding closer and closer to an on-disk liveCD.

--
:wq
 
Old 07-16-2012, 01:00 AM
Maxim Kammerer
 
Default udev <-> mdev

On Mon, Jul 16, 2012 at 3:30 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Thinking in that direction does stimulate yet another idea, tho. What
> about a squashfs root? AFAIK squashfs is read-only at use time, thus
> enforcing actually mounting something else to write anything, eliminating
> many of the down sides of sticking with the initial ramfs root, but it
> would allow the same flexibility in terms of sticking whatever into it at
> create-time, while only taking the memory necessary for what's actually
> stuck in it at create-time.

It is possible, see:
https://github.com/mkdesu/liberte/blob/master/src/root/initrd/init
https://github.com/mkdesu/liberte/blob/master/src/etc/fstab

The setup above is somewhat different from what you have in mind
(SquashFS image is located on disk, and contains the complete live
filesystem, not just a skeleton), so mounting read-writable branches
can be deferred to the regular post-initramfs services (such as
localmount) — on the other hand, maybe you want to do the same (mount
branches read-only in initramfs, and remount them read-write in an
init.d service).

--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
 
Old 07-16-2012, 07:30 AM
Nicolas Sebrecht
 
Default udev <-> mdev

The 13/07/12, William Hubbs wrote:

> What about using devtmpfs alone?

It's quiet fine for very simple systems.

--
Nicolas Sebrecht
 
Old 07-16-2012, 08:40 AM
Duncan
 
Default udev <-> mdev

Michael Mol posted on Sun, 15 Jul 2012 20:57:28 -0400 as excerpted:

> This is sounding closer and closer to an on-disk liveCD.

It is, isn't it? But I'd want to keep it reasonably small, as I guess
I'd be rebuilding the squashfs pretty much whenever I updated any package
that it contained binaries from.

Actually, I guess if I did squashfs, I could even mount it directly,
avoiding the initr* entirely, tho in effect it'd be close. I could have
the kernel call a shell script as init, then have it exec the real init
(and thus openrc) after it did some initial setup and mounts, thus
allowing the real init to inherit the same PID 1 it normally gets. (Some
of that idea is triggered by Maxim K's post. Thanks to both of you.)

Alternatively, I could reconfigure inittab to start my script first, then
start openrc (consolidating the openrc sysinit, etc, entries). But that
actually sounds more complex than simply running an initial script as
init, and having it exec init.

--
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
 
Old 07-16-2012, 09:22 AM
Peter Stuge
 
Default udev <-> mdev

Duncan wrote:
> Alternatively, I could reconfigure inittab to start my script first
..
> that actually sounds more complex

Use init. It would be a sensitive script. If it fails the kernel is sad.


//Peter
 

Thread Tools




All times are GMT. The time now is 06:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org