Mailing List Archive

1 2 3  View All
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
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

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"
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
On Jan 6, 2012 8:50 AM, "Dale" <rdalek1967@gmail.com> wrote:
>
> 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
>

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

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

Rgds,
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
Pandu Poluan wrote:
>
>
> On Jan 6, 2012 8:50 AM, "Dale" <rdalek1967@gmail.com
> <mailto:rdalek1967@gmail.com>> wrote:
> >
> > 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
> >
>
> mdev is capable of renaming devices, you know ;-)
>
> https://svn.mcs.anl.gov/repos/ZeptoOS/trunk/BGP/packages/busybox/src/docs/mdev.txt
>
> Rgds,
>

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.

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"
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
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
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
On Jan 6, 2012 10:04 AM, "pk" <peterk2@coolmail.se> wrote:
>
> 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...
>

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,
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
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 <waltdnes@waltdnes.org>
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
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
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
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 <waltdnes@waltdnes.org>
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
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
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
On Jan 9, 2012 3:24 PM, "pk" <peterk2@coolmail.se> wrote:
>
> 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
>

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

Rgds,
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
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
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
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 <waltdnes@waltdnes.org>
Re: Re: Beta test Gentoo with mdev instead of udev; version 3 [ In reply to ]
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
Re: Re: Beta test Gentoo with mdev instead of udev; version 4 [ In reply to ]
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 <waltdnes@waltdnes.org>
Re: Re: Beta test Gentoo with mdev instead of udev; version 4 [ In reply to ]
On Feb 18, 2012 6:46 AM, "Walter Dnes" <waltdnes@waltdnes.org> wrote:
>
> 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
>

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,
Re: Re: Beta test Gentoo with mdev instead of udev; version 4 [ In reply to ]
On Sat, Feb 18, 2012 at 06:40, Walter Dnes <waltdnes@waltdnes.org> wrote:
>

---- >8 snip

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

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

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

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan
Re: Re: Beta test Gentoo with mdev instead of udev; version 4 [ In reply to ]
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 <waltdnes@waltdnes.org>

1 2 3  View All