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 03-13-2012, 07:45 PM
"Walter Dnes"
 
Default Beta test Gentoo with mdev instead of udev; version 6

This revision includes some checking to see if your system can run
without udev. In general, if you use any of...
* GNOME
* KDE
* XFCE
* lvm2
... you probably need udev, so mdev is not for you. I've also found one
situation where I need to take one extra step to run without udev. I
have a laptop with a Radeon GPU that requires a binary blob for the
video driver. emerging radeon-ucode downloads a whole slew of binary
blobs, to support umpteen different models. If I leave all the binary
blobs in the library directory, the kernwl needs udev to figure out
which one of the many binary blobs to load. If I remove all the other
binary blobs, and leave only the correct one in the library directory,
it loads automatically.

There is one more imperfect sanity check you can run to check for udev
dependancy if none of the above apply...

a) add the line
sys-fs/udev
to /etc/portage/package.mask

b) execute the 2 commands
emerge -pv system
emerge -pv world

c) if the only errors you get are for not being able to re-install udev
as required by virtual/dev-manager-0, you can proceed to the next stage,
Otherwise, remove the "sys-fs/udev" line from /etc/portage/package.mask
and forget about mdev.

Proceed here only if the above stages don't find any udev
dependancies.

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

3 b) 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...

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

* In file /etc/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 03-14-2012, 12:15 PM
"J. Roeleveld"
 
Default Beta test Gentoo with mdev instead of udev; version 6

On Tue, March 13, 2012 9:45 pm, Walter Dnes wrote:
> I've also found one
> situation where I need to take one extra step to run without udev. I
> have a laptop with a Radeon GPU that requires a binary blob for the
> video driver. emerging radeon-ucode downloads a whole slew of binary
> blobs, to support umpteen different models. If I leave all the binary
> blobs in the library directory, the kernwl needs udev to figure out
> which one of the many binary blobs to load. If I remove all the other
> binary blobs, and leave only the correct one in the library directory,
> it loads automatically.

Wouldn't a good solution be to have the ebuild modified to only install
those binary blobs you actually need?
Eg. similar to how apache or sane modules are configured?

--
Joost
 
Old 03-14-2012, 08:43 PM
"Walter Dnes"
 
Default Beta test Gentoo with mdev instead of udev; version 6

On Wed, Mar 14, 2012 at 02:15:52PM +0100, J. Roeleveld wrote

> Wouldn't a good solution be to have the ebuild modified to only
> install those binary blobs you actually need? Eg. similar to how
> apache or sane modules are configured?

The tarball on the AMD website has all the binary blobs bundled
together. The ebuild simply downloads the tarball and extracts it to
the correct library directory. You could do it manually. The problem
with separate ebuilds is that one ebuild would be replaced with a couple
of dozen ebuilds, or one ebuild with a couple of dozen custom USE flags.

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 03-14-2012, 09:09 PM
Canek Peláez Valdés
 
Default Beta test Gentoo with mdev instead of udev; version 6

On Wed, Mar 14, 2012 at 3:43 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Wed, Mar 14, 2012 at 02:15:52PM +0100, J. Roeleveld wrote
>
>> Wouldn't a good solution be to have the ebuild modified to only
>> install those binary blobs you actually need? *Eg. similar to how
>> apache or sane modules are configured?
>
> *The tarball on the AMD website has all the binary blobs bundled
> together. *The ebuild simply downloads the tarball and extracts it to
> the correct library directory. *You could do it manually. *The problem
> with separate ebuilds is that one ebuild would be replaced with a couple
> of dozen ebuilds, or one ebuild with a couple of dozen custom USE flags.

You could use an use-expand variable, like INPUT_DEVICES or
VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds
like the smart thing to do.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 03-14-2012, 10:59 PM
"Walter Dnes"
 
Default Beta test Gentoo with mdev instead of udev; version 6

On Wed, Mar 14, 2012 at 04:09:33PM -0600, Canek Pel??ez Vald??s wrote

> You could use an use-expand variable, like INPUT_DEVICES or
> VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds
> like the smart thing to do.

The VIDEO_CARDS variable might be "RADEON", but there are many
different levels of Radeon GPU cards, each requiring its own specific
binary blob.

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 03-14-2012, 11:10 PM
Pandu Poluan
 
Default Beta test Gentoo with mdev instead of udev; version 6

On Mar 15, 2012 7:04 AM, "Walter Dnes" <waltdnes@waltdnes.org> wrote:

>

> On Wed, Mar 14, 2012 at 04:09:33PM -0600, Canek Pel??ez Vald??s wrote

>

> > You could use an use-expand variable, like INPUT_DEVICES or

> > VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds

> > like the smart thing to do.

>

> *The VIDEO_CARDS variable might be "RADEON", but there are many

> different levels of Radeon GPU cards, each requiring its own specific

> binary blob.

>


So, detail it down... e.g. RADEON-HD-4650, RADEON-HD-6530, etc. Kind of like the xtables-addons package.


Rgds,
 
Old 03-14-2012, 11:23 PM
Canek Peláez Valdés
 
Default Beta test Gentoo with mdev instead of udev; version 6

On Wed, Mar 14, 2012 at 5:59 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Wed, Mar 14, 2012 at 04:09:33PM -0600, Canek Pel??ez Vald??s wrote
>
>> You could use an use-expand variable, like INPUT_DEVICES or
>> VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds
>> like the smart thing to do.
>
> *The VIDEO_CARDS variable might be "RADEON", but there are many
> different levels of Radeon GPU cards, each requiring its own specific
> binary blob.

I meant coming up with a new use-expand variable, like RADEON_FIRMWARE
or something like that.

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

Thread Tools




All times are GMT. The time now is 05:21 PM.

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