For discussion of Alpine Linux development and developer support

11 6

[alpine-devel] eudev pushed to git master (edge)

Natanael Copa
Details
Message ID
<20150717115207.72d3a1e6@ncopa-desktop.alpinelinux.org>
Sender timestamp
1437126727
DKIM signature
missing
Download raw message
Hi,

I pushed eudev to the edge repo.

libkmod will not work with busybox dempod (due to it not yet creates
the modules.dep.bin), so I disabled this in eudev, assuming that it
will fall back to fork/exec modprobe instead for modaliases.

It turns out that I was wrong. when built with --disable-libkmod it
does not load any modaliases at all. This result in no /dev/input/*
devices and Xorg "hangs". (does not respond to any input).

For now I have forced starting the hwdrivers. This should at least make
xorg work, but we still do not have proper hotplugging. That is, if you
hotplug a device that needs a driver, it will not automatically be
loaded.

If you currently use udev, you will have to verify that hwdrivers is in
the sysinit runlevel before you reboot. ls -l /etc/runlevels/sysinit
should list a symlink named 'hwdrivers' that points
to /etc/init.d/hwdrivers. You can add this link if its missing with:

  rc-update add hwdrivers sysinit

If you don't use udev then nothing changes.

The longterm fix is to make busbox modprobe generate the needed binary
indexes for libkmod. Hopefully we will have something for that next
week.

We could also depend on kmod's depmod til busybox' depmod is fixed.


-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20150717120738.0058b396@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20150717115207.72d3a1e6@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1437127658
DKIM signature
missing
Download raw message
One more important thing,

When apk upgrade you need to:

 apk del udev
 apk add eudev

I would also recommend disable autostart of xorg for now. eg.

 rc-update del lxdm

At least til all the issues have been fixed.

Thanks!

and sorry...

-nc

On Fri, 17 Jul 2015 11:52:07 +0200
Natanael Copa <ncopa@alpinelinux.org> wrote:

> Hi,
> 
> I pushed eudev to the edge repo.
> 
> libkmod will not work with busybox dempod (due to it not yet creates
> the modules.dep.bin), so I disabled this in eudev, assuming that it
> will fall back to fork/exec modprobe instead for modaliases.
> 
> It turns out that I was wrong. when built with --disable-libkmod it
> does not load any modaliases at all. This result in no /dev/input/*
> devices and Xorg "hangs". (does not respond to any input).
> 
> For now I have forced starting the hwdrivers. This should at least make
> xorg work, but we still do not have proper hotplugging. That is, if you
> hotplug a device that needs a driver, it will not automatically be
> loaded.
> 
> If you currently use udev, you will have to verify that hwdrivers is in
> the sysinit runlevel before you reboot. ls -l /etc/runlevels/sysinit
> should list a symlink named 'hwdrivers' that points
> to /etc/init.d/hwdrivers. You can add this link if its missing with:
> 
>   rc-update add hwdrivers sysinit
> 
> If you don't use udev then nothing changes.
> 
> The longterm fix is to make busbox modprobe generate the needed binary
> indexes for libkmod. Hopefully we will have something for that next
> week.
> 
> We could also depend on kmod's depmod til busybox' depmod is fixed.
> 
> 
> -nc
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Carlo Landmeter
Details
Message ID
<CA+cSEmOD48ogP-BHPR1iM3_Gm5NJiDcPwhWZZ3fCVhrNMyoKbg@mail.gmail.com>
In-Reply-To
<20150717120738.0058b396@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1437212150
DKIM signature
missing
Download raw message
I just tried to update my desktop to latest edge, but im unable to start
slim anymore.
Also my first (or second) monitor has no screen anymore.

I think i was also unable to remove udev because its pulled in by
setup-desktop.
Another issue is, kmod modprobe is not compatible with bb modprobe, it does
not have the -l switch so alsa-utils fails (and probably more init scripts).

I also have the feeling I have to cleanup older (automatic) udev rules,
because my nic name has changed into something weird.
I didnt look into it too much, but i think people should really watch out
with updating edge if they don't want to break anything.


-carlo
Details
Message ID
<20150718192355.GA1999@Caracal>
In-Reply-To
<CA+cSEmOD48ogP-BHPR1iM3_Gm5NJiDcPwhWZZ3fCVhrNMyoKbg@mail.gmail.com> (view parent)
Sender timestamp
1437247436
DKIM signature
missing
Download raw message
On Sat, Jul 18, 2015 at 11:35:50AM +0200, Carlo Landmeter wrote:
> Another issue is, kmod modprobe is not compatible with bb modprobe, it does
> not have the -l switch so alsa-utils fails (and probably more init scripts).

Looking at the manpage on squeeze, I see that module-init-tools had
already marked -l as deprecated in 2012, with the comment to
'see find(1) and basename(1) for a more flexible alternative'.

Honestly, that seems to be a logical change.

Thanks,
Isaac


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Isaac Dunham
Details
Message ID
<20150719204716.GB1862@newbook>
In-Reply-To
<20150717115207.72d3a1e6@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1437338837
DKIM signature
missing
Download raw message
On Fri, Jul 17, 2015 at 11:52:07AM +0200, Natanael Copa wrote:
> Hi,
> 
> I pushed eudev to the edge repo.
> 
> libkmod will not work with busybox dempod (due to it not yet creates
> the modules.dep.bin), so I disabled this in eudev, assuming that it
> will fall back to fork/exec modprobe instead for modaliases.
> 
> It turns out that I was wrong. when built with --disable-libkmod it
> does not load any modaliases at all. This result in no /dev/input/*
> devices and Xorg "hangs". (does not respond to any input).
> 
> For now I have forced starting the hwdrivers. This should at least make
> xorg work, but we still do not have proper hotplugging. That is, if you
> hotplug a device that needs a driver, it will not automatically be
> loaded.

I need to test this, but anyhow...
As far as I can tell, the hotplugging is not hardcoded, but entirely
within rules/80-drivers.rules
If I am correct, you could enable use of Busybox via:

 sed -e 's/RUN{builtin}\(.*\)kmod load/RUN\1modprobe -ab/g' -i \
	"$pkgdir"/lib/udev/rules.d/80-drivers.rules

Testing that might be...interesting, though.
I shall try it once I'm out of mutt.

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Isaac Dunham
Details
Message ID
<20150719214810.GA2207@newbook>
In-Reply-To
<20150719204716.GB1862@newbook> (view parent)
Sender timestamp
1437342490
DKIM signature
missing
Download raw message
On Sun, Jul 19, 2015 at 01:47:16PM -0700, Isaac Dunham wrote:
> On Fri, Jul 17, 2015 at 11:52:07AM +0200, Natanael Copa wrote:
> > Hi,
> > 
> > I pushed eudev to the edge repo.
> > 
> > libkmod will not work with busybox dempod (due to it not yet creates
> > the modules.dep.bin), so I disabled this in eudev, assuming that it
> > will fall back to fork/exec modprobe instead for modaliases.
> > 
> > It turns out that I was wrong. when built with --disable-libkmod it
> > does not load any modaliases at all. This result in no /dev/input/*
> > devices and Xorg "hangs". (does not respond to any input).
> > 
> > For now I have forced starting the hwdrivers. This should at least make
> > xorg work, but we still do not have proper hotplugging. That is, if you
> > hotplug a device that needs a driver, it will not automatically be
> > loaded.
> 
> I need to test this, but anyhow...
> As far as I can tell, the hotplugging is not hardcoded, but entirely
> within rules/80-drivers.rules
> If I am correct, you could enable use of Busybox via:
> 
>  sed -e 's/RUN{builtin}\(.*\)kmod load/RUN\1modprobe -ab/g' -i \
> 	"$pkgdir"/lib/udev/rules.d/80-drivers.rules
> 
> Testing that might be...interesting, though.

OK!
Applied ~ those changes to /{lib=>etc}/udev/rules.d/80-drivers.rules
(I used "busybox modprobe" instead of "modprobe"), then disabled 
interface name mutilation (touch /etc/udev/rules.d/80-net-name-slot.rules),
dropped a symlink to busybox in /lib/udev/ (udev apparently execs
"/lib/udev/<command>" with the command line from the RUN+=... rule).

This apparently works for hotplugging, but coldplugging is not reliable.
Specifically, none of my network drivers were loaded...although they
would have been borked thanks to persistent interface mutilation.
If "mousedev" gets loaded by the initramfs, then coldplugging was probably
completely non-functional.

Thanks,
Isaac Dunham



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: Interface names (WAS: [alpine-devel] eudev pushed to git master (edge))

Isaac Dunham
Details
Message ID
<20150720150820.GA1567@localhost>
In-Reply-To
<20150720095212.238c437b@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1437404901
DKIM signature
missing
Download raw message
On Mon, Jul 20, 2015 at 09:52:12AM +0200, Natanael Copa wrote:
> On Sat, 18 Jul 2015 11:35:50 +0200
> Carlo Landmeter <clandmeter@gmail.com> wrote:
> 
> > I also have the feeling I have to cleanup older (automatic) udev rules,
> > because my nic name has changed into something weird.
> > I didnt look into it too much, but i think people should really watch out
> > with updating edge if they don't want to break anything.
> 
> For the record. As mentioned on IRC, The NIC name change is to get
> persistent and predictable net interface names.
> 
> https://github.com/gentoo/eudev/blob/master/src/udev/udev-builtin-net_id.c#L20

At the latter qualification (predictable) it fails, if you're talking about
mortals.

> To get back the old style names you can do:
> 
>   ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

I'd used "touch", but ln -s /dev/null is probably better since it
also discards future modifications.

> This also means that which NIC becomes eth0 and eth1 etc is
> unpredictable.
> 
> We will need a long term solution for this.
> 
> The problem is that kernel will assign net interface name based on what
> order they are discovered during coldplug. The way we have worked
> around this in Alpine is that we sort the modaliases before doing
> modprobe. That way eth0 will become eth0 every reboot, even after
> kernel upgrades.

Using "sort -u" is also desireable because it means that repeats of the
same hardware only provoke one module load (if you have multiple
USB buses or ethernet cards from the same manufacturer).

> Udev developers has other solution for this problem: invent a new
> naming standard for network interfaces.
> 
> I think we want keep whatever is current for people who are upgrading.
> But for new installs, what do we do? How do we name the network
> interfaces?
> 
> Do we want udev users and non-udev users have same interfaces names, or
> do we want let users who don't want udev keep the old, traditional
> inerface naming and let users who chose udev to get whatever upstream
> udev does?
> 
> How do we make sure that interface names does not change after reboot?
> 
> Do we want be (partially) compatible with other distro's way to name
> interfaces? (even a bad naming standard might be better than no naming
> standard)

I, for one, *do* *NOT* *want* udev-style names.

The kernel developers worked for years on moving from driver-specific
names to "ethN"/"wlanN" interface names. "Predictable" interface naming
a la udev not only reverses those gains, it makes things worse since
anyone who isn't using udev code can't predict interface names even
if they know the driver.
Udev's approach means that if I pull out a network card and replace it,
I have to reconfigure /etc/network/interfaces or whatever else I use.

For what it's worth, Debian Jessie (and Devuan Jessie) use
/lib/udev/write_net_rules to make the kernel name that they detect first
persistent.

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: Interface names (WAS: [alpine-devel] eudev pushed to git master (edge))

Details
Message ID
<1437405731070.2791f84d@Nodemailer>
In-Reply-To
<20150720150820.GA1567@localhost> (view parent)
Sender timestamp
1437405731
DKIM signature
missing
Download raw message
I'd also like to see us stick with ethX / wlanX naming convention if possible



—
Sent from Mailbox

On Mon, Jul 20, 2015 at 4:08 PM, Isaac Dunham <ibid.ag@gmail.com> wrote:

> On Mon, Jul 20, 2015 at 09:52:12AM +0200, Natanael Copa wrote:
>> On Sat, 18 Jul 2015 11:35:50 +0200
>> Carlo Landmeter <clandmeter@gmail.com> wrote:
>> 
>> > I also have the feeling I have to cleanup older (automatic) udev rules,
>> > because my nic name has changed into something weird.
>> > I didnt look into it too much, but i think people should really watch out
>> > with updating edge if they don't want to break anything.
>> 
>> For the record. As mentioned on IRC, The NIC name change is to get
>> persistent and predictable net interface names.
>> 
>> https://github.com/gentoo/eudev/blob/master/src/udev/udev-builtin-net_id.c#L20
> At the latter qualification (predictable) it fails, if you're talking about
> mortals.
>> To get back the old style names you can do:
>> 
>>   ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
> I'd used "touch", but ln -s /dev/null is probably better since it
> also discards future modifications.
>> This also means that which NIC becomes eth0 and eth1 etc is
>> unpredictable.
>> 
>> We will need a long term solution for this.
>> 
>> The problem is that kernel will assign net interface name based on what
>> order they are discovered during coldplug. The way we have worked
>> around this in Alpine is that we sort the modaliases before doing
>> modprobe. That way eth0 will become eth0 every reboot, even after
>> kernel upgrades.
> Using "sort -u" is also desireable because it means that repeats of the
> same hardware only provoke one module load (if you have multiple
> USB buses or ethernet cards from the same manufacturer).
>> Udev developers has other solution for this problem: invent a new
>> naming standard for network interfaces.
>> 
>> I think we want keep whatever is current for people who are upgrading.
>> But for new installs, what do we do? How do we name the network
>> interfaces?
>> 
>> Do we want udev users and non-udev users have same interfaces names, or
>> do we want let users who don't want udev keep the old, traditional
>> inerface naming and let users who chose udev to get whatever upstream
>> udev does?
>> 
>> How do we make sure that interface names does not change after reboot?
>> 
>> Do we want be (partially) compatible with other distro's way to name
>> interfaces? (even a bad naming standard might be better than no naming
>> standard)
> I, for one, *do* *NOT* *want* udev-style names.
> The kernel developers worked for years on moving from driver-specific
> names to "ethN"/"wlanN" interface names. "Predictable" interface naming
> a la udev not only reverses those gains, it makes things worse since
> anyone who isn't using udev code can't predict interface names even
> if they know the driver.
> Udev's approach means that if I pull out a network card and replace it,
> I have to reconfigure /etc/network/interfaces or whatever else I use.
> For what it's worth, Debian Jessie (and Devuan Jessie) use
> /lib/udev/write_net_rules to make the kernel name that they detect first
> persistent.
> Thanks,
> Isaac Dunham
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
Natanael Copa
Details
Message ID
<20150720082818.3b8e770e@ncopa-desktop.alpinelinux.org>
In-Reply-To
<CA+cSEmOD48ogP-BHPR1iM3_Gm5NJiDcPwhWZZ3fCVhrNMyoKbg@mail.gmail.com> (view parent)
Sender timestamp
1437373698
DKIM signature
missing
Download raw message
On Sat, 18 Jul 2015 11:35:50 +0200
Carlo Landmeter <clandmeter@gmail.com> wrote:

> I just tried to update my desktop to latest edge, but im unable to start
> slim anymore.
> Also my first (or second) monitor has no screen anymore.
> 
> I think i was also unable to remove udev because its pulled in by
> setup-desktop.

While testing, using old udev didnt work at all. I have fixed
alpine-desktop dep to use eudev.

> Another issue is, kmod modprobe is not compatible with bb modprobe, it does
> not have the -l switch so alsa-utils fails (and probably more init scripts).

The plan is to fix busybox depmod so we can use busybox utils instead
of hard depndency of kmod.

That said, it is probably a good idea to fix alsa-utils too.

> I also have the feeling I have to cleanup older (automatic) udev rules,
> because my nic name has changed into something weird.

I got other report of that too:

>> after updating my alpine linux edge, wlan0 became wlp18s0b1

I don't know why or how to fix it.

> I didnt look into it too much, but i think people should really watch out
> with updating edge if they don't want to break anything.

Yes. This was a risky upgrade. But upgrading udev has always been
risky. For a while things broke for almost every udev upgrade, which is
the reason we stayed on the old udev-175 for years without upgrading.

We need move forward though.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20150720083242.78af0196@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20150719204716.GB1862@newbook> (view parent)
Sender timestamp
1437373962
DKIM signature
missing
Download raw message
On Sun, 19 Jul 2015 13:47:17 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> As far as I can tell, the hotplugging is not hardcoded, but entirely
> within rules/80-drivers.rules
> If I am correct, you could enable use of Busybox via:
> 
>  sed -e 's/RUN{builtin}\(.*\)kmod load/RUN\1modprobe -ab/g' -i \
> 	"$pkgdir"/lib/udev/rules.d/80-drivers.rules

This looks interesting.

I ended up pulling in kmod's modprobe/demopd as a hard dep for now, at
least til we have fixed busybox's depmod.

> Testing that might be...interesting, though.
> I shall try it once I'm out of mutt.
> 
> Thanks,
> Isaac Dunham

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Interface names (WAS: [alpine-devel] eudev pushed to git master (edge))

Natanael Copa
Details
Message ID
<20150720095212.238c437b@ncopa-desktop.alpinelinux.org>
In-Reply-To
<CA+cSEmOD48ogP-BHPR1iM3_Gm5NJiDcPwhWZZ3fCVhrNMyoKbg@mail.gmail.com> (view parent)
Sender timestamp
1437378732
DKIM signature
missing
Download raw message
On Sat, 18 Jul 2015 11:35:50 +0200
Carlo Landmeter <clandmeter@gmail.com> wrote:

> I also have the feeling I have to cleanup older (automatic) udev rules,
> because my nic name has changed into something weird.
> I didnt look into it too much, but i think people should really watch out
> with updating edge if they don't want to break anything.

For the record. As mentioned on IRC, The NIC name change is to get
persistent and predictable net interface names.

https://github.com/gentoo/eudev/blob/master/src/udev/udev-builtin-net_id.c#L20

To get back the old style names you can do:

  ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

This also means that which NIC becomes eth0 and eth1 etc is
unpredictable.

We will need a long term solution for this.

The problem is that kernel will assign net interface name based on what
order they are discovered during coldplug. The way we have worked
around this in Alpine is that we sort the modaliases before doing
modprobe. That way eth0 will become eth0 every reboot, even after
kernel upgrades.

Udev developers has other solution for this problem: invent a new
naming standard for network interfaces.

I think we want keep whatever is current for people who are upgrading.
But for new installs, what do we do? How do we name the network
interfaces?

Do we want udev users and non-udev users have same interfaces names, or
do we want let users who don't want udev keep the old, traditional
inerface naming and let users who chose udev to get whatever upstream
udev does?

How do we make sure that interface names does not change after reboot?

Do we want be (partially) compatible with other distro's way to name
interfaces? (even a bad naming standard might be better than no naming
standard)

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: Interface names (WAS: [alpine-devel] eudev pushed to git master (edge))

Kevin Chadwick
Details
Message ID
<20150721230516.11cb6850@expedite.oesys.co>
In-Reply-To
<20150720150820.GA1567@localhost> (view parent)
Sender timestamp
1437516316
DKIM signature
missing
Download raw message
On Mon, 20 Jul 2015 08:08:21 -0700
Isaac Dunham wrote:

> I, for one, *do* *NOT* *want* udev-style names.
> 
> The kernel developers worked for years on moving from driver-specific
> names to "ethN"/"wlanN" interface names. "Predictable" interface naming
> a la udev not only reverses those gains,

Interesting, I never knew Linux used to have them. I've always
considered OpenBSD's driver related names as a superior mechanism but
then they have high quality man pages that make you appreciate it. I
believe they order them by PCI location so you can even be sure of the
order physically.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/rl.4?query=rl
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/bge.4?query=bge
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/fxp.4?query=fxp


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---