# Gentoo without udev? - OpenRC / netifrc problem

## vyedmic

Hello,

Please excuse my n00biness.

Here's my problem:

I rent a Xen based VPS with SolusVM Gentoo image. I was not successful in upgrading the kernel and since the hosting provider is obviously not swamped by requests for Gentoo (I discovered that their Gentoo image was corrupted originally...) I don't feel the urge to try and bother them with helping me to create another image. The problem is the supplied kernel doesn't do devtmpfs. Therefore I am stuck on the supplied udev (which is 171-9). 

The issue is that I can't update OpenRC, since the network scripts have been moved into netifrc, and that requires newer udev. 

Is it possible to run a Gentoo server without udev? Will the /dev get populated by kernel? Should there be a support for systems with older versions of udev in OpenRC? Shall I just be done with it and never update @world?

Thanks for reading and any feedback.

----------

## John R. Graham

Why can't you update openrc?

- John

----------

## vyedmic

Because I lost my network scripts when I tried. They are now part of netifrc and that needs udev higher than 171-9.

----------

## khayyam

 *vyedmic wrote:*   

> Because I lost my network scripts when I tried. They are now part of netifrc and that needs udev higher than 171-9.

 

vyedmic ... actually thats not the case at all, I don't have udev installed but have netifrc. You will need some package providing virtual/dev-manager, but there is no explict requirement for udev.

best ... khay

----------

## vyedmic

Thanks khay. I'll do more research.

----------

## khayyam

 *vyedmic wrote:*   

> Thanks khay. I'll do more research.

 

vyedmic ... you're welcome, but I'm undeserving as there may actually be a dependency for > 171-9 if udev is installed (as it is, obviously), probably as openrc wants to pull in an update to udev-init-scripts.

best ... khay

----------

## Cyker

Can you use eudev instead?

----------

## vyedmic

If I'm not mistaken, eudev needs devtmpfs too.

After researching static-dev a little bit and looking at the /dev on this host I gave up and hardmasked >udev-171-r9, eudev, systemd, >openrc-0.11.8 and kmod. Let's see how long I will be able to keep on updating. Thanks a lot for suggestions.

----------

## NeddySeagoon

vyedmic,

You can have a static /dev on a server, then throw away udev.

However, I don't think you can do the switch without booting some rescue environment.

Its devtmpfs in the kernel that populates /dev. udev only manages /dev permissions and ods and ends.

You might have a static /dev under your udev /dev.  Gentoo used to provide that.

However it will not contain /dev/sd* entries, so you cannot just use it.

----------

## bstaletic

 *NeddySeagoon wrote:*   

> However it will not contain /dev/sd* entries, so you cannot just use it.

 

Can a user just symlink block devices under static dev to /dev/sd*?

----------

## NeddySeagoon

bstaletic,

No, you need to make /dev special entries in /dev with mknod.

Until the entries exist, there is nothing to symlink to.

----------

## bstaletic

That part is obvious. When you finish creating devices using mknod could you make appropriate symlinks to be able to use /dev/sd*?

----------

## NeddySeagoon

bstaletic,

I do not understand why you would want symlinks.  I have a static /dev.  A piece of it looks like

```
 $ ls -l /dev/sd*

brw-rw---- 1 root disk 8,   0 May 12  2013 /dev/sda

brw-rw---- 1 root disk 8,   1 May 12  2013 /dev/sda1

brw-rw---- 1 root disk 8,   2 May 12  2013 /dev/sda2

brw-rw---- 1 root disk 8,   4 May 12  2013 /dev/sda4

brw-rw---- 1 root disk 8,   5 May 12  2013 /dev/sda5

brw-rw---- 1 root disk 8,   6 May 12  2013 /dev/sda6
```

The dates are when I ran mknod to make those nodes.

----------

## bstaletic

 *NeddySeagoon wrote:*   

> However it will not contain /dev/sd* entries, so you cannot just use it.

 

I have missunderstood this as you can not have /dev/sd* with static dev only. First thing I have thought of are symlinks to solve this. I now understand there's no need for this kind of symlinks symlinks.

----------

## NeddySeagoon

bstaletic,

The problem is that the default static /dev provided by gentoo is out of date by many years.

Its no use as is with current hardware.  It can be fixed ... I've done it.

----------

## UberLord

 *NeddySeagoon wrote:*   

> bstaletic,
> 
> The problem is that the default static /dev provided by gentoo is out of date by many years.
> 
> Its no use as is with current hardware.  It can be fixed ... I've done it.

 

Sure it can, but why should the users have to do this?

I for one, would kill for a static /dev like my NetBSD boxes.

Somehow it manages plug n play USB sticks without udev, but that's another story  :Wink: 

----------

## Ant P.

On my server, I use devtmpfs. On its own! Everything works fine, I don't get magic disk ID symlinks but I don't need them anyway.

I had to lie to portage to achieve that (USE=mdev, followed by not using mdev); apparently it doesn't trust the kernel to identify its own devices accurately...

----------

## khayyam

 *Ant P. wrote:*   

> On my server, I use devtmpfs. On its own! Everything works fine, I don't get magic disk ID symlinks but I don't need them anyway.

 

Ant P. ... I wasn't aware that that was an option, so good to know.

 *Ant P. wrote:*   

> I had to lie to portage to achieve that (USE=mdev, followed by not using mdev); apparently it doesn't trust the kernel to identify its own devices accurately...

 

That's cheating ;)

best ... khay

----------

## NeddySeagoon

UberLord,

I started playing with a static /dev when the udev source tree got merged inte systemd. At that time, it appeared that udev didn't have long to live as a usable seperate entitiy.

I have a strong preference for a systemd free system (this in the wrong thread to go into details) and I was curious to see how much of Linux still worked without a device manager of any sort.  A trip dowm memory lane, if you like.

The problem with updating the static-dev ebuild is always what do you include. sd* is easy.

What about /dev/md*?

With or without partitions?

dm*  ?

Then there is the virtio nodes ... where do you stop?

Users wanting a more complex setup need to make their own nodes and symlinks, sd* is an easy practice case.       

@Ant P.

devtmpfs alone works but the permissions on the /dev nodes are left as created by the kernel, since you don't have a device manager to fix them.

You might want to look into that.

----------

## Anon-E-moose

 *NeddySeagoon wrote:*   

> @Ant P.
> 
> devtmpfs alone works but the permissions on the /dev nodes are left as created by the kernel, since you don't have a device manager to fix them.
> 
> You might want to look into that.

 

Sounds like all that's needed is for some process to periodically update the permissions 

and then one has most of what udev is supposed to do without all the politics that are associated with it.

Thanks for the info, Ant and Neddy

----------

## NeddySeagoon

Anon-E-moose,

Like /sbin/hotplug  :)

I've not exhumed that yet.

----------

## Ant P.

 *NeddySeagoon wrote:*   

> @Ant P.
> 
> devtmpfs alone works but the permissions on the /dev nodes are left as created by the kernel, since you don't have a device manager to fix them.
> 
> You might want to look into that.

 

You're right - almost everything in there is mode 600 root:root, except for a few things like [u]random and zero/null/full. I wouldn't recommend it to anyone with a monitor as the same goes for the DRI nodes. Nothing on that machine needs hardware (except eth0 and a serial console) though, so "the defaults" are good enough for me.

I haven't noticed any breakage specific to that setup, so far.

----------

## eflothmeier

See:

https://forums.gentoo.org/viewtopic-t-985832-start-0.html

A quote from one of the posts:

"This is part of the process to isolate netifrc completely to net-misc/netifrc 

and to it's own repository, out from openrc, out from udev-init-scripts"

In my case I have a block as a result of a portage tree update:

,

,

,

[ebuild     U  ] sys-apps/openrc-0.13.9 [0.12.4]

[blocks B      ] <sys-fs/udev-init-scripts-27 ("<sys-fs/udev-init-scripts-27" is blocking sys-apps/openrc-0.13.9)

,

,

The solution was to modify package.mask:

.

.

>sys-apps/openrc-0.12.4

.

.

Now

  sys-fs/udev-init-scripts-27

and

  sys-apps/openrc-0.13.9)

have disappeared for the slate of merges

Am I "sweeping dirt under the carpet"?

Will this come back to haunt me later?

Erich

----------

## NeddySeagoon

eflothmeier,

Yes.  You are sweeping dirt under the carpet.

 *Quote:*   

> The solution was to modify package.mask:
> 
> >sys-apps/openrc-0.12.4 

 says, I have put a blindfold on and don't want to see newer packages of openrc.

Here

```
 [ebuild U ] sys-apps/openrc-0.13.9 [0.12.4]

[blocks B ] <sys-fs/udev-init-scripts-27 ("<sys-fs/udev-init-scripts-27" is blocking sys-apps/openrc-0.13.9) 
```

the hint to the fix is in the block message.

Specifically <sys-fs/udev-init-scripts-27 so you need to update to at least sys-fs/udev-init-scripts-27 to avoid the block.

```
emerge -1 sys-fs/udev-init-scripts
```

should do that after you remove the package mask entry.

Homework: Why the -1?

What does it do and why do you need it?

----------

## eflothmeier

I bet you're tired of telling people about

emerge -1. I searched the wiki and, so far,

haven't found any documentation on this 

technique. The section of the Gentoo

handbook "when portage is complaining"

doesn't say anyting directly about it either.

Moreover, if one were to wholesale do

installs with emerge -1, that would be 

damaging too.

Anyway, thanks for the tip

Erich

----------

