Re: [gentoo-user] udev upgrade 208 > 212-r1, openrc USE flag changed to disabled?
On 14/06/2014 15:30, Tanstaafl wrote:
> Is this right?
>
>> # eix udev
>> ...
>> [U] sys-fs/udev
>> Available versions: 208-r1^t 212-r1^t ~213^t **^t {acl doc
>> +firmware-loader gudev introspection +kmod selinux static-libs
>> ABI_MIPS="n32 n64 o32" ABI_X86="32 64 x32"}
>> Installed versions: 208^t{tbz2}(03:30:13 PM 12/08/2013)(acl
>> firmware-loader kmod openrc -doc -gudev -introspection -selinux
>> -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_X86="64 -32 -x32")
>> Homepage:
>> http://www.freedesktop.org/wiki/Software/systemd
>> Description: Linux dynamic and persistent device naming
>> support (aka userspace devfs)
> ...
>
> Installed version shows the openrc USE flag, new version doesn't.
>
> And more importantly:
>
>> # emerge -pvuDN udev
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>> [ebuild U ] sys-apps/kmod-17 [16] USE="tools zlib -debug -doc
>> -lzma -python% -static-libs (-openrc%*)" PYTHON_TARGETS="python2_7%*
>> python3_3%* -python3_2% (-python3_4)" 1,450 kB
>> [ebuild U ] sys-fs/udev-212-r1 [208] USE="acl firmware-loader
>> kmod -doc -gudev -introspection (-selinux) -static-libs (-openrc%*)"
>> ABI_X86="(64) (-32) (-x32)" 2,660 kB
>> [ebuild N ] virtual/libudev-208:0/1 USE="-static-libs"
>> ABI_X86="(64) (-32) (-x32)" 0 kB
>> [ebuild U ] virtual/udev-208-r2 [208-r1] USE="-gudev
>> -introspection -static-libs (-kmod%*) (-selinux%)" ABI_X86="(64) (-32)
>> (-x32)" 0 kB
>> [ebuild U ] sys-fs/udev-init-scripts-26-r2 [26] 0 kB
>>
>> Total: 5 packages (4 upgrades, 1 new), Size of downloads: 4,110 kB
>
> This clearly shows the -openrc USE flag being applied.
You read it wrong. The USE flag is not being applied it's being removed
(the minus "-"), and the reason it is being removed is that it doesn't
exist for the new ebuild. That's what the parenthesis means.
>
> Googling didn't reveal an answer...
It's in the emerge man page. If not there, is one of the man pages from
portage
>
>
>
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-user] how do I resolve udev145 masked issue?
On Sunday 02 August 2009 13:31:41 John covici wrote: > on Sunday 08/02/2009 Neil Bothwick(n...@digimed.co.uk) wrote > > > On Sun, 2 Aug 2009 04:45:46 -0400, John covici wrote: > > > > run the emerge with the -t option to see what is pulling in > > > > udev- > > > > > > I get the same thing if I emerge udev145, so its not unique to 999. > > > > That's because both are masked, it doesn't have any bearing on the > > reason for udev- being wanted. > > OK, here is emerge with the same options with the -t added > > Script started on Sun Aug 2 07:27:20 2009 > > These are the packages that would be merged, in reverse order: > > Calculating dependencies ... done! > > !!! All ebuilds that could satisfy ">=sys-fs/udev-145[extras]" have been > masked. !!! One of the following masked packages is required to complete > your request: - sys-fs/udev- (masked by: package.mask, missing keyword) > /usr/portage/profiles/package.mask: > # Matthias Schwarzott (3 Jul 2009) > # It needs libblkid provided by util-linux-2.16 not yet released > > - sys-fs/udev-145 (masked by: package.mask) > > For more information, see the MASKED PACKAGES section in the emerge > man page or refer to the Gentoo Handbook. > (dependency required by "sys-apps/devicekit-power-010" [ebuild]) > (dependency required by "gnome-extra/gnome-power-manager-2.26.3" [ebuild]) > (dependency required by "gnome-base/gnome-2.26.3" [ebuild]) > (dependency required by "@world" [argument]) emerge -t is not completing because of udev. You will have to deal with that to get emerge to progress to the point where it will display the build try. Put an entry for udev into package.unmask and re-run emerge with -p and -t to find what pulls in udev-. Fix that so it doesn;t do it anymore, remove the temporary package.unmask and run emerge for real. But first, these are basic fundamental gentoo and portage operations. They fall in the class of "stuff you need to know to get anything done at all if circumstances are unusual". So first, you should be reviewing the portage sections in the Gentoo handbook till you understand it all. Some things cannot be done on a wing and a prayer, this is one of them. -- alan dot mckinnon at gmail dot com
[gentoo-user] sys-fs/udev-171-r1 dependency conflict
I just updated the portage tree. But there seems to be a dependency conflict when I try to update the system. This is the first time I encounter this kind of problem. Could you guys help me out? Thanks in advance^_^ --- $ sudo emerge -avuDN world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ~] sys-kernel/gentoo-sources-2.6.39-r1 [2.6.39] USE="-build -deblob -symlink" 72 kB [ebuild U ] dev-libs/libdbusmenu-qt-0.8.2 [0.6.2] USE="-debug -doc% -test" 36 kB [ebuild U ~] sys-fs/udev-171-r1 [151-r4] USE="acl%* gudev%* hwdb%* keymap%* rule_generator%* -action_modeswitch% -debug% -edd% -floppy% (-introspection) (-selinux) -test (-devfs-compat%) (-extras%*) (-old-hd-rules%)" 595 kB [ebuild U ] net-ftp/lftp-4.2.3 [4.1.3] USE="nls ssl -gnutls -socks5" 1,296 kB [ebuild U ~] media-sound/pulseaudio-0.9.22-r2 [0.9.22] USE="X alsa asyncns bluetooth caps dbus glib ipv6 tcpd udev -avahi -doc -gnome -jack -libsamplerate -lirc (-oss) -realtime (-system-wide) -test" 0 kB [ebuild U ~] sys-fs/udisks-1.0.2-r4 [1.0.2-r1] USE="nls -bash-completion -debug -doc -remote-access" 0 kB Total: 6 packages (5 upgrades, 1 in new slot), Size of downloads: 1,997 kB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: sys-fs/udev:0 (sys-fs/udev-171-r1::gentoo, ebuild scheduled for merge) pulled in by >=sys-fs/udev-171[hwdb] required by (media-sound/pulseaudio-0.9.22-r2::gentoo, ebuild scheduled for merge) (sys-fs/udev-151-r4::gentoo, installed) pulled in by >=sys-fs/udev-147[extras] required by (sys-fs/udisks-1.0.2-r4::gentoo, ebuild scheduled for merge) (and 3 more with the same problem) It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. You may want to try a larger value of the --backtrack option, such as --backtrack=30, in order to see if that will solve this conflict automatically. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. -- Best Regards, Einux
Re: [gentoo-user] /dev/sda* missing at boot
On Fri, 9 Sep 2011 07:24:06 PM pk wrote:
> On 2011-09-09 10:53, Dale wrote:
> > Can I slap whoever started this? The more I think on this, the worse it
>
> Yes Dale, you have my permission! And while you're at it, slap him from
> me too! ;-)
>
> It _may_ be this guy that's responsible for this crap:
> http://linuxplumbersconf.org/ocw/users/58
>
> Also:
> http://comments.gmane.org/gmane.linux.hotplug.devel/16994
I've had a look at the stuff at those links, and some of what they link to in
turn, and had a bit of a think about it.
Looking at "initramfs" as a modern Linux replacement for the "bootable /
partition" of traditional Unix systems does make some sense, even though I
think it could be made simpler.
Fot those opposed to initramfs, would you also object to /boot being
1) a manditory seperate partition
2) required to be ext2 (or one of a *very* short list)
3) having /boot/{bin,sbin,lib} containing local copies of the absolute
minimum boot requirements (i.e. initramfs in a real fs)
On the other hand, most of the problem seems to stem from software packages
hooking into the early boot via udev rules, and not beiong careful where they
put the executables and libraries that they reference.
Is udev (as it currently stands) really the best place for them to hook into?
Could udev be split into 2 passes, early-boot udev that only does system stuff
(like mount filesystems out of /etc/fstab, setup keyboards & video), and late-
boot udev where other applications can put in any hooks they like, since the
full system would then be available.
The late-boot udev may need to do a full rescan of everything that early-boot
udev found, but didn't have the rules for yet, but I'm sure that the 2 passes
could talk to each other and sort that out fairly simply.
Or possibly just add a whole new service to use just for hooking software
packages into system events. Although this would probably end upneeding to be
a udev clone anyway.
--
Reverend Paul Colquhoun, ULC.http://andor.dropbear.id.au/~paulcol
Before you criticize someone, you should walk a mile in their shoes.
Then, when you do, you'll be a mile away, and you'll have their shoes.
Re: [gentoo-user] /dev/sda* missing at boot
On 9/10/2011 5:28 PM, Alan McKinnon wrote: On Sat, 10 Sep 2011 12:19:10 -0400 Michael Mol wrote: On Sat, Sep 10, 2011 at 12:09 PM, Dale wrote: Mick wrote: From my understanding, the dev is not listening. That is another thing that bothers me. When devs stop listening to users, that causes a problem. Remember hal? How many people complained early From what I read, he's listening, he just isn't being swayed by the argument. From his perspective, udev "doesn't support" a split /,/usr because of the arbitrarily complex udev rules. This is causing users to fill their bug queue with errors when needed binaries are unavailable at boot, and thus their hardware doesn't work. Apparently he has concluded that the number of people who require a separate /usr partition but cannot use an initramfs is smaller than the number of people who need udev to have access to all of /usr. Unfortunately it appears that he's taking a pretty extreme approach to solving the problem that will actually *break* the systems of that second group, which I don't quite understand the reasoning behind. As I understand it, nothing of udev itself is in /usr, but instead packages and scripts which plug themselves into udev to be triggered by various events. Perhaps the real solution is to circumvent udev and get those other packages and scripts to not put hotplug-active files under /usr. That's my understanding too, and I agree with your conclusions. The distros can easily (give enough man-power) deal with this too - they simply have to modify their rpms/debs/pkgs/ebuilds to install specific identified things to / instead of /usr. They *already* do this for packages that natively install to peculiar locations. It would make perfect sense to me for the udev maintainer to simply declare a split /,/usr "not supported" and let us deal with the issues. The problem, if I'm reading correctly, is that he's taken things one step further and decided to move udev *itself* back into /usr. Even still, I would think that a Gentoo patchset to revert the paths back to /lib would be a feasible workaround to this mess. --Mike
Re: [gentoo-user] Fwd: [gentoo-project] With regard to udev stabilization
On Fri, Nov 16, 2012 at 10:54 PM, Dale wrote: > Walter Dnes wrote: >> On Fri, Nov 16, 2012 at 07:24:54PM -0500, Michael Mol wrote >>> On Fri, Nov 16, 2012 at 5:47 PM, Walter Dnes wrote: >>>> On Mon, Nov 12, 2012 at 09:20:42PM -0600, Dale wrote >>>>> Well, it appears we have someone willing to fork udev. Yeppie !! >>>>> Me, I'm looking forward to seeing how this works and giving it a test >>>>> run when it gets ready. Since it is a fork, shouldn't be to long, >>>>> I hope. >>>> BTW, this has hit Slashdot... >>>> http://linux.slashdot.org/story/12/11/16/2052203/gentoo-developers-fork-udev >>> Be sure to read Richard Yao's response: >>> http://linux.slashdot.org/comments.pl?sid=3256499&cid=42006113 >> I understand that he's still getting the effort organized. I am not a >> C programmer, but if the effort needs any beta testers, I'm willing to >> volunteer. BTW, it looks like Lennart Poettering is more unpopular than >> Steve Ballmer on Slashdot. >> > > Thing I like about the fork, if people get fed up with udev, udev falls > flat on its face or something else causes udev to fail, we have a udev > already ready. That statement may not be true for another couple months > or so but at least there is a Gentoo plan B. > > Also, I can get rid of dracut too. ;-) > > Walter, I wonder how much your work helped this along? If you had not > stepped up and did what you have done, then this fork may have never > happened. You could have at least let others know there are people > looking for something else. If so, thanks for that. :-D I think Walter's work (and his dogged perseverance despite the negative reactions I'd seen) played a pivotal role in having this play out the way it did. If he hadn't, I'm sure the systemd+udev thing would have gotten worked out anyway, I'm not sure the solution would have come from within Gentoo, and would not have come in the form of a fork, had Walter's work not been so obvious a focal point. Thanks, Walter. *tips hat* -- :wq
[gentoo-user] udev-197-r3 update problem...
Hi Gentoo-users,
I'm just in the process of updating my nearly identical servers.
Some of them I updated without any problem. "Unfortunatelly",
right now new udev-197-r3 went stable, and so those servers
which I synced with portage-tree later want to pull udev-197,
and give this error:
---
vs1-sys ~ # emerge --ask --update --deep --newuse --verbose world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-util/gperf-3.0.4 961 kB
[ebuild N ] dev-libs/libgpg-error-1.10 USE="nls -common-lisp
-static-libs" 429 kB
[ebuild N ] dev-libs/libgcrypt-1.5.0-r2 USE="-static-libs" 1,405 kB
[ebuild N ] dev-libs/libxslt-1.1.28 USE="crypt -debug -python
-static-libs" 3,356 kB
[ebuild N ] sys-apps/kmod-12-r1 USE="tools zlib -debug -doc -lzma
-static-libs" 1,246 kB
[ebuild U ] sys-fs/udev-197-r3 [171-r9] USE="acl%* kmod%* openrc%*
-doc% -gudev -hwdb -introspection -keymap (-selinux) -static-libs%
(-action_modeswitch%) (-build%) (-debug%) (-edd%) (-extras%) (-floppy%)
(-rule_generator%*) (-test%)" 2,008 kB
[ebuild U ] virtual/udev-197 [171] USE="-gudev -hwdb -introspection
-keymap (-selinux) -static-libs" 0 kB
[ebuild N ] sys-fs/udev-init-scripts-19 5 kB
[blocks B ] sys-apps/kmod ("sys-apps/kmod" is blocking
sys-apps/module-init-tools-3.16-r2)
[blocks B ] sys-apps/module-init-tools
("sys-apps/module-init-tools" is blocking sys-apps/kmod-12-r1)
Total: 8 packages (2 upgrades, 6 new), Size of downloads: 9,407 kB
Conflict: 2 blocks (2 unsatisfied)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(sys-apps/kmod-12-r1::gentoo, ebuild scheduled for merge) pulled in by
sys-apps/kmod[tools] required by (virtual/modutils-0::gentoo,
installed)
>=sys-apps/kmod-12 required by (sys-fs/udev-197-r3::gentoo, ebuild
scheduled for merge)
(sys-apps/module-init-tools-3.16-r2::gentoo, installed) pulled in by
>=sys-apps/module-init-tools-3.2 required by
(virtual/modutils-0::gentoo, installed)
---
So how can I fix this mess? I masked sys-fs/udev-197-r3,
now portage does not complain, but it is just temporary
solution...
Jarry
--
___
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] udev-197-r3 update problem...
On Sat, Jan 19, 2013 at 10:02 AM, Jarry wrote:
> Hi Gentoo-users,
>
> I'm just in the process of updating my nearly identical servers.
> Some of them I updated without any problem. "Unfortunatelly",
> right now new udev-197-r3 went stable, and so those servers
> which I synced with portage-tree later want to pull udev-197,
> and give this error:
>
> ---
> vs1-sys ~ # emerge --ask --update --deep --newuse --verbose world
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild N ] dev-util/gperf-3.0.4 961 kB
> [ebuild N ] dev-libs/libgpg-error-1.10 USE="nls -common-lisp
> -static-libs" 429 kB
> [ebuild N ] dev-libs/libgcrypt-1.5.0-r2 USE="-static-libs" 1,405 kB
> [ebuild N ] dev-libs/libxslt-1.1.28 USE="crypt -debug -python
> -static-libs" 3,356 kB
> [ebuild N ] sys-apps/kmod-12-r1 USE="tools zlib -debug -doc -lzma
> -static-libs" 1,246 kB
> [ebuild U ] sys-fs/udev-197-r3 [171-r9] USE="acl%* kmod%* openrc%*
> -doc% -gudev -hwdb -introspection -keymap (-selinux) -static-libs%
> (-action_modeswitch%) (-build%) (-debug%) (-edd%) (-extras%) (-floppy%)
> (-rule_generator%*) (-test%)" 2,008 kB
> [ebuild U ] virtual/udev-197 [171] USE="-gudev -hwdb -introspection
> -keymap (-selinux) -static-libs" 0 kB
> [ebuild N ] sys-fs/udev-init-scripts-19 5 kB
> [blocks B ] sys-apps/kmod ("sys-apps/kmod" is blocking
> sys-apps/module-init-tools-3.16-r2)
> [blocks B ] sys-apps/module-init-tools ("sys-apps/module-init-tools" is
> blocking sys-apps/kmod-12-r1)
>
> Total: 8 packages (2 upgrades, 6 new), Size of downloads: 9,407 kB
> Conflict: 2 blocks (2 unsatisfied)
>
> * Error: The above package list contains packages which cannot be
> * installed at the same time on the same system.
>
> (sys-apps/kmod-12-r1::gentoo, ebuild scheduled for merge) pulled in by
> sys-apps/kmod[tools] required by (virtual/modutils-0::gentoo, installed)
> >=sys-apps/kmod-12 required by (sys-fs/udev-197-r3::gentoo, ebuild
> scheduled for merge)
>
> (sys-apps/module-init-tools-3.16-r2::gentoo, installed) pulled in by
> >=sys-apps/module-init-tools-3.2 required by
> (virtual/modutils-0::gentoo, installed)
>
> ---
>
> So how can I fix this mess? I masked sys-fs/udev-197-r3,
> now portage does not complain, but it is just temporary
> solution...
try:
emerge -Cv sys-apps/module-init-tools
emerge -1v sys-apps/kmod
and then try to update world again. kmod is a drop-in replacement for
module-init-tools, and it's what is used by new versions of udev. You
probably will need to keyword kmod.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: udev upgrade and non-working eth0
On Wednesday 29 November 2006 17:33, Richard Fish wrote:
> On 11/27/06, Mrugesh Karnik <[EMAIL PROTECTED]> wrote:
> > On Tuesday 28 November 2006 07:31, Richard Fish wrote:
> > > > can see a 75-persistent-net-generator.rules file in there..
> > >
> > > Hmm, not sure how I got a 70-persistent-net.rules. There is some
> > > interaction between that and 75-persistent-net-generator.rules (and
> > > the /lib/udev/write_net_rules script), but I'm a bit too tired to
> > > figure it out ATM. It looks like 70-... should be created by the
> > > write_net_rules script...
> >
> > RULES_FILE='/etc/udev/rules.d/70-persistent-net.rules'
> >
> > That's the first line of write_net_rules.
>
> Right. I just wasn't able to figure out why you didn't already have
> this file created, nor why my laptop had it but not my desktop.
>
> So the story is that 75-persistent-net-generator.rules will call the
> script when ethernet devices are added, and it is up to the
> write_net_rules script to generate 70-persistent-net.rules. The
> problem is that when udev starts very early in the boot process, your
> root filesystem may still be mounted read-only, preventing this file
> from being created.
>
> This worked on my laptop, because I added module aliases to prevent
> udev from coldplugging the ipw3945 driver, since it requires a daemon
> to be running in order to work and that required /var to be mounted.
> The module is loaded later in the boot process, after all of the
> filesystems are mounted read-write, and that allowed udev to create
> the rules file for me, but only for that adapter.
>
> The upshot of this is this: by far the easiest way to solve the
> net-naming problem is to run
>
> /lib/udev/write_net_rules all_interfaces
>
> This will generate the rules for all interfaces, and then you can just
> edit the file to change the names as you like. So I guess I'll know
> that for the next person that asks. :-P
Not sure if/how it is related to the OP, but this is what was created in
my /etc/udev/rules.d/70-persistent-net.rules:
=
# USB device 0x050d:0x7050 (rt2500usb)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:50:18:55:3f",
ATTRS{type}=="1", NAME="wlan0"
=
However, if I boot with the USB WiFi adaptor plugged in it, the device is not
being detected. If I plug it in after the system has booted then there is no
problem. The USB devices are 'udev-plugged' relatively late in the boot
process, well after udevd has started. Therefore I cannot understand why
this adaptor is not being detected. Any ideas?
--
Regards,
Mick
pgp0J6z7d8Qq0.pgp
Description: PGP signature
Re: [gentoo-user] systemd-boot on openrc
On Sun, 17 Apr 2022 11:41:23 +, Peter Humphrey wrote:
> I've been using bootctl from sys-boot/systemd-boot for several years,
> with some success, but I'm stuck after today's --sync.
>
> First I was told I had to keyword sys-apps/systemd-utils, so I did
> that, but now I get this, which I can't decode:
>
> Calculating dependencies ... . . done!
> [ebuild N~] sys-apps/systemd-utils-250.4::gentoo USE="boot
> (split-usr) sysusers tmpfiles udev (-selinux) -test" ABI_X86="(64) -32
> (-x32)" 10,872 KiB [ebuild U ~] sys-boot/systemd-boot-250::gentoo
> [249.9::gentoo] 0 KiB [blocks b ] (" sys-apps/systemd-utils-250.4) [blocks B ]
> soft blocking sys-apps/systemd-utils-250.4) [blocks B ]
> apps/systemd-utils-250.4)
>
> Total: 2 packages (1 upgrade, 1 new), Size of downloads: 10,872 KiB
> Conflict: 3 blocks (2 unsatisfied)
>
> * Error: The above package list contains packages which cannot be
> * installed at the same time on the same system.
>
> (sys-apps/systemd-tmpfiles-249.9-2:0/0::gentoo, installed) pulled in
> by sys-apps/systemd-tmpfiles required by
> (virtual/tmpfiles-0-r1-1:0/0::gentoo, installed) USE="" ABI_X86="(64)"
>
> (sys-apps/systemd-utils-250.4:0/0::gentoo, ebuild scheduled for
> merge) pulled in by
> sys-apps/systemd-utils[udev] required by (sys-boot/systemd-
> boot-250:0/0::gentoo, ebuild scheduled for merge) USE="" ABI_X86="(64)"
>
> (sys-fs/udev-249.6-r2-3:0/0::gentoo, installed) pulled in by
> >=sys-fs/
> udev-232:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]
>
> (>=sys-fs/udev-232:0/0[abi_x86_64(-)]) required by
> (virtual/libudev-232- r5-2:0/1::gentoo, installed) USE="-systemd"
> ABI_X86="(64) -32 (-x32)"
> >=sys-fs/udev-217 required by (virtual/udev-217-r3-1:0/0::gentoo,
> installed) USE="" ABI_X86="(64)"
>
> This is an amd64 openrc system.
It looks like this is cause my using mixed keywords, amd64 for udev and
~amd64 for systemd-boot/utils. Does keywording udev-250 resolve the
blocks?
> On another system, ~amd64 openrc, I was
> told to set USE=boot on systemd-utils, so I did that and now when I
> boot I have no mouse or keyboard.
>
> Is this the end of the road for systemd-boot on openrc?
I think that USE flag just causes the systemd-boot part of systemd-utils
to be built. systemd-boot itself is just a virtual now. It doesn't sound
like that would cause this problem, did you emerge anything X related at
the same time?
--
Neil Bothwick
without C people would code in Basi, Pasal and Obol
pgpalhNg49Ji2.pgp
Description: OpenPGP digital signature
Re: [gentoo-user] How to get /dev/cdrom
On Wed, 2011-01-12 at 11:54 -0500, Mike Edenfield wrote:
> On 1/12/2011 11:11 AM, Michael Sullivan wrote:
> > OK, for several years I have not had a /dev/cdrom. My workstation has
> > an internal cd-rom drive, which gets mapped to /dev/hda, and an external
> > DVD+R drive, which is mapped to /dev/sr0. When I look
> > at /etc/udev/rules.d/70-persistent-cd.rules I see:
>
> I just went through this exact same problem, and it turned out that
> having both the old ATA drivers and the new libata drivers in my kernel
> at the same time was the root of the problem. I had multiple drivers
> fighting for the same device, and it confused udev for some reason. The
> end result was, udev never picked up that the IDE drive was actually a
> CD-ROM, so it never ran the udev rules to automatically regenerated
> 70-persistent-cd.rules.
>
> The existing rules you have don't work because the ID_PATH isn't valid:
>
> ENV{ID_PATH}=="pci-:00:1f.1-ide-0:0"
>
> The "-ide-0:0" part no longer shows up when you get the udev ID_PATH for
> a device using the old ATA drivers, so there are no matching udev rules
> to create the symlinks.
>
> I fixed it by switching over completely to libata, like this:
>
> 1. Delete the 70-persistent-cd.rules file from /etc/udev. (If
> everything is working correctly, udev will regenerate this file from
> scratch the next time you start it.)
>
> 2. In your kernel config, under Device Drivers --->
> * Make sure that ATA/ATAPI/MFM/RLL support is /not/ selected.
> * Enable Serial ATA and Parallel ATA
> * Under Serial ATA and Paralle ATA --->
> ** Enable ATA SFF support
> ** Below that, enable ATA BMDMA support[1]
> ** Below that, enable whatever IDE chipset you have
>
> 3. Back under Device Drivers --->
> * Under SCSI device support --->
> ** Enable SCSI disk support
> ** Enable SCSI CDROM support
> ** /Do not/ enable SCSI Generic support[2]
>
> Build/install/reboot and you should now see your two CD drives appearing
> as sr0 and sr1. udev should now pick them both up, and write a new
> 70-persistent-cd.rules file, with the IDE drive having a different
> ID_PATH, something like:
>
> ENV{ID_PATH}=="pci-:00:1f.1-scsi-0:0:0:0"
>
> And you should now get your symlinks.
>
> [1] BMDMA is the controller type in all of the machines I have, and
> seems to be the standard for most personal desktop/laptop/etc machines.
> If you know differently, of course, pick the correct SFF controller.
>
> [2] The SCSI generic driver has a habit of grabbing my other SCSI
> devices and assigning them to sg0/sg1/sg2/etc; this seemed to prevent
> udev from picking up that they were CD drives. If you need SCSI Generic
> for some reason, I'd suggest making it a module.
>
> --Mike
>
I was still running linux-2.6.30-gentoo-r8. I didn't even HAVE an
option for ATA SFF support. I'm going to build a v2.6.36-gentoo-r5
kernel and pray that my ivtv stuff still works...
[gentoo-user] Re: udev-197-r3 update problem...
On Sat, 19 Jan 2013 10:41:07 -0600
Canek Peláez Valdés wrote:
> On Sat, Jan 19, 2013 at 10:02 AM, Jarry wrote:
> > Hi Gentoo-users,
> >
> > I'm just in the process of updating my nearly identical servers.
> > Some of them I updated without any problem. "Unfortunatelly",
> > right now new udev-197-r3 went stable, and so those servers
> > which I synced with portage-tree later want to pull udev-197,
> > and give this error:
> >
> > ---
> > vs1-sys ~ # emerge --ask --update --deep --newuse --verbose world
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> > [ebuild N ] dev-util/gperf-3.0.4 961 kB
> > [ebuild N ] dev-libs/libgpg-error-1.10 USE="nls -common-lisp
> > -static-libs" 429 kB
> > [ebuild N ] dev-libs/libgcrypt-1.5.0-r2 USE="-static-libs"
> > 1,405 kB [ebuild N ] dev-libs/libxslt-1.1.28 USE="crypt
> > -debug -python -static-libs" 3,356 kB
> > [ebuild N ] sys-apps/kmod-12-r1 USE="tools zlib -debug -doc
> > -lzma -static-libs" 1,246 kB
> > [ebuild U ] sys-fs/udev-197-r3 [171-r9] USE="acl%* kmod%*
> > openrc%* -doc% -gudev -hwdb -introspection -keymap (-selinux)
> > -static-libs% (-action_modeswitch%) (-build%) (-debug%) (-edd%)
> > (-extras%) (-floppy%) (-rule_generator%*) (-test%)" 2,008 kB
> > [ebuild U ] virtual/udev-197 [171] USE="-gudev -hwdb
> > -introspection -keymap (-selinux) -static-libs" 0 kB
> > [ebuild N ] sys-fs/udev-init-scripts-19 5 kB
> > [blocks B ] sys-apps/kmod ("sys-apps/kmod" is blocking
> > sys-apps/module-init-tools-3.16-r2)
> > [blocks B ] sys-apps/module-init-tools
> > ("sys-apps/module-init-tools" is blocking sys-apps/kmod-12-r1)
> >
> > Total: 8 packages (2 upgrades, 6 new), Size of downloads: 9,407 kB
> > Conflict: 2 blocks (2 unsatisfied)
> >
> > * Error: The above package list contains packages which cannot be
> > * installed at the same time on the same system.
> >
> > (sys-apps/kmod-12-r1::gentoo, ebuild scheduled for merge) pulled
> > in by sys-apps/kmod[tools] required by (virtual/modutils-0::gentoo,
> > installed)
> > >=sys-apps/kmod-12 required by (sys-fs/udev-197-r3::gentoo,
> > >ebuild
> > scheduled for merge)
> >
> > (sys-apps/module-init-tools-3.16-r2::gentoo, installed) pulled in
> > by
> > >=sys-apps/module-init-tools-3.2 required by
> > (virtual/modutils-0::gentoo, installed)
> >
> > ---
> >
> > So how can I fix this mess? I masked sys-fs/udev-197-r3,
> > now portage does not complain, but it is just temporary
> > solution...
>
> try:
>
> emerge -Cv sys-apps/module-init-tools
> emerge -1v sys-apps/kmod
>
> and then try to update world again. kmod is a drop-in replacement for
> module-init-tools, and it's what is used by new versions of udev. You
> probably will need to keyword kmod.
adev-197 has a kmod useflag, on by default (at least in my profile).
Disabling it lets you keep module-init-tools. I noticed because I am
one of those risk-takers who has USE -* , and now I'm wondering what
the benefits of kmod would be for me (and/or disadvantages).
If this has already been discussed here, my apologies. I try to pay
attention, but, well, you know what all udev threads are like. ;)
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Mon, Nov 10, 2014 at 8:23 AM, Tanstaafl wrote: > On 11/10/2014 7:30 AM, Rich Freeman wrote: >> Well, there are no plans to make udev stop working without systemd as >> far as I can tell. HOWEVER, there ARE plans to require using kdbus to >> communicate with udev, and for that to work there needs to be a >> userspace initialization of kdbus/etc. > > So... you're saying I'm mis-reading this: Somewhat. > >> Unless the systemd-haters prepare another kdbus userspace until then >> this will effectively also mean that we will not support non-systemd >> systems with udev anymore starting at that point. Gentoo folks, this >> is your wakeup call. > > and that it doesn't mean that "udev will stop working without systemd", > or, as Lennart said, "... we will not support non-systemd systems with > udev anymore staryting at that point (when udev is moved onto kdbus as > transport)? The part that you're missing is the "Unless the systemd-haters [sic] prepare another kdbus userspace." Like many parts of the kernel, kdbus needs initialization from userspace. This is no different than what udev does in the first place - the kernel has device drivers, but SOMETHING has to populate /dev with device nodes if you want to use them. Now /dev has been around since the dawn of time, so we get our choice of 47 different ways of doing that. Kdbus hasn't been around for long at all, so nobody has really written any standalone processes for initializing it. As far as I can tell, udev will work just fine as long as something sets up kdbus. I'd have to study it a bit more to understand if there is some reason that this something has to be PID 1. I don't care for the attitude/etc and especially the treatment of Samuli (who seems to do his best to cooperate with everybody in this contentious area), but stepping back I can't really say that a project deciding to move to a new API based on a new IPC feature is all that controversial on its own. Normally when this sort of thing happens there are a bunch of projects built to support such a new kernel feature in userspace. I think the main reasons that we are where we are right now are: 1. All the big distros are moving to systemd anyway, so they don't really have much of an itch to scratch here. 2. Most folks not interested in systemd seem to generally not be interested in dbus at all. I think there is a lot of hope that this problem will just go away, and I suspect that if anything it will get a lot worse. 3. Those who aren't using systemd to some extent are a bit split across udev, eudev, and busybox mdev. This does divide up the labor pool a bit and means interests aren't 100% aligned. The situation doesn't really see irreparable to me, but it does seem like there is something to be done. -- Rich
[gentoo-user] Good news for the HAL haters
Saw this message from an emerge today: * Messages for package x11-base/xorg-server-1.8.0: * Usage of hal is strongly discouraged. Please migrate to udev. * From next major release on the hal support will be fully disabled. * Both hal and udev flags are enabled. * Enabling only udev!
Re: [gentoo-user] My USB camera no longer works.
On Thu, Apr 16, 2009 at 2:58 PM, Dale wrote: > Also, how does one "restart" udev? Does going to "rc single" then back > to "rc default" restart udev? Surely a person doesn't have to reboot to > do this. /etc/init.d/udev restart is what i would try :)
Re: [gentoo-user] Who mount sysfs?
On Tuesday 24 March 2009, Alan McKinnon wrote: > On Tuesday 24 March 2009 05:01:36 SOrCErEr wrote: > > No, that isn't. That file exists. > > So I tested like below. > > > > /etc/init.d/udev stop > > /etc/init.d/sysfs stop > > /etc/init.d/udev start > > /etc/init.d/sysfs status > > > > Result is > > "* status: stopped" > > I had this problem recently. I had updated to udev-140 and forgot to run > conf- update to fic the changed config file. > > Did you recently update udev? I am confused reading this thread. I have sysfs mounted: $ mount | grep sysfs sysfs on /sys type sysfs (rw,nosuid,nodev,noexec) However, I do not have sysfs in /etc/init.d/sysfs. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] DVD and changing permissions
On Sat, 12 Jul 2008 19:10:12 -0500, Dale wrote: > I re-emerged udev and noticed this little foot note: > > mount options for directory /dev are no longer > set in /etc/udev/udev.conf, but in /etc/fstab > as for other directories. > > I don't have anything in fstab for /udev. This is what mount reports: Neither do I, even on a brand new, up to date install. > [EMAIL PROTECTED] / # mount > udev on /dev type tmpfs (rw,nosuid) /dev is mounted, which is what matters. If /dev were not mounting you'd have far more serious problems that reading DVDs. -- Neil Bothwick New Klingon hair salon: "Today is a good day to dye" signature.asc Description: PGP signature
Re: [gentoo-user] udevinfo - where is it
On 10/23/2008 12:29 PM, Helmut Jarausch wrote: > I have a recent GenToo system (udev-130-r1) but I cannot > find the utility 'udevinfo' > Which package contains it? With my udev-124-r1 it is in the udev package. But /usr/bin/udevinfo is just a symlink to /sbin/udevadm, so maybe you should look for the latter. Add: Just built 130-r1. In the messages for it is: "If you build an initramfs including udev, then please make sure that the /sbin/udevadm binary gets included, and your scripts changed to use it, as it replaces the old helper apps udevinfo, udevtrigger, ..." Regards, Christian Franke signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Ethernet Machination
On 2013-01-01 7:55 PM, Canek Peláez Valdés wrote: On Tue, Jan 1, 2013 at 6:50 PM, James wrote: So now that only one ethernet shows up, how do I prevent udev from renaming eth0 to eth3? Check /etc/udev/rules.d/70-persistent-net.rules. Probably the old (fried) ethernet card is listed there (along with other stuff). Leave out everything except your PCI card (the MAC address is how you tell them appart). Worst case, delete the file (after saving a copy), and see if udev automagically solves everything by itself. Also, be sure that you have completely disabled the integrated ethernet in the BIOS, otherwise gentoo/udev may still 'see' it even if it isn't working...
Re: [gentoo-user] problems getting network going properly
On 1/7/07, Etaoin Shrdlu <[EMAIL PROTECTED]> wrote: > Also, any reliable way to get a certain device to be eth0, etc. I saw > the rename, but net.examples said that was not optional. You have to create some udev rules to tie device names to MAC addresses. Search the archives of this mailing list and you'll find a few threads about this problem (with the solutions, of course). If you have udev-103, by far the easiest way to do this is run /lib/udev/write_net_rules all_interfaces This will generate /etc/udev/rules.d/70-persistent-net.rules that you can then edit to assign whatever names you want. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] UDEV permissions
On Tue, 17 Jan 2006 17:58:26 -0700, Richard Fish wrote: > > Don't use that file, that is for udev's own settings, so it will be > > updated when udev is. Use 10-udev.rules (create it if not present) > > which won't be affected by udev updates and takes precedence over the > > higher numbered file. > > It is read first, but the settings there only have precedence if the > ":=" syntax is used. If it just shows "=", later rules (i.e, from > 50-udev.rules) can override the settings. That only happens under certain circumstances. udev generally stops at the first matching rule. := is the safest option though. -- Neil Bothwick Everyone has a photographic memory. Some don't have film. signature.asc Description: PGP signature
[gentoo-user] USB, udev, and SCSI emulation
I've been researching getting my camera to work and I have a few questions. I'm running udev and kernel 2.6.15.1. 1) For USB mass storage to work do I still need SCSI emulation or does udev remove that requirement? 2) If so do I still need to pass the kernel parameter hdc=ide-scsi? 3) Should SCSI emulation be automatic with udev, or might I need to write a rule for it? 4) If SCSI emulation is working will I alway see a line in dmesg about a new SCSI device? Most howto's seem to suggest this but I want to be sure. 5) Any other things I ought to be looking at? Thanks! -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] /dev read,write problem
On 8/26/05, Walter Dnes <[EMAIL PROTECTED]> wrote: On Wed, Aug 24, 2005 at 05:06:13PM +0200, Jonas Geiregat wrote> When I startup my system I need to loing as root and run chmod a+rw> /dev/* else I have problems login in or starting multiple shells I'm> using udev anyone got any idea what could cause the problem ? Purely a guess here but have you tried poking around in /etc/udev? I run PAM and UDEV with 0 problems perhaps you have a funky udev setting? Anhow, like I said, just a guess. -Mike-- Michael E. CruteSoftware DeveloperSoftGroup Development CorporationLinux, because reboots are for installing hardware."In a world without walls and fences, who needs windows and gates?"
Re: [gentoo-user] udev Migration and SCSI
On Wednesday 19 October 2005 17:50, Ian Brandt wrote: > 1) How can I tell what the new name is going to be? I'd imagine /dev/sdXY will exist under both udev and devfs, and be the same, they certainly always have done for me. > 2) As I'm doing this upgrade remotely, how can I set up to fail back > to my udev-less 2.4.25 kernel should 2.6.13 still fail to come up? In > other words, if I change fstab to be udev specific won't that leave me > dead in the water? fstab doesn't have to take block devices, it can take labels too, you could look into labeling your partitions. -- Mike Williams -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] udev and fstab
On Wed, 14 Dec 2005 17:15:20 +0200, Martins Steinbergs wrote: > Gentoo udev Guide didnt answer my question, is it good idea to remove > fstab entry for removables, i have this > /dev/hdc /media/cdrecorder auto > user,exec,noauto,managed 0 0 since fresh install and then there was > devfs. Am I right that udev will handle mounts for /dev/hdc/ (DVD+CDRW) > according to udev.rules what media is inserted? udev handles the creation of the device nodes, mounting is handled by hal. hal normally creates its own mount points in /media, but if the device is listed in /etc/fstab, it will use whatever is in there. -- Neil Bothwick Why is the word abbreviation so long? signature.asc Description: PGP signature
Re: [gentoo-user] help with UDEV and USB flash drive
On 6/9/06, Daniel Drake <[EMAIL PROTECTED]> wrote: Richard Fish wrote: > One problem with this. Udev will apply all matching rules until it > finds one with a NAME entry. So you probably want MODE:="0666" to > prevent any later rules from overwriting your mode. This isn't entirely true, udev doesn't stop at NAME any more. It stops at the end of the rules files, or when it sees OPTIONS="last_rule". Ah, thanks. Sadly, this change is not noted in /usr/share/doc/udev-*/RELEASE-NOTES.gz file. The 057 notes specify the stop-on-NAME behavior, and nothing newer (at least through 090) retracts that statement. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: kconsole lost PTYs
On Wed, 28 Jun 2006 00:57:30 + (UTC), James wrote: > When the system boots and gives me the kdm login screen, I have to > first ssh remotely and run these commands > > chown root:tty /dev/pty* > chown root:tty /dev/tty* > chmod 666 /dev/null > > I'd sure like to know what to remerge to fix this problem. > hal ? udev ? It sounds like your udev rules are screwed. My defaults are KERNEL=="pty[pqrstuvwxyzabcdef][0123456789abcdef]",NAME="%k", GROUP="tty",OPTIONS="last_rule" KERNEL=="null",NAME="%k", MODE="0666" Re-emerging udev should fix this, let etc-update/dispatch-conf replace /etc/udev/rules.d/50-udev.rules. -- Neil Bothwick "You want us to do WHAT?" - Ancient Chinese wall engineer. signature.asc Description: PGP signature
[gentoo-user] udev blocks systemd etc
Just found that I have a blocking situation ... systemd and udev don't "like each other" right now ;-) Tried various maskings ... and found some hints in the Changelog here: http://gentoo-portage.com/sys-fs/udev/ChangeLog#ptabs this lead me to this bugreport: https://bugs.gentoo.org/show_bug.cgi?id=462750 ... it is flagged "RESOLVED FIXED" and I am digging for the solution ... the latest comment (at the very moment https://bugs.gentoo.org/show_bug.cgi?id=462750#c45) there says "Let's not discuss blocker problems on this bug report please." ok ... So I just stay with sys-fs/udev-198-r5 and sys-apps/systemd-198-r2 for now and look forward to the things coming :-) Anyone in here already hit that? Suggestions? Best regards, Stefan
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-05 4:11 PM, William Hubbs wrote: On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote: Just dealing with one server and my Linux router, they've been updated to sys-fs/udev-200 and are both still using the same /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year, which was working with udev-171. Do you have your network interface drivers built into the kernel or are they modules? I'm very interested in the significance of this question... My server is module free, so all drivers are built into the kernel. Does this provide for another option and/or make things easier?
Re: [gentoo-user] net.eth0 failed to start
Am Sonntag, 2. März 2014, 17:14:54 schrieb Skippy: > Hi y'all. I've lost my interwebz and can't view cat pictures. Major > crisis here. > Hey Skippy, dont worry the lolcats are all still there. udev-210 is the culprit. See [1,2] for details. For a quick workaround, add net.ifnames=0 to your kernel command line (e.g. in grub.conf or grub.cfg) and reboot. Cheers, Andreas [1] http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=blob;f=2014/2014-02-25-udev-upgrade/2014-02-25-udev-upgrade.en.txt;hb=HEAD [2] https://wiki.gentoo.org/wiki/Udev/upgrade#udev_208_to_210 -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Why is udev now having USE (-openrc%*)
On Friday 09 May 2014 23:25:06 Neil Bothwick wrote: > On Fri, 9 May 2014 21:56:45 +0100, Mick wrote: > > What is the meaning of this change? > > > > [ebuild U ] sys-fs/udev-212-r1 [208] USE="acl firmware-loader > > gudev introspection kmod -doc (-selinux) -static-libs (-openrc%*)" > > 2,660 kB > > It means the openrc USE flag is no longer used. From the Changelog: > > " Punt USE="openrc" and always pull in sys-fs/udev-init-scripts to match > behavior of sys-apps/systemd's ebuild." Thanks Neil, Does this mean that openrc and systemd are now aligned with regards to udev related init-scripts? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] updating to udev
On Sun, 19 Dec 2021 at 17:36, wrote: > > Updating 3-months old system. > What should I watch for when it comes to updating from eudev to udev > > from the news file: > "If you DO NOT want the "predictable interface naming" of newer versions > of udev and instead prefer the old style (e.g. "eth0"), there are several > options available." > > my interface is: enp4s0 > so I assume it will become: eth0 after upgrade, changing the name via > "rc-update" will be necessary. You are misreading that a bit. You will need to take an active action to make it register as eth0 or similar. Your interface will stay as enp4s0 on both eudev and udev. Regards, Arve
Re: [gentoo-user] Change from udev to eudev?
On Tue, Jun 07, 2016 at 05:05:47PM -0500, Dale wrote > I switched mine back when eudev was new and not even stable yet. It was > as simple as unmerge udev and emerge eudev. I don't recall even doing a > reboot, which I rarely do here anyway. *** WARNING *** After unmerging udev, do *NOT*, repeat *NOT*, reboot *** UNTIL AFTER INSTALLING EUDEV *** (same applies to going the other way). You cannot boot Gentoo without a device manager in place. Once you've installed eudev, you'll get an urgent message to execute... /etc/init.d/udev --nodeps restart At this point, you can safely reboot, but a restart is less of a pain. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] USB Audio ?
On 05/14 01:07, Jack wrote: > On 5/14/19 12:26 PM, tu...@posteo.de wrote: > > On 05/13 11:24, Jack wrote: > > > On 2019.05.13 23:10, tu...@posteo.de wrote: > > > > Hi, > > > > > > > > is it somehow possible to play USB-Audio on a PC without one of these > > > > USB-dongle-"soundcards" (DACs)? > > > > > > > > I searched the web and only got links to those dongles... > > > > > > > > On the other hand: On the forum of the developers board one post > > > > spokes of a "dummy" USB-Audio device... > > > > > > > > How can I acchieve this? > > > > > > > > Thanks for any help in advance! > > > > Cheers! > > > > Meino > > > It's not clear what you really want. Why would you want USB audio without > > > an actual USB audio device? Without a USB audio dongle/device/whatever, > > > what would you have to actually produce sound?I can imagine a "dummy" > > > USB audio device - but I can imagine it for testing the software, but not > > > actually producing any sound, so why would you want it? > > > > > > Jack > > Hi Jack, > > > > I don't wanted to pollute my posting with non-Linux details...but here > > they are: > > > > I habe a Teensy 3.6 by PJRC (=>https://www.pjrc.com/), which has an > > USB-port. This port can be switched between a lot of USB-devices... > > ...one of them is an USB-audio device (output). > > The MK66FX1M0VMD18 uC has beside an FPU a DSP block. > > With a certain (open source) firmware this chip can be used as an > > synthesizer. > > > > To cut costs I wanted no USB dongle to play the sound ... I wanted > > to use my Linux PC as "Mega DAC"...so to say. > > > > Question is: > > How can I create such an "receiver" for USB Audio signals to play > > them live with my PC? > > > > Cheers! > > Meino > > That's very different from what I (and I suspect others) thought about your > first posting. You want to do USB audio input, not output. In this case, I > don't think a usual USB audio device/dongle would even help. My first > suggestion is to just plug the USB from the Teensy into the PC, and see what > dmesg shows, and what lsusb shows. Searching on the manufacturer and device > IDs shown by lsusb might lead to solutions, or at least to further lines of > investigation. Also, the Teeny docs might give more information about what > kind of USB output their audio produces, and I wonder if you might find some > good info on their forum? > > Jack > > Hi Jack, I already posted a question on the forum. The forum is about the Teensy and not Linux. Answer was: "On a Win PC (I do not use Linux) you have to select the Teensy Audio device (Open Sound Settings) to listen to teensy " I attached a screenshot of the devices I could choose via bootloader trickery. lsusb (the relevant portion) reported this when switch to USB Audio: [ 7722.526825] usb 6-2: new full-speed USB device number 18 using ohci-pci [ 7722.691955] usb 6-2: New USB device found, idVendor=16c0, idProduct=04d2, bcdDevice= 2.77 [ 7722.691962] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 7722.691966] usb 6-2: Product: Teensy Audio [ 7722.691970] usb 6-2: Manufacturer: Teensyduino [ 7722.691973] usb 6-2: SerialNumber: 4991790 [ 7722.700415] hid-generic 0003:16C0:04D2.0009: hidraw3: USB HID v1.11 Device [Teensyduino Teensy Audio] on usb-:00:12.0-2/input0 [ 7727.761957] usb 6-2: Warning! Unlikely big volume range (=4095), cval->res is probably wrong. [ 7727.761965] usb 6-2: [49] FU [PCM Playback Volume] ch = 2, val = 0/4095/1 (hidraw is always present and is used to communicate with the bootloader) 'udevadm monitor' shows this when plugging in the Teensy: monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent KERNEL[7867.891799] add /devices/pci:00/:00:12.0/usb6/6-2 (usb) KERNEL[7867.893472] add /devices/pci:00/:00:12.0/usb6/6-2/6-2:1.0 (usb) KERNEL[7867.899759] add /devices/pci:00/:00:12.0/usb6/6-2/6-2:1.0/0003:16C0:04D2.000A (hid) KERNEL[7867.900306] add /devices/pci:00/:00:12.0/usb6/6-2/6-2:1.0/0003:16C0:04D2.000A/hidraw/hidraw3 (hidraw) KERNEL[7867.900398] bind /devices/pci:00/:00:12.0/usb6/6-2/6-2:1.0/0003:16C0:04D2.000A (hid) KERNEL[7867.900669] bind /devices/pci:00/:00:12.0/usb6/6-2/6-2:1.0 (usb) KERNEL[7867.900869] add /devices/pci:00/:00:12.0/usb6/6-2/6-2:1.1 (usb) KERNEL[7873.197477] add /device
Re: [gentoo-user] udev and coldplug blocking each other!
Mark wrote: Currently I have udev-087-r1 and coldplug-20040920-r1 installed. It would be my suggestion not to install udev-103 currently (it is marked as ~x86). Well, I bet you didn't do your emerge --sync this morning. It's x86 now. Regards, Hans. -- gentoo-user@gentoo.org mailing list
[gentoo-user] udev 084 breaks USB?
Hello! Today I updated from udev-081-r1 to udev-084. Since then, I can no longer use my USB devices, like my mouse or my flash card reader. Did anyone else notice this? Alexander Skwar -- Genius is one percent inspiration and ninety-nine percent perspiration. -- Thomas Alva Edison -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie wrote: > On Tue, Mar 13, 2012 at 04:38:08PM -0600, Canek Peláez Valdés wrote: >> On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie wrote: >> > Hello, Neil. > >> > On Tue, Mar 13, 2012 at 09:33:30PM +, Neil Bothwick wrote: >> >> On Tue, 13 Mar 2012 21:07:37 +, Alan Mackenzie wrote: > >> >> > But I really meant what functionality udev has that mdev lacks. For >> >> > example, mdev this morning recognised my USB stick being inserted, and >> >> > created /dev/sdc for it. > >> >> udev does a *lot* more than that, for example the persistent naming of >> >> network interfaces. More significantly, it can run programs based on >> >> device rules. > >> > This is where I start getting unhappy. Is there any need for this >> > blurring? Having device nodes is essential to a linux system, and >> > some programs use these nodes. Why must they be mashed together into a >> > tasteless mush? Is there some advantage to this I haven't twigged yet? > >> >> For example, usb_modeswitch installs a udev rule to switch a 3G USB >> >> modem from CD to modem mode, without which it won't work. > >> > Same question as above: why does that switching have to be done via the >> > device node system rather than via the driver. Isn't that what drivers >> > are for? > >> >> That's fine when you plug it into a running system, but when you boot >> >> with it plugged in, it can trip over itself because the usb_modeswitch >> >> executable is in /usr/sbin. > >> > Er, that's a different discussion altogether. ;-) > >> >> You could use this to argue that /usr should be mounted before udev is >> >> started, but you could just as well use it to argue that udev should not >> >> be trying to run such rules at the boot runlevel. > >> > Or that udev shouldn't have "rules". I still don't understand the basic >> > concept driving this thing. My HDDs don't need rules - they just need a >> > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate >> > drivers built into my kernel. > >> > Am I being stupid? Despite your example above, I still don't see what >> > udev is about, why it's necessary, or even why it's advantageous. > >> IMHO, the thing that most people are missing is the fact that neither >> udev nor Linux "got complicated". The computing world itself "got >> complicated". > > Not really. It's been getting more complicated since long before I > starting working in it in 1980. Nothing's changed there. > >> We have Linux running in the same beige machines it has been running >> since 1991, but it also runs in TVs, tablets, cellphones, fridges, >> cars, ebook readers, and (soon enough, I'm sure) the kitchen sink. >> This devices behave very differently from our old and beloved beige >> boxen. > > Not at the level of needing device nodes under /dev and drivers connected > to them, they haven't. > >> They need to handle lots of different hardware comming and going, via >> USB, Firewire, Bluetooth, WIMAX, and who knows what else in the future. > > Yes. That's why there's a generic facility for building arbitrary > drivers into a kernel. That's not new either. > >> The principal idea behind udev, is that we *don't* kown (we *can't* >> know) what hardware this or that machine is gonna have at some point. >> And we want the machine (and the new hardware) to "just work" when >> they are connected. > > Huh? What's that to do with udev? You're talking at far too high a > level of abstraction. The new hardware will "just work" if there are the > correct drivers built in. That's as true of udev as it is of mdev as it > is of the old static /dev with mknod. No, it is not. You are letting out the sine qua non of the matter: the device has to be built, *and the /dev file should exists*. I hope you are not suggesting that we put *ALL* the possible files under /dev, because that was the idea before devfs, and it doesn't work *IN GENERAL*. So, you need something to handle device files on /dev, so you don't need every possible device file for every possible piece of hardware. But then you want to handle the same device with the same device name, so you need some kind of database. Then for the majority of users, they want to see *something* happen when they connect aa piece of hardware to their computers
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 15, 2012 1:22 AM, "Canek Peláez Valdés" wrote:
>
> On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan wrote:
> >
> > On Mar 15, 2012 12:25 AM, "Canek Peláez Valdés"
wrote:
> >>
> >
> > >8 snip
> >
> >>
> >> That if I connect a USB wi-fi dongle, and it appears with the name
> >> wlan23, I want *every* time that dongle to have the wlan23 name .Good
> >> luck doing that without a database.
> >>
> >
> > That could -- should -- be handled by a script or a program that looks
up
> > the database, do the checks, and rename the node accordingly.
> >
> > All the device manager got to do is to plug in into the hotplug kernel
knob,
> > whereby it will be invoked on every hotplug event, and depending on the
> > nature if the device (which, in your example, fits the pattern "wlan*")
> > fires the script/program which performs the lookup+rename part.
> >
> > mdev can do that.
>
> udev already does it.
>
So does mdev. If writing a simple script is so distressing for you, why in
the world are you using Gentoo, with all its manual labor?
> > Put it under /bin
> >
> > Done.
>
> Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe
> I need a wireless connected NFS share). And...
>
> Not scalable. Doesn't solve the general case. You are seeing too small.
>
*You* are not seeing _at all_. Witness how the Fedora devs want to merge
/bin and /sbin
It *is* scalable. Ever tried du /usr?
The problem was -- is -- that package maintainers blindly put binaries
required for booting into /usr
> > The vast majority of Linux users, be they using PCs or smartphones, only
> > need a mechanism to handle hotplugs.
> >
> > udev can do it, but so can mdev (with the help of helper
scripts/programs).
>
> udev can do it *right now*, no hacks involved. Go and hack mdev until
> it handles *ALL* the cases udev handles, and see how complex it gets.
>
If you're so afraid of doing things manually, you have no business using
Gentoo in the first place.
Here's a prototype script to ensure that certain NICs will always end up
the way you want it named:
#!/bin/sh
mac="$( cat /proc/net/arp | awk -V dev="$MDEV" 'NR==1{next} $6==dev {print
$4}')"
name="$(awk -V mac="$mac" '$1==mac {print $2}')"
[ "$name" ] && mv /dev/$MDEV /dev/$name
exit 0
(Prototype, because I don't have access to a Linux box atm, so I can't test)
> Been there, tried that. What do you think devfs was? We tried this
> path already: it doesn't work, it doesn't scale. You couple together
> the device manager and the database handling and the firing of
> associated scripts because that's the technical correct solution. It
> *is* more complex, for sure, but so it's the general problem we are
> trying to solve.
>
If you step down from your high chair for awhile and read the busybox
thread I've been linking, you'll know the difference. One of the emails in
that thread explained it.
> > udev is going the kitchen sink route. mdev stays the lego brick path.
>
> And guess what? I don't want a toy solution built with lego blocks.
Obviously idioms went way over your head.
If you're taking the "Lego brick" allegory as literal, then good luck with
your kitchen sink. At least I know that with Lego bricks, amazing works of
art have been created. :-P
> I
> want a robust, general solution, that it is bound to work *now* and in
> the future.
>
So? What makes you think that in the future suddenly mdev stops working?
The flip side: as udev gets more and more complex, how could you be sure it
won't catastrophically fail one day, just like HAL?
> > Talk about double standards :-)
>
> When I hear Walt saying that mdev handles GNOME/KDE/XFCE/LVM2, you may
> say that. Right *now*, Walt says mdev doesn't handle those cases.
>
Walt said that mdev doesn't work with LVM2, but then Alan said that
actually LVM2 works after booting. It just didn't work during booting.
Suspiciously a case of missing/misnamed dev nodes to me, easily fixable by
adding some mdev.conf rules.
> Go and solve it then. I will keep using udev, which works right now,
thank you.
>
I am not using LVM, so I have no test case. But I certainly will pursue
this issue -- had you not derail the thread by slandering mdev with all
your might.
> >> With all due respect, Alan (and this is completely sincere, in this
> >> list you are of the guys I respect the most), I believe you are
> >> thinking too small.
> >>
> >
> > With all due respect, I believe *you* are too defen
Re: [gentoo-user] udev + /usr
On Thu, Sep 15, 2011 at 10:32 AM, Michael Mol wrote:
> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld wrote:
>>> I'm not entirely convinced this is the case, because it feels like
>>> some situations like network devices (nbd, iSCSI) or loopback would
>>> require userland tools to bring up once networking is up.
>>
>> Yes, but the kernel-events referencing those devices won't appear untill
>> after
>> the networking is brought up.
>> The scripts that "udev" starts are run *after* a device-event is created. If
>> the device itself has not been spotted by the kernel (for instance, the
>> networking doesn't exist yet), the event won't be triggered yet.
>>
>> This situation does not require udev to start all these tools when network-
>> devices appear.
>>
>> I hope the following would make my thoughts a bit clearer:
>>
>> 1) kernel boots
>>
>> 2) kernel detects network device and places "network-device-event" in the
>> queue
>>
>> 3) further things happen and kernel places relevant events in the queue (some
>> other events may also already be in the queue before step 2)
>>
>> 4) udev starts and starts processing the queue
>>
>> 5) For each event, udev creates the corresponding device-entry and places
>> action-entries in a queue
>>
>> 6) system-init-scripts mount all local filesystems
>>
>> 7) udev-actions starts (I made up this name)
>>
>> 8) udev-actions processes all the entries in the action-queue
>>
>> From step 4, udev will keep processing further events it gets, which means
>> that if any action taken by "udev-actions" causes further devices to become
>> available, "udev" will create the device-entries and place the action in the
>> action-queue.
>
> So, if I read this correctly, there are two classes of processing
> events. kernel events and scripted actions. Here's rough pseudocode
> describing what I think you're saying. (Or perhaps what I'm hoping
> you're saying)
>
> while(wait_for_event())
> {
> kevent* pkEvent = NULL;
> if(get_waiting_kernel_event(pkEvent)) // returns true if an event was waiting
> {
> process_kernel_event(pkEvent);
> }
> else
> {
> aevent* pAction = NULL;
> if(get_waiting_action(pAction)) // Returns true if there's an
> action waiting.
> {
> process_action(pAction);
> }
> }
> }
>
> So, udev processes one event at a time, and always processes kernel
> events with a higher priority than resulting scripts. This makes a
> certain amount of sense; an action could launch, e.g. nbdclient, which
> would cause a new kernel event to get queued.
>
>> If anyone has a setup where /usr can not be mounted easily, it won't work
>> currently either and a init* would be necessary anyway.
>> (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers, hosting /usr
>> or other required filesystems)
>
> I don't see how this is relevant to actually fixing udev. (See below)
>
>> But anyone with a currently working environment should be able to expect a
>> currently working environment. If it fails to boot with only updating
>> versions, it's a regression. And one of the worst kinds of all.
>
> I agree that the direction udev is going is a regression. There aren't
> very many people active in this thread who would disagree with that
> point. So let's just drop it and focus on what a good, general
> solution would look like. (And anyone who says something amounting to
> 'status quo' for udev needs another explanation of why the udev
> developer sees the current scenario as broken. And he's right; the
> current scenario is architecturally unsound. I just think he's wrong
> about the solution.)
Let me throw my own guess of how they came out with the corrent
proposed solution. I repeat: is my own guess: I am not the one calling
the shots, so maybe I'm completely wrong.
As many of you guys said, there are ways of solving the problem
without requiring an initramfs. Note that if you decide to use an
initramfs, every use case works: You can have a practically empty /,
throw everything in /usr, and have /usr in another partition, maybe
even an encrypted remote NFS share. With an initramfs you can have a
separate /var, you can even have a separated /etc, mounted even by NFS
too. You can do pretty much whatever you want, because you have a full
userspace *the moment you boot*. Bluetooth, network, LVM,
crypto-filesystems: Everything is available from the instant zero.
>From that perspective, the problem then is trying to support th
Re: [gentoo-user] /dev/sda* missing at boot
On Thu, Sep 8, 2011 at 6:33 PM, Mick wrote: > Unless I misunderstood this and referenced threads, all this agro is being > generated because udev devs decided to give primacy not to the linux fs and > prevailing FHS conventions, but their udev code and what may have been an easy > workaround for them? > > Given that I do not understand the ins and outs of udev, or the way gentoo and > upstream manage such proposals and ultimately accept changes, why don't gentoo > devs raise alternative options with the Fedora dev or who ever had this idea > upstream that udev code effort is more precious than all the workarounds > (initramfs, repartitioning, etc.) that some of us have to go through? > > The alternatives I've read so far that advocate the avoidance of the > imposition of an initramfs or merging /usr into / for the sake of a udev > design choice, seem more 'intelligent' to me - in a gentoo principle sort of > way. > > On the other hand, for a binary distro the udev dev approach would of course > seem less disruptive and therefore our small gentoo user base may need to > shout really loud to be heard. > > Do we get to vote on this? Not really: you can vote with your feet and use another distro/operating system. But the choice is theirs. > Can we make a difference other than venting here > and in the forums? Yes: design and write a different system. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] udev with separate /usr and no initramfs
Hi, Am Dienstag, 8. November 2011, 19:24:11 schrieb Steven J Long: > Hi, > > Following the debates over the summer, about plans to require an initramfs > for udev, I put together a slightly different approach using the dependency > tracking in openrc. It's outlined (in Unsupported Software) at: > http://forums.gentoo.org/viewtopic-p-6866484.html > and consists of a couple of simple patches to the initscripts for udev and > udev-mount, supporting a new initramfs option (defaults to "yes") in > udev.conf. I've been using it on my desktop at home for a couple of months > now and it works like a charm here. As ever, YMMV. interesting approach. > As I state in the post: > This is only for people who know they have all the modules built-in the > kernel to mount local filesystems, have a separate /usr and/or /var, and are > happy with their current setups, apart from possible future issues with > udev starting before localmount, and find the requirement for an initramfs > sufficiently annoying to tweak their setups, *and* are willing to deal with > keeping the lines in the initscripts during etc-updates. > > This is on stable udev (164-r2.) I'm not running unstable, so be careful if > you are, and let us know if there are any changes needed. You can get in > touch on IRC, or via the forum post. I am running ~amd64 and I'll try this, when I have some spare time. I'll let you know, how it works for me. Thanks a lot for this. > HTH, > igli. Best, Michael
Re: [gentoo-user] /dev/shm permissions drwxr-xr-x root:root ?
On 29/12/12 08:17, Walter Dnes wrote: > On Fri, Dec 28, 2012 at 02:10:26PM +0800, William Kenworthy wrote >> On 28/12/12 11:25, Walter Dnes wrote: >>> chmod 755 /dev/shm/hello >>> /dev/shm/hello >> >> as a user (not root) >> >> wdk@moriah /home/vm/qemu/mail $ vi /dev/shm/hello >> wdk@moriah /home/vm/qemu/mail $ chmod 755 /dev/shm/hello >> wdk@moriah /home/vm/qemu/mail $ /dev/shm/hello >> Hello World >> wdk@moriah /home/vm/qemu/mail $ >> >> worked fine. >> >> and >> >> moriah ~ # mount|grep shm >> none on /dev/shm type tmpfs (rw,relatime) >> moriah ~ # > > Are you on regular udev? I thought that /dev/shm was supposed to be > noexec as a security measure. > * sys-fs/udev Latest version available: 196-r1 Latest version installed: 196-r1 Size of downloaded files: 1,922 kB Homepage:http://www.freedesktop.org/wiki/Software/systemd Description: Linux dynamic and persistent device naming support (aka userspace devfs) License: LGPL-2.1 MIT GPL-2 * sys-fs/udev-init-scripts Latest version available: 18 Latest version installed: 18 Size of downloaded files: 4 kB Homepage:http://www.gentoo.org Description: udev startup scripts for openrc License: GPL-2 * virtual/udev Latest version available: 196 Latest version installed: 196 Size of downloaded files: 0 kB Homepage: Description: Virtual for udev implementation and number of its features License: I am waiting on eudev so I can dump it, but I also recently found "udevil" and am wondering if anyone can overview it and compare with eudev ... is it a similar project, or just for user mounting? BillK
Re: [gentoo-user] where is my /dev/cdrom using UDEV
gt-dell root # dmesg |grep ^hdhdc: SAMSUNG SC-140B, ATAPI CD/DVD-ROM drivegt-dell root # lf /dev/hd*ls: /dev/hd*: No such file or directoryI don't know why /dev/hdc does not exist.thanks,
WenjuOn 4/27/05, Robert S <[EMAIL PROTECTED]> wrote:
Try$ dmeg | grep ^hdand look for the CDROM drive. If this fails, try dmesg |less and lookfor it in the entire output.On 4/27/05, Wenju Zhang <[EMAIL PROTECTED]
> wrote:> I have try this. but the problem remains.> There is not /dev/hdc at all in my machine.>> thanks> zwj>>>> On 4/26/05, Robert S <
[EMAIL PROTECTED]>> wrote:> >> > Try this:> >> > Create a file called /etc/udev/rules.d/10- udev.rules> >> > Insert the following in the file
> >> > BUS="pci", KERNEL="hdc", SYSFS{vendor}="0x10de", NAME="%k",> > SYMLINK="cdrom cdroms/cdrom%n"> >> > You'll need to change the SYSFS{vendor} statement and you'll probably
> > need to reboot.> >> > There's a HOWTO in the gentoo docs on udev - and a very useful link on> > creating rules.> >> >> > On 4/26/05, Wenju Zhang <
[EMAIL PROTECTED]> wrote:> > > I have install gentoo 2005.0 with udev (without devfs) following> > > the gentoo udev guide,> > >
http://www.gentoo.org/doc/en/udev-guide.xml> > > and http://gentoo-wiki.com/HOWTO_Migrate_to_UDEV> > >> > > I can't find the /dev/cdrom.
> > >> > > FYI> > >> > > gt-dell rules.d # dmesg |grep hdc> > > Kernel command line: hdc=ide-cd ro> > > ide_setup: hdc=ide-cd> > > ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
> > > hdc: SAMSUNG SC-140B, ATAPI CD/DVD-ROM drive> > >> > >> > > help me, please.> > >> > > Thanks in advance.> > >> > > zwj
> > >> >> > --> > gentoo-user@gentoo.org mailing list> >> >>>--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Broken install?
Ryan Tandy wrote: > JimD wrote: >> OK, something weird is going on with a new install I just did. I might >> have hosed /dev. I though udev takes card of /dev? >> >> When I boot the new install, I get a kernel panic about the root= line >> in my grub.conf. So from the grub boot menu I press c and entered: >> >> root (hd0,0) >> Filesytem type is reiserfs... >> >> kernel /boot/kern[TAB] (grub auto-completes) root=/dev[TAB] >> Error 11: Unrecongnized device string. >> >> Did I break something or forget something? >> >> I booted into the gentoo install CD and mounted /dev/sda1 and /dev on my >> disk is empty. I started to mknod some devices, however that could take >> all night. Besides, I thought udev handles that? Or do I need a base >> set of device files for the kernel until udev kicks in? >> >> Jim >> > A truly empty /dev is a bad thing. /dev needs to contain AT LEAST > /dev/null and /dev/console in order for the kernel and baselayout to do > their thing until udev kicks in. Those two files are all my /dev has, > and it works fine. > > HTH. Hmm, my kernel would not boot when I created just /dev/null, /dev/console and /dev/sda* in the empty /dev. Once I did the steps I listed previously, the system booted fine. Did I miss some step with setting up udev? I have sys-fs/udev installed. What kernel options are required? Jim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= There's no place like 127.0.0.1 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= JimD Central FL, USA, Earth, Sol -- gentoo-user@gentoo.org mailing list
[gentoo-user] Updating Gentoo
Hello Everyone, Last time I did this we experience 3 hour downtime, and it was not fun. I was blue in the face: [1] N 2010-08-01 (2010-08-01-as-needed-default - removed?) [2] N 2012-03-16 (2012-03-16-udev-181-unmasking - removed?) [3] N 2012-05-21 Portage config-protect-if-modified default [4] N 2012-09-09 (2012-09-09-make.conf-and-make.profile-move - removed?) [5] N 2012-11-06 PYTHON_TARGETS deployment [6] 2013-03-29 Upgrading udev to version >=200 [7] 2013-06-07 Portage preserve-libs default [8] N 2013-06-30 Printer browsing in net-print/cups-1.6 [9] N 2013-08-23 Language of messages in emerge logs and output [10] N 2013-09-27 Separate /usr on Linux requires initramfs [11] N 2013-10-14 GRUB2 migration [12] N 2013-11-07 python-exec package move [13] N 2014-02-25 Upgrade to >=sys-fs/udev-210 [14] N 2014-03-02 Profile EAPI 5 requirement [15] N 2014-03-16 Ruby 1.8 removal; Ruby 1.9/2.0 default [16] N 2014-11-07 Upgrade to udev >= 217 or eudev >= 2.1 [17] N 2015-01-28 CPU_FLAGS_X86 introduction Grub2: Will this bring us down for days? Is it a hard transition Udev: Oh what a spider web you weave. We are using udev 204 right now. Please gents, is there a safe and easy way of doing this? I need to update the system but want to limit downtime as much as possible. Please help. N.
Re: [gentoo-user] Switching from eudev to udev, disaster.
On 2021-11-28 11:50-0500 Jack wrote: > This switch is NOT bringing in systemd. It is just switching which > package is now providing udev as extracted from systemd. The news > item actually gives a bit more detail. > > The network name switch (which I had thought was mentioned in the new > item, but apparently is not, so I don't remember where I read it) is > not directly due to eudev vs. udev, but to the "new" (years old at > this point) switch to consistent naming (or something like that) so > your network is probably something like enp20s2, reflecting which > slot your network card is physically in. I'm pretty sure there is a > kernel boot parameter which forces the old way, but can't find it > now, as I switched to the new naming with eudev, so switching to udev > didn't break anything for me. The name switch is announced via a warning message when you emerge udev: WARN: postinst udev-249 defaults to predictable interface renaming, as described in the URL below: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames If you wish to disable this, please see the above documentation, or set net.ifnames=0 on the kernel command line. You can change settings for log messages in make.conf, see /usr/share/portage/config/make.conf.example for documentation (search for PORTAGE_ELOG). I have PORTAGE_ELOG_SYSTEM="save echo:error,warn,log" in my make.conf. echo means the messages are displayed again when emerge exits. > […] Kind regards, tastytea -- Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at <https://tastytea.de/tastytea.asc>. pgpjFa3IJ8OoN.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
Mick wrote: > On Monday 07 Jan 2013 07:35:32 Dale wrote: > >> I think you misunderstand or I didn't make myself clear. I'm not saying >> it was udev that did this. I am pretty sure it was the kernel. All >> this happened when people with older IDE drives, myself included on my >> old machine, had to switch to the new drivers and devices. Before the >> change, old IDE drives and CD/DVD drives were given hd* devices and udev >> made a link to that with /dev/cdrom or dvd or whatever for optical >> devices which is what you seem to expect now. The reason udev did that >> was for it to be consistent which I have no problem with . When the >> kernel folks changed this, they also changed it from /dev/cdrom and >> /dev/dvd to /dev/sr0. From my understanding, all optical devices such >> as CD and DVD readers/burners are supposed to be sr0. I know k3b >> updated theirs too. I seem to recall I had to run a unstable version >> for a bit because the older version didn't have the code to see sr* >> devices. >> >> I never said anything was broke, just that it was changed. There was >> several things that was changed at about the same time that were related >> and this was just one of them. Another was the change from /dev/hdXX to >> /dev/sdXX for ALL hard drives. This change happened even if you was >> using the old IDE drives. As I understand it, /dev/hdxx is no longer >> supported on current kernels. All hard drives are /dev/sdxx and optical >> drives are /dev/sr0(1,2,3,4 etc). >> >> Also, I didn't remove anything. It was changed by the kernel which also >> lead to udev changing what it did. Again, as much as I dislike what >> udev is planning, I never said udev did this one. I'm pretty sure this >> was all started with the kernel devs. The udev folks just followed along. >> >> The biggest thing I recall is everyone with IDE drives having to update >> the kernel config, edit fstab and grub or lilo before rebooting. This >> was discussed on this list and I don't recall much fuss except for >> having to change it and update everything. It was sort of a one time >> thing and had a long term goal. All hard drives are sdxx and optical >> devices are srx. All this happened when I was on my old rig which was >> at least a few years ago. >> >> Does that make more sense now? >> >> Dale >> >> :-) :-) > > I think that you are conflating two issues which are separate in terms of > chronology at least. Years ago we moved to libata and hdX changed to sdX. > The udev confguration was updated at the time to link /dev/cd* and /dev/dvd* > to srX. > > More recently, the udev rules nomenclature changed. The udev persistent-cd > rules however was not changed. I moved it, remerged stable udev and the file > was not recreated. So something in udev has changed and it no longer > generates the persistent-cd rules. > > > BTW, pressing the touch sensitive button on the laptop to eject the CD won't > work, neither will typing eject in a terminal: > > $ eject > eject: tried to use `/mnt/cdrom' as device name but it is no block device > eject: unable to find or open device for: `cdrom' > > > So, eject is still looking for cdrom ... > > Either all commands and legacy apps should update themselves, or I better > follow Mark's suggestion? According to what I found, both changes were done at the same time. Link below is one place that I found saying both things were being changed in the kernel at the same time. There are others but anyway: http://lkml.indiana.edu/hypermail/linux/kernel/0608.1/0806.html There may have been other changes more recent in udev but if so, I missed them since this changed for me, and according to the list others too, years ago. I was on my old rig so it had to be several years ago since I have had my new rig a couple years and never had to deal with it during the install of Gentoo on it. I do think it's helpful for some to have a consistent link like cdrom or dvd. It appears someone else thinks people that find it helpful need to add their own rule. Either way, it can be made to work. Just trying to provide info based on my search results. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 11:03:09 AM Michael Mol wrote:
> On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld
wrote:
> > On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
> >> On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld
> >
> > wrote:
> >> >> I'm not entirely convinced this is the case, because it feels
> >> >> like
> >> >> some situations like network devices (nbd, iSCSI) or loopback
> >> >> would
> >> >> require userland tools to bring up once networking is up.
> >> >
> >> > Yes, but the kernel-events referencing those devices won't appear
> >> > untill after the networking is brought up.
> >> > The scripts that "udev" starts are run *after* a device-event is
> >> > created. If the device itself has not been spotted by the kernel
> >> > (for
> >> > instance, the networking doesn't exist yet), the event won't be
> >> > triggered yet.
> >> >
> >> > This situation does not require udev to start all these tools when
> >> > network- devices appear.
> >> >
> >> > I hope the following would make my thoughts a bit clearer:
> >> >
> >> > 1) kernel boots
> >> >
> >> > 2) kernel detects network device and places "network-device-event"
> >> > in
> >> > the
> >> > queue
> >> >
> >> > 3) further things happen and kernel places relevant events in the
> >> > queue (some other events may also already be in the queue before
> >> > step 2)
> >> >
> >> > 4) udev starts and starts processing the queue
> >> >
> >> > 5) For each event, udev creates the corresponding device-entry and
> >> > places
> >> > action-entries in a queue
> >> >
> >> > 6) system-init-scripts mount all local filesystems
> >> >
> >> > 7) udev-actions starts (I made up this name)
> >> >
> >> > 8) udev-actions processes all the entries in the action-queue
> >> >
> >> > From step 4, udev will keep processing further events it gets,
> >> > which
> >> > means that if any action taken by "udev-actions" causes further
> >> > devices to become available, "udev" will create the
> >> > device-entries and place the action in the action-queue.
> >>
> >> So, if I read this correctly, there are two classes of processing
> >> events. kernel events and scripted actions. Here's rough pseudocode
> >> describing what I think you're saying. (Or perhaps what I'm hoping
> >> you're saying)
> >>
> >> while(wait_for_event())
> >> {
> >> kevent* pkEvent = NULL;
> >> if(get_waiting_kernel_event(pkEvent)) // returns true if an event
> >> was
> >> waiting {
> >> process_kernel_event(pkEvent);
> >> }
> >> else
> >> {
> >> aevent* pAction = NULL;
> >> if(get_waiting_action(pAction)) // Returns true if there's an
> >> action waiting.
> >> {
> >> process_action(pAction);
> >> }
> >> }
> >> }
> >
> > This is, sort-of, what I feel should happen. But currently, in
> > pseudo-code, the following seems to happen:
> > while(wait_for_event())
> > {
> > kevent* pkEvent = NULL;
> > if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
> > waiting {
> >process_kernel_event(pkEvent);
> > }
> > }
> >
> > I would prefer to see 2 seperate processes:
> >
> > --- process 1 ---
> > while(wait_for_event())
> > {
> > kevent* pkEvent = NULL;
> > if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
> > waiting
> > {
> >action_event = process_kernel_event(pkEvent);
> >if (action_event != NULL)
> >{
> > put_action_event(pkEvent);
> >}
> > }
> > }
> >
> > --
> >
> > --- process 2 ---
> > while(wait_for_event())
> > {
> > aevent* paEvent = NULL;
> > if(get_waiting_action_event(paEvent)) // returns true if an event was
> > waiting
> > {
> >process_action_event(paEvent);
> > }
> > }
> > ---
> >
> >> So, udev processes one event at a time, and always processes kernel
> >> events with a
Re: [gentoo-user] kdm & french keyboard
Le lundi 12 juillet 2010 10:31:34, Neil Bothwick a écrit :
> On Sun, 11 Jul 2010 19:19:25 +0200, Stéphane Guedon wrote:
> > > How? I know how to use udev for device recognition, but how do you
> > > tell it to use a particular keyboard layout?
> >
> > 19:18:09 steph...@luciole:/etc/udev/rules.d $ cat 61-x11-input.rules
> > SUBSYSTEM!="input", GOTO="x11_input_end"
> > ACTION!="add", GOTO="x11_input_end"
> >
> > KERNEL=="event*", ENV{x11_driver}="evdev"
> > KERNEL=="event*", ENV{ID_INPUT_KEYBOARD}=="1
> >
> > ENV{ID_INPUT_KEY}=="?*", ENV{xkblayout}="fr"
> >
> > LABEL="x11_input_end"
> > ===
>
> Interesting, but it seems more complex that a simple stanza
> in /etc/X11/xorg.conf.d. Using udev rules for something that will only be
> used by one application adds unnecessary complication, IMO. If only X
> will use the information, I'd prefer to put in in the X configuration
> directory.
I agree with you, but I like to make things in order with the rules (without
relation to udev).
But I don't like udev, its syntax is really hard to understand for user !
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] udev broken...
On Saturday 28 November 2009 17:04:10 BRM wrote: > > You also mention /dev/hda and the context implies it is a physical disk. > > Unless you have ancient disk hardware and unusual module setup, your > > disks will be /dev/sda. Do you have references to /dev/dh** in > > /etc/fstab? That won;t work as udev will not name them that way > > Actually, yes - it is a 2003 Dell D600 with a standard ATA/IDE hard drive. > So yes - it would be /dev/hda; and yes, udev has been working fine until > this issue. > For quite some time now IDE drives have been handled below the SCSI subsytem so you do in fact get a /dev/sda, except when using the old deprectaed IDE driver that has been around for ages. That one uses /dev/hda, and it's very unusual these days to find it. You should check what the kernek you are running is using and what udev calls those things as it very likely is not the same as what it was before your kernel & udev upgrade. I want to eliminate obvious things before we go looking for exotic things -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] udevd boot messages
On 05/21/2012 03:27 PM, Michael Hampicke wrote: >> I updated udev from 171-r5 to 171-r6 and now i get several udevd >> boot message as : udevd[1389]: can not find >> '/lib/udev/rules.d/90-network.rules': No such file or directory >> udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules': No >> such file or directory .. and so on. >> >> /lib is a symlink pointing to /lib64. /lib64/udev/rules.d is ok >> with all the rules that udevd does not find at boot. > > No I would guess it was because of the upgrade of > sys-apps/baselayout to 2.1-r1. Things got crazy here with that > upgrade. I had to re-merge every package with files under /lib/ In > your case re-merging udev should to the trick. > The package clearly informed you that you need to reboot for things to work properly "You should reboot the system now to get /run mounted with tmpfs!" Have a look on pkg_postinst() function in that ebuild. You chose to ignore it and this is why you had these problems after the update. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-user] udev + /usr
On Wed, Sep 14, 2011 at 12:05 PM, Allan Gottlieb wrote: > On Wed, Sep 14 2011, Michael Mol wrote: > >> On Wed, Sep 14, 2011 at 11:36 AM, Neil Bothwick wrote: >>> On Wed, 14 Sep 2011 10:49:29 -0400, Michael Mol wrote: >>> >>>> > > Trust me, you would want to run a udev that contained any code >>>> > > written by me! >>>> > >>>> > No offense man, but I don't know you enough so I "would want to run a >>>> > udev that contained any code written by" you. >>>> >>>> He forgot to include tags. >>> >>> No I didn't. You truly would not want to run anything coded by me :( >> >> Ok, then you left out the tags. :) > > To continue the analysis of "the words of neil" :-) I believe he simply > forgot a "not". Instead of > > Trust me, you would want to run a udev that contained any code written > by me! > > neil probably meant > > Trust me, you would not want to run a udev that contained any code > written by me! Oh, didn't see that. Thanks. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] udev + /usr
On Thu, 15 Sep 2011 17:37:53 +0200, Joost Roeleveld wrote: > There are 3 solutions for this: > 1) The easy way out: the whole user-space must be available before udev > 2) udev actually includes correct error-handling for this and retries > 3) udev splits this into 2 seperate tools 4) udev remains one tool but with two modes of operation. when in early-boot mode, it can only run a restricted set of rules - such as those using LVM, RAID, cryptsetup, network device naming. When switched to "full" mode later in the boot process, it loads the rest of the rules. Which rules it runs it early-boot mode could be decided by adding a flag to the rule to mark it acceptable for early boot usage. That way, existing rules would automatically be deferred unless package maintainers update the rules for those they know will work early in the boot process. It saves writing/learning/debugging a new tool and gives maximum compatibility with existing configurations. This is pretty similar in concept to your suggestion 3, but a different approach to its implementation. -- Neil Bothwick No, you *can't* call 999 now. I'm downloading my mail. signature.asc Description: PGP signature
Re: [gentoo-user] Re: [ANNOUNCE] I like systemd now :)
On Sun, 11 Nov 2012 21:32:41 +0800 微蔡 wrote: > 在 2012年11月11日 星期日 07:22:41，Bruce Hill 写道： > > On Sun, Nov 11, 2012 at 01:49:03PM +0100, Volker Armin Hemmann > > wrote: > > > hate is a natural reaction if something you don't need and don't > > > want is forced upon you. If it is also based on lies, hate is a > > > valid reaction. A lot of people don't need nor want pulseaudio or > > > systemd. Now it is forced on everybody. > > > > > > When systemd devs took over udev, one was told that of course, > > > one could use udev without [systemd] in the future. > > > > > > Now they are talking about making udev systemd only. > > obsolutly nonsense. what they remove , is the ability to build udev > seperately. udev can still be used without systemd. > Say Dude, I have a question (well, two actually) My name is Alan and I've been subscribed on this list for 7 years. What's your name, and how long have you been around? Just trying to establish your place in the pecking order in this here meritocracy. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Ethernet Machination
On Wed, Jan 2, 2013 at 7:53 AM, Tanstaafl wrote: > On 2013-01-01 7:55 PM, Canek Peláez Valdés wrote: >> >> On Tue, Jan 1, 2013 at 6:50 PM, James wrote: >>> >>> So now that only one ethernet shows up, how do I prevent >>> udev from renaming eth0 to eth3? > > >> Check /etc/udev/rules.d/70-persistent-net.rules. Probably the old >> (fried) ethernet card is listed there (along with other stuff). Leave >> out everything except your PCI card (the MAC address is how you tell >> them appart). >> >> Worst case, delete the file (after saving a copy), and see if udev >> automagically solves everything by itself. > > > Also, be sure that you have completely disabled the integrated ethernet in > the BIOS, otherwise gentoo/udev may still 'see' it even if it isn't > working... > I once had an onboard NIC go bad, and the PCI NIC I substituted for it wouldn't work unless the onboard NIC was disabled. So disabling onboard hardware may or may not be a net positive. So long as there are no drivers available for the onboard NIC, it won't show up in the net subsystem, so udev won't tie it in under net rules. -- :wq
Re: [gentoo-user] udev-197 moves from /usr/lib to /lib
On Fri, Jan 11, 2013 at 4:33 PM, Walter Dnes wrote: > On Fri, Jan 11, 2013 at 10:42:37AM -0600, Canek Pel??ez Vald??s wrote > >> No, because the problem has never been in udev (nor systemd, for that >> matter). It fixes how *Gentoo* packages udev; probably the devs read >> the following comment from Lennart (note it was written almost a month >> ago): >> >> https://plus.google.com/u/0/115547683951727699051/posts/jcCjMct3SJ3 > > The systemd defenders are using "separate /usr" as a "wookie defense" > in an attempt to divert attention form the main issue. Separate /usr > is actually a secondary issue. The main issue is whether or not we get > systemd rammed down our throats. Lennart and Kay are the people > responsible for scaring others into mdev and/or eudev. Ubuntu wants systemd even less than Gentoo. I will not be surprised if Gentoo makes systemd the recommended default before Ubuntu. And yet, Ubuntu doesn't want to fork udev, and actually a Canonical employee has git access to the udev/systemd tree. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] odd /dev/null beharvior
I've experienced this problem before. The developers insist the ebuild
is absolutely correct, but it doesn't always attempt to migrate conf
changes to /etc/udev.
The easiest way to fix this problem permanently is to
$ sudo rm /etc/udev/{permissions,rules}.d/50-*
$ sudo emerge -av udev
This will blow away the default udev conf files that are causing you
problems, then re-emerge udev. The updated defaults will be installed in
the right place. This assumes you haven't touched the 50-* files (you
put all custom changes in 10-local, right).
-Chris
On 16:46 Sat 18 Feb , James wrote:
> Hello,
>
> /dev/null is acting weird. The permissions have recently changes
> on a system I sync regularly. I can change the permissions back
> to 666, but every time the system reboots, dev null resets to:
> crw-rw 1 root 1, 3 Jan 20 10:05 /dev/null
>
> How to I make permanent changes so that /dev/null is 666 again?
>
> Surely this is not part of some security issue that I missed?
>
> James
>
>
>
> --
> gentoo-user@gentoo.org mailing list
>
--
Christopher Cowart
Unix Systems Administrator
Residential Computing, UC Berkeley
"May all your pushes be popped"
signature.asc
Description: Digital signature
Re: [gentoo-user] re-scanning for devices
On 2/26/06, Richard Fish <[EMAIL PROTECTED]> wrote:
> On 2/25/06, Nick Smith <[EMAIL PROTECTED]> wrote:
> > is there a way to rescan for devices after bootup? like if i
> > hot-plugged a scsi drive into the machine after it was already
> > running? how can i re-detect the hardware?
>
> If you are using udev, and have configured the kernel for hotplug
> support, this should not be necessary. The kernel will generate the
> appropriate hotplug events, and udev will create the device nodes.
>
> >
> > also, what if it detects a drive as sda, and i want it to be sdb? is
> > there a way i can tell it what i want to be sda, sda etc? without
> > actually having to move the drives around?
>
> Write udev rules to create persistent device names.
>
> An example:
> BUS=="usb", KERNEL=="sd[a-z]2", SYSFS{serial}=="30005AF6",
> SYMLINK="%k", NAME="backups%e"
>
> -Richard
>
> --
> gentoo-user@gentoo.org mailing list
>
>
its actually running a 2.4 kernel on sparc, and i dont think they use
udev, i think they are still on devfs. IIRC. is udev the only way to
accomplish this?
Nick
--
gentoo-user@gentoo.org mailing list
[gentoo-user] Re: udev: lost dvd
James tampabay.rr.com> writes: > > 2. Write a custom rule for your device, and add it to > > /etc/udev/rules.d/10-local.rules. Something like this should do the > > trick: > OK, this file does not exist, only: > -rw-r--r-- 1 root root54 Sep 14 10:38 30-svgalib.rules > -rw-r--r-- 1 root root 11492 Nov 17 18:31 50-udev.rules > so I created it: > -rw-r--r-- 1 root root 120 Nov 17 18:47 10-local.rules > > KERNEL=="hdc", NAME="%k", GROUP="cdrom", ACTION=="add", > > SYMLINK+="_dvd%e", IMPORT="/sbin/cdrom_id --export $tempnode" > cat /etc/udev/rules.d/10-local.rules > KERNEL=="hdc", NAME="%k", GROUP="cdrom", ACTION=="add", > SYMLINK+="dvd%e", IMPORT="/sbin/cdrom_id --export $tempnode" I tried it with this line a 2 lines in the file /etc/udev/rules.d/10-local.rules and as a single line. cat /etc/udev/rules.d/10-local.rules KERNEL=="hdc", NAME="%k", GROUP="cdrom", ACTION=="add", SYMLINK+="dvd%e", IMPORT="/sbin/cdrom_id --export $tempnode" Neither way workd and I get the same error messages from kaffeine as before? I guess it's time to remove vixie-cron and emerge 'syslog-ng' ? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] udevstart at boot?
On Sunday 18 December 2005 14:14, a tiny voice compelled Daniel Drake to write: > Ernie Schroder wrote: > > I'm obviously looking in the wrong places, but I can't find documentation > > on getting udev to start at boot. Sound and a few other things you don't > > notice right away fail to work until I do: > > # udevstart > > /dev/dsp is created with correct permissions and I'm good to go. The > > question is: > > How to I get udev to start at boot? > > Which version of udev do you have installed? > What is the output of "cat /proc/sys/kernel/hotplug"? > > Daniel $ emerge -vp udev [ebuild R ] sys-fs/udev-070-r1 (-selinux) -static 0 kB $ cat /proc/sys/kernel/hotplug /sbin/udevsend I have added /sbin/udevstart to /etc/conf.d/local.start and it seems that /dev/dsp is recreated with the right permissions and the annoying message is gone. Not the most elegant solution, but effective. -- Regards, Ernie 100% Microsoft and Intel free 14:46:10 up 3:47, 3 users, load average: 0.31, 0.46, 0.49 Linux 2.6.14-gentoo-r42.6.14-r-4_new i686 AMD Athlon(tm) XP 2400+ -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] udev and external harddisk, some more info
On Sat, Aug 19, 2006 at 01:59:36PM -0700, Penguin Lover Richard Fish squawked: > Hrm, we can only hope that the API between the kernel and udev > stabilizes in the future. It really should _not_ be necessary to > change kernel versions when upgrading udev or vice-versa. Now that you mentioned it, it would've been nice if there were a notice to that effect when I upggraded udev. And I *do* read the portage emerge logs. But now I am just basking in the happiness of everything working like it's supposed to: udev, kernel, even xorg7. W -- Proof that "Suki is good": according to spaceballs: "[now we know evil will always triumph, because] good is dumb" according to S: "ok, now I feel really dumb" the proof follows. ~~~ (on W's attempt to prove the phrase "suki is good" by syllogism) S: it's okay, you don't need to proove [sic] it: it's a definition W: nice S: i spelled prove wrong S: geez W: don't worry W: that doesn't make you evil. Sortir en Pantoufles: up 4:06 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Wed, Apr 03, 2013 at 11:28:10PM +0100, Mick wrote: > On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote: > > > Therefore, all's well that's still working! And AFAIR, on at least 2 of > > those machines, the 70-persistent-net.rules was never something I did > > manually. > > Right, it used to be auto-generated by udev scripts. With udev-200 you are > meant to remove it along with any other files from your /etc/udev/rules.d/ > > If you left them there and their syntax is still valid, then udev will parse > them and do as is told. > > -- > Regards, > Mick Why are we "meant to remove it"? Why would we remove them, since they're working? My kernel(s) all have eth* and none of that weirdness others reported. Thanks, Bruce -- Happy Penguin Computers >') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] is zfs no longer compatible with systemd?
On 10/07/2015 11:51 PM, cov...@ccs.covici.com wrote:
In trying to emerge sysf-fs/zfs today I get the following
[ebuild R *] sys-fs/zfs-::gentoo USE="rootfs -bash-completion
-custom-cflags -debug (-kernel-builtin) -static-libs -test-suite"
PYTHON_TARGETS="python2_7 python3_4 -python3_3" 0 KiB
[blocks B ] >=sys-fs/udev-init-scripts-28
(">=sys-fs/udev-init-scripts-28" is blocking sys-fs/zfs-)
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Conflict: 1 block (1 unsatisfied)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(sys-fs/zfs-:0/0::gentoo, ebuild scheduled for merge) pulled in by
sys-fs/zfs required by @selected
sys-fs/zfs
(sys-fs/udev-init-scripts-30:0/0::gentoo, installed) pulled in by
>=sys-fs/udev-init-scripts-25 required by
(sys-apps/systemd-226-r1:0/2::gentoo, installed)
Am I reading this correctly, or is there a way to satisfy the block?
Just from your output and reading the ebuilds you can downgrade to
udev-init-scripts-27
[gentoo-user] systemd-boot on openrc
Hello list, I've been using bootctl from sys-boot/systemd-boot for several years, with some success, but I'm stuck after today's --sync. First I was told I had to keyword sys-apps/systemd-utils, so I did that, but now I get this, which I can't decode: Calculating dependencies ... . . done! [ebuild N~] sys-apps/systemd-utils-250.4::gentoo USE="boot (split-usr) sysusers tmpfiles udev (-selinux) -test" ABI_X86="(64) -32 (-x32)" 10,872 KiB [ebuild U ~] sys-boot/systemd-boot-250::gentoo [249.9::gentoo] 0 KiB [blocks b ] =sys-fs/ udev-232:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?] (>=sys-fs/udev-232:0/0[abi_x86_64(-)]) required by (virtual/libudev-232- r5-2:0/1::gentoo, installed) USE="-systemd" ABI_X86="(64) -32 (-x32)" >=sys-fs/udev-217 required by (virtual/udev-217-r3-1:0/0::gentoo, installed) USE="" ABI_X86="(64)" This is an amd64 openrc system. On another system, ~amd64 openrc, I was told to set USE=boot on systemd-utils, so I did that and now when I boot I have no mouse or keyboard. Is this the end of the road for systemd-boot on openrc? -- Regards, Peter.
Re: [gentoo-user] Re: udev -> eudev
On Tue, 9 Feb 2016 13:30:04 + (UTC), James wrote:
> sys-apps/systemd is not even installed, but it shows up as a blocker?
> gentoo-systemd-integration is not installed, but it's a blocker.
It's showing up because it is blocking your update, which means something
you are installing as part of that update wants it. You have two choices:
1) Start uninstalling important stuff at random until either the
problem goes away or you break your system badly enough to need a
reinstall.
2) Use --tree to see exactly what is pulling in the blockers, and why,
then deal with that.
> udev::
> [I] virtual/udev
> Available versions: 215 ~217 {systemd}
> Installed versions: 215(10:34:27 PM 02/15/2015)(-systemd)
That's only the virtual, that can be satisfied by udev, eudev or systemd.
If you don't choose one, portage will choose for you.
> So, for me it's time to take the risk and remove udev and install eudev.
> I do appreciate guidance and wisdom and especially syntax ideas, but
> the decision is already made.
--
Neil Bothwick
Is it possible to be totally partial?
pgpJ9K1JU2SIc.pgp
Description: OpenPGP digital signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Sun, Mar 11, 2012 at 05:09:12AM -0400, Walter Dnes 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 Yep, I got the (effectively) unbootable machine: My LVM partitions didn't get mounted. My precaution against it was: (i) Copy my entire (working) root partition to a new partition. (ii) Edit the first line of the new /etc/fstab. (iii) Add a new entry to /etc/lilo.conf. It's handy having a small root partition. :-) > 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. I may have an unusual setup, but I don't think so. I've got my root partition as ext2 on /dev/sda5, and everything else under LVM. Otherwise, pretty standard. > 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. How do I know whether my /sbin/linuxrc actually ran? Maybe, I mean how can I be sure my "append = "init=/sbin/linuxrc"" actually worked? > 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 Done > 5) reboot to your new kernel. You're now running without using udev. Here's where I got problems. None of my LVM partitions got mounted. Here're a few lines of my bootup messages, just before the problem: * Setting up mdev as hotplug agent ... * Populating /dev with existing devices with mdev -s ... * Mounting /dev/pts ... * Mounting /dev/shm ... Enter runlevel: 3 * Setting up system clock using the hardware clock [UTC] * Setting up the Logical Volume Manager * Checking local filesystems /dev/sda5: clean, 6052/655360 files, 180423/2621440 blocks fsck.ext3: No such file or directory while trying to open /dev/vg/usr . > 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 Help would be appreciated. > -- > Walter Dnes -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Mar 21, 2012 2:52 AM, wrote: > > Daddy wrote: > > > On March 11, 2012 at 5:09 AM Walter Dnes 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 > > > > > > > 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. > OK, I am not seeing mdev in the portage tree -- I would like to learn > more about this before I take the plunge. So where do I get it and does > it create the appropriate device nodes, etc? > The creation of device nodes mostly are done by the devtmpfs of the kernel. I recommend the linuxrc to look like this : #!/bin/busybox ash mount -t proc proc /proc mount -t sysfs sysfs /sys echo /bin/mdev > /proc/sys/kernel/hotplug /bin/mdev -s exec /sbin/init Before booting, ensure /bin/mdev exists and is a symlink to /bin/busybox. The rest, just follow the steps outlined by waltdnes Rgds,
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, Dec 25, 2012 at 9:54 AM, Dale wrote: > Mark David Dumlao wrote: >> On Tue, Dec 25, 2012 at 1:15 AM, Bruce Hill >> wrote: >>> On Mon, Dec 24, 2012 at 11:05:25AM -0600, Dale wrote: >>>> Bruce Hill wrote: >>>> >>>> <<< SNIP >>> >>>>> No initrd... >>>> YET!!! ROFL >>>> >>>> When eudev goes stable, then we can disregard that yet. ;-) >>>> >>>> Dale >>> devfs still works wonderfully ... for principle, if no other reason, that >>> file >>> server will *NEVER* have an initrd image >> You shouldn't need to wait for eudev. >> >> Technically any early mount system configured and done _before_ udev >> should do the trick. I mean, it's not like udev is even *essential* >> for boot - that we happen to depend on it is just a matter of >> convenience. Shouldn't be hard to write an rc script that does just >> that for anyone that hates init thingies bad enough. Just hardcode an >> n-second sleep and plug in the kernel detected device name. Do rc >> scripts count as "init thingies"? :) > > Is that what eudev is going to do? I follow -dev and according to the > eudev people they are going to support a separate /usr with no init > thingy. So, they have a plan to do this. From what they were posting, > they seem pretty sure they can do this. Contrary to all the noise in this topic, udev itself works on /. The thing is this: udev is now being _installed to_ /usr instead of /. This is an upstream decision. See, there's a common bug with a lot of programs using udev. They are also installed to /usr instead of to /. And so those programs will _silently_ fail when /usr isn't mounted. Silent failures are deemed a bad thing by some people, worse so than noisy failures, something to do with the Unix philosophy of failing early and loudly. Now, you can install udev to / if you want - by writing a custom ebuild that does just that. And it should, in theory, work. But if you want it to run without hitches, you _must_ make sure /usr is mounted in time for all the rules to run. That's why an early mount script will fix any issues with udev. One way of getting an early mount script - the most reliable and comprehensively tested one - is to use an "init thingy". I haven't used one in a long time, but you generally just run a script, mkinitrd/mkinitramfs/dracut, that generates it for you. The init thingy is a compressed filesystem that contains just enough tools and modules you need to test and mount your filesystems. Which, conspicuously, was supposed to be the reason for the / being separated from the /usr filesystem. But besides the point - it's not the only way. You could just write a mount script yourself, and force your mount script to run before udev does, by editing udev's dependencies in /etc/conf.d/udev. That will also fix any issues udev has with /usr. The eudev team did a different thing. They forked udev and changed some bits around that they didn't like. But the one thing they didn't fix - which by definition they cannot fix - is the fact that programs depending on eudev - and installed to /usr - will _still_ need /usr mounted beforehand to function properly. A lot of us don't have those programs, or invoke those programs late enough in the system uptime that /usr is guaranteed to be mounted. So we just coincidentally happen to not run into any trouble. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] devfs to udev upgrade issues [SOLVED]
Top Post Alert!! After meddling with it and recompiling my kernel w/o DEVFS at all, I managed to get it to work. (though the error has nothing to do with the DEVFS being compiled into the kernel [but not to be mounted automatically]) The error is very...very... very.. subtle and I'm not sure why I have this issue at all. Could be remmants from devfs being mounted automatically at boot?? Anyway.. I found out the file/block device /dev/.devfsd was the reason for it to not be able to go to udev. and since there's a "clear" command in /sbin/rc before it does that "The Gentoo system init." I didn't catch the error message. The MEssage was cannot remove /dev/.devfsf - read only filesystem. So.. the solution was to go to single mode and then remount the root fs read-write and then proceed to delete /dev/.devfsd Yipee.. Now I have udev working. I plug in my USB key, /dev/sda[1] is created and deleted automatically as I plug in/out the key. So.. RIght now, it's working.. Cool. On Mon, 2005-05-09 at 11:46 +0800, Ow Mun Heng wrote: > I tried to upgrade(?) from devfs to udev(045) today and it was > miserable. > > I followed the Gentoo Udev Guide as well as DSD's guide but no go. > > I've recompiled my kernel(2.6.11) to _not_ mount /dev/ automatically at > boot. (devFS is still compiled into the kernel) > > edited /etc/conf.d/rc > RC_DEVICES="auto" > RC_DEVICE_TARBALL="yes" > RC_DEVFSD_STARTUP="yes" > > changed my kernel (grub) line to append gentoo=nodevfs > > Rebooted and faced a lot of issues. > > The 1st would be the obvious /sbin/rc file : > > The Gentoo Linux system initialization scripts have detected that" > your system does not support DEVFS or UDEV. Since Gentoo Linux" > has been designed with these dynamic /dev managers in mind, it is" > highly suggested that you build support for it into your kernel." > Please read the Gentoo Handbook for more information!" > > I continue booting and I find that in the _worst_ case, I can't load > up /dev/hda3 (root) due to a missing/invalid/non-existant symlink > in /dev > > I tried executing udevstart and it spurt out these (bunch of) lines > in /var/log/messages > > configured rule in '/etc/udev/rules.d/50-udev.rules' at line 133 > applied, added symlink '%k' > > configured rule in '/etc/udev/rules.d/50-udev.rules' at line 133 > applied, 'vcs3' becomes 'vcc/%n' > > > I tried a few variants but all of them no go. I finally relented and > removed udev and reverted back to my old kernel (/dev/ mounted > automatically at boot) > > I boot into the original kernel and now I see these errors : > > devfs_mk_dev: could not append to parent for vcc/2 > devfs_mk_dev: could not append to parent for vcc/3 > devfs_mk_dev: could not append to parent for vcc/a3 > devfs_mk_dev: could not append to parent for vcc/4 > devfs_mk_dev: could not append to parent for vcc/a4 > > Guys... There are 2 ways to fix this. > > 1. Help me get udev running again. (but why do I need udev anyway??) > 2. Help me get devfs running again. Right now.. I see it's only those > few errors above and everything seems to be working. > > > > > -- > Ow Mun Heng > Gentoo/Linux on DELL D600 1.4Ghz > 98% Microsoft(tm) Free!! > Neuromancer 11:31:20 up 25 min, 5 users, load average: 1.48, 1.39, 0.87 > > -- Ow Mun Heng Gentoo/Linux on DELL D600 1.4Ghz 98% Microsoft(tm) Free!! Neuromancer 14:37:00 up 18 min, 5 users, load average: 0.31, 0.63, 0.59 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 04/01/2013 03:26 PM, William Hubbs wrote: > On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote: >> Nuno J. Silva (aka njsg) wrote: >>> On 2013-03-31, Dale wrote: >>>> Nuno J. Silva (aka njsg) wrote: >>>>> On 2013-03-31, Dale wrote: >>>>>> Pandu Poluan wrote: >>>>>>> >>>>>>> Since it's obvious that upsteam has this "my way or the highway" >>>>>>> mentality, I'm curious about whether eudev (and mdev) exhibits the >>>>>>> same behavior... >>>>>>> >>>>>> I synced yesterday and I didn't see the news alert. Last eudev update >>>>>> was in Feb. so I *guess* not. It seems to be a "udev" thing. That is >>>>>> why I mentioned eudev to someone else that was having this issue with a >>>>>> server setup. >>>>> I'd guess eudev will eventually do the same, although I hope that, it >>>>> being a separate codebase, makes it easier to adopt some solution like >>>>> the old rule generator, instead of using udev's approach. >>>>> >>>>> The udev upstream may have its issues, but there's actually a point in >>>>> removing this, the approach there was so far was just a dirty hack. >>>>> >>>> >>>> Thing is, it works for me. The old udev worked, eudev works but I'm not >>>> sure what hoops I would have to go through to get the new udev working, >>>> most likely the same ones others here are going through now. For once, >>>> I'm not having to deal with some broken issue. < knock on wood > >>>> >>>> My current uptime is about 190 days. May hit it still but I'm certainly >>>> hoping I don't. >>> And, at least now, I have got enough knowledge to know whether it >>> affects me or not. But the sad thing is that I got most of that >>> knowledge *after* the first of these versions without the old script was >>> stabilized. >>> >> >> >> I switched to eudev when the separate /usr thing popped up. While I am >> watching this thread and sort of taking mental notes, I'm hoping this is >> not a eudev thing, even in the future. > > You know that both udev and eudev have exactly the same issue with > separate /usr right? > > The problem there isn't in the udev code, but it has to do with what is > happening in rules that other packages install. As I recall, the problem is where the ebuild choses to install the code. Putting the udev code under /usr forces the issue on systems where it would otherwise not be an issue. Putting the udev code under / avoids that issue, but opens up the system to the "silently fail" thing upstream liked to use as the basis of "separate /usr is broken" So, there are three conceivable configurations (initramfs notwithstanding): 1. With systems which don't require /usr binaries before /usr would be mounted, separate /usr is not a problem. 2. With systems which require /usr binaries for some features before /usr would be mounted, those features will silently fail. 3. With systems which require /usr binaries to mount /usr, all hell breaks loose. Putting the udev code under /usr moves all udev systems from group 2 into group 3. In a sense, this fixes those systems because the admin is forced to address the silent failures he was previously unaware of. It also means pissing off a bunch of people who had features silently failing...but they probably didn't know or care about those features in the first place. It also moves all systems from group 1 into group 3...which is simply wrong. So long as eudev keeps its install path at / instead of /usr, admins in group 1 will probably be perfectly happy. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Michael Mol wrote: > On 04/01/2013 03:26 PM, William Hubbs wrote: >> On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote: >>> Nuno J. Silva (aka njsg) wrote: >>>> On 2013-03-31, Dale wrote: >>>>> Nuno J. Silva (aka njsg) wrote: >>>>>> On 2013-03-31, Dale wrote: >>>>>>> Pandu Poluan wrote: >>>>>>>> >>>>>>>> Since it's obvious that upsteam has this "my way or the highway" >>>>>>>> mentality, I'm curious about whether eudev (and mdev) exhibits the >>>>>>>> same behavior... >>>>>>>> >>>>>>> I synced yesterday and I didn't see the news alert. Last eudev update >>>>>>> was in Feb. so I *guess* not. It seems to be a "udev" thing. That is >>>>>>> why I mentioned eudev to someone else that was having this issue with a >>>>>>> server setup. >>>>>> I'd guess eudev will eventually do the same, although I hope that, it >>>>>> being a separate codebase, makes it easier to adopt some solution like >>>>>> the old rule generator, instead of using udev's approach. >>>>>> >>>>>> The udev upstream may have its issues, but there's actually a point in >>>>>> removing this, the approach there was so far was just a dirty hack. >>>>>> >>>>> >>>>> Thing is, it works for me. The old udev worked, eudev works but I'm not >>>>> sure what hoops I would have to go through to get the new udev working, >>>>> most likely the same ones others here are going through now. For once, >>>>> I'm not having to deal with some broken issue. < knock on wood > >>>>> >>>>> My current uptime is about 190 days. May hit it still but I'm certainly >>>>> hoping I don't. >>>> And, at least now, I have got enough knowledge to know whether it >>>> affects me or not. But the sad thing is that I got most of that >>>> knowledge *after* the first of these versions without the old script was >>>> stabilized. >>>> >>> >>> >>> I switched to eudev when the separate /usr thing popped up. While I am >>> watching this thread and sort of taking mental notes, I'm hoping this is >>> not a eudev thing, even in the future. >> >> You know that both udev and eudev have exactly the same issue with >> separate /usr right? >> >> The problem there isn't in the udev code, but it has to do with what is >> happening in rules that other packages install. > > As I recall, the problem is where the ebuild choses to install the code. > Putting the udev code under /usr forces the issue on systems where it > would otherwise not be an issue. > > Putting the udev code under / avoids that issue, but opens up the system > to the "silently fail" thing upstream liked to use as the basis of > "separate /usr is broken" > > So, there are three conceivable configurations (initramfs notwithstanding): > > 1. With systems which don't require /usr binaries before /usr would be > mounted, separate /usr is not a problem. > > 2. With systems which require /usr binaries for some features before > /usr would be mounted, those features will silently fail. > > 3. With systems which require /usr binaries to mount /usr, all hell > breaks loose. > > Putting the udev code under /usr moves all udev systems from group 2 > into group 3. In a sense, this fixes those systems because the admin is > forced to address the silent failures he was previously unaware of. It > also means pissing off a bunch of people who had features silently > failing...but they probably didn't know or care about those features in > the first place. > > It also moves all systems from group 1 into group 3...which is simply wrong. > > So long as eudev keeps its install path at / instead of /usr, admins in > group 1 will probably be perfectly happy. > +1 Happy I am. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] ftdi usb-serial converter broken
On Monday 28 April 2008, James wrote: > Hello, > > I've been using FTDI's usb-serial converters for a few years now with > great success. I use one of those gadgets. Wonderful devices, they always JustWorked(tm) > I have not used minicom in a month or so and now it's broken > on all(3) of the laptops where it use to work. I have googled > for a while today, with not luck on this issue. > > It the /etc/minicom/minirc.dfl used to use > /dev/ttyUSB0 on several machines. > > Now I get: nu such file or directory. > > CD into /dev and sure enough ttyUSB0 nore ttyUSB* is not there > so this is at least a udev issue? No, it's done by the driver and udev just goes along with what the driver creates. My specs: [EMAIL PROTECTED] /etc/udev/rules.d $ uname -a Linux nazgul 2.6.24-gentoo-r4 #2 SMP PREEMPT Mon Apr 7 18:40:36 SAST 2008 i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux Plugging in the device gives me this from dmesg: Apr 28 23:44:04 nazgul [110152.957575] usb 3-1: new full speed USB device using uhci_hcd and address 5 Apr 28 23:44:04 nazgul [110153.078246] usb 3-1: configuration #1 chosen from 1 choice Apr 28 23:44:04 nazgul [110153.124828] usbcore: registered new interface driver usbserial Apr 28 23:44:04 nazgul [110153.124855] drivers/usb/serial/usb-serial.c: USB Serial support registered for generic Apr 28 23:44:04 nazgul [110153.124903] usbcore: registered new interface driver usbserial_generic Apr 28 23:44:04 nazgul [110153.124906] drivers/usb/serial/usb-serial.c: USB Serial Driver core Apr 28 23:44:04 nazgul [110153.136853] drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device Apr 28 23:44:04 nazgul [110153.136903] ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected Apr 28 23:44:04 nazgul [110153.136939] drivers/usb/serial/ftdi_sio.c: Detected FT232RL Apr 28 23:44:04 nazgul [110153.137035] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 Apr 28 23:44:04 nazgul [110153.137050] usbcore: registered new interface driver ftdi_sio Apr 28 23:44:04 nazgul [110153.137053] drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver and I get this device node created automagically: [EMAIL PROTECTED] /etc/udev/rules.d $ ls -al /dev/ttyU* crw-rw 1 root uucp 188, 0 2008-04-28 23:44 /dev/ttyUSB0 There are no specific udev rules as shown by: [EMAIL PROTECTED] /etc/udev/rules.d $ grep -ir usb * | grep tty [EMAIL PROTECTED] /etc/udev/rules.d $ grep -ir tty * | grep usb [EMAIL PROTECTED] /etc/udev/rules.d $ grep -ir ftdi * [EMAIL PROTECTED] /etc/udev/rules.d $ grep -ir 188 * [EMAIL PROTECTED] /etc/udev/rules.d $ > Also, I went to rebuild the gentoo-2.6.24-r4 kernel and could not > locate the driver item for ftdi (maybe it has been combined into > a mega driver or such? It's where it's always been :-) Device Drivers -> USB support -> USB Serial Converter support -> USB FTDI Single Port Serial Driver (EXPERIMENTAL) I had no trouble finding it when I built this kernel so I assume it didn't move. The driver's dependencies: Symbol: USB_SERIAL_FTDI_SIO [=m] Prompt: USB FTDI Single Port Serial Driver (EXPERIMENTAL) Defined at drivers/usb/serial/Kconfig:167 Depends on: USB_SUPPORT && USB!=n && USB_SERIAL && EXPERIMENTAL Maybe you forgot to configure EXPERIMENTAL=Y ? -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] /dev/snd/seq access mode and permission
I have tried creating this rule: /etc/udev/rules.d/40-seq.rules KERNEL=="snd/seq", GROUP="audio", MODE="0666" ...but I'm not sure about the kernel key pair. I have tried matching "/dev/snd/seq" and just "seq" aswell. The Bug 406871 for sys-fs/udev-171-r5 looks exactly right, butI have sys-fs/udev-171-r6 installed. I''l check my kernel config and try disabling tmpfs. I have read that it helps real time audio performanc with jack(audio-connection-kit)though. I have tried removing all the rules in /etc/udev/rules.d. but the mode and permissions on /dev/snd/seq persist. Thanks for everyones help. --- mar...@gmx.de wrote: From: Marc Joliet To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] /dev/snd/seq access mode and permission Date: Fri, 17 Aug 2012 21:20:08 +0200 Am Fri, 17 Aug 2012 11:40:47 +0200 schrieb Marc Joliet : > Am Fri, 17 Aug 2012 01:54:34 -0700 > schrieb Cinder : > > > Hi, how do I make changes to permissions and access mode of device nodes > > persistent? At the moment I have to chown and chmod the /dev/snd/seq node > > every boot to make it accessible to my user. the other nodes are fine. > > Here's the output of ls -l /dev/snd/ > > > > total 0 > > drwxr-xr-x 2 root root 60 Aug 17 18:44 by-path > > crw-rw+ 1 root audio 116, 12 Aug 17 18:44 controlC0 > > crw-rw+ 1 root audio 116, 11 Aug 17 18:44 hwC0D0 > > crw-rw+ 1 root audio 116, 10 Aug 17 18:44 hwC0D3 > > crw-rw+ 1 root audio 116, 9 Aug 17 18:44 hwC0D4 > > crw-rw+ 1 root audio 116, 8 Aug 17 18:44 hwC0D5 > > crw-rw+ 1 root audio 116, 7 Aug 17 18:44 pcmC0D0c > > crw-rw+ 1 root audio 116, 6 Aug 17 18:44 pcmC0D0p > > crw-rw+ 1 root audio 116, 5 Aug 17 18:44 pcmC0D1p > > crw-rw+ 1 root audio 116, 4 Aug 17 18:44 pcmC0D3p > > crw-rw+ 1 root audio 116, 3 Aug 17 18:44 pcmC0D7p > > crw-rw+ 1 root audio 116, 2 Aug 17 18:44 pcmC0D8p > > crw--- 1 root root 116, 1 Aug 17 18:44 seq > > crw-rw+ 1 root audio 116, 33 Aug 17 18:44 timer > > > > I need /dev/snd/seq to look look the others. I can't find the udev rule or > > configuration that creates these nodes. Many thanks for any consideration. > > I have a hack for the same issue in my /etc/local.d/. A comment I put there > says this: > > # this is caused by using devtmpfs, which creates nodes with root:root and > 600; > # I believe this is fixed by udev upstream > > So devtmpfs creates the device node before udev runs, but udev does not > correct > the access permissions, which is however fixed by udev upstream (perhaps > already in ~arch?). Sadly I do not remember where I read this, but google > should > be of help there. Ah, yes, I did a quick search on b.g.o and found this: https://bugs.gentoo.org/show_bug.cgi?id=406871 So my comment is wrong, it doesn't have anything to do with devtmpfs, but udev upstream did fix it :) . HTH -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup _ Get your FREE, LinuxWaves.com Email Now! --> http://www.LinuxWaves.com Join Linux Discussions! --> http://Community.LinuxWaves.com
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Fri, Apr 05, 2013 at 01:41:28PM -0500, William Hubbs wrote:
>
> Neither of these is needed if you want to have your own names,
> because naming the interfaces yourself in /etc/uev/70-net-names.rules or
> whatever you call the file overrides udev's predictable names.
>
> If people are using ethx names and getting away with it it is probably
> because they are loading the drivers as modules, or by chance the kernel
> is initializing the cards in the order they expect. There is no
> guarantee that will stay consistent.
>
> I recommend using netx names.
>
> Does that clear it up?
>
> William
Just dealing with one server and my Linux router, they've been updated to
sys-fs/udev-200 and are both still using the same
/etc/udev/rules.d/70-persistent-net.rules file they've had for over a year,
which was working with udev-171.
mingdao@server ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:d0:68:0b:87:66", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth1"
# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:d0:68:0b:87:67", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth0"
mingdao@router ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="68:05:ca:03:05:5d", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="68:05:ca:03:05:50", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth1"
# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="f4:6d:04:e8:1d:d9", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth2"
There is no log file or any indication of other than eth* for those NICs. And
neither those 2 or the other 3 Gentoo boxen on this LAN have ever had a
/etc/udev/rules.d/80-net-name-slot.rules file.
As stated before, I didn't want to upgrade past udev-171, but kerframil told
me it would work fine, don't worry, upgrade to stable. Though I did upgrade, I
didn't intend to reboot any of those boxen until I looked carefully. And then
March 29 we had a power outage for over an hour, none of the UPSes stood up
that long, but everything was the same when I started the machines again.
Amazed, as usual...
--
Happy Penguin Computers >')
126 Fenco Drive ( \
Tupelo, MS 38801 ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Switch from devfs to udev?
On Saturday 21 May 2005 23:57, Felix Tiede wrote: > Tell it to use udev by adding "gentoo=nodevfs" to your kernel-commandline. > > Other way: Remove support for "/dev filesystem" (DEVFS) from your kernel. Or, just install udev. The init scripts will work the rest out. -- Mike Williams pgp58cDvn4oSl.pgp Description: PGP signature
Re: [gentoo-user] Switch from devfs to udev?
Tim Igoe wrote: > Install udev as in portage. Then edit the kernel to remove devfs - > recompile and reboot. > Job done, it should say using udev at bootup. Worked for me :-) I've got a question regarding this switch: Can sys-fs/devfsd be unmerged or is it still somehow needed? Sigi -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] udev-191 bit me. Insufficient ptys
On Thursday 31 January 2013 14:05:07 Michael Mol wrote: > OK, it looks like /dev/pts is not mounted. But darned if I know > why...Isn't udev supposed to handle that? Why did you remove udev-mount from the sysinit level? I left mine alone and it all works just fine. -- Peter
Re: [gentoo-user] udev 084 breaks USB?
On Wednesday 01 February 2006 20:27, Alexander Skwar wrote: > Today I updated from udev-081-r1 to udev-084. Since then, > I can no longer use my USB devices, like my mouse or my > flash card reader. > Did anyone else notice this? udevmonitor may help to diagnose your problem. -- Petr -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Without udev, who/what names ethernet devices?
On Fri, Jun 7, 2013 at 11:12 AM, Samuli Suominen wrote: > http://cgit.freedesktop.org/systemd/systemd/commit/src/udev?id=97595710b77aa162ca5e20da57d0a1ed7355eaad > > From there you can find the code that does the renaming in udev. Thank you for the description and links... that was the kind of info I was hoping to get. Chris
Re: [gentoo-user] X11 without udev/eudev
Mart: ... > Also be prepared for all the known security vulnerabilities you > reintroduce by installing a heavily outdated xorg-server with multiple > known vulnerabilities. ... I don't reintroduce them, I just keep them. Also, I had upgraded it if it wasn't for the udev dependancy. If you have a solution without udev, please tell me. Regards, /Karl Hammar
[gentoo-user] Gordian knot systemd / hwids
Hi systemd-249.6-r1 conflicts with sys-apps/hwids[udev] But when I remove the udev use flag, emerge sys-apps/hwids gives The following REQUIRED_USE flag constraints are unsatisfied: systemd? ( udev ) So, I would have to remove sys-apps/systemd-249.6 first. Is it save to emerge -C sys-apps/systemd ? Thanks for a hint, Helmut
Re: [gentoo-user] Updates = slow firefox
>>>> Can anyone confirm that as users we should be moving away from hal? >>> >>> http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml >>> http://xorg.freedesktop.org/wiki/XorgHAL >> >> OK, and since xorg-server-1.7 doesn't have a udev USE flag, I should >> probably stick with hal until 1.8. Please let me know if that isn't >> the case. I'm on udev-149. > > If HAL is working for you, stick with it. If not, turn it off. Xorg > 1.7 works equally well with or without HAL. The main difference is how > much manually configuration you need to do. > > The relative stability of using/not using udev with Xorg 1.8 have yet to > determined. Could switching to udev from hal fix my brightness adjustment keys? - Grant
[gentoo-user] re-appearance of `waiting for lock' bug?
updating from an old 2006 pkg based install to latest 2008 and have gotten pretty far along... right now emerging udev in an emerge -vuDN system command. The emerge is hung at: Calculating dependencies... done! [ebuild U ] sys-fs/udev-120 [087-r1] USE="(-selinux)" 0 kB Total: 1 package (1 upgrade), Size of downloads: 0 kB >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) sys-fs/udev-120 to / waiting for lock on /var/tmp/portage/sys-fs/.udev-120.portage_lockfile And has been there a good while. Looking at the bugs I see it mentioned but says it was fixed quite sometime ago. Any suggestions of how to get past this item and on with updating world? -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On March 13, 2012 at 5:49 PM "Canek Peláez Valdés" wrote: > Just what I was saying: I said (right there) "the probability of it > needing udev (directly or indirectly) will increase." I did not say it > would *need* udev for sure; just that the probability of it needing > udev would increase. And I call FUD! > I'm not spreading FUD; I'm just stating my opinion. And I stick to it; > wanna bet that beer? I don't bet or drink, but will say "you're right" if you produce verifiable facts. > Regards. > -- > Canek Peláez Valdés -- Happy Penguin Computers>`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com
Re: [gentoo-user] Huh? udev-182 package collision with own files
On Fri, 23 Mar 2012 21:32:49 +0700, Pandu Poluan wrote: > > * sys-fs/udev-182 > > * /usr/share/gtk-doc/html/gudev > > * /usr/share/gtk-doc/html/libudev > > > > So udev-182 cannot install because it does not want to overwrite some > > of its own directories. > More reason for me to stay away from udev as if it's the plague ;-) > > Seriously, it's too complex for its own good. Why? Because it includes documentation? Errors like this are down to either the package or the package manager, not the software they are trying to install. https://bugs.gentoo.org/show_bug.cgi?id=409359 confirms that this is down to the ebuild breaking the rules. -- Neil Bothwick Geordi, show these children the antimatter - Picard signature.asc Description: PGP signature
[gentoo-user] Re: trouble understanding a slot conflict
On 04/02/2012 07:20 PM, Allan Gottlieb wrote: > A normal update world turned up the error below > (~amd64, gnome profile) > > !!! Multiple package instances within a single package slot have been pulled > !!! into the dependency graph, resulting in a slot conflict: > > sys-apps/pciutils:0 > > (sys-apps/pciutils-3.1.9-r1::gentoo, installed) pulled in by > >=sys-apps/pciutils-3.1.9-r1[-compress-db] required by > (sys-fs/udev-171-r5::gentoo, installed) I've been through this one already ;) The ~amd64 keyword wants a newer version of udev (182-r3) than you have. The question is why you still have the old version of udev. Did you maybe mask the newer udev to avoid the infamous separate-usr-partition-is-deprecated problem?
Re: [gentoo-user] udev-197: activate new naming scheme
>> I've booted into udev-197 but my network interfaces are named the same >> as ever and I've read that the new naming scheme is deactivated by >> default. Do you think the new naming scheme will stick? > > In the discussion in [1] the consensus seems to be that they actually > solve a real problem, and that they are an improvement to the old > scheme. > >> If so, how can I activate it? > > Follow the instructions at [2]. In short, eliminate > /etc/udev/rules.d/80-net-name-slot.rules and Thank you for the info. I just read the contents of the above file which has good info too. - Grant > /etc/udev/rules.d/70-persistent-net.rules. > > [1] http://lwn.net/Articles/531850/ > [2] > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
Re: [gentoo-user] where to put mknod & chmod
> What baselayout and udev version are you using? > Thanks Alan, I added the commands to local.start and that seems to have done the trick. But here's the baselayout and udev info: [EMAIL PROTECTED] ~ $ emerge -pv baselayout These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-apps/baselayout-1.12.5-r1 [1.11.15-r3] USE="unicode* -bootstrap -build -static" 215 kB Total size of downloads: 215 kB [EMAIL PROTECTED] ~ $ emerge -pv udev These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-fs/udev-087-r1 USE="(-selinux)" 0 kB -Maxim __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: Re: /dev/cdrom has gone!
> yes, it works just well in WindowsXP. > it even works before i use udev. hehe > > i'm not sure it failed due to the udev, > i have no idea now. I had the exact same problem when switching to the 2.6 kernel and udev several months ago. After deleting .devfsd from the devices directory my CD burner was properly detected upon reboot, and the directory was populated with devices that were missing. There was a line in dmesg about .devfsd blocking at startup. Is .devfsd in your /dev directory? Run an "ls -al /dev | grep devfsd". If so, boot off a livecd and delete the file. Be sure that you aren't using a hybrid of devfs and udev before doing this. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How do I use 2.6.14 and remove udev and go back to devfs
Yes udev works, however works well is something else entirely. Udev has been the bane of my life a number of times - at least with devfs I had a chance of working it out. It often seems like we take two steps back with every new approach, and take a lot of pain just to get back to where we were. But I digress. BillK On Wed, 2005-11-16 at 09:26 -0700, Richard Fish wrote: > On 11/16/05, Dirk Heinrichs <[EMAIL PROTECTED]> wrote: > > Am Mittwoch, 16. November 2005 10:19 schrieb ext brullo nulla: > > David, udev works, and it works well. If you have problems migrating, -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] 2.6.14-hardened-r1 kernel causing problems
> > I just updated my laptop from 2.6.11-hardened-r14 to > > 2.6.14-hardened-r1 and I'm having a couple of strange problems. > > During bootup, I get a message saying that my system doesn't seem to > > support devfs or udev. Once it is booted, I can't use a terminal in > > X. xterm won't start and "terminal" starts but doesn't display a > > prompt. Does anyone know what's going on here? > > I am assuming you _have_ upgraded to udev, as support for devfs has > been removed from recent kernels? > > -Richard I thought I had upgraded to udev but I guess I hadn't. I followed this: http://www.gentoo.org/doc/en/udev-guide.xml and rebooted and now everything works perfectly. Thanks Richard! - Grant -- gentoo-user@gentoo.org mailing list
[gentoo-user] udev hickup
From: Meino Christian Cramer <[EMAIL PROTECTED]> Subject: Re: [gentoo-user] Is the best solution still NIS+NFS? Date: Fri, 11 Aug 2006 16:03:58 +0200 (CEST) (ooops...sorry...wrong subject...) Hi, from time to time when shutdown is nearly complete (right before the system's power goes down) udev spits a lot of messages onto the console. It way to fast to notice anything. I recognized only, that udev is the one with the "famous last words". I checked the file below /var/log for anything useful, but founnd nothing. Does anyone have any idea, what is triggering this "cry of the udev" and what is going wrong there ? Thank you very much for any help in advance! Keep hacking! mcc -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] LVM2 compile error. Clock_gettime
Samuli Suominen wrote: > > sys-fs/udev-197, 200, 204. --- will install to / instead of /usr so it > will work with sep. /usr just like eudev does, or just like udev-171 > used to > > basically the only thing to look out for is the network interface > names, you can add extra entry to grub that boots with net.ifnames=0 > kernel parameter, or create empty file > /etc/udev/rules.d/80-net-name-slot.rules if you don't like the new names > > Someone else ran into the same thing and it appears they use udev. So switching wouldn't help anyway. https://bugs.gentoo.org/show_bug.cgi?id=370217 Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] after recent update - openpty failed: 'out of pty devices' - please help?
On 06/28/2013 03:06 PM, Denis Shcherbakov wrote: > openpty failed: 'out of pty devices' There was a news item corresponding to the udev upgrade. 1. udev-postmount init script: Remove the udev-postmount init script from your runlevels. 2. devtmpfs support: You need at least version 2.6.32 of the kernel for devtmpfs functionality. Once you have this, make sure CONFIG_DEVTMPFS=y is set in the kernel configuration. See the gentoo udev guide for the option in make menuconfig [1]. If you have a line for /dev in /etc/fstab, make sure it is configured for file system type devtmpfs (not tmpfs or any other type). Also, you can remove this line if you prefer, since devtmpfs is mounted automatically.
Re: [gentoo-user] Moving from old udev to eudev
On 05/08/13 13:27, Marc Stürmer wrote: Why is was forked you ask? Because of the predictable Name stuff and some People disliked the attitude of the udev programmer which was "either my way or the high way." aside choice is always Good to have so in the end IT was bound to happen sooner or later and is a Good thing to have. nope, the forking happened before predictable network interface names. and forking udev was never the smart choice here, but it would be rather easy to port the old rule generator as a standalone udev helper and make it use free names like lan0, wireless0. as in, you don't change whole car if your tire blows out
Re: [gentoo-user] Moving from old udev to eudev
On 11/08/13 08:36, Walter Dnes wrote: On Sat, Aug 10, 2013 at 09:57:52AM +0300, Samuli Suominen wrote I expect it to happen around every new udev release that causes slight incompability; the default of the virtual/udev, sys-fs/udev, doesn't have to wait for the alternative providers. The elegant solution is outlined in my post... http://www.gossamer-threads.com/lists/gentoo/user/275977#275977 I.e. *UNTIL SUCH TIME AS EUDEV HITS STABLE* (on whatever arch you're using), add the entry bad idea to unmask "the new multilib eudev" on stable, regarding blockers it has like "!<=app-emulation/emul-linux-x86-baselibs-20130224-r7" on amd64 multilib when ABI_X86="32" is enabled as in, unresolvable dependencies
Re: [gentoo-user] installing gentoo with a systemd profile
2015-07-20 19:13 GMT-06:00 :
> I tried via depclean. I wanted to ask here before actually trying
> --unmerge, which seems rather brutal. I actually had a tiny part in the
> systemd wiki and remember that you could switch from an openrc system to
> systemd without unmerging. Instead, you either changed use flags
> (+systemd and -consolekit) or went to the a systemd profile
> (recommended).
It is needed to remove sys-fs/udev in order to get apps-sytem/systemd,
remember is the same code base the difference is you only compile one
part when emerging sys-fs/udev, not unmerging would cause file
conflicts, at install time.
sys-fs/udev/udev-222.ebuild:
SRC_URI="https://github.com/systemd/systemd/archive/v${PV}.tar.gz ->
${P}.tar.gz"
Re: [gentoo-user] Portage spokes again...
On 12/21/2016 06:59 AM, Matthias Hanft wrote: > Corbin Bird wrote: >> The "sys-fs/eudev" package is the Gentoo fork of "sys-fs/udev" for >> people who don't want systemd. > Ehm... I still use "sys-fs/udev" (not eudev) without systemd. > No problems so far. Do I have to worry? > > -Matt > > It is currently part of the systemd code base. ( It was merged in some time back. ) The ability to separate "udev" code from "systemd" code is going away very soon. ( by design, on purpose, etc. ) So if you want to run "udev" ... you going to be running "systemd". No choice. ( PulseAudio is also being merged into systemd. Think about it. ) I hope that Gentoo can keep the eudev fork going.
Re: [gentoo-user] Re: /dev/ttyUSB* group changed from uucp to root?
On Fri, Sep 26, 2014 at 12:12 PM, Grant Edwards wrote: > Which sets the group to 0 (root). The weird thing is that I don't > know where that file came from. Dong an "equery belongs" doesn't show > it belonging to any package. I do have dev-embedded/openocd installed, > but it doesn't own that file... But, doing an emerge -C openocd > removed the file /lib64/udev/rules.d/99-openocd.rules. > udev rules get installed to /lib/udev/rules.d, not /lib64/udev/rules.d. Most Gentoo systems have a symlink at /lib pointing at /lib64, but equery does not look at this. It only looks at the contents of /var/db/pkg/*/*/CONTENTS, which would contain lib instead of lib64.
Re: [gentoo-user] How do I eject an audio CD inside Gnome?
>> > I can't be of much more help to you, I don't use Gnome at all (see above)
>>
>> Can't say I blame you. What's the choice, though? I appreciate the
>> spare uncluttered desktop of Gnome. Last time I tried KDE (about 7 years
>> ago) it was anything but uncluttered. I tried XFCE briefly, but couldn't
>> get it to run stably. Besides, it was missing an application to switch
>> between keyboard layouts, something I absolutely need.
>
> I hear good things about XFCE these days. If you haven't tried it lately, it
> might be worth a new look. And you can always write a small script to change
> your keyboard layout if there's no gui app. Not as convenient as a systray
> icon, but probably a small price to pay if everything else suits your needs
>
My basic response was in fact that I now use XFCE, and I basically do
not have any auto-mounting software even installed. I don't mind
mounting and umounting manually for some stuff, and then using udev
rules and scripts for like my regular USB items (harddisks, flash
memory...).
So yeah, you go mount the CD yourself, but then the eject button will
work if you just set up a script in the very worst case, as long as
all permissions are satisfied (group, whatever). Usually an eject
call on the device will work fine for the hotkey. Just use some
keyboard tweaking program to fix it up. And for me that's just fine.
Other people may prefer it differently. But auto-mounting will do
annoying stuff on my laptop every time it goes to sleep and wakes up
and...it's just annoying to me personally.
If you don't have much experience setting up you own custom
'automonting' tools, I'll give just a couple examples. I think with
the comments it's clear enough.
daid@titan ~ % cat /etc/udev/rules.d/10-local.rules
# external USB, Seagate FreeAgent GO aka cyclops
SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{serial}=="
5LZ2XQJ5", SYMLINK+="cyclops" ACTION=="add",
RUN+="/etc/udev/scripts/mount_cyclops.sh"
daid@titan ~ % more /etc/udev/scripts/mount_cyclops.sh
#!/bin/bash
#mount Seagate FreeAgent Go with serial 5LZ2XQJ5 to /mnt/cyclops on ACTION='add'
mount -t ext3 /dev/cyclops /mnt/cyclops
chown root:users /mnt/cyclops
chmod 775 /mnt/cyclops
daid@titan ~ % ls -l /etc/udev/scripts/mount_cyclops.sh
-rwxr--r-- 1 root root 186 Apr 27 04:21 /etc/udev/scripts/mount_cyclops.sh
daid@titan ~ % ls -l /etc/udev/rules.d/10-local.rules
-rw-r--r-- 1 root root 1409 May 25 13:43 /etc/udev/rules.d/10-local.rules
The udev rule will do a tricky thing making the /dev/cyclops symlink
so it doesn't matter what *order* the device was connected. Rather
than 'naming' it like in some other operating systems, you just give
it a static mount point. When you're done, just manually umount the
mount point.
Cheers,
daid
