[gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[walt...@waltdnes.org]

After a recent thread, about udev developers wanting /usr on the same
partition as / (or else requiring initramfs), it was pretty obvious
that 90%+ of the users here strongly disliked the idea. I went around
asking on various lists if it was possible to run Gentoo without udev.
After some research, and various unrelated delays, I've come up with a
working Gentoo without udev. It turns out that busybox's mdev
implementation is sufficient for my needs. I do the usual email, web
surfing, including Youtube. I'm listening to Live365.com as I type this
email, so Flash works just fine. Contrary to the FUD I've heard, X
works just fine, thank you, without an xorg.conf. Modern flatscreens
with EDID info are set up automatically. I suppose that old CRT
monitors without EDID info might require xorg.conf, but that's "exotic
hardware" nowadays. The only change I notice is somewhat faster bootup.

The purpose of this email is to ask adventurous people here to beta
test my approach to a udev-less Gentoo. If we don't find any
showstopper problems, we can think about requesting Gentoo developers to
support an mdev-based profile. It would help the cause if a large
number of testers can report that it works for them. The instructions
for a udev-ectomy follow below. Thanks to Zac Medico and others on the
Gentoo developers' list for their helpful hints and pointers on how to
do this. I couldn't have figured this out by myself.

The usual warnings apply...
* this is a beta
* use a spare test machine
* if you don't follow the instructions correctly, the result might be
an unbootable linux
* even if you do follow instructions, the result might be an unbootable
linux


1) Set up your kernel to support and automount a devtmpfs filesystem at
/dev

* If you prefer to edit .config directly, set
CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y

* If you prefer "make menuconfig", the route is as shown below. Note
that the "Autount devtmpfs..." option won't appear until you enable
"Maintain a devtmpf..." option.

make menuconfig
Device Drivers --->
Generic Driver Options --->
[*] Maintain a devtmpfs filesystem to mount at /dev
[*] Automount devtmpfs at /dev, after the kernel mounted the rootfs

Once you've made the changes, rebuild the kernel.


2) Set up for emerging busybox, there are 2 items to change

A) It appears that there may be an mdev bug in older versions of
busybox. To avoid that bug, keyword busybox-1.19.2 in
/etc/portage/package.keywords E.g. if you're using 32-bit Gentoo on
Intel, the incantation is...

=sys-apps/busybox-1.19.2 ~x86

Change the "~x86" to reflect your architecture, etc.

B) busybox requires the "mdev" flag in this situation. The "static"
flag is probably also a good idea. In file /etc/portage/package.use
add the line

sys-apps/busybox static mdev

Now, "emerge busybox"


3) In the bootloader append line, include "init=/sbin/linuxrc" where
the file /sbin/linuxrc consists of *AT LEAST*...

#!/sbin/busybox ash
mount -t proc proc /proc
mount -t sysfs sysfs /sys
exec /sbin/init

This should be enough for most users. If you have an unusual setup,
you may need additional stuff in there. If you're using lilo remember
to re-run lilo to implement the changes.

4) Remove udev from the services list, and replace it with mdev. Type
the following 2 commands at the command line
rc-update del udev sysinit
rc-update add mdev sysinit


5) reboot to your new kernel. You're now running without using udev.


6) ***THIS STEP IS OPTIONAL*** This is only to alay any suspicion that
udev is still in use. udev is pulled in by virtual/dev-manager,
which in turn is pulled in by the kernel.
* cd /usr/portage/virtual/dev-manager
* Make a backup copy of dev-manager-0.ebuild
* Edit dev-manager-0.ebuild to include "sys-apps/busybox" as one option
in RDEPEND, like so...

RDEPEND="|| ( sys-fs/udev
sys-fs/devfsd
sys-apps/busybox
sys-fs/static-dev
sys-freebsd/freebsd-sbin )"

I had really wanted to use "sys-apps/busybox[mdev]", but an EAPI-0
ebuild can't handle that syntax.

* execute the following 3 commands at the commandline
ebuild dev-manager-0.ebuild digest
emerge -1 dev-manager
emerge --unmerge sys-fs/udev

* In file /atc/portage/package.mask, append the line
sys-fs/udev
Create the file if it doesn't already exist. You now have a totally
udev-free machine

--
Walter Dnes <walt...@waltdnes.org>

[Pandu Poluan]

Sounds nice!

However, my Gentoo systems are all virtual servers (DomU VMs on XenServer). So, the hardware devices are static. Will switching over to mdev give any benefits?

I even am toying around with the idea of having a completely static /dev, but still can't find any guide/pointers yet.

(Apologies if my email is OOT)

Rgds,

[Alan McKinnon]

On Tue, 15 Nov 2011 14:44:58 +0700
Pandu Poluan <pa...@poluan.info> wrote:

> >  Create the file if it doesn't already exist.  You now have a
> > totally udev-free machine
> >
>
> Sounds nice!
>
> However, my Gentoo systems are all virtual servers (DomU VMs on
> XenServer). So, the hardware devices are static. Will switching over
> to mdev give any benefits?
>
> I even am toying around with the idea of having a completely
> static /dev, but still can't find any guide/pointers yet.
>
> (Apologies if my email is OOT)
>

A VM can be surprisingly useful for this. If you can emulate different
hardware you can generate useful testing scenarios quickly. The tests
won't be conclusive (emulated hardware is not the same thing as real
hardware) but you *can* test to a standard.

--
Alan McKinnnon
alan.m...@gmail.com

[Albert W. Hopkins]

On Tue, 2011-11-15 at 14:44 +0700, Pandu Poluan wrote:
> However, my Gentoo systems are all virtual servers (DomU VMs on
> XenServer).
> So, the hardware devices are static. Will switching over to mdev give
> any
> benefits?
>
> I even am toying around with the idea of having a completely
> static /dev,
> but still can't find any guide/pointers yet.

I have a completely static /dev/ on my VMs.. I just disable the udev
devfs services and create whatever device nodes needed manually.

[Pandu Poluan]

True. Unfortunately, I don't have 'exotic' hardware to test mdev against, and USB pass-through is not yet supported on XenServer 5.6 (which I'm using right now).

I can try it inside VirtualBox on my Windows workstation though. Will that help?

Rgds,

[Pandu Poluan]

Ah, thanks! Now I have more confidence to experiment, knowing someone else have successfully went the static /dev road :-)

Rgds,

[walt...@waltdnes.org]

On Tue, Nov 15, 2011 at 02:44:58PM +0700, Pandu Poluan wrote

> However, my Gentoo systems are all virtual servers (DomU VMs on XenServer).
> So, the hardware devices are static. Will switching over to mdev give any
> benefits?
>
> I even am toying around with the idea of having a completely static /dev,
> but still can't find any guide/pointers yet.
>
> (Apologies if my email is OOT)

The more scenarios we can test, the better. mdev might shave a second
or two off the VM's bootup time, versus udev.

--
Walter Dnes <walt...@waltdnes.org>

[Pandu Poluan]

Okay, I have two staging VMs on XenServer and one on VMware. I'm going to report back what happens. If anything bad happens, *should* be an easy rollback to the previous snapshot.

Rgds,

[Pandu Poluan]

Plus, I'm feeling adventurous and will experiment with VirtualBox also ;)

Rgds,

[yegle]

I'm using systemd as init. Currently there's no .service file for mdev. Hope someone on this list can provide one :-)

[Pandu Poluan]

1st Report: amd64-hardened on XenServer, PV-mode

Booted okay. There's 1 (one) red asterisk but it booted so fast I
can't see what that asterisk was about. `less /var/log/rc.log` did not
show anything...

... but I realized that I can scroll up on XenServer console, so I saw
that the asterisk said:

* Error: fopen(/lib64/rc/init.d/rc.log) failed: No such file or directory

Nothing serious though. I think it was because /lib64/rc/init.d got
overlaid by rc-svcdir during boot, so rc.log disappeared.

(Doing `mount -o bind / /mnt/rooot && ls /mnt/rooot/lib64/rc/init.d`
showed that rc.log existed in the non-overlaid /lib64/rc/init.d)

/dev/xvdb* (which was not created statically in the non-overlaid /dev) appeared.

/dev/xvdd appeared when I attached an ISO image to the VM.

mount /dev/xvdd /mnt/cd worked. I could `ls /mnt/cd` and see the
contents of the CD.

"Ejecting" the ISO image made /dev/xvdd disappear (as it should).

Networking is okay.

The Xen virtual console (hvc0) works okay.

`rc-update | grep dev` showed `udev-postmount` still part of default,
so I did `rc-update del udev-postmount default` and rebooted, and all
were still well (and still a glint of red asterisk).

Unmerging udev went well.

All in all, rebooting after switching to udev *seems* to be faster.

Rgds,
--
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

[Pandu Poluan]

On Wed, Nov 16, 2011 at 07:52, Pandu Poluan <pa...@poluan.info> wrote:
>

2nd Report: amd64-hardened on VMware, using VMware PVSCSI for hard
disk, but e1000 for network.

Booted okay, and similar to the report on XenServer. But this time. I
got 2 (two) red asterisks during boot. The 1st one seems to say "Error
... read-only file system". The second starts with "Warning temp file
left behind ..." (or something similar)

`rc-update del udev-postmount default && reboot` ... no problem.

Unmerged udev && reboot ... no problem.


There. No problem with XenServer and/or VMware. Except for the 1 or 2
red asterisks during boot (which I'm not sure caused by udev-->mdev
switch or something else).


I'll experiment with VirtualBox (on Windows) tomorrow. This might be
much more interesting :-)

[pk]

On 2011-11-15 07:21, walt...@waltdnes.org wrote:

> The purpose of this email is to ask adventurous people here to beta
> test my approach to a udev-less Gentoo. If we don't find any
> showstopper problems, we can think about requesting Gentoo developers to
> support an mdev-based profile. It would help the cause if a large
> number of testers can report that it works for them. The instructions
> for a udev-ectomy follow below. Thanks to Zac Medico and others on the
> Gentoo developers' list for their helpful hints and pointers on how to
> do this. I couldn't have figured this out by myself.

I apologize for not having replied sooner. This sounds very interesting
and I will try this out, when I can find the time to "tinker". Thanks
for doing this!

Best regards

Peter K

[walt...@waltdnes.org]

Based on feedback, I've changed step 6, to get a modified ebuild for
virtual/dev-manager to properly check for busybox with the "mdev" USE
flag. Steps 1-through-5 are unchanged.

* If you don't already have an overlay, create one, and implement it in
/etc/make.conf. In the following example, I'll use my setup, which has
the overlay in /usr/local/portage

* copy the contents of /usr/portage/virtual/dev-manager/ to
/usr/local/portage/virtual/dev-manager/

* cd /usr/local/portage/virtual/dev-manager/

* Edit the dev-manager-0.ebuild in the overlay to include
"sys-apps/busybox[mdev]" as one option in RDEPEND. And also include
"EAPI=2" at the top of the ebuild, which is required for this syntax.
The revised ebuild is shown below.

############################################
EAPI=2

DESCRIPTION="Virtual for the device filesystem manager"
HOMEPAGE=""
SRC_URI=""

LICENSE=""
SLOT="0"
KEYWORDS="alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~spar
c-fbsd ~x86-fbsd"
IUSE=""

DEPEND=""
RDEPEND="|| ( sys-fs/udev
sys-apps/busybox[mdev]
sys-fs/devfsd
sys-fs/static-dev
sys-freebsd/freebsd-sbin )"
############################################

[Pandu Poluan]

On Mon, Nov 21, 2011 at 17:47, <walt...@waltdnes.org> wrote:
>

----- >8 snip

> 3) In the bootloader append line, include "init=/sbin/linuxrc" where
>   the file /sbin/linuxrc consists of *AT LEAST*...
>
> #!/sbin/busybox ash
> mount -t proc proc /proc
> mount -t sysfs sysfs /sys
> exec /sbin/init
>
>   This should be enough for most users.  If you have an unusual setup,
>   you may need additional stuff in there.  If you're using lilo remember
>   to re-run lilo to implement the changes.
>

----- >8 snip

BTW, "which busybox" returns /bin/busybox instead of /sbin/busybox

In other words, all this time /sbin/linuxrc *didn't* run on my boxen,
but the kernel is smart enough to "run with the defaults", whatever
that is (I forgot to write down the exact error message in dmesg).

After fixing the hashbang line, I can now insert the line "mount -o
remount,rw /" at the 2nd line...

... and I no longer have the two red asterisks! Yay!!

[Walter Dnes]

On Wed, Nov 30, 2011 at 08:58:13PM +0700, Pandu Poluan wrote

> On Mon, Nov 21, 2011 at 17:47, <walt...@waltdnes.org> wrote:
> >
>
> ----- >8 snip
>
> > 3) In the bootloader append line, include "init=/sbin/linuxrc" where

> > ?? the file /sbin/linuxrc consists of *AT LEAST*...

> >
> > #!/sbin/busybox ash
> > mount -t proc proc /proc
> > mount -t sysfs sysfs /sys
> > exec /sbin/init
> >

> > ?? This should be enough for most users. ??If you have an unusual setup,
> > ?? you may need additional stuff in there. ??If you're using lilo remember
> > ?? to re-run lilo to implement the changes.

> >
>
> ----- >8 snip
>
> BTW, "which busybox" returns /bin/busybox instead of /sbin/busybox

In plain English... I goofed. It is /bin/busybox. Thanks for
catching that. This is what beta testing is for <G>. I'll update the
instructions.

--
Walter Dnes <walt...@waltdnes.org>

[Walter Dnes]

Corrected "#!/sbin/busybox ash" to "#!/bin/busybox ash" in step 3. The
weird part is that my system actually booted and ran fine even with this
typo in the script.

#!/bin/busybox ash

[Pandu Poluan]

On Dec 2, 2011 2:50 AM, "Walter Dnes" <walt...@waltdnes.org> wrote:
>
>  Corrected "#!/sbin/busybox ash" to "#!/bin/busybox ash" in step 3.  The
> weird part is that my system actually booted and ran fine even with this
> typo in the script.
>

Amazingly enough, my system also works. Albeit with two red asterisks during boot. But the errors only affected rc logging, so I didn't pursue the issue further. Then again, I don't need to do smarty exotic things in /sbin/linuxrc, so the kernel's default actions of automagically mounting /proc and /sys saved my posterior ;-)

The only thing left for me now is to figure out how the hey rc logging perform logging while root is still ro. I currently have suppressed the red asterisks by remounting root rw in /sbin/linuxrc, but am thinking of reverting that because fsck won't work. Yes, the fsck can be performed inside /sbin/linuxrc, but I rather not do that to keep /sbin/linuxrc simple.

Am going to parse the initscripts later today to figure things out.

Rgds,

[Walter Dnes]

In the instructions here, I've set up a revised dev-manager ebuild in
an overlay. I've requested the changes to be incorporated into the
official ebuild and it appears to have been accepted. See...

https://bugs.gentoo.org/show_bug.cgi?id=395319

It should be rolled out eventually, and the overlay won't be necessary.

I think I've found one item so far that requires udev. My laptop's
graphics chip needs a binary blob from radeon-ucode. That binary blob,
in turn, requires the presence of /usr/lib/libudev.so.0 which is a
symlink to /usr/lib/libudev.so.0.9.3 (which is also required). I can

emerge udev
move or copy the 2 files over to /root
unmerge udev
move or copy the 2 files from /root to /usr/lib/

and it still works. Note that /usr/lib/ is a symlink to /usr/lib64 on my
64-bit gentoo.

--
Walter Dnes <walt...@waltdnes.org>

[Pandu Poluan]

On Tue, Jan 3, 2012 at 17:04, Walter Dnes <walt...@waltdnes.org> wrote:
>  In the instructions here, I've set up a revised dev-manager ebuild in
> an overlay.  I've requested the changes to be incorporated into the
> official ebuild and it appears to have been accepted.  See...
>
> https://bugs.gentoo.org/show_bug.cgi?id=395319
>
> It should be rolled out eventually, and the overlay won't be necessary.
>

Cool! :D

>  I think I've found one item so far that requires udev.  My laptop's
> graphics chip needs a binary blob from radeon-ucode.  That binary blob,
> in turn, requires the presence of /usr/lib/libudev.so.0 which is a
> symlink to /usr/lib/libudev.so.0.9.3 (which is also required).  I can
>
> emerge udev
> move or copy the 2 files over to /root
> unmerge udev
> move or copy the 2 files from /root to /usr/lib/
>
> and it still works. Note that /usr/lib/ is a symlink to /usr/lib64 on my
> 64-bit gentoo.
>

Well it doesn't need udev itself, just libudev.

But if the binary blob is hard-coded to search for
/usr/lib/libudev.so.0{,.9.3}, that means /usr must exist at
boot-time...

... or at least /usr/lib/libudev.so.0{,.9.3}

IMO, providing 1 file (+ 1 symlink) is still much better than having
to provide the *whole* /usr tree during boot-time.

Now, what's needed is to "catalog" (1) essential boot-time devs that
can't be handled by mdev, and (2) essential files that need to exist
under /usr during boot-time.

#1 should be interesting for busybox upstream, while #2 will be
necessary for those trying to wean themselves off udev :-)

We're one step closer to an udev-free Gentoo, yay!

(Come to think of it, has *any* distro ever attempted this...
'unconventional of going udev-free?)

[Nicolas Sebrecht]

The 03/01/12, Pandu Poluan wrote:

> (Come to think of it, has *any* distro ever attempted this...
> 'unconventional of going udev-free?)

mdev is not an udev replacement. It's a very minimalist udev designed
for embedded systems and initramfs. These days, a full-featured system
require a dynamic /dev and AFAIK the only existing and up-to-date tool
for this job is udev.

I don't think any other distro attempted to get free of udev as it means
coming back to 10 years ago, at least.

--
Nicolas Sebrecht

[Pandu Poluan]

For desktops, I agree.

But I can see a use case for mdev completely replacing udev: servers and virtual machines.

Servers, especially production ones, have a hardware change only once in every two blue moons. They don't need all the bells and whistles of udev.

Even more so when you've gone the virtualized route.

Since servers are arguably where Linux shines the most, mdev should be seriously considered as a udev replacement.

Rgds,

[Nicolas Sebrecht]

But servers have enough ressources to run udev and any required
initramfs to mount /usr.

So, the question is where engineering should go:

- mdev and manually manage /dev devices if nedded

or

- rely on initramfs to mount /usr.

As initramfs is a prooven working solution, all distributions I know use
it either by default or if needed.

Also, I think the coming problem you will be face with in the mdev way
is the move of binaries from /bin to /usr/bin and so.

--
Nicolas Sebrecht

[Alan McKinnon]

If you go back through the list archives you will find the enormous
thread that caused Walter to start down this road in the first place.
His efforts are an attempt to deal with the gigantic bloat-fest that
the udev devs seem to revel in.

Walter is doing fine work, he should be supported in this.



--
Alan McKinnnon
alan.m...@gmail.com

[Nicolas Sebrecht]

The 03/01/12, Alan McKinnon wrote:

> If you go back through the list archives you will find the enormous
> thread that caused Walter to start down this road in the first place.
> His efforts are an attempt to deal with the gigantic bloat-fest that
> the udev devs seem to revel in.

If you go back through the list archives you will find that I'm envolved
in this thread. ,-p

> Walter is doing fine work, he should be supported in this.

It's free software so everybody can feel free to support him, of course.
I think it's time consummed in the wrong road. I'm a bit curious how
long this alternative can survive. :-)

--
Nicolas Sebrecht

[Pandu Poluan]

On Tue, Jan 3, 2012 at 20:13, Nicolas Sebrecht <nseb...@piing.fr> wrote:
> The 03/01/12, Pandu Poluan wrote:
>
>>    But I can see a use case for mdev completely replacing udev: servers and
>>    virtual machines.
>>
>>    Servers, especially production ones, have a hardware change only once in
>>    every two blue moons. They don't need all the bells and whistles of udev.
>>
>>    Even more so when you've gone the virtualized route.
>>
>>    Since servers are arguably where Linux shines the most, mdev should be
>>    seriously considered as a udev replacement.
>
> But servers have enough ressources to run udev and any required
> initramfs to mount /usr.
>

No, no, no, you got it the wrong way around.

It's not udev *per se* that I -- as a server admin -- want to get rid of.

It's the initramfs.

And I also want to put /usr in a separate partition.

The problem is that, judging from where udev is going in upstream, we
will be forced to use initramfs, or put /usr in /

By migrating from udev to mdev, I am no longer forced to do either.

> So, the question is where engineering should go:
>
> - mdev and manually manage /dev devices if nedded
>
> or
>
> - rely on initramfs to mount /usr.
>

As a SysAdmin, I'd prever the 1st one, thank you.

Adding hardware to server is a MAJOR event, something worthy of
sacrificing some goats and lambs to appease the Information Gods and
Goddesses.

And after the new shiny thing gets installed physically, it will be
followed up -- with 109% certainty -- with some configuration in the
OS.

> As initramfs is a prooven working solution, all distributions I know use
> it either by default or if needed.
>

Then again, using initramfs is yet-another-component waiting to break.

Knowing Murphy's Law, it will one day fuck up everything.

> Also, I think the coming problem you will be face with in the mdev way
> is the move of binaries from /bin to /usr/bin and so.
>

Again, on a server, this will be a one-time affair.

I can always bind-mount the /usr of / under /mnt, letting the "/usr"
get overlaid by the /usr partition. If there's a piece of hardware
that needs a piece of binary inside /usr, I'll just cp that binary
into /mnt/usr/whatever to appease that piece of hardware.

[Volker Armin Hemmann]

since Walter does it to ease an itch he is feeling and since Walter is doing
this for fun 'time consumed in the wrong road' is not an argument.

Other people love to build miniature F1 cars and put them behind glass. Waste
of time? From my POV sure. From theirs? Hell no!

--
#163933

[Dale]

Personally, I hope to turns out to be a replacement for udev, if for no
other reason than to be a poke in the eye of the fedora dev that started
this crap to begin with.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

[Nicolas Sebrecht]

The 03/01/12, Pandu Poluan wrote:
> On Tue, Jan 3, 2012 at 20:13, Nicolas Sebrecht <nseb...@piing.fr> wrote:

> > But servers have enough ressources to run udev and any required
> > initramfs to mount /usr.
>
> No, no, no, you got it the wrong way around.
>
> It's not udev *per se* that I -- as a server admin -- want to get rid of.
>
> It's the initramfs.
>
> And I also want to put /usr in a separate partition.
>
> The problem is that, judging from where udev is going in upstream, we
> will be forced to use initramfs, or put /usr in /

I know. It's the "I want to get the rid of initramfs" thing that looks
crazy to me.

> > As initramfs is a prooven working solution, all distributions I know use
> > it either by default or if needed.
>
> Then again, using initramfs is yet-another-component waiting to break.
>
> Knowing Murphy's Law, it will one day fuck up everything.

And the mdev alternative won't follow this law?

--
Nicolas Sebrecht

[Nicolas Sebrecht]

The 03/01/12, Volker Armin Hemmann wrote:
> Am Dienstag, 3. Januar 2012, 14:36:08 schrieb Nicolas Sebrecht:

> > It's free software so everybody can feel free to support him, of course.
> > I think it's time consummed in the wrong road. I'm a bit curious how
> > long this alternative can survive. :-)
>
> since Walter does it to ease an itch he is feeling and since Walter is doing
> this for fun 'time consumed in the wrong road' is not an argument.

Of course, it's not an argument. It's my feeling. I'm not against people
hacking on crazy ideas. I do it myself when I think it worth.

--
Nicolas Sebrecht

[Alan McKinnon]

On Tue, 3 Jan 2012 15:31:20 +0100
Nicolas Sebrecht <nseb...@piing.fr> wrote:

> > Then again, using initramfs is yet-another-component waiting to
> > break.
> >
> > Knowing Murphy's Law, it will one day fuck up everything.
>
> And the mdev alternative won't follow this law?

It's not immune to it, just statistically less likely to be affected.

mdev sans initramfs is a less complex solution than udev plus
initramfs. Ergo, all other things being equal, less bits to break.



--
Alan McKinnnon
alan.m...@gmail.com

[Dale]

Yep. I *think* I got a init thingy to work but I'm still not sure and
apparently since there was no replies to my other thread, no one else
knows either. From the messages in dmesg, it looks like I have tho.
Thing is, if I reboot and the init fails, I have no real clue how to fix
it. I know this because I ran into this same thing on Mandriva, along
with the dependency problems that is well known. The fact that Gentoo
has a simple booting process is what really got me interested in
Gentoo. If we are going down this road, I may check and see if the
dependency problems are fixed. As bad as it is to say, Gentoo is
getting more like other distros that I left or didn't want to bother
with. Makes me wonder. I know I am a unique old bird but I bet I am
not alone in this.

It sort of comes down to this, if I can't boot because of a broken
init*, I may just save my /home and data drive and install something else.

Just my $0.02 worth and it ain't worth more than that I'm sure.

[Walter Dnes]

On Tue, Jan 03, 2012 at 05:22:09PM +0700, Pandu Poluan wrote

> (Come to think of it, has *any* distro ever attempted this...
> 'unconventional of going udev-free?)

Alpine linux has done it http://alpinelinux.org/ Unfortunately,
they're so minimalistic and server-oriented that they use uclibc instead
of glibc. So Alpine is not viable as a desktop distro. Think of it as

Gentoo with mdev instead of udev == Alpine with glibc instead of uclibc

By the way, there's a thread on the Gentoo developer list discussing
the situation, and the proposed move of a bunch of stuff to /usr. See
http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=245148;page=1;mh=-1;list=gentoo;sb=post_latest_reply;so=ASC

I piped up with my proposal. We'll see what happens.

--
Walter Dnes <walt...@waltdnes.org>

[Nicolas Sebrecht]

The 03/01/12, Walter Dnes wrote:
> On Tue, Jan 03, 2012 at 05:22:09PM +0700, Pandu Poluan wrote
>
> > (Come to think of it, has *any* distro ever attempted this...
> > 'unconventional of going udev-free?)
>
> Alpine linux has done it http://alpinelinux.org/ Unfortunately,
> they're so minimalistic and server-oriented that they use uclibc instead
> of glibc.

Hugh?

http://alpinelinux.org/apk/main/x86/udev

--
Nicolas Sebrecht

[Mick]

I'd like to thank Walter for doing something about this and Pandu for testing
it, rather than just wingeing (like I did). :p

I don't hold any hope that mdev will replace udev, but that this effort may go
someway to influence the development philosophy that has been entertained to
date with udev. A philosophy that removes choice and flexibility. This is
felt more by Gentoo users, because Gentoo as we know is not a binary distro
and the needs of its users are more nuanced and eclectic.

As I recall from this mammoth thread mdev is one option, a staged mounting of
devices/running of scripts by udev is another. Anything that will make udev
devs to stop for a minute and think again the impact of their choices on the
overall Linux community will be of benefit. If Walter's good effort bring this
about I would be more than happy to support him, although with a laptop using
mdev may not be my immediate preferred solution.
--
Regards,
Mick

[Neil Bothwick]

On Tue, 3 Jan 2012 15:31:20 +0100, Nicolas Sebrecht wrote:

> I know. It's the "I want to get the rid of initramfs" thing that looks
> crazy to me.

No one is saying they want to get rid of the initramfs, because they are
not using one. What people object to is being forced to start using one.


--
Neil Bothwick

"An investment in knowledge always pays the best interest." - Benjamin
Franklin

[Dale]

Neil Bothwick wrote:
> On Tue, 3 Jan 2012 15:31:20 +0100, Nicolas Sebrecht wrote:
>
>> I know. It's the "I want to get the rid of initramfs" thing that looks
>> crazy to me.
> No one is saying they want to get rid of the initramfs, because they are
> not using one. What people object to is being forced to start using one.
>
>

You got that right. I have not used one since I started using Gentoo.
Now, I may very well have to start. I hope mdev gets to a point where
it works really well on desktop systems.

[Pandu Poluan]

On Jan 4, 2012 6:19 AM, "Dale" <rdale...@gmail.com> wrote:
>
> Neil Bothwick wrote:
>>
>> On Tue, 3 Jan 2012 15:31:20 +0100, Nicolas Sebrecht wrote:
>>
>>> I know. It's the "I want to get the rid of initramfs" thing that looks
>>> crazy to me.
>>
>> No one is saying they want to get rid of the initramfs, because they are
>> not using one. What people object to is being forced to start using one.
>>
>>
>
> You got that right.  I have not used one since I started using Gentoo.  Now, I may very well have to start.  I hope mdev gets to a point where it works really well on desktop systems.
>

You were there in the thread linked by Walt, udev is just one of several packages maintained by RH people that *demands* /usr to be mounted during boot.

And the RH devels insistence to deprecate /bin, /sbin, /usr/sbin...

I'm getting depressed. One battle might be won (mdev vs udev), but there's still a war against the RH braindeadness...

Rgds,

[Canek Peláez Valdés]

I'm sorry to tell you this, but (as admirable as it could be), the
mdev hack to use it instead of udev is not a "victory". We are not at
war, in the first place; and in the second place, the mdev hack would
be used by a handful of guys bent on refusing a change that, like it
or not, would in the end come. Like Gentoo on FreeBSD, it would be a
nice hack, maybe even worthy of applause, but in the end irrelevant: a
toy. A cute, entertaining (and, in a few cases, useful) toy. But a toy
nonetheless.

The heavy development will continue to happen in udev, and the devices
that will dominate in the future (touchscreens, bluetooth input and
audio devices, hardware that has a highly dynamic change rate) will
only be supported by udev. The mdev hack will be useful maybe to only
some guys, and even then udev would be able to do the same (and more).

The use of an initramfs (or, alternatively, having /usr in the same
partition as /), and maybe the move of /bin to /usr/bin and /lib to
/usr/lib will be made, and in the future most of the interesting
software will simply assume that this is how a system works. Maybe we
will even stop to use the ridiculous short directory names from the
stone age, and we will start using sensible names:

/usr -> /System
/etc -> /Config
/var -> /Variable

I feel a deep respect for the people working on making mdev a
"replacement" of udev; it is not an easy task (even if it only works
for a really small subset of the use cases udev covers), and something
that I certainly would never do. But their hack (as beautiful as it
may be) will never be used by the majority of Linux users, and
probably not even by the majority of Gentoo users (if my
interpretation of the discussion on gentoo-dev is correct). And with
the pass of time it will be harder and harder to keep the hack working
with new hardware, new software, and new use cases.

But, hey, this is FOSS; you guys go nuts hacking in whatever feature
(or anti-feature) you like. As in the case of this mdev hack, it may
even be included in the Gentoo ebuilds. Just don't expect it to be
supported forever, don't expect it to support general-purpose setups,
and certainly don't call it "a victory". It's just the same history as
always: the people writing the code are the ones calling the shots.

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

[Dale]

I wonder how many times this has been said about other software that is
now in wide spread use. Keep in mind, some people think Gentoo is dying
and has been dying for YEARS. That's not just one package but a whole
distro.

Will mdev replace udev, I dunno. Thing is, you don't know that it won't
either. Someone could come along and help Walter and make it better
than udev ever dreamed of being.

I just have to mention hal too. Lots of people thought that was the new
sliced bread and frozen pizza. It sure did fall hard tho.

As I said about my ex once, time tells. Sometimes, time is the only
thing that does tell too. Reminds me of wine although I don't drink it.

[Michael Mol]

Netcraft confirms it?

>
> Will mdev replace udev, I dunno.  Thing is, you don't know that it won't
> either.  Someone could come along and help Walter and make it better than
> udev ever dreamed of being.

It's not that mdev will be better than udev, or udev better than mdev,
it's that they'll be able to service different roles very effectively.

> I just have to mention hal too.  Lots of people thought that was the new
> sliced bread and frozen pizza.  It sure did fall hard tho.

For a fair number of use cases, udev works pretty well. It's been
around for far longer, too.

> As I said about my ex once, time tells.  Sometimes, time is the only thing
> that does tell too.  Reminds me of wine although I don't drink it.

I think it's absolutely ridiculous to look at udev and mdev as winner
or loser. I'm not trying to be even-handed or fair in this; I just
think they service different needs.

Currently, the only advantage I see for udev in a server is the
ability to give network interfaces meaningful names...

--
:wq

[Alan McKinnon]

On Wed, 4 Jan 2012 18:49:29 -0500
Michael Mol <mik...@gmail.com> wrote:

> > As I said about my ex once, time tells.  Sometimes, time is the
> > only thing that does tell too.  Reminds me of wine although I don't
> > drink it.
>
> I think it's absolutely ridiculous to look at udev and mdev as winner
> or loser. I'm not trying to be even-handed or fair in this; I just
> think they service different needs.
>
> Currently, the only advantage I see for udev in a server is the
> ability to give network interfaces meaningful names...

Even that isn't all that useful for me. For my servers I know exactly
which interface is which (turns out that when Dell give you 4 on-board
nics they always come up in the same order. Pretty useful.)

We do the proper thing and document every bit of hardware in a central
repo (ocsng makes this automagic) and the way it is when the box is
racked is the way it stays till it's switched off 5 years later.

Aside from disks and RAM I've only had 2 hardware failures in 4 years
(both were Adaptec RAID cards) so changing hardware is an unusual event
(and rather major at that when it does happen).

For me, udev is more of a hindrance in the data centre than a help. I
simply do not need it at all, so mdev interests me a lot.

On my notebooks and test/development VMs, that's different. Those need
udev.

On something as complex as a node manager, I do not believe there is
such a thing as one-size fits all or a universal design.

--
Alan McKinnnon
alan.m...@gmail.com

[pk]

On 2012-01-05 01:02, Alan McKinnon wrote:

> On my notebooks and test/development VMs, that's different. Those need
> udev.

Why does it need udev specifically? Just curious... if there's a
technical need for something else than /dev population (and possible
configuration of devices, i.e. tell the kernel what bits needs to be
switched)?

> On something as complex as a node manager, I do not believe there is
> such a thing as one-size fits all or a universal design.

Fully agree.

Best regards

Peter K

[Alan McKinnon]

On Thu, 05 Jan 2012 08:30:52 +0100
pk <pet...@coolmail.se> wrote:

> > On my notebooks and test/development VMs, that's different. Those
> > need udev.
>
> Why does it need udev specifically? Just curious... if there's a
> technical need for something else than /dev population (and possible
> configuration of devices, i.e. tell the kernel what bits needs to be
> switched)?

Simply because they are typical notebooks and VMs :-)

I fiddle around a lot with the hardware on those and udev deals with
that nicely considering udev is designed to deal with that nicely.

Becoming rather lazy in my old age is getting to be a factor too

--
Alan McKinnnon
alan.m...@gmail.com

[pk]

On 2012-01-05 08:43, Alan McKinnon wrote:

> I fiddle around a lot with the hardware on those and udev deals with
> that nicely considering udev is designed to deal with that nicely.

I confess to being quite ignorant when it comes to what magic udev does
behind the scenes but what makes it different to any other device
manager (well, I don't know any other than mdev but...)? I.e. what
technical problem(s) does udev solve that no other device manager can't?
What is the technical need for something else than a device file under
/dev that can be used to communicate with the kernel?

What I mean is: If you say "... considering udev is designed to deal
with that..." you seem to indicate that you know what it does and why it
does what it does... and henceforth the technical reason why the
rearrangements of the file system hierarchy is necessary...

> Becoming rather lazy in my old age is getting to be a factor too

Ho hum... so "you lazy old fart" is true then? ;-)

Best regards

Peter K

[Pandu Poluan]

On Thu, Jan 5, 2012 at 03:21, Canek Peláez Valdés <can...@gmail.com> wrote:
> On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluan <pa...@poluan.info> wrote:
>>

----- >8 snip

>>
>> You were there in the thread linked by Walt, udev is just one of several
>> packages maintained by RH people that *demands* /usr to be mounted during
>> boot.
>>
>> And the RH devels insistence to deprecate /bin, /sbin, /usr/sbin...
>>
>> I'm getting depressed. One battle might be won (mdev vs udev), but there's
>> still a war against the RH braindeadness...
>
> I'm sorry to tell you this, but (as admirable as it could be), the
> mdev hack to use it instead of udev is not a "victory". We are not at
> war, in the first place; and in the second place, the mdev hack would
> be used by a handful of guys bent on refusing a change that, like it
> or not, would in the end come. Like Gentoo on FreeBSD, it would be a
> nice hack, maybe even worthy of applause, but in the end irrelevant: a
> toy. A cute, entertaining (and, in a few cases, useful) toy. But a toy
> nonetheless.
>

I may have been slightly hyperbolic in my usage of "battle" and "war",
but then again why must Gentoo bend over to the wills of RH developers
who insist on doing things their way?

And mdev might be a 'toy' to you, but embedded Linux developers will
vehemently disagree with you.

And based on the responses in this thread, server guys will also
disagree with you.

For these two groups, mdev is not a toy but a necessity.

> The heavy development will continue to happen in udev, and the devices
> that will dominate in the future (touchscreens, bluetooth input and
> audio devices, hardware that has a highly dynamic change rate) will
> only be supported by udev. The mdev hack will be useful maybe to only
> some guys, and even then udev would be able to do the same (and more).
>

The ability of mdev is more than enough for those handling the
back-end servers, thank you.

udev just adds bells and whistles *not* needed in server environs.

> The use of an initramfs (or, alternatively, having /usr in the same
> partition as /), and maybe the move of /bin to /usr/bin and /lib to
> /usr/lib will be made, and in the future most of the interesting
> software will simply assume that this is how a system works. Maybe we
> will even stop to use the ridiculous short directory names from the
> stone age, and we will start using sensible names:
>
> /usr -> /System
> /etc -> /Config
> /var -> /Variable
>

I can agree with sensible names. Unfortunately, forcing sensible names
upon servers *already* in the field is a sure fire recipe to disaster.

Besides, the FHS itself explains the reasoning behind each directory.

As to the forced use of initramfs, again it runs counter to the wishes
of embedded Linux people (for whom storage is at a premium) and the
wishes of server people (whom would prefer as few 'breaking points' as
possible).

(As a side note, initramfs introduces not one, but *MANY* additional
breaking points: the tool used to generate the initramfs might be
buggy and/or feature-incomplete, the initramfs itself might encounter
an unrecoverable error, the pivot_root or chroot might snag upon some
not-so-edge cases, etc.)

> I feel a deep respect for the people working on making mdev a
> "replacement" of udev; it is not an easy task (even if it only works
> for a really small subset of the use cases udev covers), and something
> that I certainly would never do. But their hack (as beautiful as it
> may be) will never be used by the majority of Linux users, and
> probably not even by the majority of Gentoo users (if my
> interpretation of the discussion on gentoo-dev is correct). And with
> the pass of time it will be harder and harder to keep the hack working
> with new hardware, new software, and new use cases.
>
> But, hey, this is FOSS; you guys go nuts hacking in whatever feature
> (or anti-feature) you like. As in the case of this mdev hack, it may
> even be included in the Gentoo ebuilds. Just don't expect it to be
> supported forever, don't expect it to support general-purpose setups,
> and certainly don't call it "a victory". It's just the same history as
> always: the people writing the code are the ones calling the shots.
>

As long as there are embedded Linux, mdev *will* be maintained and
supported in perpetuum.

Besides, the so-called mdev "hack" is really just a small script which
gets executed before "init" runs. The other convoluted steps waltdnes
had provided is just necessary to fix the virtual/dev-manager ebuild
to allow using mdev instead of udev (and, with the acceptance of his
bug report, we will soon see in the main portage tree). The actual
steps to replace udev with mdev are very simple.

[Nicolas Sebrecht]

The 05/01/12, Pandu Poluan wrote:

> And mdev might be a 'toy' to you, but embedded Linux developers will
> vehemently disagree with you.
>
> And based on the responses in this thread, server guys will also
> disagree with you.

On the embedded side, we need udev much more than you think to support
bluetooth, tablet and so. Android uses udev. This is even more true when
we know that users will expect to have any plugged-in devices at
whatever boot time or runing system be working out of the box. BTW, this
is not a major problem since embedded devices already often use initramfs.

On servers, I wouldn't be surprised that hypervisor tools will expect
/dev/cdrom instead of /dev/sr0.
AFAIK, mdev doesn't provide persistent device names and changing a
ethernet card might result in a highly broken system where udev will let
all interfaces working but the changed one. Worse, I think mdev might
change of device names upon reboot so that all ethernet devices can be
mixed up in ways like eth0 -> eth1, eth1 -> eth3 and eth2 -> eth0.

These are only few examples and this is whole mdev hack (requirements
and consequences) that makes "mdev alternative" look like a toy.

People thinking that mdev could replace udev even on embedded devices
and servers are wrong for both current or longer term.
You might like it or not but udev is a core system tool, nowadays.

As admin, I will expect to have a initramfs and udev on linux systems
whatever they are desktop, embedded or servers. Actually, I already rely
on initramfs for all of these kind of systems for years with success.

--
Nicolas Sebrecht

[Neil Bothwick]

On Thu, 5 Jan 2012 11:01:49 +0100, Nicolas Sebrecht wrote:

> You might like it or not but udev is a core system tool, nowadays.

Yes, today. It wasn't yesterday and it may not be tomorrow. I like udev,
but I do not like the direction it is taking. I am not alone in this and
there may be a critical mass needed to create an alternative, whether
that be an evolution of mdev or something completely new.

You cannot assume that you can make whatever changes you want and all
users will follow, that's why there are so many new Xubuntu and Mint
users.

You are clearly happy with udev and already want/need an initramfs. Don't
fall into the same trap as the udev developers and think that what you
want it was everyone else wants.


--
Neil Bothwick

Power corrupts. Absolute power is kind of neat.

[Alan McKinnon]

On Thu, 5 Jan 2012 16:07:04 +0700
Pandu Poluan <pa...@poluan.info> wrote:

> (As a side note, initramfs introduces not one, but *MANY* additional
> breaking points: the tool used to generate the initramfs might be
> buggy and/or feature-incomplete, the initramfs itself might encounter
> an unrecoverable error, the pivot_root or chroot might snag upon some
> not-so-edge cases, etc.)

I completely agree. But if we take one more step backwards for a wider
view we see something even more bizarre:


I switch on a modern computer and it:

- loads a feature rich OS (UEFI) from a fixed point in firmware which
then

- loads a feature rich OS (grub2) from a fixed point on a storage
device which then

- loads a feature rich OS (initrd) from a variable location on a
storage device which then

- loads the real OS (the thing I actually wanted).

So, let's see now. I need 4 OSes to get one. Wow. If a design engineer
pulled that stunt in almost any other field of technology, he'd be
laughed out of Dodge in a heartbeat.

Methinks someone (many someones) completely lost the plot a long time
ago.


--
Alan McKinnnon
alan.m...@gmail.com

[Alan McKinnon]

On Thu, 05 Jan 2012 09:17:23 +0100
pk <pet...@coolmail.se> wrote:

> On 2012-01-05 08:43, Alan McKinnon wrote:
>
> > I fiddle around a lot with the hardware on those and udev deals with
> > that nicely considering udev is designed to deal with that nicely.
>
> I confess to being quite ignorant when it comes to what magic udev
> does behind the scenes but what makes it different to any other device
> manager (well, I don't know any other than mdev but...)? I.e. what
> technical problem(s) does udev solve that no other device manager
> can't? What is the technical need for something else than a device
> file under /dev that can be used to communicate with the kernel?
>
> What I mean is: If you say "... considering udev is designed to deal
> with that..." you seem to indicate that you know what it does and why
> it does what it does... and henceforth the technical reason why the
> rearrangements of the file system hierarchy is necessary...

I don't claim any special deep knowledge of these things, but a
superficial glance over the packages tells you a lot. udev is designed
to deal with any realistic device needs on modern systems - it's the
kitchen sink.

mdev has a much narrower scope where things are considerably more
static.

As for re-arranging the fs layout, I think it was Canek in the last
thread that gave an excellent example of why this is needed. When
devices hotplug, or need to become active early on in the boot process,
they need to run code that can be located almost anywhere. It wouldn't
be fun trying to get a wireless keyboard going when it's start-up
script needs to get into /usr/lib/firmware and /usr isn't mounted yet.

The example was something along the lines of a machine that has no
physical keyboard or a port for one, it uses a bluetooth keyboard. But
the main file systems are encrypted using a key that's on a smartcard.
To decrypt and mount the filesystems, the drivers for keyboard,
bluetooth and smart card, plus all firmware, needs to be loaded first.
This is actually not all that far-fetched, and it's a classic bootstrap
problem first solved in the 60s. It much more complex now than it was
then but the principles behind the solution are much the same.

I do agree with collapsing the executable code in /usr into /, or
having /usr on the root partition. A separate /usr/{,s}bin is pretty
pointless and was never done for safety or maintenance reasons. It was
done way way way back when disks were small and a convenient hack was
to keep the OS on the boot device and user apps somewhere else on
bigger but slower storage (which often was remote).

If /usr is local, what really is the point of having it separate
from /? Have you ever found a Linux system in any condition that could
not start just because the stuff in /usr was available? I haven't.

Even the split between bin and sbin is arbitrary. It's only there so
that users can take sbin out of PATH and not have the screen cluttered
with endless junk when they tab-tab. It makes much more sense to me to
just have one single bin and lib location and shove everything into it.

What I do object to is any possible idea that an initramfs will be
*required* regardless. I know this isn't on the table just yet, but
it's a very small amount of creep before it is.

>
> > Becoming rather lazy in my old age is getting to be a factor too
>
> Ho hum... so "you lazy old fart" is true then? ;-)

Dunno about lazy old fart, but splog (snarky pedantic lazy old git)
definitely is. I think we decided that Neil is the lazy old fart :-)



--
Alan McKinnnon
alan.m...@gmail.com

[Dale]

Alan McKinnon wrote:
> Dunno about lazy old fart, but splog (snarky pedantic lazy old git)
> definitely is. I think we decided that Neil is the lazy old fart :-)

I'll take the plain "old fart" title. lol Drs think my body is at
least 70 anyway. I think my brain is old to but that's not what they
test, YET. o_O

[pk]

On 2012-01-05 12:46, Alan McKinnon wrote:

> I switch on a modern computer and it:
>
> - loads a feature rich OS (UEFI) from a fixed point in firmware which
> then
>
> - loads a feature rich OS (grub2) from a fixed point on a storage
> device which then

This is a precise argument why coreboot (and filo for grub(n)) is
needed... Unfortunately it's not widely available for consumers... :-(
I do have a couple of motherboards with switchable flash roms that I
intend to get coreboot on, "when I can find the time"... sigh...

> - loads a feature rich OS (initrd) from a variable location on a
> storage device which then

Haven't used this since I got rid of Redhat 5.x (or maybe it was
6.x?)... and never will again even if that means going the non-linux route.

> - loads the real OS (the thing I actually wanted).
>
> So, let's see now. I need 4 OSes to get one. Wow. If a design engineer
> pulled that stunt in almost any other field of technology, he'd be
> laughed out of Dodge in a heartbeat.

Couldn't agree more!

> Methinks someone (many someones) completely lost the plot a long time
> ago.

Yes, and we're continuing along that path, it seems.

Best regards

Peter K

[Neil Bothwick]

Alan McKinnon wrote:

> Dunno about lazy old fart, but splog (snarky pedantic lazy old git)
> definitely is. I think we decided that Neil is the lazy old
> fart :-)

I can't be bothered to answer that one.


--
Neil Bothwick

Q: What's the proper plural of a 'Net-connected Windows machine?
A: A Botnet

[pk]

On 2012-01-05 13:08, Alan McKinnon wrote:

> I don't claim any special deep knowledge of these things, but a
> superficial glance over the packages tells you a lot. udev is designed
> to deal with any realistic device needs on modern systems - it's the
> kitchen sink.

^^^^^^^^^^^^
Fully agree... :-/

> mdev has a much narrower scope where things are considerably more
> static.

Currently it does have a more narrow scope, yes, but that can change,
no? Although I'm not entirely convinced that a userspace dev manager is
needed (yes, devfs on Linux was an utter failure but Solaris, Mac OS X,
*BSDs use it[1] and done properly in Linux it should work just as fine)...

1: https://en.wikipedia.org/wiki/Devfs#devfs

> As for re-arranging the fs layout, I think it was Canek in the last
> thread that gave an excellent example of why this is needed. When
> devices hotplug, or need to become active early on in the boot process,
> they need to run code that can be located almost anywhere. It wouldn't
> be fun trying to get a wireless keyboard going when it's start-up
> script needs to get into /usr/lib/firmware and /usr isn't mounted yet.

Yes, I understand the need for this but... how does a wireless keyboard
work under bios/firmware (*efi)? Never tried one and never will... A
computer without ports should handle such connections in firmware
(analogy: You don't need software to drive a cable).

> I do agree with collapsing the executable code in /usr into /, or
> having /usr on the root partition. A separate /usr/{,s}bin is pretty
> pointless and was never done for safety or maintenance reasons. It was
> done way way way back when disks were small and a convenient hack was
> to keep the OS on the boot device and user apps somewhere else on
> bigger but slower storage (which often was remote).

Hm... I find it quite elegant and flexible with the separation of / and
it's various underlying directories. I guess we can agree on disagreeing
here... although, I'm a bit surprised to see you as an admin defending
the "new" way... Windows does have such a philosophy with putting
everything system related into a directory (\WINDOWS)... Ultimately one
can argue why use anything else besides Windows, it does the job
reasonably well.

> If /usr is local, what really is the point of having it separate
> from /? Have you ever found a Linux system in any condition that could
> not start just because the stuff in /usr was available? I haven't.
>
> Even the split between bin and sbin is arbitrary. It's only there so
> that users can take sbin out of PATH and not have the screen cluttered
> with endless junk when they tab-tab. It makes much more sense to me to
> just have one single bin and lib location and shove everything into it.

I'm not an admin of a large organization so what do I know... but, I
still can appreciate the flexibility and "tidyness" it[2] gives you in a
multi-user system. I also can see this from a security point of view
("keep the cool toys from the children")... I personally like it for my
very local computer as well for the above reasons (flex./tidy).

2: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

What you are basically saying is that everything "we" have learned about
computer systems should be abolished and we adapt the monolithic, "black
box" philosophy of newish systems like Windows. That's how I interpret
what you're saying (yes, I do know hardware has changed since the 60'ies
but not that radically, IMO)... I tend to think of Unix as "Lego" where
you have lots of little bits with clean(ish) interfaces with which you
can build whatever you want. With the new philosophy it's more like
buying an Audi A2 (for those who don't know it, basically all you can do
is fill it up with petrol, oil and window fluid; anything else you need
to take it to an Audi workshop). Maybe I suck at car analogies... :-P

> Dunno about lazy old fart, but splog (snarky pedantic lazy old git)
> definitely is. I think we decided that Neil is the lazy old fart :-)

:-D

Oh... I'm not that far behind unfortunately... so, I'm a "lazy,
pedantic, oldish, ???". ;-)

Best regards

Peter K

[pk]

On 2012-01-05 15:03, Dale wrote:

> I'll take the plain "old fart" title. lol Drs think my body is at
> least 70 anyway. I think my brain is old to but that's not what they
> test, YET. o_O

Here's the condensed version of what's happening (laughing is good for
you or so I hear):

https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6#diff-1

[Dale]

rm -rf /usr /lib/nvidia-current/xorg/xorg

ROFLMAO. That one space bar hit caused a bit of trouble. WOW. I would have been pretty pissed. lol

Dale

:-) :-)

P. S. I may be a bit. I got to get my innards back in. O_O

[Pandu Poluan]

After some soul-searching (yes, I still have one despite learning from BOFH), I think I'll agree with Alan... with some caveats.

I have less resistance to requiring /usr to be part of /. The way I see it, I can still do some bind mount black magic to provide a minimal /usr for booting yet isolating the 'real' /usr to prevent it messing up the rootfs.

As to udev, I still think it's an overkill for a static server environment. With virtualization, I can *guarantee* that the (virtual) hardware environment will never change. For these environments, I much prefer mdev to udev.

Finally, regarding initramfs, I wholly agree. Don't force me to use one. A server is already a complex system, and adding complexity won't end up pretty.

Rgds,

[pk]

On 2012-01-05 17:20, Dale wrote:

> rm -rf /usr /lib/nvidia-current/xorg/xorg
>
> ROFLMAO. That one space bar hit caused a bit of trouble. WOW. I would
> have been pretty pissed. lol

Yes, buy it's the comments (and pictures) below that made me laugh...
the link is a definite keeper... :-D

Best regards

Peter K

[Pandu Poluan]

Hehehe... geek joke at its finest :-)

Thanks for the heads up!

Rgds,

[Alan McKinnon]

On Thu, 05 Jan 2012 16:50:45 +0100
pk <pet...@coolmail.se> wrote:

> On 2012-01-05 13:08, Alan McKinnon wrote:

[snip]

> > mdev has a much narrower scope where things are considerably more
> > static.
>
> Currently it does have a more narrow scope, yes, but that can change,
> no? Although I'm not entirely convinced that a userspace dev manager
> is needed (yes, devfs on Linux was an utter failure but Solaris, Mac
> OS X, *BSDs use it[1] and done properly in Linux it should work just
> as fine)...
>
> 1: https://en.wikipedia.org/wiki/Devfs#devfs

As I understand it, devfs had unfixable race-condition problems.
Normally these things can be fixed with an architectural re-design but
Greg then showed up with udev. It's in-kernel design is quite elegant
actually. But udev then and udev now are likely very different beasts.

And that's about my limit of things I know for certain with udev

> > As for re-arranging the fs layout, I think it was Canek in the last
> > thread that gave an excellent example of why this is needed. When
> > devices hotplug, or need to become active early on in the boot
> > process, they need to run code that can be located almost anywhere.
> > It wouldn't be fun trying to get a wireless keyboard going when
> > it's start-up script needs to get into /usr/lib/firmware and /usr
> > isn't mounted yet.
>
> Yes, I understand the need for this but... how does a wireless
> keyboard work under bios/firmware (*efi)? Never tried one and never
> will... A computer without ports should handle such connections in
> firmware (analogy: You don't need software to drive a cable).

To you and I it might seem absurd, but I think out there in the
marketplace it's quite a reasonable thing for a user to want. And if
that example never happens, there's hundreds more than can. Point
being, the code must be able to deal with such things.

> > I do agree with collapsing the executable code in /usr into /, or
> > having /usr on the root partition. A separate /usr/{,s}bin is pretty
> > pointless and was never done for safety or maintenance reasons. It
> > was done way way way back when disks were small and a convenient
> > hack was to keep the OS on the boot device and user apps somewhere
> > else on bigger but slower storage (which often was remote).
>
> Hm... I find it quite elegant and flexible with the separation of /
> and it's various underlying directories. I guess we can agree on
> disagreeing here... although, I'm a bit surprised to see you as an
> admin defending the "new" way... Windows does have such a philosophy
> with putting everything system related into a directory (\WINDOWS)...
> Ultimately one can argue why use anything else besides Windows, it
> does the job reasonably well.

Oh, I'm not advocating doing it Windows style, I'm simply saying what's
the point of the system itself having 4 locations for binaries when I
never use that separation? I gain nothing from having a /bin and
a /usr/bin.

/opt and /usr/local/bin *are* useful so I'd keep those. Same with /var
and all the other traditional separate mount points.

> > If /usr is local, what really is the point of having it separate
> > from /? Have you ever found a Linux system in any condition that
> > could not start just because the stuff in /usr was available? I
> > haven't.
> >
> > Even the split between bin and sbin is arbitrary. It's only there so
> > that users can take sbin out of PATH and not have the screen
> > cluttered with endless junk when they tab-tab. It makes much more
> > sense to me to just have one single bin and lib location and shove
> > everything into it.
>
> I'm not an admin of a large organization so what do I know... but, I
> still can appreciate the flexibility and "tidyness" it[2] gives you
> in a multi-user system. I also can see this from a security point of
> view ("keep the cool toys from the children")... I personally like it
> for my very local computer as well for the above reasons (flex./tidy).
>
> 2: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
>
> What you are basically saying is that everything "we" have learned
> about computer systems should be abolished and we adapt the
> monolithic, "black box" philosophy of newish systems like Windows.
> That's how I interpret what you're saying (yes, I do know hardware
> has changed since the 60'ies but not that radically, IMO)... I tend
> to think of Unix as "Lego" where you have lots of little bits with

> clean(ish) interfaces with which you can build whatever you want.dual
>

Good analogy. I also like building systems from individual Lego bricks.
I don't like having to build the bricks themselves first :-)

Windows goes too far to the other extreme IMO. That OS seems to have
largely abandoned control and there's not much in the way of
structure. Too little control is just as bad as too much


[snip]



--
Alan McKinnnon
alan.m...@gmail.com

[Alan McKinnon]

On Thu, 5 Jan 2012 15:52:04 +0000
Neil Bothwick <ne...@digimed.co.uk> wrote:

> Alan McKinnon wrote:
>
> > Dunno about lazy old fart, but splog (snarky pedantic lazy old git)
> > definitely is. I think we decided that Neil is the lazy old
> > fart :-)
>
> I can't be bothered to answer that one.
>
>

touche :-)

--
Alan McKinnnon
alan.m...@gmail.com

[Michael Mol]

Apparently they're going the 'app store' route in Windows 8.

--
:wq

[Michael Mol]

On Thu, Jan 5, 2012 at 5:01 AM, Nicolas Sebrecht <nseb...@piing.fr> wrote:
> The 05/01/12, Pandu Poluan wrote:
>
>> And mdev might be a 'toy' to you, but embedded Linux developers will
>> vehemently disagree with you.
>>
>> And based on the responses in this thread, server guys will also
>> disagree with you.
>
> On the embedded side, we need udev much more than you think to support
> bluetooth, tablet and so. Android uses udev. This is even more true when
> we know that users will expect to have any plugged-in devices at
> whatever boot time or runing system be working out of the box. BTW, this
> is not a major problem since embedded devices already often use initramfs.
>
> On servers, I wouldn't be surprised that hypervisor tools will expect
> /dev/cdrom instead of /dev/sr0.
> AFAIK, mdev doesn't provide persistent device names and changing a
> ethernet card might result in a highly broken system where udev will let
> all interfaces working but the changed one.  Worse, I think mdev might
> change of device names upon reboot so that all ethernet devices can be
> mixed up in ways like eth0 -> eth1, eth1 -> eth3 and eth2 -> eth0.

FWIW, I had a /dev/cdrom symlink long before *devfs* even existed, let
alone udev.

Also, ethN numberings are generally stable until and unless you do
some strange BIOS tweaking or hardware changes, and should be able to
be stabilized in the event the instability comes from some racy module
loading mechanism.

udev's attempts at stabilizing network interfaces have made things
worse more often than I've heard of it making them better. Hit any
search engine for "eth0 missing 70-persistent-net.rules".

(Apologies for anyone who sees this message in such a result; just
delete /etc/udev/rules.d/70-persistent-net.rules, and you should get
eth0 back.)
--
:wq

[pk]

On 2012-01-05 19:02, Alan McKinnon wrote:

> structure. Too little control is just as bad as too much

Well, I am a control freak so... I started out with Redhat a long time
ago and then ended up with Linux From Scratch but it needed a bit too
much maintenance so I found Gentoo as a good compromise.

Best regards

Peter K

[Mick]

They're just playing catch up with Apple instead of trying to innovate.
--
Regards,
Mick

[Neil Bothwick]

On Thu, 5 Jan 2012 13:20:16 -0500, Michael Mol wrote:

> Apparently they're going the 'app store' route in Windows 8.

WooHoo! 200 fart apps on the first day.


--
Neil Bothwick

... "I'm simply not a nice girl", she whispered tartly.

[Nicolas Sebrecht]

On Thu, Jan 05, 2012 at 02:20:21PM -0500, Michael Mol wrote:

> FWIW, I had a /dev/cdrom symlink long before *devfs* even existed, let
> alone udev.

We are not looking for device paths that existed berfore udev. Actually,
most of them exist since much more time than udev. It's not relevant at
all.

> Also, ethN numberings are generally stable until and unless you do
> some strange BIOS tweaking or hardware changes, and should be able to
> be stabilized in the event the instability comes from some racy module
> loading mechanism.

This is not true. I've had computers in hands where network cards could
change of names without any BIOS tunning. BIOS is a executed program and
the way each is implemented can guarantee *or not* to have the
conditions for persistent NIC names on Linux.

> udev's attempts at stabilizing network interfaces have made things
> worse more often than I've heard of it making them better. Hit any
> search engine for "eth0 missing 70-persistent-net.rules".

It's fully expected and required. Persistent naming can work if you have
a configuration for that somewhere. I see nothing worse here. But I see
an improvement to let me tune the NIC names if I need to. I have routers
with *lot of* NIC cards where this feature is very usefull (expressive
names are much better than ethX).

> (Apologies for anyone who sees this message in such a result; just
> delete /etc/udev/rules.d/70-persistent-net.rules, and you should get
> eth0 back.)

<still quoting to help beginners>

--
Nicolas Sebrecht

[Michael Mol]

On Thu, Jan 5, 2012 at 5:08 PM, Nicolas Sebrecht
<nicola...@laposte.net> wrote:
> On Thu, Jan 05, 2012 at 02:20:21PM -0500, Michael Mol wrote:
>
>> FWIW, I had a /dev/cdrom symlink long before *devfs* even existed, let
>> alone udev.
>
> We are not looking for device paths that existed berfore udev. Actually,
> most of them exist since much more time than udev. It's not relevant at
> all.

You missed my point. My point was that udev wasn't needed to resolve
the use case you described, that stable solutions to such cases
preceded udev, and so udev wasn't a necessary tool to solve them.

>
>> Also, ethN numberings are generally stable until and unless you do
>> some strange BIOS tweaking or hardware changes, and should be able to
>> be stabilized in the event the instability comes from some racy module
>> loading mechanism.
>
> This is not true. I've had computers in hands where network cards could
> change of names without any BIOS tunning.

Did this happen after a kernel update or a change to your kernel
configuration? A software update? A change in the set of enabled
modules, or which were built-in vs built as modules?

In any production server environment, I would assume you're already
watching the thing like a hawk and verifying that the thing comes up
properly after a reboot. Reboots should be very, very rare things. I
try to do things more or less correctly on a high-profile machine, and
I'm still giddy when the once-in-a-blue-moon reboot doesn't break
anything.

> BIOS is a executed program and
> the way each is implemented can guarantee *or not* to have the
> conditions for persistent NIC names on Linux.

What you're saying is that NIC stability is dependent on how the OEM
built the BIOS and software. I'll posit there may be strange NICs out
there which can't be initialized within a deterministic time frame
without some external factor such as a link handshake. If this were a
common behavior for a piece of hardware though, I'd consider it
indicative of shoddy quality, and would want to replace it.
Regardless, it's resolvable in software without using a tool that
imposes significant restrictions on system structure.

>
>> udev's attempts at stabilizing network interfaces have made things
>> worse more often than I've heard of it making them better. Hit any
>> search engine for "eth0 missing 70-persistent-net.rules".
>
> It's fully expected and required. Persistent naming can work if you have
> a configuration for that somewhere. I see nothing worse here.

One week, I helped no fewer than five people who ran afoul of the
70-persistent-net.rules file, and didn't know why their eth0
disappeared. These weren't newbie Linux users, either. Some knew their
way around GNOME better than I still do, and they mostly knew their
way around the shell. Some were networking professionals pulling more
than I do.

I'd wager the vast majority of systems out there have devices named as
'ethN' for wired connections, and 'wlanN', 'athN' or whatever for
wireless connections. And that the vast majority of those systems have
one or fewer wired connection ports. And that the further vast
majority of those don't have customized 70-persistent-net.rules files
as you and I have. If that's true, then the persistent-net rules
behavior currently harms more users than it benefits.

> But I see
> an improvement to let me tune the NIC names if I need to. I have routers
> with *lot of* NIC cards where this feature is very usefull (expressive
> names are much better than ethX).

I, too, noted this as a potential advantage of udev. On my router, I
have five interfaces. 'wan', 'he-tunnel', lan, wifi, lo and 'tun0'.
tun0 is only so-named because it's an OpenVPN thing I haven't bothered
to change. I've tried to advocate use this feature of udev.

But I administer my router the way I like to. Most people I've pointed
toward this capability just go "Meh. I have a list of interfaces and
what they're for." even when they already have udev.

--
:wq

[Alan McKinnon]

On Thu, 5 Jan 2012 16:38:20 -0500
Michael Mol <mik...@gmail.com> wrote:

> > But I see
> > an improvement to let me tune the NIC names if I need to. I have
> > routers with *lot of* NIC cards where this feature is very usefull
> > (expressive names are much better than ethX).
>
> I, too, noted this as a potential advantage of udev. On my router, I
> have five interfaces. 'wan', 'he-tunnel', lan, wifi, lo and 'tun0'.
> tun0 is only so-named because it's an OpenVPN thing I
> haven't bothered to change. I've tried to advocate use this feature
> of udev.
>
> But I administer my router the way I like to. Most people I've pointed
> toward this capability just go "Meh. I have a list of interfaces and
> what they're for." even when they already have udev.

I see that as a liability not a feature.

Our routers have very clear naming conventions for interfaces and they
are exactly how Cisco enumerates them and no other way. It's a firing
offense to dick with them and dream up useless "descriptive names".

Mind you, these for the most part are big iron with several 1000
interfaces each and 100+ support personnel working on them. But even
the on-site routers and firewalls at customer premises have the same
rule.

I assume we are talking about kit that routes properly (whether a
Unix or something else is not relevant) and not some joke system.


As for NICs that do not come up at boot time in a consistent
order, if any piece of hardware in our DC did that it would be sent
right back to the vendor labeled as a piece of shit with a demand for a
refund. FFS, if my boss shells out 3 months wages for some iron and it
can't even get something that basic correct, I start to wonder what
else might be dodgy.

There is ZERO excuse for a system that cannot deterministically
enumerate it's fixed devices at boot time.


--
Alan McKinnnon
alan.m...@gmail.com

[Dale]

Yea, they were funny. Sort of surprising tho. Most people were making
a joke about it. Mistakes happen tho. I'm sure it wasn't intentional.

Dale

:-) :-)

[Dale]

Alan McKinnon wrote:
> I see that as a liability not a feature. Our routers have very clear
> naming conventions for interfaces and they are exactly how Cisco
> enumerates them and no other way. It's a firing offense to dick with
> them and dream up useless "descriptive names". Mind you, these for the
> most part are big iron with several 1000 interfaces each and 100+
> support personnel working on them. But even the on-site routers and
> firewalls at customer premises have the same rule. I assume we are
> talking about kit that routes properly (whether a Unix or something
> else is not relevant) and not some joke system. As for NICs that do
> not come up at boot time in a consistent order, if any piece of
> hardware in our DC did that it would be sent right back to the vendor
> labeled as a piece of shit with a demand for a refund. FFS, if my boss
> shells out 3 months wages for some iron and it can't even get
> something that basic correct, I start to wonder what else might be
> dodgy. There is ZERO excuse for a system that cannot deterministically
> enumerate it's fixed devices at boot time.

I have a couple desktop rigs. I had a card that would sometimes not do
right and change the order of my cards numbering. Since it was earlier
than the card that hooked to my modem, it would mess up my connection to
the internet. The card was eth0 and I had internet coming through on
eth2. That rig now has two nics. The defective nic was removed. It
has a new address called /dev/dump.

It may be a desktop rig but I like them being recognized the same each
time I reboot. Although, I forgot about being able to give them names.
< scratches chin > Nah, I'll leave well enough alone. It's working and
we don't mess with what is working, except for Fedora devs. lol

[Pandu Poluan]

mdev is capable of renaming devices, you know ;-)

https://svn.mcs.anl.gov/repos/ZeptoOS/trunk/BGP/packages/busybox/src/docs/mdev.txt

Rgds,

[Dale]

udev does too.  I'm just used to et0, eth1 etc.  If I renamed them, I'd forget the names anyway.  Then I would have to /etc/init.d/<tab tab> then slap forehead.  lol 

Right now, I only use one nic on each rig.  I got a Linksys router now.  I used to use my main rig as a router so it had three nics not counting the built in which I didn't use and was disabled in the BIOS. 

[pk]

On 2012-01-06 02:29, Dale wrote:

> Yea, they were funny. Sort of surprising tho. Most people were making
> a joke about it. Mistakes happen tho. I'm sure it wasn't intentional.

It's easy to make such a mistake when in a hurry, or tired or distracted
for some reason; I'm also quite sure it wasn't intentional...

Best regards

Peter K

[Pandu Poluan]

Anyways, the dev seems to take the gentle (and not so gentle) ribbings in stride, so all is well.

(In any case, he got good promotion for his project).

What really cracked me up: someone asked, didn't the testers -- if any -- caught the error? To which another commenter replied, yes, the testers caught the error, but they can't file a bug until they restore their /usr.

Rich XD

Rgds,

[Walter Dnes]

On Thu, Jan 05, 2012 at 08:30:52AM +0100, pk wrote
> On 2012-01-05 01:02, Alan McKinnon wrote:
>
> > On my notebooks and test/development VMs, that's different. Those need
> > udev.
>
> Why does it need udev specifically? Just curious... if there's a
> technical need for something else than /dev population (and possible
> configuration of devices, i.e. tell the kernel what bits needs to be
> switched)?

I think I've found one item so far that requires udev. My laptop's
graphics chip needs a binary blob from radeon-ucode. That binary blob,
in turn, requires the presence of /usr/lib/libudev.so.0 which is a
symlink to /usr/lib/libudev.so.0.9.3 (which is also required). I can

emerge udev
move or copy the 2 files over to /root
unmerge udev
move or copy the 2 files from /root to /usr/lib/

and it still works. Note that /usr/lib/ is a symlink to /usr/lib64 on my
64-bit gentoo.

--
Walter Dnes <walt...@waltdnes.org>

[pk]

On 2012-01-07 02:17, Walter Dnes wrote:

> I think I've found one item so far that requires udev. My laptop's
> graphics chip needs a binary blob from radeon-ucode. That binary blob,
> in turn, requires the presence of /usr/lib/libudev.so.0 which is a
> symlink to /usr/lib/libudev.so.0.9.3 (which is also required). I can
>
> emerge udev
> move or copy the 2 files over to /root
> unmerge udev
> move or copy the 2 files from /root to /usr/lib/
>
> and it still works. Note that /usr/lib/ is a symlink to /usr/lib64 on my
> 64-bit gentoo.

Hm... I also use a radeon (w/ KMS) and needs this binary blob but I
compile that into the kernel*.

*Device Drivers --->
Generic Driver Options --->
[*] Include in-kernel firmware blobs in kernel binary

If you don't have it compiled in I can see why you would need udev...

Disclaimer: I assume it's not needed in my case - haven't tested though
but fail to see any technical reason for calling libudev, in this case.

Also, this work around... I'm not so sure it's a good solution to
require a pseudo need for udev which is placed on / before mounting /usr
but then again we (can) have a static /dev before {u,m}dev takes over...

Best regards

Peter K

[Walter Dnes]

On Sat, Jan 07, 2012 at 12:44:36PM +0100, pk wrote

> Hm... I also use a radeon (w/ KMS) and needs this binary blob but I
> compile that into the kernel*.
>
> *Device Drivers --->
> Generic Driver Options --->
> [*] Include in-kernel firmware blobs in kernel binary
>
> If you don't have it compiled in I can see why you would need udev...
>
> Disclaimer: I assume it's not needed in my case - haven't tested though
> but fail to see any technical reason for calling libudev, in this case.

I also have that. To test it out, I moved R600_rlc.bin from
/lib/firmware/radeon, and X still comes up. So it has been pulled into
the kernel.

But wait, whilst screwing around, I noticed that the compile pulls in
every blob in the /lib/firmware/radeon directory...

BARTS_mc.bin CAYMAN_pfp.bin JUNIPER_pfp.bin SUMO2_me.bin
BARTS_me.bin CAYMAN_rlc.bin JUNIPER_rlc.bin SUMO2_pfp.bin
BARTS_pfp.bin CEDAR_me.bin PALM_me.bin SUMO_me.bin
BTC_rlc.bin CEDAR_pfp.bin PALM_pfp.bin SUMO_pfp.bin
CAICOS_mc.bin CEDAR_rlc.bin R600_rlc.bin SUMO_rlc.bin
CAICOS_me.bin CYPRESS_me.bin R700_rlc.bin TURKS_mc.bin
CAICOS_pfp.bin CYPRESS_pfp.bin REDWOOD_me.bin TURKS_me.bin
CAYMAN_mc.bin CYPRESS_rlc.bin REDWOOD_pfp.bin TURKS_pfp.bin
CAYMAN_me.bin JUNIPER_me.bin REDWOOD_rlc.bin

I removed all but R600_rlc.bin (the one the laptop graphics chip
requires) from /lib/firmware/radeon, rebuilt the kernel, and rebooted,
and now X comes up fine without the libudev files. This is weird. The
only thing I can think of is...

* with only one binary blob. it "just works"

* multiple blobs should not be included in the kernel, otherwise it gets
confused. If multiple blobs are included, there's a fallback
mechanism that uses udev to figure out exactly which graphics chip the
laptop has, and which of the built-in blobs to use.

So my laptop is now entirely udev-free.

--
Walter Dnes <walt...@waltdnes.org>

[pk]

On 2012-01-09 00:48, Walter Dnes wrote:

Hm... if you didn't compile it in you would have needed an initrd;
didn't think of that... :-(

> * with only one binary blob. it "just works"
>
> * multiple blobs should not be included in the kernel, otherwise it gets
> confused. If multiple blobs are included, there's a fallback
> mechanism that uses udev to figure out exactly which graphics chip the
> laptop has, and which of the built-in blobs to use.

Well, if udev has the database that connects the blob to the chip then
yes it does sounds likely but still a bit strange... I also have only
one blob (I dislike "waste" so I only put the correct blob in there). :-)

> So my laptop is now entirely udev-free.

Congratulations! :-D

PS. I will dive into this and test mdev soon-ish (when I can find the time).

Best regards

Peter K

[Pandu Poluan]

Is it possible to load the firmware blob after booting, from the shell?

Rgds,

[pk]

On 2012-01-09 10:47, Pandu Poluan wrote:

> Is it possible to load the firmware blob after booting, from the shell?

I don't think so; KMS needs it to talk to the gpu so either it needs to
be in an initrd (loaded with the KMS/framebuffer module) or compiled in.
That's how I understand it anyway...

Best regards

Peter K

[Walter Dnes]

On Mon, Jan 09, 2012 at 04:47:22PM +0700, Pandu Poluan wrote

> Is it possible to load the firmware blob after booting, from the shell?

I don't think so. These are not standard kernel modules (*.o) files.

--
Walter Dnes <walt...@waltdnes.org>

[Sebastian Beßler]

On 09.01.2012 22:08, Walter Dnes wrote:
> On Mon, Jan 09, 2012 at 04:47:22PM +0700, Pandu Poluan wrote
>
>> Is it possible to load the firmware blob after booting, from the shell?
>
> I don't think so. These are not standard kernel modules (*.o) files.

You could build the radeon driver as module and load that after booting
via modprobe radeon modeset=1
The firmware then gets loaded from the module.

I do that here because building the driver inside the kernel makes
problems for me.

Greetings

Sebastian Beßler

[Walter Dnes]

This revision removes a couple of steps in the process, so there's
less stuff involved. If only software developers worked that way <G>.

* Busybox stable is now past the buggy version that didn't work with
mdev. There is no need to keyword version 1.19.2

* The virtual/dev-manager-0.ebuild has been modified as per my feature
request to support an mdev-based system. There is no longer any need
for a customized/hacked ebuild in an overlay

The usual warnings apply...
* this is a beta
* use a spare test machine
* if you don't follow the instructions correctly, the result might be
an unbootable linux
* even if you do follow instructions, the result might be an unbootable
linux


1) Set up your kernel to support and automount a devtmpfs filesystem at
/dev

* If you prefer to edit .config directly, set
CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y

* If you prefer "make menuconfig", the route is as shown below. Note
that the "Autount devtmpfs..." option won't appear until you enable
"Maintain a devtmpf..." option.

make menuconfig

Device Drivers --->
Generic Driver Options --->

[*] Maintain a devtmpfs filesystem to mount at /dev
[*] Automount devtmpfs at /dev, after the kernel mounted the rootfs

Once you've made the changes, rebuild the kernel.


2) Set up for emerging busybox. busybox requires the "mdev" flag in
this situation. The "static" flag is probably also a good idea. In
file /etc/portage/package.use add the line

sys-apps/busybox static mdev

Now, "emerge busybox"


3) In the bootloader append line, include "init=/sbin/linuxrc" where
the file /sbin/linuxrc consists of *AT LEAST*...

#!/bin/busybox ash
mount -t proc proc /proc
mount -t sysfs sysfs /sys
exec /sbin/init

This should be enough for most users. If you have an unusual setup,
you may need additional stuff in there. If you're using lilo remember
to re-run lilo to implement the changes.

4) Remove udev from the services list, and replace it with mdev. Type
the following 2 commands at the command line
rc-update del udev sysinit
rc-update add mdev sysinit


5) reboot to your new kernel. You're now running without using udev.


6) ***THIS STEP IS OPTIONAL*** This is only to alay any suspicion that
udev is still in use.

* execute the following command at the commandline
emerge --unmerge sys-fs/udev

* In file /atc/portage/package.mask, append the line
sys-fs/udev
Create the file if it doesn't already exist. You now have a totally
udev-free machine

--
Walter Dnes <walt...@waltdnes.org>

[Pandu Poluan]

Thanks for the update!

I've been mdev-ing my servers, and no problems whatsoever until now (touch wood!).

For those still on the sidelines re: mdev-for-udev, be aware that progress is happening rapidly with regards to what udev feature is 'vital' for modern systems.

Heck, mdev is already perfect for my needs: it can rename devices, fire up a script on hotplug/hotunplug events, load a firmware if told so by the kernel...

I suggest interested people should at least lurk in the busybox mailing list. The mdev-for-udev discussion us quite fresh, patches (not bloats) have been submitted... and we have our very own Walt Dnes in that list, proudly waving the Gentoo banner ;-)

Rgds,

[Walter Dnes]

On Mon, Feb 27, 2012 at 04:49:40PM +0700, Pandu Poluan wrote

> I suggest splitting this step into two:
>
> 3a) Create /sbin/linuxrc containing at least ... chmod ...
>
> 3b) Append "init=/sbin/linuxrc" to bootloader line
>
> Slightly less confusing :-)

OK. I'll modify it as suggested. There is talk on the gentoo-dev
list that mod-utils will be replaced by virtual/mod-utils which will
default to kmod (required to build udev-181). Note that mod-utils and
kmod are mutually exclusive. That should be taken care of in the
ebuilds, but I'll monitor the situation. I may have to modify the setup
instructions for conversion to mdev... i.e. an additional step, removing
kmod and installing mod-utils.

--
Walter Dnes <walt...@waltdnes.org>

[Walter Dnes]

This revision makes 2 changes...

A) The removal of udev is now standard instead of optional. udev-181
and higher will be pulling in kmod, and anything else that kmod depends
on. Removing udev will avoid unnecessary cruft on your machine.

B) Splitting up step 3) into 3a) and 3b) for greater clarity as
requested in user feedback.

3 a) Create /sbin/linuxrc containing at least

#!/bin/busybox ash
mount -t proc proc /proc
mount -t sysfs sysfs /sys
exec /sbin/init

This should be enough for most users. If you have an unusual setup,

you may need additional stuff in there. Remember to
"chmod 744 /sbin/linuxrc" to make it executable.

In the bootloader "append" line, include "init=/sbin/linuxrc". If
you're using lilo remember to re-run lilo to implement the changes. If
you're using another bootloader, make the equivalant initialization.

4) Remove udev from the services list, and replace it with mdev. Type
the following 2 commands at the command line
rc-update del udev sysinit
rc-update add mdev sysinit


5) reboot to your new kernel. You're now running without using udev.

6) Remove udev as per the following instructions...

[Daddy]

Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd?

 

One minor typo to point out:

 

/atc/portage/package.mask should be /etc/portage/package.mask

 

I just joined this list last week, but might consider sacrificing some hardware to join your endeavor if you need more testers.

 

Kindest regards,

Bruce 

[Pandu Poluan]

On Mar 11, 2012 6:30 PM, "Daddy" <da...@happypenguincomputers.com> wrote:
>
> On March 11, 2012 at 5:09 AM Walter Dnes <walt...@waltdnes.org> wrote:
>

> Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd?
>
>  
>
> One minor typo to point out:
>
>  
>
> /atc/portage/package.mask should be /etc/portage/package.mask
>
>  
>
> I just joined this list last week, but might consider sacrificing some hardware to join your endeavor if you need more testers.
>
>  

I'm one of the long-suffering beta-tester for Walt ;-)

I've tested all his procedures (except this one), and up to now found no problems. One caveat: my tests are all on servers (test-dev-staging-production). We -- that is, Gentoo users who want to go udev-less -- will certainly appreciate feedback from desktop users.

Rgds,

[Alan McKinnon]

No, it's his reaction to the fantastical amount of kitchen-sinking
going on surrounding udev. Most specifically, it's the recent
"requirement" foisted on the udev-using community to require
either /usr to be part of / or to use an initramfs.

Walter simply wants to show that mdev is a suitable replacement for
udev in simple environments eg embedded, simple desktops without
complex hotplug requirements, and servers.

Canek will no doubt chip in about how this is the way things are going,
it is inevitable, the boot sequence is becoming complex and various
other rehashings of what's coming out of udev upstream.

However, something needs to be pointed out in that regard. What udev
upstream is saying is probably quite true, but only within the limits
of the environment in which they work and udev is designed to handle -
sophisticated desktops. The three cases I mentioned are perfectly valid
use-cases, comprise a large percentage of the Linux installed base,
should be catered to and have no need of the sophistication current
udev aims to provide.

As such, mdev is a good fit and we can add Walter to the long list of
people before him who selflessly worked to make our software work
better.

>
> One minor typo to point out:
>
> /atc/portage/package.mask should be /etc/portage/package.mask
>
> I just joined this list last week, but might consider sacrificing some
> hardware to join your endeavor if you need more testers.

Welcome to the list, you'll soon get to know all the personalities
here. We have at least one of everything - class clowns, old farts,
newbies, voices of reason, influential devs and even the occasional
fellow who knows what he's talking about.

:-)




--
Alan McKinnnon
alan.m...@gmail.com

[Canek Peláez Valdés]

No, I will not ;)

As I have said before, I admire a lot what Walter et al. are doing,
and as I always will say, this is how our community works: people
writing the code (as Walter is doing) are the ones that get things
done. This is the correct (and only) way to address a problem
(perceived or real) with the current status: write the code that does
the thing the way you want it. Complaining and crying that you don't
like the direction some part of the stack is taking is at best a waste
of time, and at worst idiotic. Actually doing something about it (as
Walter is doing) is the smart thing to do.

I personally will not use Walt's work. Not in my desktop, laptop, nor
in my servers or embedded systems (I don't know if my Media Center
qualifies as "embedded", if I'm truthful); they all run amazingly well
with systemd. But that's my decision: if anybody else wants to go the
mdev route, that's their absolute right.

This is open source: code talks. If anyone with enough interest and
capabilities wants to implement any feature (or anti feature) they
want, they will. That's what Walter is doing, and I sincerely salute
that effort.

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

[Walter Dnes]

On Sun, Mar 11, 2012 at 07:27:05AM -0400, Daddy wrote

> Having personally long considered Lennart Poettering a 'spawn of
> the devil' my question is ... is this your reaction to systemd?

It's my reaction to the "Windows-isation" and "Firefox-isation" of
linux. So far I've managed to keep systemd and hal and dbus and
pulseaudio off my machines. I agree with Linus Torvalds that linux is
getting bloated and huge and scary...
http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux_bloated_huge/

> One minor typo to point out:
>
> /atc/portage/package.mask should be /etc/portage/package.mask

Thanks; fixed now.

> I just joined this list last week, but might consider sacrificing
> some hardware to join your endeavor if you need more testers.

I have a couple of regular desktops here at home, and a desktop
dedicted to my TV, plus a netbook, and a laptop. So far, I've run into
only one situation where laziness on my part ends up requiring udev.
The laptop has an ATI Radeon chip that requires emerging radeon-ucode.
That ebuild simply dumps a bunch of binary blobs into a library folder.
The kernel loads one of the binary blobs at bootup. Radeon-ucode has
blobs for 2 or 3 dozen differnt Radeon GPU models. If I leave all the
binary blobs in the library folder, the kernel needs udev to figure out
which blob to load. But, if I leave only the correct blob for my GPU in
the library folder (move/delete all the others), it loads properly
without any help from udev.

--
Walter Dnes <walt...@waltdnes.org>

[Daddy]

First, my class is old fart. Though I'm always in IRC, mailing lists and forums are more my speed.

 

<story>

 

I built my first PC in 1984, but dropped out of society in totality from 1986 until 1996. In '97 an old PC was given me, then in '98 we bought a bare bones desktop box online and applied some nasty Mickey$oft OS to it. Subsequent hardware failures led me down the path I'm on today.

 

In 1999 a Linux geek where I worked introduced me to RedHat, which couldn't be successfully updated on my dialup connection. To me at that time, it looked like some hobby kit you'd get from Radio Shack.

 

In 2003, while living in China, one of the principles of the privacy service we used out of Virginia convinced me my computer was fast enough, and rather than making a RAID0 with the second drive, to "try Linux". It was RedHat 9.0, and after one month the distro itself sickened me.

 

However, in that length of time I'd found "cdrecord" and various other apps and scripts via CLI ... and seen the ability of Linux to multitask ... and I was hooked. The next few months were spent on Debian, with a kind gentleman from Belgium offering to mentor me. But all he offered, it turned out, were his scripts to do things. One day he just disappeared off the face of the earth.

 

By that time I'd gotten addicted to rebuilding my kernel, especially getting it down to < 1.0MB. And since this guy's "script" was the only way I'd done it, me and Google struck out for the bright, new Linux horizon. Someone had pointed me to "The Cathedral and The Bazaar", also, and my mind was made up. The business model and practices of Mickey$oft and that fruitloop company had opened my eyes to a world I wished I'd never seen, so I was looking for a way out. (They'd stolen, and killed by lawsuit, two particular projects of interest to me.)

 

After a month of reading (primarily some Google groups and LinuxQuestions.org), it seemed that my desires would best be met by (a) LFS, (b) Gentoo, or (c) Slackware. Not wanting to spend so much time compiling from source, not knowing the benefit, and having Gentoo buddies who regularly broke their system and spent more time compiling than I spent awake -- Slackware became my Linux distro. From Nov 2003 until the end of 2010, I was a Slacker.

 

Eventually the Slackware community no longer appealed to me (nicest thing I can say). Most of my time working on projects was spent with the #2 in Slackware via email and IM anyway. 

 

In January 2011 we moved from China back to America. The other big change was my migration to Gentoo.

 

Today we have 1 workstation, 1 server, one PC, and 2 laptops running Gentoo (all but one laptop have no other OS). No devices plugged into our LAN are automounted. 

 

My server is headless and X-less; all the other comps run Fluxbox. IMO there is no need for a desktop environment, but then, we use our computers for work. When we want to play we leave them alone.

 

We opened Happy Penguin Computers 5 months after returning to America, and are still getting established. That's my introduction to this list.

 

</story>

 

We have spare parts so tomorrow I'll build a test machine. My Gentoo knowledge is quite limited, seeing as how we moved back after 9 years and had to start life over. But I can start by following this guide, and probably reading and learning about ebuilds. They're quite different from Slackware's build scripts, primarily due to dependency checking, etc.

 

Kindest regards,

Bruce Hill 

[Daddy]

 

On March 11, 2012 at 3:28 PM Walter Dnes <walt...@waltdnes.org> wrote:

> On Sun, Mar 11, 2012 at 07:27:05AM -0400, Daddy wrote
>
> > Having personally long considered Lennart Poettering a 'spawn of
> > the devil' my question is ... is this your reaction to systemd?
>
>   It's my reaction to the "Windows-isation" and "Firefox-isation" of
> linux.  So far I've managed to keep systemd and hal and dbus and
> pulseaudio off my machines.  I agree with Linus Torvalds that linux is
> getting bloated and huge and scary...
> http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux_bloated_huge/

 

We share the same opinions there. To me the Linux distros have shot their desktops in the foot; instead of getting _better_ than the competition, IMO they've actually gotten worse in the last 5 years.

 

Will joyfully read that from Linus after my nap. (Probably did long ago and forgot it.)

 

> > One minor typo to point out:
> >
> > /atc/portage/package.mask should be /etc/portage/package.mask
>
>   Thanks; fixed now.
>

 

Even when I can't offer code changes, typos are easy (having grown up in the newspaper and printing business).

 

> > I just joined this list last week, but might consider sacrificing
> > some hardware to join your endeavor if you need more testers.
>
>   I have a couple of regular desktops here at home, and a desktop
> dedicted to my TV, plus a netbook, and a laptop.  So far, I've run into
> only one situation where laziness on my part ends up requiring udev.
> The laptop has an ATI Radeon chip that requires emerging radeon-ucode.
> That ebuild simply dumps a bunch of binary blobs into a library folder.
> The kernel loads one of the binary blobs at bootup.  Radeon-ucode has
> blobs for 2 or 3 dozen differnt Radeon GPU models.  If I leave all the
> binary blobs in the library folder, the kernel needs udev to figure out
> which blob to load.  But, if I leave only the correct blob for my GPU in
> the library folder (move/delete all the others), it loads properly
> without any help from udev.
>
> --
> Walter Dnes <walt...@waltdnes.org>
>

iamben in #gentoo on IRC has piqued my interest to build a HTPC. Friday I put a 60G SSD and a 1TB mechanical drive on a board, partitioned the SDD, and d/led stage3 and portage before stopping. That and the earlier mentioned test machine will be my builds for tomorrow. Actually the HTPC is a strange idea, since we don't watch or even own a TV, but it might be a way to sell some of this hardware on my shelf.

 

Kindest regards,

Bruce Hill 

--

sig to come after punching a hole in the LAN and starting mutt on the server 

[David Abbott]

On Sun, Mar 11, 2012 at 3:37 PM, Daddy <da...@happypenguincomputers.com> wrote:

> First, my class is old fart. Though I'm always in IRC, mailing lists and
> forums are more my speed.

[snip]
>
> Kindest regards,
>
> Bruce Hill
Hi Bruce,
You are cordially invited to join the "Gentoo Old Timers Club" [1]
All the best :)
David
[1] http://dev.gentoo.org/~neddyseagoon/docs/oldtimers.xml
--
David Abbott (dabbott)

[Alan McKinnon]

Once you've got the hang of building a Gentoo system from scratch, the
best thing you can do is read all the man pages from portage and seeing
how that compares to what's in simple ebuilds.

ebuilds are quite straightforward, they all have a "global" section (my
phrase) defining various constants, and code sections for fetching,
unpacking, compiling, installing sources and the files to the live
system. Quite simple in concept.

The fun starts when ebuilds work fine and the dev's machine and get
published, but don;t do quite the same thing on your machine :-)



--
Alan McKinnnon
alan.m...@gmail.com

[Alan McKinnon]

My mother swears blind I watched England win the World Cup but I don't
remember (being only 1 year old at the time).

I'm still going to call myself a members (point 5 applies)


--
Alan McKinnnon
alan.m...@gmail.com

[Dale]

Bruce,

Aren't you a bit younger than me? If so, I'm a old fart too. ;-)

[/Bruce]

BTW folks, I have met Bruce, and family, in person and we have talked in
various ways for years. We live about 75 miles apart. My lady friend
ain't geeky so I can't stop by when I'm up that way, plus he moved on me
again. Of course, I'm glad he moved from China and back here tho. Whew!!!

[Walter Dnes]

Correcting a typo pointed out in the earlier post today.

* In file /etc/portage/package.mask, append the line

[Daddy]

Thanks, David. I remember you from LQ.

 

I'm also usually found in ##Neddyseagoon on FreeNode. <:-)}