Re: [gentoo-dev] udev and /usr
On 19-09-2011 19:19:12 -0400, Joshua Kinard wrote:
Really, MacOS's filesystem layout is not something anyone in their right
mind should deign to mimic/copy.
I didn't get that from either of the links you posted. Seems to me the
systemd developers are looking at the split as a host-specific / vs
host-independent /usr.
From:
http://marc.info/?l=linux-hotplugm=131206447302056w=2
Kay Sievers writes:
What's not needed today is stuff in /. We can think of /usr a /System.
The entire system is installed in one single directory, and that can
be mounted r/o, or even shared between many hosts/guest. The stuff on
the rootfs is always host-only then.
It is from this that I derive the concept of a few folks wanting everything
in /usr, as-if to brand /usr the new / (where the 'old' / has just directory
stubs and a few symlinks, maybe some minor bits in /etc). That's also where
my Mac comment stems from, in that /System hides most of the details of the
BSD-nature of MacOS X, and tries to dissuade the user from ever having to go
in there.
Not sure what you mean here. An OSX system has /bin, /sbin, and
/usr/{bin,lib}. What's in /Library and /System is typically what the OS
uses for its own services and graphical stuff. So, /System doesn't
hide any BSD-nature to me. It's true that a normal user really has
nothing to do in /System.
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] udev and /usr
On 09/15/2011 10:33, Joost Roeleveld wrote: Hi Devs, Not sure if you are aware of the discussions on the gentoo-user list about the upcoming change where systemd and udev require /usr to be available prior to starting of udev. What is systemd again? Yes, some of us live in a tiny box filled with non-x86 hardware, and don't always get out to see the Daystar. Is it an init replacement? If sowhy? Or to quote an Admiral from Hunt for the Red October: Admiral Josh Painter: This business will get out of control. It will get out of control and we'll be lucky to live through it. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On 09/18/2011 13:26, Nirbheek Chauhan wrote:
I don't see how this is relevant to the problem of udev and /usr at
all. Unless you want to go back to the days of devfs and lots of
manual configuration. :)
Me either (somewhat). But I do see is this: If udev is going to make it a
requirement that one or more paritions be available at udevd start time,
then maybe going back to devfs might not be such a bad idea after all.
I use plain vanilla setups on almost any Linux box I build. For x86, LILO
(yes, that thing), a simple kernel, most hardware built in, some extraneous
stuff built as modules. sysvinit for the init package, /{usr,home,var,tmp}
on separate partitions, no X11, no gnome, no KDE, no Xfce, no fluxbox, no
IRIS Indigo, no aewm++, no CDE, no DBUS, no audio support (the machine
doesn't even have an audio card), headless (except with it messes up, which
is very rare), etc. I.e., I run my box like a server.
My MIPS systems (the working ones, anyways) are even more vanilla. I
netboot each of them off my x86 box versus using a bootloader, they have
what amounts to a minimal Gentoo install, system + plus other utilities,
definitely no X11, etc.
These setups are pretty much plain vanilla Linux/UNIX setups, and it's what
has worked for years, so I don't see a need to change it with a permanence.
If other distros want to create alternatives, that is fine. But *I* should
retain the choice to use or not to use those alternatives. That means, udev
needs to be configurable enough to allow me to make it _not_ require /usr
being available. Let the default be the other way -- that's fine.
But if udev upstream is taking *away* choice, and making /usr mandatory
(especially if it's because some other distro has this offbeat, utopian,
überDesktop concept), then that's a bug and someone needs to write a patch
and send it upstream.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
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
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Mon, 19 Sep 2011 03:59:43 -0400 Joshua Kinard ku...@gentoo.org wrote: On 09/15/2011 10:33, Joost Roeleveld wrote: Hi Devs, Not sure if you are aware of the discussions on the gentoo-user list about the upcoming change where systemd and udev require /usr to be available prior to starting of udev. What is systemd again? Yes, some of us live in a tiny box filled with non-x86 hardware, and don't always get out to see the Daystar. Is it an init replacement? If sowhy? Because noone actually used init, rather forked few processes out of it and let it rot. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 1:15 AM, Joshua Kinard ku...@gentoo.org wrote:
On 09/18/2011 13:26, Nirbheek Chauhan wrote:
I don't see how this is relevant to the problem of udev and /usr at
all. Unless you want to go back to the days of devfs and lots of
manual configuration. :)
Me either (somewhat). But I do see is this: If udev is going to make it a
requirement that one or more paritions be available at udevd start time,
then maybe going back to devfs might not be such a bad idea after all.
I use plain vanilla setups on almost any Linux box I build. For x86, LILO
(yes, that thing), a simple kernel, most hardware built in, some extraneous
stuff built as modules. sysvinit for the init package, /{usr,home,var,tmp}
on separate partitions, no X11, no gnome, no KDE, no Xfce, no fluxbox, no
IRIS Indigo, no aewm++, no CDE, no DBUS, no audio support (the machine
doesn't even have an audio card), headless (except with it messes up, which
is very rare), etc. I.e., I run my box like a server.
My MIPS systems (the working ones, anyways) are even more vanilla. I
netboot each of them off my x86 box versus using a bootloader, they have
what amounts to a minimal Gentoo install, system + plus other utilities,
definitely no X11, etc.
These setups are pretty much plain vanilla Linux/UNIX setups, and it's what
has worked for years, so I don't see a need to change it with a permanence.
If other distros want to create alternatives, that is fine. But *I* should
retain the choice to use or not to use those alternatives. That means, udev
needs to be configurable enough to allow me to make it _not_ require /usr
being available. Let the default be the other way -- that's fine.
But if udev upstream is taking *away* choice, and making /usr mandatory
(especially if it's because some other distro has this offbeat, utopian,
überDesktop concept), then that's a bug and someone needs to write a patch
and send it upstream.
I think the list you want is
linux-hotplug-de...@lists.sourceforge.net; the gentoo-dev list is not
for udev development. If 'someone' needs to write a patch then I
assume you will volunteer?
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
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
Re: [gentoo-dev] udev and /usr
On Mon, 19 Sep 2011 04:15:02 -0400 Joshua Kinard ku...@gentoo.org wrote: But if udev upstream is taking *away* choice, and making /usr mandatory (especially if it's because some other distro has this offbeat, utopian, überDesktop concept), then that's a bug and someone needs to write a patch and send it upstream. Does the patch involve moving even more stuff to rootfs? If I'm going to see /share directory or even more /usr/share files in /lib, then I'm probably going to fork something too. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On 09/19/2011 04:25, Alec Warner wrote: If 'someone' needs to write a patch then I assume you will volunteer? My C is getting better. Don't tempt me... -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On 09/19/2011 04:33, Michał Górny wrote: Does the patch involve moving even more stuff to rootfs? If I'm going to see /share directory or even more /usr/share files in /lib, then I'm probably going to fork something too. Per our original discussion, isn't the only file udev is looking for pci.ids? If so, I honestly see no reason why that cannot exist in /etc. It fits in perfectly with other files like /etc/DIR_COLORS. If udev hardcodes the path too /usr/share, that's an easy patch then. And that's just one option. We can maintain a minimal pci.ids consisting only of disk drivers if need be in /etc, or find some other clever solution. We've got enough people here; someone oughta be able to figure something out. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Mon, 19 Sep 2011 04:57:10 -0400 Joshua Kinard ku...@gentoo.org wrote: On 09/19/2011 04:33, Michał Górny wrote: Does the patch involve moving even more stuff to rootfs? If I'm going to see /share directory or even more /usr/share files in /lib, then I'm probably going to fork something too. Per our original discussion, isn't the only file udev is looking for pci.ids? If so, I honestly see no reason why that cannot exist in /etc. It fits in perfectly with other files like /etc/DIR_COLORS. If udev hardcodes the path too /usr/share, that's an easy patch then. Could we stop putting random stuff in random dirs because 'it will work'? /etc is _SYSCONFDIR_. I don't see how PCI IDs are config at all. And that's just one option. We can maintain a minimal pci.ids consisting only of disk drivers if need be in /etc, or find some other clever solution. We've got enough people here; someone oughta be able to figure something out. As I see it, the simplest solution would be to lay out the minimal initramfs contents to rootfs and make it mount /usr and stuff before starting actual rc. This should cut all the complaints and possibly let us move some stuff back to /usr where it belongs. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
Michał Górny wrote: This should cut all the complaints and possibly let us move some stuff back to /usr where it belongs. Not all the complaints. Dale :-) :-)
Re: [gentoo-dev] udev and /usr
On 09/19/2011 05:10, Michał Górny wrote: Could we stop putting random stuff in random dirs because 'it will work'? /etc is _SYSCONFDIR_. I don't see how PCI IDs are config at all. The best answer is for someone to look into udev and see what it needs exactly from /usr. Does it really need pci.ids? Or is it just the fact that random udev rules might rely on a tool/lib in /usr? Former, yes, pci.ids is perfectly valid to go into /etc. It specifies a mapping of PCI ID numbers to device strings used in udev rules. In the latter case, maybe rules specifically required for booting up enough to mount disks need to be isolated into their own file and udev pointed there, then re-pointed to the bigger file after /usr is made available. If that is even possible. Note: I'm brainstorming here. Anyone else? As I see it, the simplest solution would be to lay out the minimal initramfs contents to rootfs and make it mount /usr and stuff before starting actual rc. This should cut all the complaints and possibly let us move some stuff back to /usr where it belongs. Yes, but some of us don't even want to have that initramfs built into our kernels. And no one, other than freedesktop.org* and a few people on linux-hotplug-devel*, said everything belongs in /usr. FHS clearly defines the roles for /, /bin, /sbin, /lib*, /usr, /var, /home, /tmp and the virtual fses. Plus others. http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken http://marc.info/?l=linux-hotplugm=131206447302056w=2 Really, MacOS's filesystem layout is not something anyone in their right mind should deign to mimic/copy. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On 19 September 2011 16:07, Joshua Kinard ku...@gentoo.org wrote: [...] Yes, but some of us don't even want to have that initramfs built into our kernels. And no one, other than freedesktop.org* and a few people on linux-hotplug-devel*, said everything belongs in /usr. FHS clearly defines the roles for /, /bin, /sbin, /lib*, /usr, /var, /home, /tmp and the virtual fses. Plus others. http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken http://marc.info/?l=linux-hotplugm=131206447302056w=2 Really, MacOS's filesystem layout is not something anyone in their right mind should deign to mimic/copy. I didn't get that from either of the links you posted. Seems to me the systemd developers are looking at the split as a host-specific / vs host-independent /usr. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 06:37:49AM -0400, Joshua Kinard wrote:
On 09/19/2011 05:10, Michał Górny wrote:
Could we stop putting random stuff in random dirs because 'it will
work'? /etc is _SYSCONFDIR_. I don't see how PCI IDs are config at all.
The best answer is for someone to look into udev and see what it needs
exactly from /usr. Does it really need pci.ids? Or is it just the fact
that random udev rules might rely on a tool/lib in /usr?
Oh come on people, please do some basic research and read what has been
posted about this numerous times in the past instead of just guessing.
Former, yes, pci.ids is perfectly valid to go into /etc. It specifies a
mapping of PCI ID numbers to device strings used in udev rules.
In the latter case, maybe rules specifically required for booting up enough
to mount disks need to be isolated into their own file and udev pointed
there, then re-pointed to the bigger file after /usr is made available. If
that is even possible.
Note: I'm brainstorming here. Anyone else?
It's as if people are just totally ignoring what has already been
discussed here, why should we even pay attention to this anymore?
And for those udev/systemd haters, you all do know about devtmpfs,
right? If not, {sigh}, I don't even know why I care anymore...
greg sick of it all k-h
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 1:36 PM, Greg KH gre...@gentoo.org wrote: Note: I'm brainstorming here. Anyone else? It's as if people are just totally ignoring what has already been discussed here, why should we even pay attention to this anymore? I agree that this is getting a bit off-topic. If anybody wants to brainstorm about how udev ought to work, I'd suggest finding their mailing list and posting it there. Gentoo is a distro. We take the stuff other people make and make it work nicely together. Our value add comes from the source-based concept and the fact that we do support a pretty wide variety of configurations, within the confines of what the upstream projects allow. If your favorite webapp supports mysql, postgres, or sqlite for the backend chances are you'll find that Gentoo supports all three. However, if your favorite webapp only supports mysql then chances are that we won't write a full postgres integration layer simply because mysql is for losers. If you want more options - then somebody has to write them so that we can integrate them. Rich
Re: [gentoo-dev] udev and /usr
On 19/09/2011 19:36, Greg KH wrote:
And for those udev/systemd haters, you all do know about devtmpfs,
right? If not, {sigh}, I don't even know why I care anymore...
greg sick of it all k-h
I'm wondering is if devtmpfs covers what is needed to mount /usr so the
new and grand udev can do all its stuff...
Going around upstream asking to provide init.d files themselves might be
useful btw.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 11:46:39PM +0200, Luca Barbato wrote:
On 19/09/2011 19:36, Greg KH wrote:
And for those udev/systemd haters, you all do know about devtmpfs,
right? If not, {sigh}, I don't even know why I care anymore...
greg sick of it all k-h
I'm wondering is if devtmpfs covers what is needed to mount /usr so the
new and grand udev can do all its stuff...
You are kidding me, right?
Going around upstream asking to provide init.d files themselves might be
useful btw.
I have no idea what in the world you are talking about here.
Gibberish, that's all it is these days, gibberish.
Oh wait, this all is a joke on me, right? Ok, that makes more sense,
hahaha, you all got me, good one.
Sorry, I was being slow here, next time I'll get it quicker, nice one
people.
greg k-h
p.s. and yes, this is the only reasonable explanation for this whole
thread, especially given the fact that this whole thing is explained in
extreme detail on the freedesktop.org site, and it has been beaten to
death on this very mailing list in the past. Otherwise what other
reason could this whole thing have been...
Re: [gentoo-dev] udev and /usr
On Tue, Sep 20, 2011 at 4:10 AM, Greg KH gre...@gentoo.org wrote: p.s. and yes, this is the only reasonable explanation for this whole thread, especially given the fact that this whole thing is explained in extreme detail on the freedesktop.org site, and it has been beaten to death on this very mailing list in the past. Otherwise what other reason could this whole thing have been... For reference, these are (some of?) the pages: http://www.freedesktop.org/wiki/Software/systemd http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] udev and /usr
On 09/19/2011 07:17, Arun Raghavan wrote: On 19 September 2011 16:07, Joshua Kinard ku...@gentoo.org wrote: [...] Yes, but some of us don't even want to have that initramfs built into our kernels. And no one, other than freedesktop.org* and a few people on linux-hotplug-devel*, said everything belongs in /usr. FHS clearly defines the roles for /, /bin, /sbin, /lib*, /usr, /var, /home, /tmp and the virtual fses. Plus others. http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken http://marc.info/?l=linux-hotplugm=131206447302056w=2 Really, MacOS's filesystem layout is not something anyone in their right mind should deign to mimic/copy. I didn't get that from either of the links you posted. Seems to me the systemd developers are looking at the split as a host-specific / vs host-independent /usr. From: http://marc.info/?l=linux-hotplugm=131206447302056w=2 Kay Sievers writes: What's not needed today is stuff in /. We can think of /usr a /System. The entire system is installed in one single directory, and that can be mounted r/o, or even shared between many hosts/guest. The stuff on the rootfs is always host-only then. It is from this that I derive the concept of a few folks wanting everything in /usr, as-if to brand /usr the new / (where the 'old' / has just directory stubs and a few symlinks, maybe some minor bits in /etc). That's also where my Mac comment stems from, in that /System hides most of the details of the BSD-nature of MacOS X, and tries to dissuade the user from ever having to go in there. Host-specific / and host-independent /usr is not itself a bad idea. I can envision quite a few useful scenarios for this. But on a single box, why? And for those of us with differing architectures, how would this add any benefit? Is this more of a detail for future RHEL releases (since Fedora is a type of proving ground for RH) so that sysadmins have an easier time managing them? Nothing wrong with it, but it needs to be a configurable choice by the end-user. I'll admit I may not be as informed as I oughta to be, but what I have read indicates that some people think this is the direction to go in, for various reasons. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On 09/19/2011 13:36, Greg KH wrote:
On Mon, Sep 19, 2011 at 06:37:49AM -0400, Joshua Kinard wrote:
On 09/19/2011 05:10, Michał Górny wrote:
Could we stop putting random stuff in random dirs because 'it will
work'? /etc is _SYSCONFDIR_. I don't see how PCI IDs are config at all.
The best answer is for someone to look into udev and see what it needs
exactly from /usr. Does it really need pci.ids? Or is it just the fact
that random udev rules might rely on a tool/lib in /usr?
Oh come on people, please do some basic research and read what has been
posted about this numerous times in the past instead of just guessing.
I'll admit that I do need to read more. But it seems this discussion goes
back a few months and there's no clear starting point on what began this. I
don't always have time to keep tabs on every diverging trend in the Linux
world, so I missed this back when it started. Any references you can point
me to?
And for those udev/systemd haters, you all do know about devtmpfs,
right? If not, {sigh}, I don't even know why I care anymore...
I'm not a hater of systemd or udev. I just don't use systemd, because basic
init and the OpenRC setup work for my installs. Maybe not everyone's, so
systemd (and others) fill those gaps.
With udev, I don't pay a lot of attention to it -- it JustWorks(TM). No
need to really fiddle with something that isn't broken.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
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
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 7:19 PM, Joshua Kinard ku...@gentoo.org wrote: Host-specific / and host-independent /usr is not itself a bad idea. I can envision quite a few useful scenarios for this. But on a single box, why? And for those of us with differing architectures, how would this add any benefit? Is this more of a detail for future RHEL releases (since Fedora is a type of proving ground for RH) so that sysadmins have an easier time managing them? Nothing wrong with it, but it needs to be a configurable choice by the end-user. I'll admit I may not be as informed as I oughta to be, but what I have read indicates that some people think this is the direction to go in, for various reasons. See: http://fedoraproject.org/wiki/Features/UsrMove That is some of the rationale for Fedora. It isn't a bad idea both for destop-oriented and server-oriented setups. It especially makes sense for a more traditional distro with versioned releases (basicaly you just drop in a new /usr and you're done minus a few /etc updates - and if you make /etc nothing but overrides from defaults then it would itself be almost empty and not need updates much). Sure, we're not really planning to do that with Gentoo, but that is the pressure upstream is under. When you have big distros pushing all the major projects in a particular direction we need to be really selective about where we push back. The sky isn't falling though - nobody is looking to go out of their way to break non-root /usr, and we are looking to have a minimal initramfs even for those cases where it breaks a little. Rich
Re: [gentoo-dev] udev and /usr
On 09/19/2011 20:29, Rich Freeman wrote: See: http://fedoraproject.org/wiki/Features/UsrMove That is some of the rationale for Fedora. It isn't a bad idea both for destop-oriented and server-oriented setups. It especially makes sense for a more traditional distro with versioned releases (basicaly you just drop in a new /usr and you're done minus a few /etc updates - and if you make /etc nothing but overrides from defaults then it would itself be almost empty and not need updates much). Sure, we're not really planning to do that with Gentoo, but that is the pressure upstream is under. When you have big distros pushing all the major projects in a particular direction we need to be really selective about where we push back. The sky isn't falling though - nobody is looking to go out of their way to break non-root /usr, and we are looking to have a minimal initramfs even for those cases where it breaks a little. Rich Good info, thanks! It definitely seems like something RH is cooking up for future releases of RHEL, where their primary customer base is going to be installing clusters and a ton of VMs. I understand this, but I still disagree with them pushing for this to be the default in a way to influence major projects. Regardless if Gentoo goes in that direction or not, if enough core software adopts this, we'll essentially have no choice but to adopt the same. That's what I take issue with -- the whims of a commercial enterprise ultimately deciding, at some possible, future point, what path we take. In other words, those of us not running cluster farms shouldn't have to change things, even slightly (like using an initramfs if needed) for those that do. Linux's greatest asset is its extreme configurability -- a single source tree can be compiled to run on super computers or cable boxes. And I see yet another reference to MacOS's /System in that link, too... -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 7:08 PM, Joshua Kinard ku...@gentoo.org wrote: That's what I take issue with -- the whims of a commercial enterprise ultimately deciding, at some possible, future point, what path we take. In other words, those of us not running cluster farms shouldn't have to change things, even slightly (like using an initramfs if needed) for those that do. Linux's greatest asset is its extreme configurability -- a single source tree can be compiled to run on super computers or cable boxes. For what it's worth, I've got a simple alternative to the initramfs approach, that may be handy for people like you. The idea is to enable CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y in the kernel, pass something like init=/sbin/linuxrc as a kernel parameter via the bootloader, and have /sbin/linuxrc be a simple shell script that mounts /proc, /sys, and /usr before calling 'exec /sbin/init'. You can use whatever shell you want for /sbin/linuxrc, as long as it doesn't have some kind of dependency on /usr. For example, if you want your script to run using a really minimal shell with the fewest possible dependencies, you can put '#!/sbin/busybox ash' in the shebang so that it will use your statically linked busybox. Something like this should do the trick in /sbin/linuxrc: #!/sbin/busybox ash mount -t proc proc /proc mount -t sysfs sysfs /sys mount /usr exec /sbin/init -- Thanks, Zac
Re: [gentoo-dev] udev and /usr
On 09/19/2011 03:40 PM, Greg KH wrote: Oh wait, this all is a joke on me, right? Ok, that makes more sense, hahaha, you all got me, good one. Yes, very funny indeed. It's good to keep your sense of humor. Sorry, I was being slow here, next time I'll get it quicker, nice one people. Now you've earned the right to subscribe to the secret mailing list where we think up gags like this one. greg k-h p.s. and yes, this is the only reasonable explanation for this whole thread, especially given the fact that this whole thing is explained in extreme detail on the freedesktop.org site, and it has been beaten to death on this very mailing list in the past. Otherwise what other reason could this whole thing have been... One explanation for life itself is that it's a way for the cosmos play a joke on itself. Going with that explanation, this thread is just a microcosm of a cosmic joke. -- Thanks, Zac
Re: [gentoo-dev] udev and /usr
On Sun, Sep 18, 2011 at 1:43 AM, Luca Barbato lu_z...@gentoo.org wrote: I think putting more pressure so systemd isn't given as granted would be more healthy for both those who are not using it (because, again, is an aberration for any kind of daemon not written for it) and those that want to use it (since maybe as desktop-only it might have some nice integrations). I'm not sure I've seen anybody talk of it being a given (ie no other configuration is supported). If many devs want openrc to stick around indefinitely I'm sure it will remain supported. Probably just adding the dbus interfaces and thinning it down might be something useful if that integration might have use-cases. I would think the intent would be to stay close to upstream as is usually the case with Gentoo. If they have integrations with 14 things than we should, and that shouldn't be horribly difficult since all the upstream projects would support them. That said, there is wisdom in only tackling a few things at a time and having 2 working integrations might be more useful than 47 non-working ones. Is there something in particular that is causing alarm with systemd? All I've seen is a package in the tree and some discussion. I'm sure there will be requests for various packages to install some files needed for integrations/etc. If anything is traumatic I'd be specific in stating concerns so that the root cause can be addressed. Rich
Re: [gentoo-dev] udev and /usr
On Sun, 18 Sep 2011 08:38:31 -0400 Rich Freeman ri...@gentoo.org wrote: Is there something in particular that is causing alarm with systemd? All I've seen is a package in the tree and some discussion. I'm sure there will be requests for various packages to install some files needed for integrations/etc. If anything is traumatic I'd be specific in stating concerns so that the root cause can be addressed. No, there isn't anything traumatic. The only thing systemd folks are doing is nicely asking devs to include systemd unit files whenever necessary or use the eclass whenever upstream supplies those files. In other words, some devs just found themselves a scapegoat. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Sun, Sep 18, 2011 at 6:19 PM, Michał Górny mgo...@gentoo.org wrote: No, there isn't anything traumatic. The only thing systemd folks are doing is nicely asking devs to include systemd unit files whenever necessary or use the eclass whenever upstream supplies those files. In other words, some devs just found themselves a scapegoat. ++ I'm astonished by the large amount of misinformation that is being spread around about systemd. If this originated on the gentoo-user mailing list, I'm disappointed that Gentoo users wouldn't do some basic research. I kind of expect this kind of trigger-happy FUD from websites like omgubuntu, but surely Gentoo folk are more mature. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] udev and /usr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-09-2011 12:59, Nirbheek Chauhan wrote: On Sun, Sep 18, 2011 at 6:19 PM, Michał Górny mgo...@gentoo.org wrote: No, there isn't anything traumatic. The only thing systemd folks are doing is nicely asking devs to include systemd unit files whenever necessary or use the eclass whenever upstream supplies those files. In other words, some devs just found themselves a scapegoat. ++ I'm astonished by the large amount of misinformation that is being spread around about systemd. If this originated on the gentoo-user mailing list, I'm disappointed that Gentoo users wouldn't do some basic research. I kind of expect this kind of trigger-happy FUD from websites like omgubuntu, but surely Gentoo folk are more mature. You mean that no Linux users, in particular anyone not running or not wanting to run GNOME and Fedora, shouldn't be worried about the way some people in the GNOME and Fedora community seem intent to impose their ways to everyone else? Worse, in the process seeming to want to convince everyone they found the panacea and that the old unix ways that have been around for 40+ years are all obsolete and that we should give in to the collective? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOdf+2AAoJEC8ZTXQF1qEPyKEQANmT0GVzK0aHSCPiX8d08ZY0 dSFiiXHUyXPemT1k0ilKk87uFkejhV3KFD3HUv9QwMJ/7NTOKIZibYG3i2+lPWhS +1eTjprsuke08YaPbo4HQMyGwPgwyMDNJ4wz30NDDmu3UgyFHsMNyF24vaVv6rri 7EgVUIbhJIWUl57sQ9nDT8njxh3I1RUykP8rxlob5iF2aLPVojKd/FoyP5daBXne kZfWdz5/L7qxslIaUnSjLfZ2Oeu9PRN7UOMWWTlZfq77r2z4yDlYv0SEN5o8+oEw uVLtTD+nZvN67WYNh7GrXn5ix/cGWieHkV6q23HrmNPA6wCUCqNgLNNkiKWlrHpc E/IO5vu4YYEqCmedYS7mnbJEQjlOsrDjyTDaHJ0YGLoLs2+zr9RME8PADRu/mM5I 4LUX4G8b5PAagZmNr32061YCHCgh6qAcUPcFJCaoBAOITLVH8tf1STaH6vJ7p56e eeaT+fipDLKrdYX/xfYlxe/RvU+Sz0dsnNEf863p8s7QNCFmZV8DHUh5Q0g5tHUb m/xib5WhCF68o73t05PEAYcIoDapmMscLNQ0l/xIPT+OQiVOOUH2FfYFbZ5sAUHK HVKF46jyZdkIHWGQFW4GfopHDMZDmKWL4jUgfERnmV8JeOZtvK8h61k+35HiLrSu MhbFeB3VJnnl8HHHXWcx =2sUg -END PGP SIGNATURE-
Re: [gentoo-dev] udev and /usr
On Sun, 18 Sep 2011 14:27:02 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-09-2011 12:59, Nirbheek Chauhan wrote: On Sun, Sep 18, 2011 at 6:19 PM, Michał Górny mgo...@gentoo.org wrote: No, there isn't anything traumatic. The only thing systemd folks are doing is nicely asking devs to include systemd unit files whenever necessary or use the eclass whenever upstream supplies those files. In other words, some devs just found themselves a scapegoat. ++ I'm astonished by the large amount of misinformation that is being spread around about systemd. If this originated on the gentoo-user mailing list, I'm disappointed that Gentoo users wouldn't do some basic research. I kind of expect this kind of trigger-happy FUD from websites like omgubuntu, but surely Gentoo folk are more mature. You mean that no Linux users, in particular anyone not running or not wanting to run GNOME and Fedora, shouldn't be worried about the way some people in the GNOME and Fedora community seem intent to impose their ways to everyone else? Worse, in the process seeming to want to convince everyone they found the panacea and that the old unix ways that have been around for 40+ years are all obsolete and that we should give in to the collective? Could you give at least a single example instead of this 'blah blah blah, I don't like you'? It's much easier to discuss particular cases rather than 'they all make me feel sad'. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Saturday, September 17, 2011 06:40:03 PM Robin H. Johnson wrote: On Fri, Sep 16, 2011 at 10:36:27AM +0200, Joost Roeleveld wrote: (The other reason I think systemd and udev might merge at some point, or at least have good IPC between them, because there is a potential for speed gains there). If udev and systemd merge, what will happen with people not using systemd? I don't see any added benefit from using DBUS on my servers. udev runs that rule as soon as the hardware turns up, which is often before localmount. I have doubts about having all these things handled by udev. As you said, there is an init-script that handles this. Is the ultimate goal to get rid of init-scripts and have everything done automagically? The rule is really useful important if you plug in a USB or Firewire sound card at some point after boot. If you already had it configured a previous time, that rule will restore your volume settings :-). udev knows the sound card is removable (USB, Firewire,...) or fixed (PCI, ISA,...) For removable devices, yes, these extra scripts make sense. But why have this same mechanism forced with non-removable hardware as the same can easily (and already is) be handled by existing init-scripts that run after localmount? The other parts of that init script are valuable still, but the volume restore is just a crutch for failing to load the volume when the device was first detected. If you have a soundcard that makes a pop when your system boots, that's a bug caused by this. My sound card doesn't pop, actually. So I guess I am lucky I don't see this bug on my system. Just because there are no visible errors, doesn't mean that they don't exist. This move to encourage initramfs is to ensure that there isn't any major breakage incidents soon. What if udev upstream suddenely starts hard requiring /usr to mounted, and not doing retries at all. How many systems are going to break, and users going to complain about needing to use livecds to recover? A lot. And those will be very vocal. I have a few goals with this thread and one of them is to try to figure out how best to avoid users to get affected by this. For now, users having an initramfs ahead of time is the best option to avoid future breakages. That, or have the logic of the initramfs in localmount and have udev wait till after localmount is run. DEVTMPFS creates the first batch, and udev creates the rest. The deciding case then becomes: - Is the device for your /usr entry in fstab created by udev or something else? MD: done by devtmpfs LVM: done by udev+lvm by-uuid/by-label: done by udev by-uuid and by-label present a lot of annoyance to the minimal initramfs. We have to ensure that we explicitly support them, which has increased the complexity of the initramfs. My /usr is on LVM. That requires udev. My understanding is: - udev needs /usr to be mounted to work Correct. - udev is needed to sort out LVM to get access to /usr Incorrect. But perhaps not for the reason that you think. Using genkernel's initramfs here as an example, this is the sequence of LVM commands that run: vgscan vgchange -ay --sysinit That --sysinit part is important, as it tells LVM to avoid locking (and some interaction with udev), and then LVM has fallback code to create the symlinks and other device nodes in /dev. What udev CAN do is create all of the by-label/by-uuid bits above. The fallback code in LVM is very complex, just for the case of handling udev not being there yet. And why can't this be implemented in localmount? /etc/init.d/lvm does it on your system. Ok, so have localmount depend on /etc/init.d/localmount and the problem is solved. -- Joost
Re: [gentoo-dev] udev and /usr
On Sun, Sep 18, 2011 at 7:57 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: On 18-09-2011 12:59, Nirbheek Chauhan wrote: I'm astonished by the large amount of misinformation that is being spread around about systemd. If this originated on the gentoo-user mailing list, I'm disappointed that Gentoo users wouldn't do some basic research. I kind of expect this kind of trigger-happy FUD from websites like omgubuntu, but surely Gentoo folk are more mature. You mean that no Linux users, in particular anyone not running or not wanting to run GNOME and Fedora, shouldn't be worried about the way some people in the GNOME and Fedora community seem intent to impose their ways to everyone else? If their ways are better, there should be absolutely no problem. Worse, in the process seeming to want to convince everyone they found the panacea and that the old unix ways that have been around for 40+ years are all obsolete and that we should give in to the collective? I don't see how this is relevant to the problem of udev and /usr at all. Unless you want to go back to the days of devfs and lots of manual configuration. :) My problem was with people blaming the need for an initramfs on systemd, which is not true at all. The discussion of the relative merits and demerits of systemd is an entirely different discussion. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] udev and /usr
On 09/18/2011 07:27 AM, Jorge Manuel B. S. Vicetto wrote: You mean that no Linux users, in particular anyone not running or not wanting to run GNOME and Fedora, shouldn't be worried about the way some people in the GNOME and Fedora community seem intent to impose their ways to everyone else? As a Gentoo user, you can avoid installing software from those projects as long as you don't require any software from them, and you don't require any components that unconditionally depend on them. Worse, in the process seeming to want to convince everyone they found the panacea and that the old unix ways that have been around for 40+ years are all obsolete and that we should give in to the collective? Generally speaking, Gentoo doesn't have the resources necessary to diverge very far from upstream, so whether various Gentoo components unconditionally depend on GNOME and Fedora projects is very much dependent on the requirements imposed by various upstream software developers (aka the collective). Like it or not, that's how it is. Like rich0 said, you need to try to influence the upstream projects if you are concerned about the the direction that they are going. -- Thanks, Zac
Re: [gentoo-dev] udev and /usr
On Fri, Sep 16, 2011 at 10:36:27AM +0200, Joost Roeleveld wrote: Either udev does this already and the execution sequence is always the same. In which case my suggestion above would follow the same sequence as the queue would be on a First-in First-out basis. Or, if udev doesn't do this yet, udev will end up having the same problem. It doesn't do it presently. The worst case I've seen is having an early rule that succeeds, but gives different results w/ /var mounted vs. not mounted. This rule didn't actual fail, so it does not get retried... And here is my main concern with this. The udev team don't list all the possible filesystems where things can go wrong. They only mention /usr. We know that there are rules that invoke various parts of /usr, and rules that have state storage in various parts of /var. I agree that a lot more granularity would be useful, to help those that might have multiple mountpoints within each of /usr and /var (eg, I have /usr/lib64/debug in a seperate LV). This is why I would suggest the actiond process to be started after localmount. That's too late. What about all the udev rules required to get the device nodes for localmount to succeed? Shouldn't these already exist for currently working setups? Specifically, I meant, how do you know which rules to run immediately before localmount, and which to postpone via actiond? The upstream discussions I've been party to previously (both on lists and in person), have been trying to avoid needing a full dependency system in udev, because it's a huge degree of additional complexity. I don't see why it would not be possible to pause actioning of these scripts till the boot-process says all required mounts are available. You still have to declare which scripts need to be paused, and/or which rules inside the scripts need to be paused. Even worse are cases where mounting some of localmount entries requires those scripts to have completed. In other words, a dependency on the rules would be needed? Yes, as I noted in my initial response to you, there's going to be interdependencies between udev rules and other parts of the system. (The other reason I think systemd and udev might merge at some point, or at least have good IPC between them, because there is a potential for speed gains there). udev runs that rule as soon as the hardware turns up, which is often before localmount. I have doubts about having all these things handled by udev. As you said, there is an init-script that handles this. Is the ultimate goal to get rid of init-scripts and have everything done automagically? The rule is really useful important if you plug in a USB or Firewire sound card at some point after boot. If you already had it configured a previous time, that rule will restore your volume settings :-). The other parts of that init script are valuable still, but the volume restore is just a crutch for failing to load the volume when the device was first detected. If you have a soundcard that makes a pop when your system boots, that's a bug caused by this. Just because there are no visible errors, doesn't mean that they don't exist. This move to encourage initramfs is to ensure that there isn't any major breakage incidents soon. What if udev upstream suddenely starts hard requiring /usr to mounted, and not doing retries at all. How many systems are going to break, and users going to complain about needing to use livecds to recover? A lot. And those will be very vocal. I have a few goals with this thread and one of them is to try to figure out how best to avoid users to get affected by this. For now, users having an initramfs ahead of time is the best option to avoid future breakages. DEVTMPFS creates the first batch, and udev creates the rest. The deciding case then becomes: - Is the device for your /usr entry in fstab created by udev or something else? MD: done by devtmpfs LVM: done by udev+lvm by-uuid/by-label: done by udev by-uuid and by-label present a lot of annoyance to the minimal initramfs. We have to ensure that we explicitly support them, which has increased the complexity of the initramfs. My /usr is on LVM. That requires udev. My understanding is: - udev needs /usr to be mounted to work Correct. - udev is needed to sort out LVM to get access to /usr Incorrect. But perhaps not for the reason that you think. Using genkernel's initramfs here as an example, this is the sequence of LVM commands that run: vgscan vgchange -ay --sysinit That --sysinit part is important, as it tells LVM to avoid locking (and some interaction with udev), and then LVM has fallback code to create the symlinks and other device nodes in /dev. What udev CAN do is create all of the by-label/by-uuid bits above. The fallback code in LVM is very complex, just for the case of handling udev not being there yet. And why can't this be implemented in
Re: [gentoo-dev] udev and /usr
On 9/15/11 1:33 PM, Joost Roeleveld wrote: On Thursday, September 15, 2011 09:31:45 PM Luca Barbato wrote: On 15/09/2011 16:33, Joost Roeleveld wrote: Hi Devs, Not sure if you are aware of the discussions on the gentoo-user list about the upcoming change where systemd and udev require /usr to be available prior to starting of udev. systemd seems more and more just a support burden for no gain... Myself and a lot of others on the gentoo-user list agree with this. Especially as there are plenty of installations where udev works without /usr mounted. Glad we agree. I think putting more pressure so systemd isn't given as granted would be more healthy for both those who are not using it (because, again, is an aberration for any kind of daemon not written for it) and those that want to use it (since maybe as desktop-only it might have some nice integrations). Probably just adding the dbus interfaces and thinning it down might be something useful if that integration might have use-cases. lu - not feeling a mindless lemming
Re: [gentoo-dev] udev and /usr
On Friday, September 16, 2011 12:27:19 AM Michał Górny wrote: On Fri, 16 Sep 2011 00:13:15 +0200 Joost Roeleveld jo...@antarean.org wrote: I think systemd is nice for desktops/laptops. But on servers it seems to be overkill to me and as I umount filesystems as part of my backup-scripts, having something force-mount them in the background is going to kill those scripts. But this bit is off-topic. It's all about replacing 'umount' with 'systemctl stop'. But if you don't use automount, I don't think systemd will actually interfere. That's something that needs to be looked into. I tell apache to switch to a maintenance-page which is on a filesystem that doesn't get umounted. Then I umount the websites for the backup. The changes to the script would require more work. If openrc stays with a classical init, then I will be happy. Systemd is nice for desktops. And systemctl will try to remount the filesystem when simply using umount: http://archives.gentoo.org/gentoo- user/msg_0883f3103a3fa025cc2121117169a287.xml -- Joost
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 08:32:17 PM Rich Freeman wrote: On Thu, Sep 15, 2011 at 5:48 PM, Joost Roeleveld jo...@antarean.org wrote: Will the ebuild automatically add all the different modules into the /etc/dracut.conf ? Please note, I am asking these questions to put my mind at ease and hopefully be able to explain all this back to the people on gentoo-user. Honestly, I'd recommend just trying it out. Dracut right now is as usable as any non-initramfs solution out there and you can always add it as an extra non-default option in grub so that it doesn't mess you up if it doesn't work. It is on my list of things to test and I will let you know my findings. I've found that dracut is pretty auto-magic by default and the config file doesn't generally need tampering. Most of the options are to NOT load modules or to minimize the initramfs size by figuring out what modules are actually needed and only load those (which means if you change hardware between boots it could come up short). If I change hardware, the kernel is likely not to boot as I disable anything I don't have. The modules that are available are controlled by use flags. Actually, I think it is a DRACUT_MODULES variable or something like that (not unlike how X11 handles drivers). Yes, this matches what I have found out already. -- Joost
Re: [gentoo-dev] udev and /usr
On Fri, Sep 16, 2011 at 09:25:12AM +0200, Joost Roeleveld wrote: I've found that dracut is pretty auto-magic by default and the config file doesn't generally need tampering. Most of the options are to NOT load modules or to minimize the initramfs size by figuring out what modules are actually needed and only load those (which means if you change hardware between boots it could come up short). If I change hardware, the kernel is likely not to boot as I disable anything I don't have. If that's the case, when you change your kernel ahead of changing hardware, change dracut too. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 10:18:27 PM Robin H. Johnson wrote: On Thu, Sep 15, 2011 at 11:00:47PM +0200, Joost Roeleveld wrote: See below on the existing udev retry queue that is hiding many of the issues from you. This hidden issues are also negatively affecting boot times (failures and retries take time). I don't actually mind too much about the boot time. If there are retries like this, I would expect this to be visible in the system logs. udev does not log rule failures to the best of my knowledge. In other words, it silently fails... That is unfortunate. Either udev does this already and the execution sequence is always the same. In which case my suggestion above would follow the same sequence as the queue would be on a First-in First-out basis. Or, if udev doesn't do this yet, udev will end up having the same problem. It doesn't do it presently. The worst case I've seen is having an early rule that succeeds, but gives different results w/ /var mounted vs. not mounted. This rule didn't actual fail, so it does not get retried... And here is my main concern with this. The udev team don't list all the possible filesystems where things can go wrong. They only mention /usr. 1. While the binary invoked by a given rule might reside entirely on a mounting that is already available, how do you ensure that the other mountpoints required by said binary are ALSO available (the bluetooth and ALSA rules actually need /var, what if you have a bluetooth keyboard? [see footnote]). This is why I would suggest the actiond process to be started after localmount. That's too late. What about all the udev rules required to get the device nodes for localmount to succeed? Shouldn't these already exist for currently working setups? Anyway, take your proposed split actiond/udev solution to the upstream udev list. I don't believe that we have the manpower to develop it here. If we did develop it here, I don't believe it will gain enough traction amongst other distros, and we'll be stuck supporting it. I personally don't think your split solution covers the usage cases well enough, but that's an actual decision best left to the upstream udev developers. Please take the discussion there, and don't pursue it on this list. Ok. The upstream discussions I've been party to previously (both on lists and in person), have been trying to avoid needing a full dependency system in udev, because it's a huge degree of additional complexity. I don't see why it would not be possible to pause actioning of these scripts till the boot-process says all required mounts are available. You still have to declare which scripts need to be paused, and/or which rules inside the scripts need to be paused. Even worse are cases where mounting some of localmount entries requires those scripts to have completed. In other words, a dependency on the rules would be needed? I see this as a solution for the situation where someone decides to use less-common hardware and force this solution onto everyone else. I'm trying to get as little forced on us as possible. Gentoo is one of the few distros at this point that doesn't already require initramfs. While we're going to carry on supporting not requiring an initramfs as long as possible (and documenting what is needed for that), we also don't want this to become a stumbling block for users that just want their system to work, and with how upstream udev and other projects are going, there is a real possibility of breakage caused by their code, far more than the potential of breakage because /usr failed to mount. I agree with you on this one. That is also why I am trying to get a clear picture of all the possible alternatives. If I would want to put my /usr filesystem on a bluetooth harddrive (for instance my mobile phone), then I would not expect to have this work without a lot of extra effort. While that is in the realms of extreme, having /usr or /var on NFS isn't extreme at all. I agree, I just used this example to explain that it shouldn't be necessary to force an initramfs on all users just because there is a small group who wants to have an extreme setup. udev has a retry queue already, see udev-postmount: === # Run the events that failed at first udev trigger udevadm trigger --type=failed -v === This is a retry-queue. That's a good start already, but why not redo this queue and put ALL the scripts into that queue untill after localmount? See above, about rules that are required for localmount to be able to complete. The most prevalent ones would probably be devices by-uuid and by-label. Those symlinks come from udev... These must also come from somewhere else as this also works in the initramfs stage. Which is, from what I gather, used to get to the stage where udev can run. With a smaller udev, the chances
Re: [gentoo-dev] udev and /usr
On 09/15/2011 07:33 AM, Joost Roeleveld wrote: The use for an initrd/initramfs/... will create an additional layer of complexity a lot of us users are not really waiting for, especially as we are not seeing any issues with our current systems. Like it or not, it's the simplest possible solution if you want separate /usr. The plan is to provide a minimal initramfs that won't contain any modules, so it won't have to be rebuilt for each kernel. See the /usr vs. initramfs redux thread: http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.xml -- Thanks, Zac
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 08:07:35 AM Zac Medico wrote:
On 09/15/2011 07:33 AM, Joost Roeleveld wrote:
The use for an initrd/initramfs/... will create an additional layer of
complexity a lot of us users are not really waiting for, especially as
we are not seeing any issues with our current systems.
Like it or not, it's the simplest possible solution if you want separate
/usr. The plan is to provide a minimal initramfs that won't contain any
modules, so it won't have to be rebuilt for each kernel. See the /usr
vs. initramfs redux thread:
http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.x
ml
Zac,
Thank you for your response, however, I do have a few questions about this.
Where will this default initramfs actually need to be placed? Also, how will
we be able to deal with situations where this script fails?
If Gentoo does decide to follow the initramfs-route, why not simply implement
/etc/init.d/localmount in the initramfs? Why require users to figure out which
filesystems are needed for udev?
Also, I was actually hoping for a reply to the rest of my email as well,
especially the idea for splitting udev into 2 seperate processes.
What I'm thinking off would be the following in pseudo-code:
--- process 1 ---
while(wait_for_event())
{
kevent* pkEvent = NULL;
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
waiting
{
action_event = process_kernel_event(pkEvent);
if (action_event != NULL)
{
put_action_event(pkEvent);
}
}
}
--
--- process 2 ---
while(wait_for_event())
{
aevent* paEvent = NULL;
if(get_waiting_action_event(paEvent)) // returns true if an event was
waiting
{
process_action_event(paEvent);
}
}
---
In human that would be:
The kernel puts events in the new-dev-event-queue that process 1 picks up.
process 1 creates the /dev-entrie(s) and, if there is an action to be taken,
puts the action in the new-action-event-queue.
Process 2 will then pick up this action from the new-action-event-queue and
will process this.
If, as a side-effect, of the action processed by process 2, a new device
appears for the kernel, the kernel will simply put a corresponding event in
the new-dev-event-queue.
I don't see why this option would be ignored. Especially as the simpler
process 1 should be smaller and as such less likely to contain bugs and any
action that needs to be taken can be done manually to test why something isn't
working correctly if the boot-process, for whatever reason, fails.
I'm not a good enough developer to do build this myself, but I am willing to
try this.
All I'm asking for is the help and advice of more experienced developers with
the design and implementation.
If someone can explain to me why my idea won't work, please let me know.
If someone actually has some ideas on how to implement it, I would really
appreciate it. My current idea is to try to split the 2 parts out of udev and
have it use the same configuration files.
Many thanks,
Joost
Re: [gentoo-dev] udev and /usr
On 09/15/2011 09:04 AM, Joost Roeleveld wrote: Thank you for your response, however, I do have a few questions about this. Where will this default initramfs actually need to be placed? It should be similar to how sys-apps/v86d is used for uvesafb support. It installs /usr/share/v86d/initramfs and when you configure your kernel, you set CONFIG_INITRAMFS_SOURCE=/usr/share/v86d/initramfs in order to have in included in your kernel image. Also, how will we be able to deal with situations where this script fails? It should drop you to a minimal shell. If Gentoo does decide to follow the initramfs-route, why not simply implement /etc/init.d/localmount in the initramfs? I think that's pretty close to what we have planned, since the plan is to have the initramfs mount configuration stored on the root filesystem. Why require users to figure out which filesystems are needed for udev? Simply mount all filesystems containing files managed by the package manager with the initramfs. Anything else would expose you to the possibility of unsatisfied dependencies. Also, I was actually hoping for a reply to the rest of my email as well, especially the idea for splitting udev into 2 seperate processes. In essence, what your doing here is playing a game of let's see how long we can delay the mounting of essential filesystems. If you play this game, then again, you expose yourself to the possibility of unsatisfied dependencies. Therefore, the only foolproof approach is to mount all essential filesystems as soon as possible (via initramfs). If someone can explain to me why my idea won't work, please let me know. If your goal is to expose yourself to the possibility of unsatisfied dependencies, they your idea will achieve it. -- Thanks, Zac
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 11:07 AM, Zac Medico zmed...@gentoo.org wrote: On 09/15/2011 07:33 AM, Joost Roeleveld wrote: The use for an initrd/initramfs/... will create an additional layer of complexity a lot of us users are not really waiting for, especially as we are not seeing any issues with our current systems. Like it or not, it's the simplest possible solution if you want separate /usr. The plan is to provide a minimal initramfs that won't contain any modules, so it won't have to be rebuilt for each kernel. See the /usr vs. initramfs redux thread: It should be noted that the alternative is to use a more full-featured initramfs like dracut, which will also be updated to support mounting /usr (it already parses /etc/fstab to remount root anyway). The minimal initramfs will not contain mdadm or lvm tools, so it is basically suitable for booting systems that don't currently require an initramfs. Of course, something like dracut is more likely to require you to rebuild the initramfs every time you update your kernel, and won't simply be a static image like the simplified one. The simplified initramfs could be compiled into the kernel as Zac suggests (this is probably the most foolproof method), or it could be loaded from /boot using the appropriate grub settings. Note that dracut does drop you to a shell if it fails (this is configurable), but by default this shell is dash, not bash. No doubt it would work fine either way, but bash is likely to be a little slower. I don't think RAM use is likely to be a problem - it should be completely de-allocated before init runs.
Re: [gentoo-dev] udev and /usr
On 15/09/2011 16:33, Joost Roeleveld wrote: Hi Devs, Not sure if you are aware of the discussions on the gentoo-user list about the upcoming change where systemd and udev require /usr to be available prior to starting of udev. systemd seems more and more just a support burden for no gain... lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 04:33:01PM +0200, Joost Roeleveld wrote: The use for an initrd/initramfs/... will create an additional layer of complexity a lot of us users are not really waiting for, especially as we are not seeing any issues with our current systems. See below on the existing udev retry queue that is hiding many of the issues from you. This hidden issues are also negatively affecting boot times (failures and retries take time). My idea is, to me at least, simple. udev is split into 2 parts: 1) udevd, which creates the /dev-tree based on the events it currently gets 2) actiond processes all the actions udevd puts in a seperate queue. This needs to be taken to the upstream udev list. The problem is that there is a bit of a catch-22 in running some udev rules: 0. You're going to have to declare interdependencies between ALL udev rules. This is because udev rules could be usable independently, or they could be interrelated (first rule sets some state variable or file, second one consumes it). 1. While the binary invoked by a given rule might reside entirely on a mounting that is already available, how do you ensure that the other mountpoints required by said binary are ALSO available (the bluetooth and ALSA rules actually need /var, what if you have a bluetooth keyboard? [see footnote]). 2. If the udev rule fails because the filesystem was not yet mounted, how does udev know that is safe to retry? Do we have to start declaring every file used (opened, dlopen'd, linked against) by a given rule? The upstream discussions I've been party to previously (both on lists and in person), have been trying to avoid needing a full dependency system in udev, because it's a huge degree of additional complexity. I think that if udevd is started at boot-time and actiond only after localmount has finished, there shouldn't be the situation where a script in the udev-configuration fails because of missing files. Even if it does, then this can be handled in actiond itself and placed in a retry-queue. udev has a retry queue already, see udev-postmount: === # Run the events that failed at first udev trigger udevadm trigger --type=failed -v === (upstream is actually planning to remove it, because of problems of rules with side-effects to being run multiple times, amongst other things). With a smaller udev, the chances of it failing should also be less. (less code-lines to check) and as long as the /dev-entries are created, these can be used to manually mount the other partitions to get to the point where the system can be fixed to get it back to a workable state. The problem is NOT in the udev codebase. It's in udev rules. Even at the rule level, it's mostly rules for packages other than udev itself. If, in the currently planned form, udev fails, it will be necessary to use a rescue-cd/usb to boot the system, try to fix it inside a chroot where it's not easy to check what is actually going wrong during the boot-process as the different tools can then not be run with the error-messages printed to the console. No, you're gotten the failure case wrong. Ok, so take the minimal initramfs as I proposed on this list as the working case. Let's say for some reason the initramfs doesn't load at all, so you have only / mounted when you go into the rootfs init. If you had a setup that was complex enough to require udev to come up for mounting /usr, you're going to end up at a real shell on your rootfs by one of the following means: - Pressing I for interactive boot, selecting shell (if you have not locked it down) - Passing init=/bin/sh to your boot loader. The problem case that does NOT exist here is anything more complicated; because if you have something like root-on-LVM, or encrypted root, you already have an initramfs. If the initramfs itself does exist, but fails to mount anything, you also get a rescue shell from the initramfs. Footnotes: -- A bluetooth keyboard as your system keyboard is a very interesting test case here. It's the only keyboard you can get on some tablet systems, because the onscreen keyboard isn't available until your graphics are running are running. I've had a media-centre box with a bluetooth keyboard in the past as well. Side-effects of having only a Bluetooth keyboard: - No ability to have ANY system input until bluetooth is online. - This means no ability to control GRUB, or activate interactive boot early on. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 signature.asc Description: Digital signature
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: On 09/15/2011 09:04 AM, Joost Roeleveld wrote: Thank you for your response, however, I do have a few questions about this. Where will this default initramfs actually need to be placed? It should be similar to how sys-apps/v86d is used for uvesafb support. It installs /usr/share/v86d/initramfs and when you configure your kernel, you set CONFIG_INITRAMFS_SOURCE=/usr/share/v86d/initramfs in order to have in included in your kernel image. Will this be set somewhere globally to the initramfs automatically? And doesn't this mean that a new kernel will need to be build just to satisfy this? I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Wouldn't automatic inclusion into grub.conf be a better approach? Not sure if grub.conf can handle a global setting for initramfs. Also, how will we be able to deal with situations where this script fails? It should drop you to a minimal shell. But, with udev then failing, will there be the /dev-entries to mount the different partitions to fix the environment? If Gentoo does decide to follow the initramfs-route, why not simply implement /etc/init.d/localmount in the initramfs? I think that's pretty close to what we have planned, since the plan is to have the initramfs mount configuration stored on the root filesystem. But still require a seperate configuration file for this? Why require users to figure out which filesystems are needed for udev? Simply mount all filesystems containing files managed by the package manager with the initramfs. Anything else would expose you to the possibility of unsatisfied dependencies. On my desktop, that would mean the following list: /usr/ /var/ /opt/ /tmp/ /opt/tmp/ Also, I was actually hoping for a reply to the rest of my email as well, especially the idea for splitting udev into 2 seperate processes. In essence, what your doing here is playing a game of let's see how long we can delay the mounting of essential filesystems. If you play this game, then again, you expose yourself to the possibility of unsatisfied dependencies. Therefore, the only foolproof approach is to mount all essential filesystems as soon as possible (via initramfs). True, but I don't have any scripts configured for udev on my desktop. My server has some scripts related to Xen, and those are all under /etc/xen/... In this case, would it still be necessary to use an initramfs? If someone can explain to me why my idea won't work, please let me know. If your goal is to expose yourself to the possibility of unsatisfied dependencies, they your idea will achieve it. No, my goal is to come up with a different solution to this problem which, on my system and possibly also on a lot of other systems, doesn't actually exist. -- Joost
Re: [gentoo-dev] udev and /usr
On Thu, 15 Sep 2011 22:03:53 +0200 Joost Roeleveld jo...@antarean.org wrote: I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Guess we could try to detect a few common cases and die in pkg_setup() whenever the failure is imminent. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 4:03 PM, Joost Roeleveld jo...@antarean.org wrote: On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: It should be similar to how sys-apps/v86d is used for uvesafb support. It installs /usr/share/v86d/initramfs and when you configure your kernel, you set CONFIG_INITRAMFS_SOURCE=/usr/share/v86d/initramfs in order to have in included in your kernel image. Will this be set somewhere globally to the initramfs automatically? And doesn't this mean that a new kernel will need to be build just to satisfy this? I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Wouldn't automatic inclusion into grub.conf be a better approach? Not sure if grub.conf can handle a global setting for initramfs. Well, the only way to set a kernel config parameter is to rebuild the kernel. There might be some way to extract the built-in initramfs (every kernel has one) and replace it with the new one without rebuilding it, but I doubt most users would prefer that we mount /boot and start modifying their kernel images. Changes to grub.conf will only be properly merged if /boot is mounted, if grub is installed (don't laugh - I checked and since my system was migrated so many times I don't actually have the package installed any longer), and the user actually merges the changes in. Fiddling with grub.conf isn't exactly risk-free either. I think something like this is best handled via news. Note also that depending on your definition of broken the separate /usr situation is already broken. It will probably steadily become more broken over time, so when it stops booting altogether for any particular user might happen anytime from a year ago to never. Rich
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 10:03:53PM +0200, Joost Roeleveld wrote: On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: On 09/15/2011 09:04 AM, Joost Roeleveld wrote: Thank you for your response, however, I do have a few questions about this. Where will this default initramfs actually need to be placed? It should be similar to how sys-apps/v86d is used for uvesafb support. It installs /usr/share/v86d/initramfs and when you configure your kernel, you set CONFIG_INITRAMFS_SOURCE=/usr/share/v86d/initramfs in order to have in included in your kernel image. Will this be set somewhere globally to the initramfs automatically? And doesn't this mean that a new kernel will need to be build just to satisfy this? I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Wouldn't automatic inclusion into grub.conf be a better approach? Not sure if grub.conf can handle a global setting for initramfs. Grub doesn't support a global initramfs setting, but you can build a static initramfs for v86d if needed. Also, how will we be able to deal with situations where this script fails? It should drop you to a minimal shell. But, with udev then failing, will there be the /dev-entries to mount the different partitions to fix the environment? Yes, /dev is provided by devtmpfs already, and that is populated by the kernel. If Gentoo does decide to follow the initramfs-route, why not simply implement /etc/init.d/localmount in the initramfs? I think that's pretty close to what we have planned, since the plan is to have the initramfs mount configuration stored on the root filesystem. But still require a seperate configuration file for this? The configuration file isn't actually required, but it's there in case you want to specify MORE filesystems to mount before switching to the rootfs init. There are two files to load from the rootfs: 1. /etc/fstab 2. /etc/minimal-filesystems.cfg [exact name undecided] The list is in the second file, just one mountpoint per line. Defaults to /usr, /var If the file is not available, the default is also /usr, /var. For each filesystem for the minimal list, use the line from fstab to mount it. This covers getting the device, mountpoint and mount options. There is a catch to this: If those non-root filesystems live on LVM or something complex, you're going to need to use a more advanced initramfs, genkernel/dracut/roll-your-own. On my desktop, that would mean the following list: /usr/ /var/ Only these two should be needed to early-boot the system successfully. True, but I don't have any scripts configured for udev on my desktop. My server has some scripts related to Xen, and those are all under /etc/xen/... In this case, would it still be necessary to use an initramfs? Where is /usr, and do you have any udev rules that need /var? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 09:31:45 PM Luca Barbato wrote: On 15/09/2011 16:33, Joost Roeleveld wrote: Hi Devs, Not sure if you are aware of the discussions on the gentoo-user list about the upcoming change where systemd and udev require /usr to be available prior to starting of udev. systemd seems more and more just a support burden for no gain... Myself and a lot of others on the gentoo-user list agree with this. Especially as there are plenty of installations where udev works without /usr mounted. -- Joost
Re: [gentoo-dev] udev and /usr
On 09/15/2011 01:03 PM, Joost Roeleveld wrote: On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: On 09/15/2011 09:04 AM, Joost Roeleveld wrote: Thank you for your response, however, I do have a few questions about this. Where will this default initramfs actually need to be placed? It should be similar to how sys-apps/v86d is used for uvesafb support. It installs /usr/share/v86d/initramfs and when you configure your kernel, you set CONFIG_INITRAMFS_SOURCE=/usr/share/v86d/initramfs in order to have in included in your kernel image. Will this be set somewhere globally to the initramfs automatically? And doesn't this mean that a new kernel will need to be build just to satisfy this? You could also pass it as an initrd via your bootloader, like rich0 said in his reply. I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Wouldn't automatic inclusion into grub.conf be a better approach? Not sure if grub.conf can handle a global setting for initramfs. Maybe so. I'm not involved the implementation. I was just telling you the obvious stuff that I've gleaned from the discussions. Also, how will we be able to deal with situations where this script fails? It should drop you to a minimal shell. But, with udev then failing, will there be the /dev-entries to mount the different partitions to fix the environment? I the preferred approach is to enable CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y, so that the kernel populates /dev for you automatically. If Gentoo does decide to follow the initramfs-route, why not simply implement /etc/init.d/localmount in the initramfs? I think that's pretty close to what we have planned, since the plan is to have the initramfs mount configuration stored on the root filesystem. But still require a seperate configuration file for this? I guess it could probably just use fstab. Again, I'm not involved in the implementation of all this. Why require users to figure out which filesystems are needed for udev? Simply mount all filesystems containing files managed by the package manager with the initramfs. Anything else would expose you to the possibility of unsatisfied dependencies. On my desktop, that would mean the following list: /usr/ /var/ /opt/ /tmp/ /opt/tmp/ Also, I was actually hoping for a reply to the rest of my email as well, especially the idea for splitting udev into 2 seperate processes. In essence, what your doing here is playing a game of let's see how long we can delay the mounting of essential filesystems. If you play this game, then again, you expose yourself to the possibility of unsatisfied dependencies. Therefore, the only foolproof approach is to mount all essential filesystems as soon as possible (via initramfs). True, but I don't have any scripts configured for udev on my desktop. My server has some scripts related to Xen, and those are all under /etc/xen/... In this case, would it still be necessary to use an initramfs? Well, as long as your essential filesytems aren't mounted before init is called, there's always the possibility that some issue of unsatisfied dependencies will arise in the future. Therefore, the most foolproof and future-proof approach is to have them all mounted before init is called. If someone can explain to me why my idea won't work, please let me know. If your goal is to expose yourself to the possibility of unsatisfied dependencies, they your idea will achieve it. No, my goal is to come up with a different solution to this problem which, on my system and possibly also on a lot of other systems, doesn't actually exist. If a problem doesn't exist now, that doesn't mean one won't arise in the future. As said, the most future-proof approach is to have them all mounted before init is called. -- Thanks, Zac
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 16:14:20 Michał Górny wrote: On Thu, 15 Sep 2011 22:03:53 +0200 Joost Roeleveld wrote: I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Guess we could try to detect a few common cases and die in pkg_setup() whenever the failure is imminent. yeah, no. pkgs shouldnt be divining the properties of the kernel used to boot the system and aborting based on their guess. `ewarn` would probably be fine though -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 02:29:20 PM Rich Freeman wrote: On Thu, Sep 15, 2011 at 11:07 AM, Zac Medico zmed...@gentoo.org wrote: On 09/15/2011 07:33 AM, Joost Roeleveld wrote: The use for an initrd/initramfs/... will create an additional layer of complexity a lot of us users are not really waiting for, especially as we are not seeing any issues with our current systems. Like it or not, it's the simplest possible solution if you want separate /usr. The plan is to provide a minimal initramfs that won't contain any modules, so it won't have to be rebuilt for each kernel. See the /usr vs. initramfs redux thread: It should be noted that the alternative is to use a more full-featured initramfs like dracut, which will also be updated to support mounting /usr (it already parses /etc/fstab to remount root anyway). The minimal initramfs will not contain mdadm or lvm tools, so it is basically suitable for booting systems that don't currently require an initramfs. Of course, something like dracut is more likely to require you to rebuild the initramfs every time you update your kernel, and won't simply be a static image like the simplified one. The simplified initramfs could be compiled into the kernel as Zac suggests (this is probably the most foolproof method), or it could be loaded from /boot using the appropriate grub settings. Is there an option in Grub to add a default initramfs that is used for all boot-options that can be overriden per boot-set? In other words, if I don't specify an initramfs for a kernel, that this default is then automatically applied? And will this then also work when using Xen where the kernel is already passed as a module? Note that dracut does drop you to a shell if it fails (this is configurable), but by default this shell is dash, not bash. No doubt it would work fine either way, but bash is likely to be a little slower. I don't think RAM use is likely to be a problem - it should be completely de-allocated before init runs. It is my understanding all the options need to be specified every time dracut is run to create an initramfs. If this becomes mandatory, will this be added to the make script of the kernel-sources and as such, make this more specific? Another issue arrises where some of the tools are updated that are also in the initramfs. Will we then still need to remember to also update the initramfs if these are needed? My server currently uses mdadm raid1 for /, /boot and swap and raid1+lvm for the rest. This works without the need of an initramfs. Will this still work? Or will I need to be using dracut instead? Please note, I'm not the only one using this option as it was taking directly from the Gentoo guides: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml -- Joost
Re: [gentoo-dev] udev and /usr
On 9/15/11 1:14 PM, Michał Górny wrote: On Thu, 15 Sep 2011 22:03:53 +0200 Joost Roeleveld jo...@antarean.org wrote: I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Guess we could try to detect a few common cases and die in pkg_setup() whenever the failure is imminent. Even better in pkg_pretend if you can use EAPI=4 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 4:40 PM, Joost Roeleveld jo...@antarean.org wrote: It is my understanding all the options need to be specified every time dracut is run to create an initramfs. If this becomes mandatory, will this be added to the make script of the kernel-sources and as such, make this more specific? There are no plans to make dracut mandatory, unless you're putting root on lvm or luks or something, and a good initramfs is already needed for that. I think /etc/dracut.conf already has just about anything you'd want to be persistent across runs. Another issue arrises where some of the tools are updated that are also in the initramfs. Will we then still need to remember to also update the initramfs if these are needed? Potentially - if the tools in the initramfs won't work. That seems unlikely though - on-disk formats don't really change much and all stuff like mdadm and lvm tools do is find stuff and pass it along to the kernel which does the real work. If you migrate your root from raid1 to raid17 and the old initramfs doesn't understand raid17 then you'll have a problem. I imagine that if you migrate to raid17, however, you'd have put some thought into this. My server currently uses mdadm raid1 for /, /boot and swap and raid1+lvm for the rest. This works without the need of an initramfs. Will this still work? Or will I need to be using dracut instead? I suspect that if /usr is on raid1+lvm that you might need dracut. I'm not 100% sure on that, since in theory the initramfs can find all it needs on root in this case. However, the goal was to keep it simple. I'd defer to somebody actually involved with the simple image. Rich
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 09:27:06AM -0700, Zac Medico wrote: On 09/15/2011 09:04 AM, Joost Roeleveld wrote: Thank you for your response, however, I do have a few questions about this. Where will this default initramfs actually need to be placed? It should be similar to how sys-apps/v86d is used for uvesafb support. It installs /usr/share/v86d/initramfs and when you configure your kernel, you set CONFIG_INITRAMFS_SOURCE=/usr/share/v86d/initramfs in order to have in included in your kernel image. Actually, we are looking at installing the initramfs image directly in /boot, then you will have to configure your boot loader to use it. William pgpkKPGLROdhr.pgp Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 07:41:57 PM Robin H. Johnson wrote: On Thu, Sep 15, 2011 at 04:33:01PM +0200, Joost Roeleveld wrote: The use for an initrd/initramfs/... will create an additional layer of complexity a lot of us users are not really waiting for, especially as we are not seeing any issues with our current systems. See below on the existing udev retry queue that is hiding many of the issues from you. This hidden issues are also negatively affecting boot times (failures and retries take time). I don't actually mind too much about the boot time. If there are retries like this, I would expect this to be visible in the system logs. My idea is, to me at least, simple. udev is split into 2 parts: 1) udevd, which creates the /dev-tree based on the events it currently gets 2) actiond processes all the actions udevd puts in a seperate queue. This needs to be taken to the upstream udev list. The problem is that there is a bit of a catch-22 in running some udev rules: 0. You're going to have to declare interdependencies between ALL udev rules. This is because udev rules could be usable independently, or they could be interrelated (first rule sets some state variable or file, second one consumes it). Either udev does this already and the execution sequence is always the same. In which case my suggestion above would follow the same sequence as the queue would be on a First-in First-out basis. Or, if udev doesn't do this yet, udev will end up having the same problem. 1. While the binary invoked by a given rule might reside entirely on a mounting that is already available, how do you ensure that the other mountpoints required by said binary are ALSO available (the bluetooth and ALSA rules actually need /var, what if you have a bluetooth keyboard? [see footnote]). This is why I would suggest the actiond process to be started after localmount. 2. If the udev rule fails because the filesystem was not yet mounted, how does udev know that is safe to retry? Do we have to start declaring every file used (opened, dlopen'd, linked against) by a given rule? See my reply to 1. The upstream discussions I've been party to previously (both on lists and in person), have been trying to avoid needing a full dependency system in udev, because it's a huge degree of additional complexity. I don't see why it would not be possible to pause actioning of these scripts till the boot-process says all required mounts are available. I see this as a solution for the situation where someone decides to use less-common hardware and force this solution onto everyone else. If I would want to put my /usr filesystem on a bluetooth harddrive (for instance my mobile phone), then I would not expect to have this work without a lot of extra effort. I think that if udevd is started at boot-time and actiond only after localmount has finished, there shouldn't be the situation where a script in the udev-configuration fails because of missing files. Even if it does, then this can be handled in actiond itself and placed in a retry-queue. udev has a retry queue already, see udev-postmount: === # Run the events that failed at first udev trigger udevadm trigger --type=failed -v === This is a retry-queue. That's a good start already, but why not redo this queue and put ALL the scripts into that queue untill after localmount? (upstream is actually planning to remove it, because of problems of rules with side-effects to being run multiple times, amongst other things). If this mechanism would be used to have all external scripts run after localmount for the first time, these side-effects shouldn't happen. With a smaller udev, the chances of it failing should also be less. (less code-lines to check) and as long as the /dev-entries are created, these can be used to manually mount the other partitions to get to the point where the system can be fixed to get it back to a workable state. The problem is NOT in the udev codebase. It's in udev rules. Even at the rule level, it's mostly rules for packages other than udev itself. Yes, but as I already stated, the problem-rules do not exist on all systems. My systems for instance don't have any pointing to anything other then /etc/... These scripts also don't call anything that isn't mounted at the time. That system has been running without incident for several years. Why do I suddenly have to make that system more complex? If, in the currently planned form, udev fails, it will be necessary to use a rescue-cd/usb to boot the system, try to fix it inside a chroot where it's not easy to check what is actually going wrong during the boot-process as the different tools can then not be run with the error-messages printed to the console. No, you're gotten the failure case wrong. Ok, so take the minimal initramfs as I proposed on this list as the working case. Let's say for
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 01:45:23PM -0700, Paweee Hajdan, Jr. wrote: On 9/15/11 1:14 PM, Michał Górny wrote: On Thu, 15 Sep 2011 22:03:53 +0200 Joost Roeleveld jo...@antarean.org wrote: I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Guess we could try to detect a few common cases and die in pkg_setup() whenever the failure is imminent. Even better in pkg_pretend if you can use EAPI=4 Which will misbehave if the kernel is one of the things to be updated. pkg_pretend shouldn't really be used for that unfortunately. ~brian
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 04:54:38 PM Rich Freeman wrote: On Thu, Sep 15, 2011 at 4:40 PM, Joost Roeleveld jo...@antarean.org wrote: It is my understanding all the options need to be specified every time dracut is run to create an initramfs. If this becomes mandatory, will this be added to the make script of the kernel-sources and as such, make this more specific? There are no plans to make dracut mandatory, unless you're putting root on lvm or luks or something, and a good initramfs is already needed for that. I think /etc/dracut.conf already has just about anything you'd want to be persistent across runs. That would be a good starting point. Having to type a lengthy commandline each time I update the kernel and/or toolstack will become troublesome and problems will easily occur. Will the ebuild automatically add all the different modules into the /etc/dracut.conf ? Please note, I am asking these questions to put my mind at ease and hopefully be able to explain all this back to the people on gentoo-user. Another issue arrises where some of the tools are updated that are also in the initramfs. Will we then still need to remember to also update the initramfs if these are needed? Potentially - if the tools in the initramfs won't work. That seems unlikely though - on-disk formats don't really change much and all stuff like mdadm and lvm tools do is find stuff and pass it along to the kernel which does the real work. If you migrate your root from raid1 to raid17 and the old initramfs doesn't understand raid17 then you'll have a problem. I imagine that if you migrate to raid17, however, you'd have put some thought into this. Migrating to raid17 (mirrored raid7, where there can be 3 failed disks per raid7?) would require some thought already. My server currently uses mdadm raid1 for /, /boot and swap and raid1+lvm for the rest. This works without the need of an initramfs. Will this still work? Or will I need to be using dracut instead? I suspect that if /usr is on raid1+lvm that you might need dracut. I'm not 100% sure on that, since in theory the initramfs can find all it needs on root in this case. However, the goal was to keep it simple. I'd defer to somebody actually involved with the simple image. If this is the case, then, to me, this is a major regression. As the current toolstack does not need an initramfs. All the lvm-tools are installed on / by default. None of the required tools are under /usr. -- Joost
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 04:27:35 PM Rich Freeman wrote: On Thu, Sep 15, 2011 at 4:03 PM, Joost Roeleveld jo...@antarean.org wrote: On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: It should be similar to how sys-apps/v86d is used for uvesafb support. It installs /usr/share/v86d/initramfs and when you configure your kernel, you set CONFIG_INITRAMFS_SOURCE=/usr/share/v86d/initramfs in order to have in included in your kernel image. Will this be set somewhere globally to the initramfs automatically? And doesn't this mean that a new kernel will need to be build just to satisfy this? I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Wouldn't automatic inclusion into grub.conf be a better approach? Not sure if grub.conf can handle a global setting for initramfs. Well, the only way to set a kernel config parameter is to rebuild the kernel. There might be some way to extract the built-in initramfs (every kernel has one) and replace it with the new one without rebuilding it, but I doubt most users would prefer that we mount /boot and start modifying their kernel images. I wasn't actually talking about changing kernels, but was wondering if grub.conf has some option for a global initramfs. I couldn't find anything in the manpage. Changes to grub.conf will only be properly merged if /boot is mounted, if grub is installed (don't laugh - I checked and since my system was migrated so many times I don't actually have the package installed any longer), and the user actually merges the changes in. Fiddling with grub.conf isn't exactly risk-free either. I know, which is why I was asking for a default option for the initrd/module part. I think something like this is best handled via news. And perhaps also an announcement on gentoo-user. I think a lot of users are subscribed to there. Note also that depending on your definition of broken the separate /usr situation is already broken. It will probably steadily become more broken over time, so when it stops booting altogether for any particular user might happen anytime from a year ago to never. In what way is it broken? I've only seen comments about where some udev-rules seem to expect /usr to be present when run and udev not properly handling these cases. (I know this is the very short version) If an installation works and none of the udev-rules depend on /usr (or /var, ) then a seperate /usr should not be considered broken. My desktop is up-to-date and none of my udev-rules even have a RUN+= part. Only my server has these for Xen-devices and these aren't run until xendomains starts and this is quite late in the boot-sequence. All my machines have /usr on LVM. -- Joost
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 08:31:51 PM Robin H. Johnson wrote: On Thu, Sep 15, 2011 at 10:03:53PM +0200, Joost Roeleveld wrote: On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: On 09/15/2011 09:04 AM, Joost Roeleveld wrote: Thank you for your response, however, I do have a few questions about this. Where will this default initramfs actually need to be placed? It should be similar to how sys-apps/v86d is used for uvesafb support. It installs /usr/share/v86d/initramfs and when you configure your kernel, you set CONFIG_INITRAMFS_SOURCE=/usr/share/v86d/initramfs in order to have in included in your kernel image. Will this be set somewhere globally to the initramfs automatically? And doesn't this mean that a new kernel will need to be build just to satisfy this? I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Wouldn't automatic inclusion into grub.conf be a better approach? Not sure if grub.conf can handle a global setting for initramfs. Grub doesn't support a global initramfs setting, but you can build a static initramfs for v86d if needed. Ok, was afraid there wasn't. If there was, it would make things easier. Also, how will we be able to deal with situations where this script fails? It should drop you to a minimal shell. But, with udev then failing, will there be the /dev-entries to mount the different partitions to fix the environment? Yes, /dev is provided by devtmpfs already, and that is populated by the kernel. If /dev is already populated by devtmpfs with the stuff for mounting what can currently already be mounted without an initramfs. Won't that be sufficient to have udev started *after* localmount? Eg. the following configuration: Kernel has the devtmpfs option localmount mounts the local filesystems using the devtmpfs /dev-tree udev is configured to start after localmount If Gentoo does decide to follow the initramfs-route, why not simply implement /etc/init.d/localmount in the initramfs? I think that's pretty close to what we have planned, since the plan is to have the initramfs mount configuration stored on the root filesystem. But still require a seperate configuration file for this? The configuration file isn't actually required, but it's there in case you want to specify MORE filesystems to mount before switching to the rootfs init. There are two files to load from the rootfs: 1. /etc/fstab 2. /etc/minimal-filesystems.cfg [exact name undecided] The list is in the second file, just one mountpoint per line. Defaults to /usr, /var If the file is not available, the default is also /usr, /var. For each filesystem for the minimal list, use the line from fstab to mount it. This covers getting the device, mountpoint and mount options. Why not try to mount all the filesystems in /etc/fstab in the minimal script automatically unless there is a list (not commented out) in /etc/minimal- filesystems.cfg ? There is a catch to this: If those non-root filesystems live on LVM or something complex, you're going to need to use a more advanced initramfs, genkernel/dracut/roll-your-own. This means that on a system where I currently don't need an initramfs, I suddenly need a full-grown initramfs. On my desktop, that would mean the following list: /usr/ /var/ Only these two should be needed to early-boot the system successfully. True, but I don't have any scripts configured for udev on my desktop. My server has some scripts related to Xen, and those are all under /etc/xen/... In this case, would it still be necessary to use an initramfs? Where is /usr, and do you have any udev rules that need /var? I followed the following guide: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml I have /usr on LVM which is on top of mdadm-raid1 on the server. My desktop has the same, except for the raid1-part. I don't have any udev-rules needing anything outside of /. Eg. they don't need /usr or anything else that is not part of the root- filesystem. The xen-scripts might, but those devices only appear when starting the PV- domains. And those don't start until well after everything else. -- Joost
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 01:34:50 PM Zac Medico wrote: On 09/15/2011 01:03 PM, Joost Roeleveld wrote: But, with udev then failing, will there be the /dev-entries to mount the different partitions to fix the environment? I the preferred approach is to enable CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y, so that the kernel populates /dev for you automatically. Will this be sufficient for localmount to get the system to work correctly? It is my understanding that some udev-scripts are the actual problem that is being solved with this? I wasn't aware of these kernel options also being required. Also, I was actually hoping for a reply to the rest of my email as well, especially the idea for splitting udev into 2 seperate processes. In essence, what your doing here is playing a game of let's see how long we can delay the mounting of essential filesystems. If you play this game, then again, you expose yourself to the possibility of unsatisfied dependencies. Therefore, the only foolproof approach is to mount all essential filesystems as soon as possible (via initramfs). True, but I don't have any scripts configured for udev on my desktop. My server has some scripts related to Xen, and those are all under /etc/xen/... In this case, would it still be necessary to use an initramfs? Well, as long as your essential filesytems aren't mounted before init is called, there's always the possibility that some issue of unsatisfied dependencies will arise in the future. Therefore, the most foolproof and future-proof approach is to have them all mounted before init is called. With systemd, one of these is the dbus-stack. Yes, I'm aware of this. But, if systemd isn't used, init should work. Or have I missed something about init being deprecated for systemd? I think systemd is nice for desktops/laptops. But on servers it seems to be overkill to me and as I umount filesystems as part of my backup-scripts, having something force-mount them in the background is going to kill those scripts. But this bit is off-topic. If someone can explain to me why my idea won't work, please let me know. If your goal is to expose yourself to the possibility of unsatisfied dependencies, they your idea will achieve it. No, my goal is to come up with a different solution to this problem which, on my system and possibly also on a lot of other systems, doesn't actually exist. If a problem doesn't exist now, that doesn't mean one won't arise in the future. As said, the most future-proof approach is to have them all mounted before init is called. Or, if I am not mistaken, before udev is started when not using systemd. -- Joost
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 03:56:19 PM William Hubbs wrote: On Thu, Sep 15, 2011 at 09:27:06AM -0700, Zac Medico wrote: On 09/15/2011 09:04 AM, Joost Roeleveld wrote: Thank you for your response, however, I do have a few questions about this. Where will this default initramfs actually need to be placed? It should be similar to how sys-apps/v86d is used for uvesafb support. It installs /usr/share/v86d/initramfs and when you configure your kernel, you set CONFIG_INITRAMFS_SOURCE=/usr/share/v86d/initramfs in order to have in included in your kernel image. Actually, we are looking at installing the initramfs image directly in /boot, then you will have to configure your boot loader to use it. William, This, to me, seems like the obvious solution. However, to make the change as unobtrusive as possible for the majority of users. Wouldn't it be possible to have grub support a default initrd in the grub.conf and use that unless the grub-entry specifies it's own? This is just an idea that I have. Not sure how much work this would bring. It would still not catch the situation on my server where the kernel is passed with the same mechanism to the xen-hypervisor and as such, the defeault initrd would then be ignored. But on my desktop, this would work automagically. -- Joost
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 11:00:47PM +0200, Joost Roeleveld wrote: See below on the existing udev retry queue that is hiding many of the issues from you. This hidden issues are also negatively affecting boot times (failures and retries take time). I don't actually mind too much about the boot time. If there are retries like this, I would expect this to be visible in the system logs. udev does not log rule failures to the best of my knowledge. The problem is that there is a bit of a catch-22 in running some udev rules: 0. You're going to have to declare interdependencies between ALL udev rules. This is because udev rules could be usable independently, or they could be interrelated (first rule sets some state variable or file, second one consumes it). Either udev does this already and the execution sequence is always the same. In which case my suggestion above would follow the same sequence as the queue would be on a First-in First-out basis. Or, if udev doesn't do this yet, udev will end up having the same problem. It doesn't do it presently. The worst case I've seen is having an early rule that succeeds, but gives different results w/ /var mounted vs. not mounted. This rule didn't actual fail, so it does not get retried... 1. While the binary invoked by a given rule might reside entirely on a mounting that is already available, how do you ensure that the other mountpoints required by said binary are ALSO available (the bluetooth and ALSA rules actually need /var, what if you have a bluetooth keyboard? [see footnote]). This is why I would suggest the actiond process to be started after localmount. That's too late. What about all the udev rules required to get the device nodes for localmount to succeed? Anyway, take your proposed split actiond/udev solution to the upstream udev list. I don't believe that we have the manpower to develop it here. If we did develop it here, I don't believe it will gain enough traction amongst other distros, and we'll be stuck supporting it. I personally don't think your split solution covers the usage cases well enough, but that's an actual decision best left to the upstream udev developers. Please take the discussion there, and don't pursue it on this list. The upstream discussions I've been party to previously (both on lists and in person), have been trying to avoid needing a full dependency system in udev, because it's a huge degree of additional complexity. I don't see why it would not be possible to pause actioning of these scripts till the boot-process says all required mounts are available. You still have to declare which scripts need to be paused, and/or which rules inside the scripts need to be paused. Even worse are cases where mounting some of localmount entries requires those scripts to have completed. I see this as a solution for the situation where someone decides to use less-common hardware and force this solution onto everyone else. I'm trying to get as little forced on us as possible. Gentoo is one of the few distros at this point that doesn't already require initramfs. While we're going to carry on supporting not requiring an initramfs as long as possible (and documenting what is needed for that), we also don't want this to become a stumbling block for users that just want their system to work, and with how upstream udev and other projects are going, there is a real possibility of breakage caused by their code, far more than the potential of breakage because /usr failed to mount. If I would want to put my /usr filesystem on a bluetooth harddrive (for instance my mobile phone), then I would not expect to have this work without a lot of extra effort. While that is in the realms of extreme, having /usr or /var on NFS isn't extreme at all. udev has a retry queue already, see udev-postmount: === # Run the events that failed at first udev trigger udevadm trigger --type=failed -v === This is a retry-queue. That's a good start already, but why not redo this queue and put ALL the scripts into that queue untill after localmount? See above, about rules that are required for localmount to be able to complete. The most prevalent ones would probably be devices by-uuid and by-label. Those symlinks come from udev... With a smaller udev, the chances of it failing should also be less. (less code-lines to check) and as long as the /dev-entries are created, these can be used to manually mount the other partitions to get to the point where the system can be fixed to get it back to a workable state. The problem is NOT in the udev codebase. It's in udev rules. Even at the rule level, it's mostly rules for packages other than udev itself. Yes, but as I already stated, the problem-rules do not exist on all systems. My systems for instance don't have any pointing to anything other then /etc/... These scripts also don't call anything that isn't mounted at
Re: [gentoo-dev] udev and /usr
On Fri, 16 Sep 2011 00:13:15 +0200 Joost Roeleveld jo...@antarean.org wrote: I think systemd is nice for desktops/laptops. But on servers it seems to be overkill to me and as I umount filesystems as part of my backup-scripts, having something force-mount them in the background is going to kill those scripts. But this bit is off-topic. It's all about replacing 'umount' with 'systemctl stop'. But if you don't use automount, I don't think systemd will actually interfere. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 5:48 PM, Joost Roeleveld jo...@antarean.org wrote: Will the ebuild automatically add all the different modules into the /etc/dracut.conf ? Please note, I am asking these questions to put my mind at ease and hopefully be able to explain all this back to the people on gentoo-user. Honestly, I'd recommend just trying it out. Dracut right now is as usable as any non-initramfs solution out there and you can always add it as an extra non-default option in grub so that it doesn't mess you up if it doesn't work. I've found that dracut is pretty auto-magic by default and the config file doesn't generally need tampering. Most of the options are to NOT load modules or to minimize the initramfs size by figuring out what modules are actually needed and only load those (which means if you change hardware between boots it could come up short). The modules that are available are controlled by use flags. Actually, I think it is a DRACUT_MODULES variable or something like that (not unlike how X11 handles drivers). Rich
