FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 12-01-2011, 06:45 PM
"Walter Dnes"
 
Default Beta test Gentoo with mdev instead of udev; version 3

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.

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

#!/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. udev is pulled in by virtual/dev-manager,
which in turn is pulled in by the kernel.

* 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 )"
############################################

* 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 <waltdnes@waltdnes.org>
 
Old 12-01-2011, 11:23 PM
Pandu Poluan
 
Default Beta test Gentoo with mdev instead of udev; version 3

On Dec 2, 2011 2:50 AM, "Walter Dnes" <waltdnes@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,
 
Old 01-03-2012, 09:04 AM
"Walter Dnes"
 
Default Beta test Gentoo with mdev instead of udev; version 3

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 <waltdnes@waltdnes.org>
 
Old 01-03-2012, 09:22 AM
Pandu Poluan
 
Default Beta test Gentoo with mdev instead of udev; version 3

On Tue, Jan 3, 2012 at 17:04, Walter Dnes <waltdnes@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!

> *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?)

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

*• LOPSA Member #15248
*• Blog : http://pepoluan.tumblr.com
*• Linked-In : http://id.linkedin.com/in/pepoluan
 
Old 01-03-2012, 11:32 AM
Nicolas Sebrecht
 
Default Beta test Gentoo with mdev instead of udev; version 3

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
 
Old 01-03-2012, 11:48 AM
Pandu Poluan
 
Default Beta test Gentoo with mdev instead of udev; version 3

On Jan 3, 2012 7:35 PM, "Nicolas Sebrecht" <nsebrecht@piing.fr> wrote:

>

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

>


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,
 
Old 01-03-2012, 12:13 PM
Nicolas Sebrecht
 
Default Beta test Gentoo with mdev instead of udev; version 3

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.

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
 
Old 01-03-2012, 12:18 PM
Alan McKinnon
 
Default Beta test Gentoo with mdev instead of udev; version 3

On Tue, 3 Jan 2012 13:32:09 +0100
Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

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

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.mckinnon@gmail.com
 
Old 01-03-2012, 12:36 PM
Nicolas Sebrecht
 
Default Beta test Gentoo with mdev instead of udev; version 3

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
 
Old 01-03-2012, 12:42 PM
Pandu Poluan
 
Default Beta test Gentoo with mdev instead of udev; version 3

On Tue, Jan 3, 2012 at 20:13, Nicolas Sebrecht <nsebrecht@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.

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

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

Thread Tools




All times are GMT. The time now is 03:30 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org