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-11-2012, 08:09 AM
"Walter Dnes"
 
Default Beta test Gentoo with mdev instead of udev; version 5

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.

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.

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 /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 03-11-2012, 10:27 AM
Daddy
 
Default Beta test Gentoo with mdev instead of udev; version 5

On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@waltdnes.org> wrote:




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


>


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


>


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


>

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

On Mar 11, 2012 6:30 PM, "Daddy" <daddy@happypenguincomputers.com> wrote:

>

> On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@waltdnes.org> wrote:

>

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

> >

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

> >

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

> >

>

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

On Sun, 11 Mar 2012 07:27:05 -0400 (EDT)
Daddy <daddy@happypenguincomputers.com> wrote:

> On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@waltdnes.org>
> wrote:
>
> > 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.
> >
> > 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.
> >
> > 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 /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>
> >
>
> Having personally long considered Lennart Poettering a 'spawn of the
> devil' my question is ... is this your reaction to systemd?


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.mckinnon@gmail.com
 
Old 03-11-2012, 05:39 PM
Canek Peláez Valdés
 
Default Beta test Gentoo with mdev instead of udev; version 5

On Sun, Mar 11, 2012 at 8:17 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Sun, 11 Mar 2012 07:27:05 -0400 (EDT)
> Daddy <daddy@happypenguincomputers.com> wrote:
>
>> On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@waltdnes.org>
>> wrote:
>>
>> > * 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.
>> >
>> > * 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.
>> >
>> > *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 /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>
>> >
>>
>> Having personally long considered Lennart Poettering a 'spawn of the
>> devil' my question is ... is this your reaction to systemd?
>
>
> 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.

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
 
Old 03-11-2012, 06:28 PM
"Walter Dnes"
 
Default Beta test Gentoo with mdev instead of udev; version 5

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 <waltdnes@waltdnes.org>
 
Old 03-11-2012, 06:37 PM
Daddy
 
Default Beta test Gentoo with mdev instead of udev; version 5

On March 11, 2012 at 10:17 AM Alan McKinnon <alan.mckinnon@gmail.com> wrote:




> On Sun, 11 Mar 2012 07:27:05 -0400 (EDT)


> Daddy <daddy@happypenguincomputers.com> wrote:


>


> > On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@waltdnes.org>


> > wrote:


> >


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


> > >


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


> > >


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


> > >


> >


> > Having personally long considered Lennart Poettering a 'spawn of the


> > devil' my question is ... is this your reaction to systemd?


>


>


> 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.mckinnon@gmail.com

*

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*
 
Old 03-11-2012, 06:49 PM
Daddy
 
Default Beta test Gentoo with mdev instead of udev; version 5

*





On March 11, 2012 at 3:28 PM Walter Dnes <waltdnes@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 <waltdnes@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*
 
Old 03-11-2012, 07:10 PM
David Abbott
 
Default Beta test Gentoo with mdev instead of udev; version 5

On Sun, Mar 11, 2012 at 3:37 PM, Daddy <daddy@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)
 
Old 03-11-2012, 07:27 PM
Alan McKinnon
 
Default Beta test Gentoo with mdev instead of udev; version 5

On Sun, 11 Mar 2012 15:37:26 -0400 (EDT)
Daddy <daddy@happypenguincomputers.com> wrote:

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

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.mckinnon@gmail.com
 

Thread Tools




All times are GMT. The time now is 01:31 AM.

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