[gentoo-dev] udev and /usr

[gentoo-dev] udev and /usr

[Joost Roeleveld]

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.

I would like to know what the position of the Gentoo developers is with 
regarding this and how best to deal with this.

There have been several use-cases mentioned in the other list describing the 
need for a seperate /usr and /var partition. I also have these on seperate 
partitions.

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.
It's also one extra thing that can go wrong and it is not clear how we could 
solve the situation where we messed something up with the initramfs and can't 
get to the tools in single-usermode to try and fix it. That is if we can even 
get access to the machine in question.

I have raised a possible alternative on the other list and would like to know 
how you, the Developers, feel about it.

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.

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.

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.

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.

Kind regards,

Joost Roeleveld

Re: [gentoo-dev] udev and /usr

[Zac Medico]

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

[Joost Roeleveld]

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

[Zac Medico]

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

[Joost Roeleveld]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

On Thu, 15 Sep 2011 22:03:53 +0200
Joost Roeleveld <joost@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] udev and /usr

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 533 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] udev and /usr

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

On 9/15/11 1:14 PM, Michał Górny wrote:
> On Thu, 15 Sep 2011 22:03:53 +0200
> Joost Roeleveld <joost@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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] udev and /usr

[Brian Harring]

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 <joost@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

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

On Thu, Sep 15, 2011 at 4:03 PM, Joost Roeleveld <joost@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

[-- Attachment #2: Type: text/html, Size: 2300 bytes --]

Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 04:27:35 PM Rich Freeman wrote:
> On Thu, Sep 15, 2011 at 4:03 PM, Joost Roeleveld <joost@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

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

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

[Zac Medico]

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

[Joost Roeleveld]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Fri, 16 Sep 2011 00:13:15 +0200
Joost Roeleveld <joost@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

On Friday, September 16, 2011 12:27:19 AM Michał Górny wrote:
> On Fri, 16 Sep 2011 00:13:15 +0200
> 
> Joost Roeleveld <joost@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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

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

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On Thu, Sep 15, 2011 at 11:07 AM, Zac Medico <zmedico@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.

[-- Attachment #2: Type: text/html, Size: 2058 bytes --]

Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 02:29:20 PM Rich Freeman wrote:
> On Thu, Sep 15, 2011 at 11:07 AM, Zac Medico <zmedico@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

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

On Thu, Sep 15, 2011 at 4:40 PM, Joost Roeleveld <joost@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

[-- Attachment #2: Type: text/html, Size: 2425 bytes --]

Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 04:54:38 PM Rich Freeman wrote:
> On Thu, Sep 15, 2011 at 4:40 PM, Joost Roeleveld <joost@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

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On Thu, Sep 15, 2011 at 5:48 PM, Joost Roeleveld <joost@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

[-- Attachment #2: Type: text/html, Size: 1461 bytes --]

Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

On Thursday, September 15, 2011 08:32:17 PM Rich Freeman wrote:
> On Thu, Sep 15, 2011 at 5:48 PM, Joost Roeleveld <joost@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

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] udev and /usr

[Luca Barbato]

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

[Joost Roeleveld]

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

[gentoo-dev] Re: udev and /usr

[Duncan]

Joost Roeleveld posted on Thu, 15 Sep 2011 22:33:18 +0200 as excerpted:

> On Thursday, September 15, 2011 09:31:45 PM Luca Barbato wrote:
>> On 15/09/2011 16:33, Joost Roeleveld wrote:
>> > 
>> > 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.

As a kde user[1] I tend to agree, but I'm increasingly seeing talk on the 
gnome side of the "Gnome OS", to include pulse-audio, systemd, policykit, 
udev/u* (thus forcing lvm as well, at least lvm installation tho nothing 
forces one to use it... yet, since lvm is required for udisks), etc.

Legitimate question, primarily for the gentoo/gnome folks I guess.  I 
simply don't know how it's to work but am honestly rather fearful for the 
traditional Gentoo policy of letting the local sysadmin decide such 
things:

How serious is this talk, how integrated are they actually talking, and 
what are the implications for Gentoo's Gnome users?  Is gnome 3.5 or 4.0 
or whatever going to require pulse-audio and systemd, on ANY 
distribution, even Gentoo?  If not, how much hacking is going to be 
required by the gentoo/gnome folks to keep those sorts of choices for 
Gentoo users?  Will gentoo simply drop gnome as an option if it forces 
the issue, or ???

It may be that this is already sorted on the gnome side, or that all this 
talk of gnome-os is simply hot-air, but like I said, I'm a kde user, so I 
wouldn't know, tho I'm concerned about its implications for the rest of 
us (including kde, since it might well end up with similar 
requirements).  And I've not yet seen it mentioned in the gentoo 
implications context, so I'm compelled to ask.

---
[1] Tho the kde side seems headed the same direction, but at a somewhat 
slower pace and with a bit more of a reputation for at least /some/ 
respect of user choice, so I expect the issue to come up first and worst 
with gnome, and gentoo/kde to be able to follow the precedent, to some 
degree.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: udev and /usr

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

On Fri, Sep 16, 2011 at 12:03 AM, Duncan <1i5t5.duncan@cox.net> wrote:

> It may be that this is already sorted on the gnome side, or that all this
> talk of gnome-os is simply hot-air, but like I said, I'm a kde user, so I
> wouldn't know, tho I'm concerned about its implications for the rest of
> us (including kde, since it might well end up with similar
> requirements).  And I've not yet seen it mentioned in the gentoo
> implications context, so I'm compelled to ask.
>
>
I too am a bit concerned with some of the trends here.  I recently installed
Ubuntu to see how it handles suspend-to-disk and compare Gentoo's support
(believe it or not it worked more reliably on my Gentoo install!).  However,
what struck me is messages like my VM didn't meet the requirements for unity
so it was falling back to classic gnome, and that got me thinking.

I'm seeing a bit of a trend in the linux world towards major distros and
desktop environments building these huge highly integrated platforms.
 Instead of having core modules that everybody shares and clear interfaces,
everybody wants to build their own SysVInit replacement, their own audio
system, their own window managers, their own web browsers, and so on.  With
Wayland on the horizon we're talking about having multiple X11
implementations/replacements possibly.

Granted, KDE/Gnome have been doing this sort of thing for a while with
arts/etc.  However, if arts wasn't working right it didn't really keep you
from getting stuff done (unless you are mixing audio for a living).

I'm a bit concerned that the future of linux on the desktop is going to be
one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS,
or a "KDE OS."  Each one would have its own package managers, repositories,
distros, APIs, etc.  Clearly there is some benefit from the vertical
integration (Android and ChromeOS have a very high level of polish, and
Ubuntu is approaching this often by just writing their own stuff).  Instead
of working to influence other projects (which can be frustrating), big
distros are looking to just eliminate dependencies outside of themselves.

This will be a big challenge for a smaller distro like Gentoo.  Obviously we
can't just go write our own Wayland replacement, even if we did essentially
make our own "systemd" of sorts.

Rich

[-- Attachment #2: Type: text/html, Size: 2789 bytes --]

Re: [gentoo-dev] Re: udev and /usr

[Mike Frysinger]

On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote:
> I'm a bit concerned that the future of linux on the desktop is going to be
> one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS,
> or a "KDE OS."  Each one would have its own package managers, repositories,
> distros, APIs, etc.  Clearly there is some benefit from the vertical
> integration (Android and ChromeOS have a very high level of polish, and
> Ubuntu is approaching this often by just writing their own stuff).  Instead
> of working to influence other projects (which can be frustrating), big
> distros are looking to just eliminate dependencies outside of themselves.
> This will be a big challenge for a smaller distro like Gentoo.  Obviously we
> can't just go write our own Wayland replacement, even if we did essentially
> make our own "systemd" of sorts.

you're aware the ChromeOS is built on top of / with Gentoo right ?
-mike

Re: [gentoo-dev] Re: udev and /usr

[Nirbheek Chauhan]

On Sun, Sep 25, 2011 at 12:05 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote:
>> I'm a bit concerned that the future of linux on the desktop is going to be
>> one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS,
>> or a "KDE OS."  Each one would have its own package managers, repositories,
>> distros, APIs, etc.  Clearly there is some benefit from the vertical
>> integration (Android and ChromeOS have a very high level of polish, and
>> Ubuntu is approaching this often by just writing their own stuff).  Instead
>> of working to influence other projects (which can be frustrating), big
>> distros are looking to just eliminate dependencies outside of themselves.
>> This will be a big challenge for a smaller distro like Gentoo.  Obviously we
>> can't just go write our own Wayland replacement, even if we did essentially
>> make our own "systemd" of sorts.
>
> you're aware the ChromeOS is built on top of / with Gentoo right ?

"Gentoo" is defined by portage and the portage tree. If we remove
that, the end result is no different than compiling stuff manually in
Slackware or by hand.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: udev and /usr

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1358 bytes --]

On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote:
> On Sun, Sep 25, 2011 at 12:05 PM, Mike Frysinger wrote:
> > On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote:
> >> I'm a bit concerned that the future of linux on the desktop is going to
> >> be one where your choices are things like Android, ChromeOS, Ubuntu,
> >> Gnome OS, or a "KDE OS."  Each one would have its own package managers,
> >> repositories, distros, APIs, etc.  Clearly there is some benefit from
> >> the vertical integration (Android and ChromeOS have a very high level
> >> of polish, and Ubuntu is approaching this often by just writing their
> >> own stuff).  Instead of working to influence other projects (which can
> >> be frustrating), big distros are looking to just eliminate dependencies
> >> outside of themselves. This will be a big challenge for a smaller
> >> distro like Gentoo.  Obviously we can't just go write our own Wayland
> >> replacement, even if we did essentially make our own "systemd" of
> >> sorts.
> > 
> > you're aware the ChromeOS is built on top of / with Gentoo right ?
> 
> "Gentoo" is defined by portage and the portage tree. If we remove
> that, the end result is no different than compiling stuff manually in
> Slackware or by hand.

which is how Chrome OS is built.
ROOT=/some/place emerge <some binpkgs>
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: udev and /usr

[Nirbheek Chauhan]

On Mon, Sep 26, 2011 at 7:02 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote:
>> "Gentoo" is defined by portage and the portage tree. If we remove
>> that, the end result is no different than compiling stuff manually in
>> Slackware or by hand.
>
> which is how Chrome OS is built.
> ROOT=/some/place emerge <some binpkgs>
>

Yes, I'm well aware of how ChromeOS is built. :)

But neither portage, nor the portage tree, nor any of our branding are
shipped with ChromeOS. Hence it's as much a Gentoo install as $company
that uses portage to build $image for their embedded device, but
doesn't leave any trace of Gentoo behind.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: udev and /usr

[Zac Medico]

On 09/25/2011 06:57 PM, Nirbheek Chauhan wrote:
> On Mon, Sep 26, 2011 at 7:02 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote:
>>> "Gentoo" is defined by portage and the portage tree. If we remove
>>> that, the end result is no different than compiling stuff manually in
>>> Slackware or by hand.

Sure, the average Chrome OS end user may not know the difference.
However, it makes a difference to the Gentoo community to have our tools
and tree used by Chrome OS developers, and have them contribute back
fixes and enhancements.

>> which is how Chrome OS is built.
>> ROOT=/some/place emerge <some binpkgs>
>>
> 
> Yes, I'm well aware of how ChromeOS is built. :)
> 
> But neither portage, nor the portage tree, nor any of our branding are
> shipped with ChromeOS. Hence it's as much a Gentoo install as $company
> that uses portage to build $image for their embedded device, but
> doesn't leave any trace of Gentoo behind.

So what? I work on Gentoo for the benefit of myself and others
(including Chrome OS devs), not because I want people to see Gentoo
branding, or have more people identify themselves as "Gentoo users."
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: udev and /usr

[Nirbheek Chauhan]

On Mon, Sep 26, 2011 at 7:57 AM, Zac Medico <zmedico@gentoo.org> wrote:
> On 09/25/2011 06:57 PM, Nirbheek Chauhan wrote:
>> But neither portage, nor the portage tree, nor any of our branding are
>> shipped with ChromeOS. Hence it's as much a Gentoo install as $company
>> that uses portage to build $image for their embedded device, but
>> doesn't leave any trace of Gentoo behind.
>
> So what? I work on Gentoo for the benefit of myself and others
> (including Chrome OS devs), not because I want people to see Gentoo
> branding, or have more people identify themselves as "Gentoo users."
>

I never meant to say that it's NOT beneficial to Gentoo. I've stated
publicly, numerous times since the very beginning in emails, on IRC,
twitter, etc. that the fact that ChromeOS uses Portage is and will be
quite beneficial to us in many ways. If you recall my recent email to
gentoo-core, I specifically talked about this.

Please don't take my pedantic definition-wrangling as anything but pedantry.

All I've been saying is that it's *misleading* to users for us to say
that Google uses Gentoo on its Chrome Books. Google uses Gentoo's
portage tools to build ChromeOS, which is hence arguably a
*derivative* of Gentoo, but not really Gentoo.

This is precisely what Mike said in his last email, and resolved his
initial statement for me, which was ambiguous from my PoV.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: udev and /usr

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 551 bytes --]

On Sunday, September 25, 2011 21:57:27 Nirbheek Chauhan wrote:
> But neither portage, nor the portage tree, nor any of our branding are
> shipped with ChromeOS. Hence it's as much a Gentoo install as $company
> that uses portage to build $image for their embedded device, but
> doesn't leave any trace of Gentoo behind.

you don't need a portage tree.  binpkgs work just fine.  all the metadata is 
pulled down as you go.

i'm not saying it is Gentoo, but it is clearly a derivative that relies on 
quite a bit of the tree to build.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: udev and /usr

[Rich Freeman]

On Sun, Sep 25, 2011 at 2:35 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote:
>> This will be a big challenge for a smaller distro like Gentoo.  Obviously we
>> can't just go write our own Wayland replacement, even if we did essentially
>> make our own "systemd" of sorts.
>
> you're aware the ChromeOS is built on top of / with Gentoo right ?

Sure - I'm typing this on my CR-48.  :)

However, I can't seem to find a chromeos-meta package in portage, and
the fact that my chromeos laptop has some feature does me little good
in getting my Gentoo desktop to do the same.  At best ChromeOS is a
fork of Gentoo, and the work that is done to highly integrate it
doesn't really trickle back upstream.  To be honest, I'm not sure it
would be easy for them to do so.

I think that the issue is that big companies are moving away from
The-Unix-Way(TM), to some extent.  Rather than having a bunch of
modular components that you can mix and match, everybody is looking to
vertically integrate.  That often starts with existing components but
then leads to various changes such that the components are no longer
replaceable.

Suppose you're a big integrator like Canonical.  You employ 1000 linux
devs, all paid to work 40 hours per week and who regularly meet and
are competently managed/etc (let's assume for the sake of argument
that this makes them more productive).  You want to add feature X to
your product.  However, to accomplish this you need to get module A
and module B to talk to each other in some way not allowed by their
APIs.  Module A is maintained by 3 volunteers, and module B is
maintained by 100 people but they have a huge NIH chip on their
shoulder and half of them work for competitors and they don't take
module A seriously.  You can spend hundreds of hours getting them to
try them to play nicely with each other, or you can just fork A and B
and patch them to do what you want them to do.  Sure, that is a
long-term maintenance burden, but your 1000 devs can surely handle
that.  Repeat this 100 times and you end up with a chromium tarball
that consists of 90% redistributed 3rd-party libraries with subtle
tweaks.  However, can you really argue with Google's success with this
approach.

The FOSS world tends to be messy - lots of strong personalities and
nobody really has a financial interest in doing much of anything that
doesn't scratch a personal itch.  There are alliances of convenience.
Big companies are finding it less expensive to just do an end-run
around the whole thing.

I think there will be a balance, since fundamentally there are
advantages to compatibility.  However, I fear that the future will
look more and more like a world where you pick one ecosystem and end
up with first-rate apps that work nicely and 3rd-rate apps that don't.
 If you pick KDE, then you had better like amarok or whatever else
comes with it, or be prepared to quit and restart the app anytime your
laptop switches from your car's bluetooth stereo to internal speakers.

Rich

Re: [gentoo-dev] Re: udev and /usr

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On 9/25/11 5:53 AM, Rich Freeman wrote:
> Repeat this 100 times and you end up with a chromium tarball
> that consists of 90% redistributed 3rd-party libraries with subtle
> tweaks.  However, can you really argue with Google's success with this
> approach.

At least in Gentoo we remove _most_ of the bundled libraries. Currently
the biggest culprits are probably ffmpeg (Chromium upstream breaks it so
often that I gave up trying to use the system version) and mesa (yeah,
Chromium bundles it and it seems it's patched).

I'm slowly convincing the upstream to have a more distro-friendly
bundling strategy (i.e. staying close to upstream and making it possible
to use system versions). This takes time, and I often need to do the
unbundling work myself.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Re: udev and /usr

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 753 bytes --]

On Sunday, September 25, 2011 08:53:08 Rich Freeman wrote:
> However, I can't seem to find a chromeos-meta package in portage, and
> the fact that my chromeos laptop has some feature does me little good
> in getting my Gentoo desktop to do the same.  At best ChromeOS is a
> fork of Gentoo, and the work that is done to highly integrate it
> doesn't really trickle back upstream.  To be honest, I'm not sure it
> would be easy for them to do so.

Chrome OS uses the Gentoo tree of ebuilds and an overlay of custom packages.  
there are also a number of patches to packages that are in our tree, but those 
are in the process of merging back into Gentoo mainline.

i wouldn't really clasify this as a fork ... it's more a derivative.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] udev and /usr

[Luca Barbato]

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

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

On Sun, Sep 18, 2011 at 1:43 AM, Luca Barbato <lu_zero@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

[-- Attachment #2: Type: text/html, Size: 1979 bytes --]

Re: [gentoo-dev] udev and /usr

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Sun, 18 Sep 2011 08:38:31 -0400
Rich Freeman <rich0@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] udev and /usr

[Nirbheek Chauhan]

On Sun, Sep 18, 2011 at 6:19 PM, Michał Górny <mgorny@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

[Jorge Manuel B. S. Vicetto]

-----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 <mgorny@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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

On Sun, 18 Sep 2011 14:27:02 +0000
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@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 <mgorny@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] udev and /usr

[Nirbheek Chauhan]

On Sun, Sep 18, 2011 at 7:57 PM, Jorge Manuel B. S. Vicetto
<jmbsvicetto@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

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

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
kumba@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] udev and /usr

[Alec Warner]

On Mon, Sep 19, 2011 at 1:15 AM, Joshua Kinard <kumba@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-devel@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
> kumba@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

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

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
kumba@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] udev and /usr

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Mon, 19 Sep 2011 04:15:02 -0400
Joshua Kinard <kumba@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] udev and /usr

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

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
kumba@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] udev and /usr

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Mon, 19 Sep 2011 04:57:10 -0400
Joshua Kinard <kumba@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] udev and /usr

[Dale]

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

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

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-hotplug&m=131206447302056&w=2

Really, MacOS's filesystem layout is not something anyone in their right
mind should deign to mimic/copy.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] udev and /usr

[Arun Raghavan]

On 19 September 2011 16:07, Joshua Kinard <kumba@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-hotplug&m=131206447302056&w=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

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]

On 09/19/2011 07:17, Arun Raghavan wrote:

> On 19 September 2011 16:07, Joshua Kinard <kumba@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-hotplug&m=131206447302056&w=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-hotplug&m=131206447302056&w=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
kumba@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] udev and /usr

[Rich Freeman]

On Mon, Sep 19, 2011 at 7:19 PM, Joshua Kinard <kumba@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

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

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
kumba@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] udev and /usr

[Zac Medico]

On Mon, Sep 19, 2011 at 7:08 PM, Joshua Kinard <kumba@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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

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-hotplug&m=131206447302056&w=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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] udev and /usr

[Greg KH]

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

[Rich Freeman]

On Mon, Sep 19, 2011 at 1:36 PM, Greg KH <gregkh@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

[Luca Barbato]

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

[Greg KH]

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

[Nirbheek Chauhan]

On Tue, Sep 20, 2011 at 4:10 AM, Greg KH <gregkh@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

[Zac Medico]

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

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

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
kumba@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] udev and /usr

[Zac Medico]

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

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 4792 bytes --]

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     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 330 bytes --]

Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

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

From my understanding, udev is needed to create the /dev-entries to be able to 
mount /usr.
If the changes proposed are actually done (moving everything out of / and into 
/usr) then udev won't be available to create the /dev-entries.
A pre-populated set would work for most, but /dev/mapper used to require an 
initramfs as this device would have different numbers upon boot.
If this is still the case, how would I be able to get LVM and MDADM to run to 
get to my partitions?

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

In this case, you'd need to put full bluetooth support into the initramfs. On 
all the "normal" computers I see for sale online all have USB-keyboards.
And that is, still, the vast majority of systems currently in use and 
available.

I'm sorry, but I see bluetooth-keyboards still as a minority. If someone 
wants/has to use this, then an initramfs will be necessary. Same as if someone 
wants to have his filesystem on a strange new harddrive (like my bluetooth 
enabled mobile phone storage).

The vast majority doesn't use those.

--
Joost

Re: [gentoo-dev] udev and /usr

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 9001 bytes --]

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 the time.
Does your desktop use ALSA?
/lib/udev/rules.d/90-alsa-restore.rules 
invokes 
"/usr/sbin/alsactl restore ..."
Which in turn reads from /var/lib/alsa/asound.state.

We presently have the restore() function in /etc/init.d/alsasound that
repeats this, because that rule fails to work often during boot
(non-existence of the state file causes it to use built-in defaults
instead).

udev runs that rule as soon as the hardware turns up, which is often
before localmount.

> That system has been running without incident for several years. Why do I 
> suddenly have to make that system more complex?
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?

> 
> > > 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.
> 
> >From my understanding, udev is needed to create the /dev-entries to be able to 
> > mount /usr.
> If the changes proposed are actually done (moving everything out of / and into 
> /usr) then udev won't be available to create the /dev-entries.
> A pre-populated set would work for most, but /dev/mapper used to require an 
> initramfs as this device would have different numbers upon boot.
> If this is still the case, how would I be able to get LVM and MDADM to run to 
> get to my partitions?
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.

> I'm sorry, but I see bluetooth-keyboards still as a minority. If someone 
> wants/has to use this, then an initramfs will be necessary.
...
> The vast majority doesn't use those.
Likewise, we're NOT going to force you to use an initramfs.
We're going to be providing it regardless. If the users choose not to
use the initramfs, they get to keep the broken pieces of their systems.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 330 bytes --]

Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

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 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.
> 
> Does your desktop use ALSA?
> /lib/udev/rules.d/90-alsa-restore.rules
> invokes
> "/usr/sbin/alsactl restore ..."
> Which in turn reads from /var/lib/alsa/asound.state.
> 
> We presently have the restore() function in /etc/init.d/alsasound that
> repeats this, because that rule fails to work often during boot
> (non-existence of the state file causes it to use built-in defaults
> instead).
> 
> 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?

> > That system has been running without incident for several years. Why do
> > I
> > suddenly have to make that system more complex?
> 
> 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.
I am not a developer (I would like to try to do some programming), but I do 
have a lot of ideas. And due to the lack of information available to the 
users, I decided to check here.

I truly appreciate the time everyone is taking to try to answer the questions 
I have. I hope to be able to come to a clearer understanding of the whole 
thing.

> > If the changes proposed are actually done (moving everything out of /
> > and into /usr) then udev won't be available to create the /dev-entries.
> > A pre-populated set would work for most, but /dev/mapper used to require
> > an initramfs as this device would have different numbers upon boot. If
> > this is still the case, how would I be able to get LVM and MDADM to run
> > to get to my partitions?
> 
> 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
- udev is needed to sort out LVM to get access to /usr

How does the initramfs handle this?
And why can't this be implemented in localmount?

--
Joost

[gentoo-dev] Re: udev and /usr

[Duncan]

Joost Roeleveld posted on Fri, 16 Sep 2011 10:36:27 +0200 as excerpted:

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

Careful with the "extreme".  As you no doubt realize by now, the udev 
folks apparently consider anyone wanting a separate /usr but not an initr* 
"extreme".  That'd certainly apply double if said admin (since no simple 
"user" cares about such stuff, in this view) had /usr on lvm.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: udev and /usr

[Joost Roeleveld]

On Friday, September 16, 2011 06:06:35 PM Duncan wrote:
> Joost Roeleveld posted on Fri, 16 Sep 2011 10:36:27 +0200 as excerpted:
> > 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.
> 
> Careful with the "extreme".  As you no doubt realize by now, the udev
> folks apparently consider anyone wanting a separate /usr but not an initr*
> "extreme".  That'd certainly apply double if said admin (since no simple
> "user" cares about such stuff, in this view) had /usr on lvm.

Yes, I've noticed that.

Except that Redhat and Centos use LVM by default. Which will also mean that 
"simple users" also end up using LVM.
Then again, they also end up with an initr* and a generic kernel for 
everything under the sun.
I haven't properly looked at the kernel-configs from redhat lately, but I 
don't think they include all the possible hardware options be default?

--
Joost

Re: [gentoo-dev] Re: udev and /usr

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

On Sat, Sep 17, 2011 at 2:16 AM, Joost Roeleveld <joost@antarean.org> wrote:

>
> Except that Redhat and Centos use LVM by default. Which will also mean that
> "simple users" also end up using LVM.
> Then again, they also end up with an initr* and a generic kernel for
> everything under the sun.
> I haven't properly looked at the kernel-configs from redhat lately, but I
> don't think they include all the possible hardware options be default?
>
>
>
The typical mainstream binary distro approach is to:

1.  Build every module under the sun that won't cause more support headaches
than benefits.
2.  Build a really smart initramfs that can find root whether it is on raid,
lvm, luks, or on a SAN behind luks and a VPN (ok, I'm stretching it a
little).
3.  Deploy that on everything.

With an initramfs you can essentially build a completely modular kernel,
since the kernel can rely on any module it wishes right from the start.
 However, once the initramfs is done the kernel is still a minimal size
since unused modules don't occupy space (the initramfs wipes itself out of
ram as its last step, unless in a debug mode).

Sure, the fancy initramfs takes work, but since the install image is
one-size-fits-all it is less maintenance in the long haul.  Plus you can
replace your motherboard and still boot the same drive image.  The downside
is that it might take an extra second or two to boot, but dracut is pretty
fast.

Honestly, if I were running a server setup I'd probably consider using an
intiramfs.  They're a lot less susceptible to being messed up if for
whatever reason the drives get re-ordered in the BIOS (root=UUID, or with
LVM the device names can usually be trusted).  I once booted off of a rescue
CD that for whatever reason changed the major numbers assigned to my raid
devices and for a while I could never predict what /dev/md# my root would
end up with.  That is what started my quest to get dracut working, which
I'll continue whenever git.kernel.org is back up...

Rich

[-- Attachment #2: Type: text/html, Size: 2551 bytes --]

Re: [gentoo-dev] Re: udev and /usr

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

On 09/16/2011 14:06, Duncan wrote:

> 
> Careful with the "extreme".  As you no doubt realize by now, the udev 
> folks apparently consider anyone wanting a separate /usr but not an initr* 
> "extreme".  That'd certainly apply double if said admin (since no simple 
> "user" cares about such stuff, in this view) had /usr on lvm.


I'd say the udev folks need their coffee/tea checked.  If this logic stems
from some requirement for a window manager/desktop environment on some other
distro, then we need to make sure that becomes a configurable item in Gento
or not support that package.

This is the exact setup I use, and it's worked great since 2003.  No, it's
not the setup for everyone, so I don't think it should be mandatory for
everyone, either.  I expect the same for other approaches to have a use for
some segment of users, but not to code it in as a hard-set default.
Gentoo's about choice.  Why else do we have more USE flags than the entirety
of the IPv6 address space?

(okay, I'm stretching that last a sentence a fair bit ...)

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] udev and /usr

[Robin H. Johnson]

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 localmount?
/etc/init.d/lvm does it on your system.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

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

[gentoo-dev] Re: udev and /usr

[Duncan]

Joost Roeleveld posted on Sun, 18 Sep 2011 17:22:42 +0200 as excerpted:

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

Interesting question.  I hadn't seen the suggestion until this thread, 
either, and it bothered me too.

With a moment's thought, I decided I could probably return to a semi-
static dev setup reasonably easily.  I'd potentially turn on the early-dev 
option in the kernel that I still have off, ATM, which presumably would 
mount a tmpfs on dev and populate it with the earliest devices.  After 
that, if necessary, I'd copy the existing udev-created nodes out to a 
persistent state dir, and copy them back in with a little init-time 
script of my own.  As long as the device ordering remains stable, this 
could include by-label, etc, symlinks, or I could simply kill the by-
label, by-uid stuff in fstab, and go back to traditional devices there, 
too.

Either that, or simply go back to a static /dev entirely.

People with dynamic ordered devices may have to devise their own scripts, 
tho, or perhaps more likely, fork off udev from the pre-union state.

But it's also possible that's far enough in the future that we can't 
really answer the question now, since technology will have changed enough 
to make an answer now look senseless, then.  Consider trying to answer 
the question in terms of the kernel devfs back before udev.  The tech 
simply changed and those answers wouldn't really work, today.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: udev and /usr

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

On Sun, Sep 18, 2011 at 2:14 PM, Duncan <1i5t5.duncan@cox.net> wrote:

> Joost Roeleveld posted on Sun, 18 Sep 2011 17:22:42 +0200 as excerpted:
> > I don't see any added benefit from using DBUS on my servers.
>
> Interesting question.  I hadn't seen the suggestion until this thread,
> either, and it bothered me too.
>
>
Well, I can't really speak about the specific issue as I'm not sure what the
maintainers of dbus, systemd, and udev are thinking.

However, I can imagine that the goals of parties like Canonical and RedHat
are to cut down on the number of configurations.  If the server image is
vastly different from the desktop image you start having to divide your
resources to maintain both.  If the only difference is that you install a
little less stuff (or just different stuff) by default then it isn't such a
big deal.

Gentoo is not immune to these pressures either.  If upstream moves in one
direction then it will take consistent effort just to stay still.  Anytime
we have six months without a dev we'll just inevitably get pulled along with
upstream anyway.  If people have concerns with the direction upstream is
going, then they need to try to influence the upstream projects to change
direction.  Simply posting on this list isn't going to change udev's
long-term strategy.

Personally I feel that Gentoo is all about choice and we should continue to
give our users as many choices as are practical.  However, we don't have the
resources of Canonical and we can't just fork upstream and take it an
entirely different direction as a result.

Rich

[-- Attachment #2: Type: text/html, Size: 2001 bytes --]

[gentoo-dev] Re: udev and /usr

[Nicolas Sebrecht]

The 18/09/11, Duncan wrote:

> > I don't see any added benefit from using DBUS on my servers.

Insterstingly, Duncan just answered your question...

> Interesting question.  I hadn't seen the suggestion until this thread, 
> either, and it bothered me too.

From here:

> With a moment's thought, I decided I could probably return to a semi-
> static dev setup reasonably easily.  I'd potentially turn on the early-dev 
> option in the kernel that I still have off, ATM, which presumably would 
> mount a tmpfs on dev and populate it with the earliest devices.  After 
> that, if necessary, I'd copy the existing udev-created nodes out to a 
> persistent state dir, and copy them back in with a little init-time 
> script of my own.  As long as the device ordering remains stable, this 
> could include by-label, etc, symlinks, or I could simply kill the by-
> label, by-uid stuff in fstab, and go back to traditional devices there, 
> too.
> 
> Either that, or simply go back to a static /dev entirely.
> 
> People with dynamic ordered devices may have to devise their own scripts, 
> tho, or perhaps more likely, fork off udev from the pre-union state.

...to here.

> But it's also possible that's far enough in the future that we can't 
> really answer the question now, since technology will have changed enough 
> to make an answer now look senseless, then.  Consider trying to answer 
> the question in terms of the kernel devfs back before udev.  The tech 
> simply changed and those answers wouldn't really work, today.

Upstream changes the init process is done. So, you're free to either:

 stick to upstream (with best long term support);

or

 fork off upstream (requires knowledges, manpower and time);

or

 go back to 1960 with a full/partial static /dev (asking to manually
 maintain the crap).

See the benenfit, now?

-- 
Nicolas Sebrecht

Re: [gentoo-dev] udev and /usr

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

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 so....why?

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
kumba@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] udev and /usr

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On Mon, 19 Sep 2011 03:59:43 -0400
Joshua Kinard <kumba@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 so....why?

Because noone actually used init, rather forked few processes out of it
and let it rot.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]