Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

 

 

First page Previous page 1 2 3 4 5 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


kumba at gentoo

Mar 15, 2012, 5:09 AM

Post #76 of 108 (439 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 18:14, David Leverton wrote:

> On 14 March 2012 21:04, Greg KH <gregkh [at] gentoo> wrote:
>> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
>> and /bin/ into /usr/ it makes even more sense. See the /usr page at
>> fedora for all of the great reasons why this is good.
>
> My point was examine, in detail, whether separate-/usr-with-initramfs
> has any disadvantages compared to separate-/usr-without-initramfs.
> Either it has, in which case we have a concrete argument against
> requiring initramfs (albeit possibly one that can be fixed), or it
> hasn't, which should hopefully convince at least some people to accept
> it.


I went with a split filesystem design when I built my first Gentoo install
back in mid 2003 because at the time, both the Gentoo and Debian security
guides referenced it as being an option for a more secure system.

Specifically so that you could apply mount options to each partition. For
example, on /home, you would usually want to do nodev and nosuid, because
rarely does a user need the ability to create device nodes and SUID
binaries. On /var, nodev, nosuid, and noexec, with the one exception if you
ran qmail or a few other packages known to stick executables into /var. For
/usr, the guides suggested just nodev, because you rarely, if ever need to
create device nodes in /usr. Optionally, you could mount /usr ro and only
make it rw if updating packages.

You won't find A separate /usr mentioned specifically anymore in either
security guide, but I'm sure if you dig on the Wayback Machine (once it
comes back online), you can probably find these references. Search from
2003 to 2007. I'm not certain when they were removed.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 5:16 AM

Post #77 of 108 (437 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 18:51, Greg KH wrote:

> On Wed, Mar 14, 2012 at 10:14:54PM +0000, David Leverton wrote:
>> On 14 March 2012 21:04, Greg KH <gregkh [at] gentoo> wrote:
>>> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
>>> and /bin/ into /usr/ it makes even more sense. See the /usr page at
>>> fedora for all of the great reasons why this is good.
>>
>> My point was examine, in detail, whether separate-/usr-with-initramfs
>> has any disadvantages compared to separate-/usr-without-initramfs.
>
> Oh, that's simple, separate-/usr-without-initramfs will not work and
> will not be supported :)


Not supported by whom? udev? Or Gentoo?

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 5:23 AM

Post #78 of 108 (440 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/15/2012 07:20, Stelian Ionescu wrote:

> On Thu, 2012-03-15 at 00:29 +0000, David Leverton wrote:
>> On 14 March 2012 23:44, Greg KH <gregkh [at] gentoo> wrote:
>>> Oh, and somehow "consensus" will work? No, sorry, it will not.
>>
>> No, logical analysis will, as I said in the rest of my post which you
>> conveniently ignored - either we conclude with evidence that there are
>> no issues, which should settle the matter for reasonable people, or we
>> discover that there are, in which case they have to be dealt with one
>> way or another. I really don't see how anyone can object to that,
>> unless they're worried they won't like the result....
>>
>>> How about the basic FACT that today, such systems do not work
>>
>> This is debatable at best. You can keep screaming "but bluetooth
>> won't work!" until you're blue in the face, but that's not relevant at
>> all to people who don't use bluetooth.
>
> That's true, but given the need to have a "one size fits all" boot
> system(for obvious practical reasons), such boot system needs to work
> with bluetooth input devices


With Gentoo, that's really only for the preliminary installation. Once you
get the system up and running, you're free to modify it in whatever way
pleases you.

For binary distributions, especially those that deal in the enterprise
sector, the one-size-fits-all approach is damn near mandatory because most
admins run with the distro-provided kernel and typically are not custom
compiling them.

But we're not a binary distro. We're a source-based distro, although it's
possible to run Gentoo in a binary fashion. As such, we're not necessarily
beholden to the "one-size-fits-all" approach.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 5:27 AM

Post #79 of 108 (443 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 20:45, Zac Medico wrote:

> On 03/14/2012 05:36 PM, David Leverton wrote:
>> On 14 March 2012 23:47, Zac Medico <zmedico [at] gentoo> wrote:
>>> It's more about what we're _not_ doing that what we're doing.
>>
>> Clearly something must have changed in udev 181 to make
>> /usr-without-initramfs not work anymore, and someone must have done
>> something to make that change happen, unless udev has aquired the
>> ability to evolve by itself.
>
> You're pointing your finger at udev, but the udev change is just a
> symptom of a more general shift away from supporting the "/ is a
> self-contained boot disk that is independent of /usr" use case.


I think it's better to say that udev is one of the more important components
of your average Linux system that's decided to support a unified root + /usr
filesystem. If we were looking at some non-critical, non-boot service that
made this decision, then we wouldn't be having this discussion.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


rich0 at gentoo

Mar 15, 2012, 5:30 AM

Post #80 of 108 (447 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Thu, Mar 15, 2012 at 7:04 AM, Joshua Kinard <kumba [at] gentoo> wrote:
> This does lead me to wonder if a light-weight udev could exist that lacks
> half or more of the functionality of the current udev. †I'll be honest, I've
> only edited my udev rules file once, and that was only when I installed a
> Sun Happy Meal quad ethernet card in which all four ports utilize the same
> MAC address and udev doesn't handle this very gracefully (if I had Solaris,
> I could edit the card's firmware and change this setting).

You know - I had a similar issue, but with a pair of PL2303 USB RS232
interfaces. That makes me wonder if there is a possible way to
enhance udev to better handle situations where devices have no unique
ID and thus tend to be difficult to access consistently across
reboots. In my case I had to hack a rule so that I got a symlink if
the device was in a specific USB slot. Use case is controlling tuners
for mythtv.

No doubt a simpler 80% solution could be created for udev, and likely
it would be easier to cut down on its dependencies as a result.
However, the other 20% of users will still need the more complete
solution. Big distros that want to support lots of hardware with a
one-size-fits-all configuration will just deploy that complete
solution everywhere, which means that the only people maintaining the
simple solution would be people who like to tailor each system.

For most of the more enterprise-y OS providers (ie the ones with money
to pay devs), one-size-fits-all is a lot more sustainable. You won't
find an edition of MS Windows that works only on PCs without scanners
and sound but uses 50MB less RAM, for example.

Sure, we don't have the same constraints as the enterprise-y distros,
but we do have the constraint that if we want to do things differently
we will spend a lot of time patching what we could otherwise simply
reuse as-is.

I don't think that split filesystem installs are going away anytime
soon. In fact, when btrfs is finally mature we might see them
blossum. Using subvolumes you could have more granular snapshotting
and mount options, while still maintaining a shared disk space pool
(with granular quotas). If everything the distro is likely to mangle
is in a few subvolumes you can reverts snapshots on those without
losing changes in other subvolumes if you ran in production before
deciding to revert. That gets you a lot more flexibility than a
single snapshot on root - especially in terms of recovery time (you
can still copy files between snapshots if you only snapshotted root -
in fact with reflinks this is very fast).

Rich


kumba at gentoo

Mar 15, 2012, 5:34 AM

Post #81 of 108 (437 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 19:27, Richard Yao wrote:

> On 03/14/12 18:49, Greg KH wrote:
>> On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
>>> With that said, I have a few questions:
>>>
>>> 1. Why does no one mention the enterprise use case at all?
>>
>> It has been pointed out before, why constantly repeat ourselves.
>
> Simple. No one has documented it. A webpage that makes a few vague
> references to "enterprise use" does not count as documentation.
>
> I happened to figure it out when trying to rationalize why anyone would
> want this, but this is hardly obvious to those that imagine a computer
> as a self-sufficient single disk system.


You'll also find a lot of enterprise-specific decisions went into IPv6,
without necessarily stating them as being enterprise-specific. I.e., the
requirement for Unique Local Addresses, which are IPv6's idea of RFC1918,
required to be "globally-unique". When I quizzed someone about this one (I
think it was on ServerFault somewhere), I was basically told that "IPv6 is
not for home use".


>>> 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
>>
>> unionfs is still a "work in progress", some systems can't do that yet.
>
> That sounds like something that needs to be fixed.


I thought UnionFS died? Or was better handled by other "tricks" involving
filesystem overlays?


>>> 3. Why not let the users choose where these directories go and support
>>> both locations?
>>
>> Because a plethera of options is a sure way to make sure that half of
>> them don't work over the long run.
>>
>> We aren't Debian here people, we don't support "everything" :)
>
> Gentoo provides far more options than Debian does, so this seems
> somewhat contradictory to me.


Agreed. Debian is focused on an entirely different model of building a
Linux system, thus they have a narrower dependency chain and you sometimes
have to include packages that you don't necessarily care for because they're
required by a package that you do want to use. We have USE flags to resolve
that issue.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 5:40 AM

Post #82 of 108 (440 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 19:37, Greg KH wrote:

> On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote:
>>>> 3. Why not let the users choose where these directories go and support
>>>> both locations?
>>>
>>> Because a plethera of options is a sure way to make sure that half of
>>> them don't work over the long run.
>>>
>>> We aren't Debian here people, we don't support "everything" :)
>>
>> Gentoo provides far more options than Debian does, so this seems
>> somewhat contradictory to me.
>
> Not really, I don't think we support systems without udev anymore,
> right? And we get away with a lot of these different "options" at
> compile time, which makes it easier than what Debian has to handle, so
> perhaps it's not a fair comparison.

I already looked in the tree and nothing really stands out as a suitable
replacement for /dev management. mdev might, but it's part of busybox and
not standalone as far as I know (at least, we don't have an independent
package for it).

For my simplistic setups, I apparently only need udev just to setup the
networking interfaces, because Linux has never created /dev/lo or /dev/ethX
(nor does it even support them). Thus, CONFIG_DEVTMPFS can't set those up
at all. If I could find a small utility that was like udev and which took
care of that one little element, I think I'd be able to boot my systems up
just fine.

Is it futureproof? Not really. I imagine plugging USB mass storage devices
into a udevless system might be problematic. Food for thought.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 5:47 AM

Post #83 of 108 (441 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 16:55, Zac Medico wrote:

>> Deprecation of this practice would mean that people could type
>> /bin/command instead of /usr/bin/command in situations where absolute
>> paths are necessary. We could symlink things in /usr to rootfs for
>> compatibility with legacy software. In a more extreme case, we could
>> symlink /usr to /, which would make plenty of sense given that we do not
>> need a separate /usr at all.
>
> I'm not seeing any compelling benefits here that would justify a lack of
> conformity with other *nix distros. It seems almost as though it's an
> attempt to be different for the sake of being different, perhaps a
> symptom of something like NIH syndrome.


Gentoo, by its very nature, has always been regarded as somewhat
non-conformist. When Gentoo first popped onto the scene, most other distros
didn't do colors in the terminal. We did. And it all branches out from there.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 5:51 AM

Post #84 of 108 (444 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 13:59, Rich Freeman wrote:

> On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico <zmedico [at] gentoo> wrote:
>> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>>> What's wrong with:
>>> * having an "early mounts" list file
>>> * having an "early modules" list file
>>> * init system in early boot (e.g., OpenRC in init.sh) loading "early
>>> modules" and mounting "early mounts" from /etc/fstab
>>
>> You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init.
>> Other that that, it sounds like a perfect solution if you're in the "I'd
>> rather die than use an initramfs" camp.
>
> Well, anybody is welcome to create any replacement/addition for
> (/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it
> good enough, perhaps others will even use it.
>
> Beyond that, anything else is just a suggestion. In the end the folks
> writing udev and systemd are writing code, which gets them a lot
> further than emails do... :)

Debian has a small, yet fairly unique little package called "file-rc" that
replaces their more traditional init system with a single text file,
/etc/runlevels, to manage system services. A small utility runs that parses
the text file and sets up the /etc/rc.x symlinks for you, based on that file.

Fairly novel little package. Wholly-incompatible with Gentoo's system,
without fully replacing OpenRC, but I would actually be interested in seeing
something like this on Gentoo (such as something that simply parses and
executes rc-update to change things).

http://packages.debian.org/squeeze/file-rc

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 6:05 AM

Post #85 of 108 (450 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/15/2012 08:30, Rich Freeman wrote:

>
> You know - I had a similar issue, but with a pair of PL2303 USB RS232
> interfaces. That makes me wonder if there is a possible way to
> enhance udev to better handle situations where devices have no unique
> ID and thus tend to be difficult to access consistently across
> reboots. In my case I had to hack a rule so that I got a symlink if
> the device was in a specific USB slot. Use case is controlling tuners
> for mythtv.


I use a ton of the pl2303-based devices, too. Except I'm usually in Windows
with them, so I just have to deal with Window's oddball way of renumbering
them sometimes when I unplug one and plug it right back into the same USB
slot (i.e., I lost COM11, and it's now COM14, which, ironically, is outside
the range of TeraTerm)


> No doubt a simpler 80% solution could be created for udev, and likely
> it would be easier to cut down on its dependencies as a result.
> However, the other 20% of users will still need the more complete
> solution. Big distros that want to support lots of hardware with a
> one-size-fits-all configuration will just deploy that complete
> solution everywhere, which means that the only people maintaining the
> simple solution would be people who like to tailor each system.

That, or udev making more of its functionality optional via its build system
(does it use autotools and configure, I never looked, to be honest?). This
would allow additional USE flags to be added to enable or disable additional
functionality as needed.


> For most of the more enterprise-y OS providers (ie the ones with money
> to pay devs), one-size-fits-all is a lot more sustainable. You won't
> find an edition of MS Windows that works only on PCs without scanners
> and sound but uses 50MB less RAM, for example.


Funny, but as much as I am against Windows on a server, Windows Server is
easier to turn off unneeded stuff than RHEL5 is. Windows Server comes with
audio and TWAIN/IMAPI components disabled (or out right missing -- you have
to add them back in through server manager). But try to remove features
like sound, CD burning, various media players, text-to-speech, etc, from a
fresh RHEL5 install, and you're in for a fight. It's not necessarily RHEL's
fault, but more Gnome's fault because of the massive about of
interdependency that you get with Gnome, and the fact RH chose to just not
bother with it and build in a ton of stuff by default.

Ditto for an install of OpenSolaris that I did.


> I don't think that split filesystem installs are going away anytime
> soon. In fact, when btrfs is finally mature we might see them
> blossum. Using subvolumes you could have more granular snapshotting
> and mount options, while still maintaining a shared disk space pool
> (with granular quotas). If everything the distro is likely to mangle
> is in a few subvolumes you can reverts snapshots on those without
> losing changes in other subvolumes if you ran in production before
> deciding to revert. That gets you a lot more flexibility than a
> single snapshot on root - especially in terms of recovery time (you
> can still copy files between snapshots if you only snapshotted root -
> in fact with reflinks this is very fast).


ZFS encourages creating volumes and filesystems en masse. Right down to a
separate ZFS mount for each user's home directory under /home, and /home
itself is a mount point. So yeah, Btrfs, ZFS, etc...get an FS like those
two which not only encourage dozens of mount points, but which seamlessly
hide all the dirty details from you (and the users), and issues like this
will simply vanish into thin air.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 6:07 AM

Post #86 of 108 (441 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181] [In reply to]

On 03/14/2012 16:10, Kent Fredric wrote:

>
> Considering this pretty much eliminates using / for anything useful,
> we might as well rename "/usr" "/c"
>
> Even if it /is/ just to confuse the windows crowd =)


Unless you're one of those that installs Windows into D:\ :)

I'd say call it /sys for NetWare's old SYS:\ volume, but that's already
taken by sysfs.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 6:22 AM

Post #87 of 108 (436 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 12:28, Matthew Summers wrote:

>
> Gentoo provides a solution with genkernel, dracut provides a solution,
> even the linux kernel itself provides a solution (in my view the
> easiest solution at that).


The kernel doesn't appear to create the networking interfaces, though.
CONFIG_DEVTMPFS is only going to handle things that physically exist within
/dev, of which, ethernet devices have always been excluded. If that can get
fixed in some fashion, then devtmpfs pretty much does make this a non-issue.


> I just wanted to drop this simple fact in there. This has been coming
> for several years now AND the linux kernel has been using an initramfs
> for every boot, every time for a long time now, all 2.6 and up as I
> understand it. If the initramfs is empty, well the kernel is smart
> enough to fall back on "legacy" boot process.


initramfs was introduced in 2.6.10, and prior to that, only a handful of
architectures even supported a built-in initrd (MIPS was one, and it wasn't
very pretty or functional). I believe other distros required the bootloader
to pass the initrd to them somehow, but having never used an initrd in that
fashion, I don't know for certain.

But yes, if you enable CONFIG_IKCONFIG_PROC, you're essentially turning on
(or utilizing) an initramfs accessible via /proc.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 6:36 AM

Post #88 of 108 (441 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 14:56, Zac Medico wrote:

> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>> <quantumsummers [at] gentoo> wrote:
>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>> etc.
>>
>> There is nothing bad about initramfs. I think that you are misreading
>> the arguments above.
>
> Whatever the arguments may be, the whole discussion boils down to the
> fact that the only people who seem to have a "problem" are those that
> have a separate /usr partition and simultaneously refuse to use an
> initramfs.


I refuse to use an initramfs as this point in time because I haven't had to
use one in the past 10 years to get my Gentoo installs to boot. Right now,
all three active Gentoo installs that I have (x86_64, Vbox, MIPS) boot
*fine* with a separate /usr and no initramfs. That, in my opinion, is not
"broke", despite statements made to the contrary.

It only became "broke" when individuals not involved with Gentoo declared it
to be "broke", and then back it up with use-case scenarios that are really
only applicable to their distribution of choice.

I'm not saying that I'll continue to not use an initramfs, but I would like
for some Gentoo-specific reasoning to be offered as to why we have to follow
along with this change. Constantly referring to Fedora or Freedesktop
websites for their reasoning doesn't matter to me. I don't use Fedora nor
do I use X11 (at least the server. I tunnel 2-5 X11 apps over SSH, however).

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


kumba at gentoo

Mar 15, 2012, 7:01 AM

Post #89 of 108 (444 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 19:44, Greg KH wrote:

>
> Oh, and somehow "consensus" will work? No, sorry, it will not.


If compelling arguments were used, yes, you can sometimes trigger people to
change their minds and arrive at a consensus. But outright dismissing them
as if that will make them disappear is what won't work.


> So it's not a "we know best", it's a "it will not properly work
> otherwise."


Udev is the only package I have installed in my VM setup that fails at boot
with a separate /usr and no initramfs. And that isn't even a fatal failure,
but it is a failure none the less, at least by virtue of OpenRC flagging the
fact that udev returned an error code. Everything else works fine.

But it's not udev that is broke, is it? It's my setup, right? I've been
wrong for the last 10 years? Why was this ever referenced then in the
Security Handbook? See Code Listing 1.1:

http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1&chap=4


> It is strange to watch people somehow think that if they complain
> enough, or feel strongly enough, something is going to change here to
> make this basic fact go away.


It's human nature to complain or otherwise voice dissent, especially when
someone or something comes along and declares that what used to JustWork(TM)
now NoLongerWorks(TM).

Does that mean my dissent matters? Probably not. But that's not going to
stop me from trying.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


gregkh at gentoo

Mar 15, 2012, 7:41 AM

Post #90 of 108 (439 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Thu, Mar 15, 2012 at 07:04:52AM -0400, Joshua Kinard wrote:
> Devtmpfs quite literally handles 98% of my particular usage scenario. Does
> that apply to everyone? Nope. Just an interesting observation.

devtmpfs does not handle device permissions.

As for a "smaller" udev, feel free to try, please realize that this that
is what udev used to be, before it was fixed to work properly. udev is
very small and compact, but patches to make it smaller are always
welcome.

There's always mudev if you don't want to run udev, good luck with that.

greg k-h


gregkh at gentoo

Mar 15, 2012, 7:42 AM

Post #91 of 108 (441 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Thu, Mar 15, 2012 at 08:30:49AM -0400, Rich Freeman wrote:
> You know - I had a similar issue, but with a pair of PL2303 USB RS232
> interfaces. That makes me wonder if there is a possible way to
> enhance udev to better handle situations where devices have no unique
> ID and thus tend to be difficult to access consistently across
> reboots. In my case I had to hack a rule so that I got a symlink if
> the device was in a specific USB slot. Use case is controlling tuners
> for mythtv.

Why not use the links in /dev/serial/ which are there for this specific
reason?

greg k-h


zmedico at gentoo

Mar 15, 2012, 8:29 AM

Post #92 of 108 (440 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/15/2012 05:27 AM, Joshua Kinard wrote:
> On 03/14/2012 20:45, Zac Medico wrote:
>
>> On 03/14/2012 05:36 PM, David Leverton wrote:
>>> On 14 March 2012 23:47, Zac Medico <zmedico [at] gentoo> wrote:
>>>> It's more about what we're _not_ doing that what we're doing.
>>>
>>> Clearly something must have changed in udev 181 to make
>>> /usr-without-initramfs not work anymore, and someone must have done
>>> something to make that change happen, unless udev has aquired the
>>> ability to evolve by itself.
>>
>> You're pointing your finger at udev, but the udev change is just a
>> symptom of a more general shift away from supporting the "/ is a
>> self-contained boot disk that is independent of /usr" use case.
>
>
> I think it's better to say that udev is one of the more important components
> of your average Linux system that's decided to support a unified root + /usr
> filesystem. If we were looking at some non-critical, non-boot service that
> made this decision, then we wouldn't be having this discussion.

They're intertwined though, since having a unified root implies that
there is no support for the "/ is a self-contained boot disk that is
independent of /usr" use case, and the bulk of people's opposition to
having a unified root seems to stem from their dependence on the "/ is a
self-contained boot disk that is independent of /usr" use case.

So, the question at the heart of the whole discussion is: Should we
support the "/ is a self-contained boot disk that is independent of
/usr" use case?
--
Thanks,
Zac


rich0 at gentoo

Mar 15, 2012, 12:04 PM

Post #93 of 108 (441 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Thu, Mar 15, 2012 at 10:42 AM, Greg KH <gregkh [at] gentoo> wrote:
>
> Why not use the links in /dev/serial/ which are there for this specific
> reason?
>

# ls -l /dev/serial
ls: cannot access /dev/serial: No such file or directory

Something in a newer version of udev perhaps? Or would my defining my
own symlinks end up overriding some rule elsewhere. I just added
these lines to /etc/udev/rules.d:
SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0",
KERNEL=="ttyUSB*", SYMLINK="mythser/rca1"
SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="3-3:1.0",
KERNEL=="ttyUSB*", SYMLINK="mythser/rca2"

Rich


ryao at cs

Mar 15, 2012, 1:44 PM

Post #94 of 108 (441 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/15/12 08:40, Joshua Kinard wrote:
> I already looked in the tree and nothing really stands out as a suitable
> replacement for /dev management. mdev might, but it's part of busybox and
> not standalone as far as I know (at least, we don't have an independent
> package for it).

Busybox is installed as part of the system profile on amd64. You can
install mdev by doing this:

ln -s /bin/busybox /sbin/mdev

There is documentation in the busybox GIT for how to use it:

http://git.busybox.net/busybox/plain/docs/mdev.txt
Attachments: signature.asc (0.88 KB)


ryao at cs

Mar 15, 2012, 1:45 PM

Post #95 of 108 (437 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/15/12 08:34, Joshua Kinard wrote:
> On 03/14/2012 19:27, Richard Yao wrote:
>
>> On 03/14/12 18:49, Greg KH wrote:
>>>> 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
>>>
>>> unionfs is still a "work in progress", some systems can't do that yet.
>>
>> That sounds like something that needs to be fixed.
>
>
> I thought UnionFS died? Or was better handled by other "tricks" involving
> filesystem overlays?

I know the UnionFS developer offline. I will ask him what the status of
unionFS is the next time I see him. :)
Attachments: signature.asc (0.88 KB)


mk at dee

Mar 15, 2012, 2:49 PM

Post #96 of 108 (441 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Thu, Mar 15, 2012 at 22:45, Richard Yao <ryao [at] cs> wrote:
> I know the UnionFS developer offline. I will ask him what the status of
> unionFS is the next time I see him. :)

Unionfs patchset is regularly released for new kernels, and bugs are
fixed. I wouldn't call the project "dead", I would call it "mature"
and "stable". I am not aware of the current state of affairs wrt.
Unionfs vs. aufs, and whether the propaganda at unionfs.org still
holds water, though. Too bad that there is no stacking filesystem in
the mainline kernel.

--
Maxim Kammerer
Libertť Linux (discussion / support: http://dee.su/liberte-contribute)


kumba at gentoo

Mar 15, 2012, 5:47 PM

Post #97 of 108 (436 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/15/2012 10:41, Greg KH wrote:

>
> There's always mudev if you don't want to run udev, good luck with that.


Got a link? We don't have anything matching in the tree, and Google turns
up nothing relevant in the first few pages.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


caneko at gmail

Mar 15, 2012, 6:17 PM

Post #98 of 108 (438 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 7:07 PM, Rich Freeman <rich0 [at] gentoo> wrote:
> On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao <ryao [at] cs> wrote:
>>
>> I proposed a way that this could work with no effort on the part of the
>> Gentoo developers in one of my earlier emails:
>>
>
> Then go ahead and make it happen.  If as you say no dev participation
> is needed there is nothing Gentoo needs to do to support this.
>
> On Wed, Mar 14, 2012 at 6:49 PM, Greg KH <gregkh [at] gentoo> wrote:
>>
>> We aren't Debian here people, we don't support "everything" :)
>>
>> If you want to support both, great, feel free to step up and do the
>> work.
>>
>
> Gentoo is about choice, but it is largely about the choices that
> people are willing to step up and maintain.
>
> A few months ago there was a big thread and lots of devs said that
> systemd isn't supported on Gentoo.  Some devs stepped up and decided
> to maintain it and now I'd say systemd is about as supported on Gentoo
> as Prefix, FreeBSD, Sparc, or MIPS.  That didn't happen because of
> mailing list persuasion - it happened because a few people interested
> in making it happen wrote a bunch of ebuilds.  How do systemd units
> end up in various packages?  The people interested in seeing them
> write good-quality patches and submit bugs, or otherwise work with the
> maintainers to commit them.
>
> For those who don't like the current direction, by all means create an
> overlay called udev-root, mdev-boot, noinitramfs, or whatever.  You
> don't need anybody's permission to do it - just go on github and make
> it happen.  Write some good code.  There are several devs here who
> might even help you out with it, and nobody here is going to object to
> packages going into the main tree as long as they're maintained in
> accordance with Gentoo QA.  Create some USE flags where you need
> tie-ins to other system packages and as long as everything behaves
> nicely and patches are good and maintained, I'm sure the package
> maintainers will accept them.

In that vein... just to let you guys know that I have set up an
overlay that has allowed me to run my Gentoo machines with only
systemd: no OpenRC, no baselayout, no sysvinit:

http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/

The changes are rather minimal (less than ten lines (usually a cople)
per ebuild changed from the original ebuilds in the tree), and almost
all will go away when the following bugs get fixed:

https://bugs.gentoo.org/show_bug.cgi?id=366173
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=405703
https://bugs.gentoo.org/show_bug.cgi?id=408379

Bug 373219 is specially problematic, since several scripts in packages
on the tree source /etc/init.d/functions.sh, (which lives in OpenRC),
and don't depend on OpenRC explicitly. I wrote a little script that
replaces the einfo, ewarn, etc. functions of OpenRC, and it seems to
be working. I also wrote alternative versions of the packages on the
tree that implicitly depend on OpenRC, so they now explicitly depend
on a little package that only installs my script.

It seems to be working.

If you guys want to try it, I would love to hear some comments about
it. (Usual disclaimer; if it breaks, you get to keep all the pieces).

Oh, and obviously the only supported setups are those with /usr in the
same partition as /; or, if /usr is in a separated partition, systems
that use an initramfs to mount it.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México


caneko at gmail

Mar 15, 2012, 6:18 PM

Post #99 of 108 (437 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Thu, Mar 15, 2012 at 7:17 PM, Canek Peláez Valdés <caneko [at] gmail> wrote:

[...]

> https://bugs.gentoo.org/show_bug.cgi?id=366173
> https://bugs.gentoo.org/show_bug.cgi?id=373219
> https://bugs.gentoo.org/show_bug.cgi?id=399615
> https://bugs.gentoo.org/show_bug.cgi?id=405703
> https://bugs.gentoo.org/show_bug.cgi?id=408379

Oops, sorry, fogot to use uniq.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México


gregkh at gentoo

Mar 15, 2012, 7:43 PM

Post #100 of 108 (441 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote:
> On 03/15/2012 10:41, Greg KH wrote:
>
> >
> > There's always mudev if you don't want to run udev, good luck with that.
>
>
> Got a link? We don't have anything matching in the tree, and Google turns
> up nothing relevant in the first few pages.

Sorry, I think it's called 'mdev' and is part of busybox.

greg "no one asked me to adopt a package, amazing" k-h

First page Previous page 1 2 3 4 5 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.