Re: [gentoo-user] Moving from old udev to eudev
On 12/08/2013 13:37, Tanstaafl wrote: > On 2013-08-12 6:48 AM, Alan McKinnon wrote: >> On 12/08/2013 12:19, Tanstaafl wrote: >>> Hmmm... so is it eudev that would need to be updated to 'fix' this? Or >>> virtual/udev? Or both? > >> It has to do with how virtuals work. >> >> If you have the virtual in @world, and none of the packages that satisfy >> the virtual are in world, then portage is free to do whatever it deems >> correct to satisfy the virtual. This is what it did, and it is rather >> important you understand why this is so. >> >> If you have the virtual in world, and one of the packages that satisfy >> the virtual are in world, then portage will not uninstall that package >> and instead obey your instruction. > > Ok, I'm getting there... > > I just confirmed that while I do have sys-fs/udev in world, but I *do* > have virtual/udev. > > So, based on what Samuli said about sys-fs/udev being the gentoo default > (where is this documented by the way?), seems the simplest thing to do > is add sys-fs/eudev to @world, but is this really the most appropriate > 'gentoo way'? > > Or, maybe just remove virtual/udev from @world? Or both (add > sys-fs/eudev, remove virtual/udev)? > > Actually, since udev/eudev are more appropriately @system packages, This is incorrect. @system is the minimal set of packages for a Gentoo system to work at all, and consists mostly of baselayout, toolchain and various packages used by the toolchain. A Gentoo system does NOT have to have a device manager to function, you can accomplish that easily with static device nodes. What is in @system is virtual/dev-manager which has this RDEPEND: RDEPEND="|| ( virtual/udev sys-apps/busybox[mdev] sys-fs/devfsd sys-fs/static-dev sys-freebsd/freebsd-sbin )" So you are free to install any of those methods you choose and thereby have working device nodes. To back up what Samuli said, if you want to GUARANTEE a certain device manager then you need to put it in @world, just like you already do for all the other packages you have. udev is in no way special in this regard. > it > would make more sense to add them there - except @system is defined not > by a file but by the profile, and so would require a USE flag to define > this, but if I recall, adding a USE flag for this was decided against > (why I don't know)... > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Is there any way out of this...?
On Sat, 7 Dec 2013 09:40:13 +0100
Tom Wijsman wrote:
> On Sat, 7 Dec 2013 07:32:09 +0100
> meino.cra...@gmx.de wrote:
>
> > [blocks B ] sys-fs/udev ("sys-fs/udev" is blocking
> > sys-apps/systemd-208-r2)
>
> Pick one or the other; you can use sys-apps/systemd without running or
> migrating to it if you want just the sys-fs/udev portion of it.
That is actually what I have asked just a few days ago in thread
"Systemd as drop-in replacement for udev?" and here I have another
answer. :-)
> > * Error: The above package list contains packages which cannot be
> > * installed at the same time on the same system.
> >
> > (sys-apps/systemd-208-r2::gentoo, ebuild scheduled for merge)
> > pulled in by sys-apps/systemd required by
> > (gnome-base/gnome-settings-daemon-3.8.6.1::gentoo, ebuild scheduled
> > for merge)
> > >=sys-apps/systemd-207 required by
> > >(sys-apps/gentoo-systemd-integration-2::gentoo, ebuild
> > >scheduled for merge)
> >
> > (sys-fs/udev-208::gentoo, installed) pulled in by
> > sys-fs/udev required by @selected
> >
> > >=sys-fs/udev-208[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev?,introspection?,kmod?,selinux?,static-libs?]
> > >(>=sys-fs/udev-208[abi_x86_64(-),gudev,kmod]) required by
> > >(virtual/udev-208::gentoo, installed)
>
> This is the actual problem, which I have already covered; just enable
> the openrc-force USE flag on =gnome-base/gnome-settings-daemon-3.8.6.1
> or alternatively mask >=gnome-base/gnome-settings-daemon-3.8.
>
> You need to put -openrc-force in /etc/portage/profile/use.mask to
> start with and then you can toggle it as you see fit. As you don't
> intend to run GNOME as far as I understood, this USE flag doesn't
> need to be masked for you.
What about the message in gnome-settings-daemon ebuild?
"gnome-settings-daemon needs Systemd to be *running* for working
properly. ..."
Also, Canek in the thread I have mentioned wrote:
"The GNOME stuff that requires systemd will not work under OpenRC from
3.10 on, you could get strange fails with gdm and
gnome-settings-daemon."
So *I think* for the long run, if not using GNOME, it could be better to
get rid GNOME applications (in my case it was just GDM) and be free to
choose either of systemd, udev or eudev OR fully migrate to systemd
(and be able to use GNOME apps).
Robert
--
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk
Re: [gentoo-user] Udev error and how to fix it.
On Tue, Mar 16, 2010 at 2:15 AM, Dale wrote:
> Mar 16 01:55:54 smoker udevd[1275]: SYSFS{}= will be removed in a future
> udev version, please use ATTR{}= to match the event device, or ATTRS{}= to
> match a parent device, in /lib/udev/rules.d/70-nut-usbups.rules:42
Have you checked to see who actually owns that rules file?
equery b /lib/udev/rules.d/70-nut-usbups.rules
-James
Re: [gentoo-user] Trying to solve blockage when trying to install kde-meta-4.1.2
On Wed, 29 Oct 2008 13:14:34 -0400, Andrey Vul wrote: > >> emerge -av1 udev > I prefer emerge -1pv udev > > emerge -1 udev Which means you have to wait for the dependency resolver to run twice. Which is why it's better to use emerge -1av udev look at output press enter -- Neil Bothwick If it ain't broke, wait a day or two!! signature.asc Description: PGP signature
Re: [gentoo-user] Re: odd /dev/null beharvior
According to: http://bugs.gentoo.org/show_bug.cgi?id=123249 The problem has been resolved. You should try # emerge sync # emerge -C udev # rm -f /etc/udev/permissions.d/50-udev.permissions # rm -f /etc/udev/rules.d/50-udev.rules # emerge -av udev If you still experience digest problems, reopen that bug and include any relevant information. -Chris -- Christopher Cowart Unix Systems Administrator Residential Computing, UC Berkeley "May all your pushes be popped" signature.asc Description: Digital signature
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Tue, Mar 13, 2012 at 2:09 AM, Walter Dnes wrote:
> On Mon, Mar 12, 2012 at 06:22:39PM -0500, Dale wrote
>
>> I think mdev has shown it can be fixed. Given time, it just may replace
>> udev then the udev dev can screw up his own stuff on not bother other
>> distros. I'm giving mdev some thought here. I want /usr on LVM which
>> means it has to be separate.
>
> Sorry, in lste-breaking news, it looks like udev is a mandatory
> dependancy for lvm2. No udev ==> No lvm2
It seems so; from lvm2 2.02.93:
DEPEND_COMMON="!!sys-fs/device-mapper
readline? ( sys-libs/readline )
clvm? ( =sys-cluster/dlm-2*
cman? ( =sys-cluster/cman-2* ) )
>=sys-fs/udev-151-r4"
...
econf $(use_enable readline) \
$(use_enable selinux) \
--enable-pkgconfig \
--with-confdir="${EPREFIX}/etc" \
--sbindir="${EPREFIX}/sbin" \
--with-staticdir="${EPREFIX}/sbin" \
--libdir="${EPREFIX}/$(get_libdir)" \
--with-usrlibdir="${EPREFIX}/usr/$(get_libdir)" \
--enable-udev_rules \
--enable-udev_sync \
--with-udevdir="${EPREFIX}/lib/udev/rules.d/" \
${myconf} \
CLDFLAGS="${LDFLAGS}" || die
Maybe you could try to modify the LVM ebuild to point udevdir to a
black hole and disable udev_rules and udev_sync. But that would be at
best a hack; I'm not familiar enough with the LVM code to know if they
actually need udev to run, or it only installs some rules so it can
run better with it.
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: Anyone switched to eudev yet?
On Fri, Dec 14, 2012 at 08:25:08AM -0600, Dale wrote: > > Pretty much yea. I started making a init thing when they were talking > about not supporting /usr on a separate partition. Then about a month > ago eudev was announced which means we can boot with /usr on a separate > partition and no init thingy, like it used to be. > > My basic question is this, has anyone started using eudev yet? From my > understanding it is basically udev with the files where they used to be > before they changed things. I'm thinking about switching but wondering > what all is involved. It appears to be as simple as unmerge udev and > emerge eudev and restart eudev. Is it really THAT simple? > > Dale What Mark wrote you is golden. I might only add that if you put: >=sys-fs/udev-181 into /etc/portage/package.mask you will have the present stable udev from *before* those weirdos starting messing it up, forcing systemd to take over udev. And, you won't be required to have an initrd image. (At sys-fs/udev-171-r9 as of Fri Dec 14 09:37:06 CST 2012). And the only USE flag you *need* for that version of udev would be rule_generator. If you don't know that you need another, you probably don't. Bruce -- Happy Penguin Computers >') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] How do I use 2.6.14 and remove udev and go back to devfs
I've been running 2.6.10 for some time. Then I started reading some stuff that I should update my Dell Inspiron 8200 notebook to UDEV. So I followed the gentoo wiki page and used kernel 2.6.13. This caused (known) issues with my nvidia driver and I couldn't get the USB mouse to work (yet the alps pad AND track point both worked fine). I didn't know what else was going to not work, so I said the hell with this as I'd already wasted enough time and went back to my old kernel image (until the udev people get their shit together and this is more stable). I unmerged 'udev' I re-emerged devfsd Things were generally working fine (with 2.6.10) Tonight I tried to make a new 2.6.14 kernel (using make oldconfig) and when it booted, there was some message that I don't have DEVFS or UDEV installed and so many things didn't work including sound, nvidia, wireless, etc. I re-read the udev wiki page and tried to find the 'make menuconfig' options they suggest and can't find them. I also grepped my .config for both "UDEV" and "DEVFS" and found nothing. WTF! How do I use the good old devfs with the 2.6.14+ kernels?! Where are the freakin' settings? What do I need to change/fix to get it to work again. UGH! -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] udevstart at boot?
On 12/17/05, Ernie Schroder <[EMAIL PROTECTED]> 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? Udevstart doesn't actually start udevd...it just rescans the devices and recreates device nodes. The actual udev daemon is started by /sbin/rc, possibly via /lib/rc-scripts/add-ons/udev-start.sh depending upon your version of baselayout. Having RC_DEVICES=udev or auto should be sufficient to start udevd on startup. Setting dev=udev in grub.conf is not necessary, and probably won't change anything. Now for your missing device nodes, maybe you just need to do: rc-update -a coldplug default > kernel /bzImage-2.6.14-gentoo-r4 root=/dev/hda5 dev=udev > video=vesafb:ywrap,mtrr vga=0x317 > > Also If you see why the boot complains about my video mode, feel free to > comment. 1. If you are using vesafb-tng, you cannot use vga= to set the video mode. It must be part of the video option like so: video=vesafb:[EMAIL PROTECTED],ywrap,mtrr 2. If you are not using vesafb-tng, you cannot use video=, so you should take out that option. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 31/03/13 at 12:41pm, Tanstaafl wrote: > Googled and can't seem to find an answer to this... > > I've had FEATURES="buildpkg" for some time on my system, so I already > have udev-171-r10 quickpkg'd... > > But for the life of me, I can't seem to find instructions for how to > convert /usr/portage/packages/sys-fs/udev-171-r10.tbz2 to an ebuild that > I can then add to my local overlay... > > Can this be done with the quickpkg command, or some other portage > tool/command? Or do I have to > > Anyone know how to do this? > > I'm basically using this udev event to learn a little about how quickpkg > works, so, since udev-171 is no longer in the portage tree, I want to > convert my quickpkg of it to an ebuild in my local overlay so my mask > will work again... then I'll back everything up, and do the update to > udev... Although that is sort of possible that's not how your supposed to use binary packages with portage. What you need to do is add the original ebuild for udev-171 to your local overlay as is. Then run emerge using the -g option see man emerge. For more info on bin packages see http://wiki.gentoo.org/wiki/Binary_package_guide -- - Yohan Pereira The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain
Re: [gentoo-user] mdev and lvm2
Alan Mackenzie wrote: >Hi, Dan. > >On Sun, Apr 07, 2013 at 02:34:16PM +0200, Dan Johansson wrote: >> Hello List, > >> What is the status of using mdev (instead the ever "growing" udev) >> together with lvm2? Reason for my question is that at >> https://wiki.gentoo.org/wiki/Mdev it says " One beta tester reports >> getting close with lvm2, but it's not there yet.". > >I think that beta tester was me. I had lvm2 partitions running under >mdev without problems. (They were also RAID-1, just for completion's >sake.) > >The only change I had to make was to my /etc/fstab. Where I previously >had: > > /dev/vg/usr /usr > >under udev, I then needed > > /dev/mapper/vg-usr /usr > >instead. mdev failed to create the /dev/vg directory. With this >change, >my system worked quite happily. Sadly, I went back to udev when >xf86-input-evdev-2.7.0 started depending on udev, back in June last >year. > >> Regards, >> -- >> Dan Johansson, <http://www.dmj.nu> >> *** >> This message is printed on 100% recycled electrons! >> *** > >-- >Alan Mackenzie (Nuremberg, Germany). LVM can be configured to double-check udev to make sure all the /dev entries are done correctly. By default this is not switched on. See /etc/lvm/lvm.conf It might solve that part. It solves some udev issues on one of my systems where the links are not handled correctly by udev for snapshots. -- Joost -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Moving from old udev to eudev
Samuli Suominen wrote: > On 01/08/13 19:28, Tanstaafl wrote: >> Hi all, >> >> Ok, rehashing this, but please don't turn it into another udev vs >> systemd thread. >> >> I have an older server that I have been putting off this update, >> debating on whether to update to the regular udev, or to eudev. >> >> I've googled until my fingers are blue, but cannot for the life of me >> find any explicit instructions for *how* to switch from udev to eudev. >> >> The eudev project page is sparse, to say the least. >> >> Anyone? >> > > First of all, eudev only has IUSE="rule-generator" that is backported > from udev-171. > It's otherwise same in users point of view with sys-fs/udev, except > sys-fs/eudev is constantly out of date and the code forwarding from > upstream is not very reliable process. > Futhermore sys-fs/udev is not 'old' but it's the new one and will be > the default for OpenRC for long as OpenRC is in Portage. > I don't want to bash anything or anybody but sys-fs/eudev as-is in the > Portage is currently useless and a bit buggy. > > That's odd. I been using eudev since like the second version that came out and have had zero issues with it. Ask anyone here, if it had a problem, I'd be found it by now. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE="firmware-loader" is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli
Re: [gentoo-user] Persistence of ZFS /dev/zvol/rpool/swap
Hi, I followed fearedbliss's guide a couple years back. Here are my 2 cents. On Sun, Nov 25, 2018 at 04:36:35PM -0500 , Pariksheet Nanda wrote: > I'm actually surprised my system boots at all, because /etc/fstab looks for > that partition to be the swap: I don't think swap is required for booting. > My best guesses at the problem are either that it's udev related or that > the various ZFS services need to be better configured to expose the zvol. > I read the "Admin Documentation" links on the zfsonlinux.org website > looking for mentions on "zvol" and the only relevant section seems to be > the `zpool import` should apply `zfs share -a` to zvols [2]. Maybe I need > to run `zfs share`? But that doesn't seem to help: > It does seem to be a udev issue on your end. This is what your udev rule should look like. https://github.com/zfsonlinux/zfs/blob/master/udev/rules.d/60-zvol.rules.in Check it exists. # cat /lib/udev/rules.d/60-zvol.rules Reload udev rules. # rc-service udev reload I think you also have to re-trigger the rules, which is beyond the scope of my knowledge. # man udevadm If it exists on `zfs list`, your swap partition is in there somewhere. This command will show you any swap partitions in use. # swapon --show Good luck! -- Roger Welsh fpr: 2FCB 9E31 EA77 CDEC A3AE 5DD7 D54C C777 553A 180D
[gentoo-user] udev upgrade 208 > 212-r1, openrc USE flag changed to disabled?
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.
Googling didn't reveal an answer...
Re: [gentoo-user] udev + /usr
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 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.
>
> Yes, except that udev ONLY handles kernel-events and doesn't process any
> "actions" itself.
> These are placed on a seperate queue for a seperate process.
>
>> > 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)
>>
[gentoo-user] unmerge sys-fs/udev-171-r9
Is it safe to unmerge "sys-fs/udev-171-r9" it is blocking udev-197 -- Joseph
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
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. Kindest regards, Bruce
Re: [gentoo-user] gentoo-systemd-only deprecation
On Thu, Aug 1, 2013 at 4:43 AM, Walter Dnes wrote: > On Wed, Jul 31, 2013 at 02:00:23AM -0500, Canek Peláez Valdés wrote >> On Wed, Jul 31, 2013 at 1:24 AM, Daniel Campbell wrote: > >> You need an OpenRC use flag to install OpenRC init scripts? That's >> simply a lie. > > An apology to Daniel might be in order. I start my USE flag with "-*". > During a recent install, I found out "the hard way" that eudev (and udev) > do not install their init scripts without the "openrc" flag. As you can > see from the ebuild fragments below, they require the "openrc" flag to > pull in sys-fs/udev-init-scripts > > From sys-fs/udev/udev-197-r8.ebuild > === > PDEPEND=">=virtual/udev-197-r1 > hwdb? ( >=sys-apps/hwids-20130114[udev] ) > openrc? ( >=sys-fs/udev-init-scripts-19-r1 )" > > From sys-fs/eudev/eudev-1_beta4-r1.ebuild > = > PDEPEND=">=virtual/udev-180 > openrc? ( >=sys-fs/udev-init-scripts-18 )" udev/eudev are special cases: the first is systemd with systemd removed at make install time; the second is a fork of systemd with systemd exorcised. The systemd package also uses the "openrc" USE flag to install OpenRC init scripts; I hope you agree that it is also an special case (systemd, which is a whole init system, provides init scripts for another init system). The package sys-apps/kmod also uses the "openrc" USE flag to install an init script, which "Create[s] [a] list of required static device nodes for the current kernel". I have no idea why this is necessary, but kmod is a dependency of systemd, and the developers of both projects collaborate a lot between them. No other package in the tree uses an "openrc" USE flag (or at least they don't appear in /usr/portage/profiles/use.local.desc), except for plymouth, and that it's to install a plugin for OpenRC, not to install its OpenRC scripts. So no package in the tree uses an "openrc" USE flag to install init scripts, except for one somewhat related to systemd, two forks and/or special handling of systemd, and systemd itself. In *ALL* the other packages in the tree, the OpenRC init scripts are installed unconditionally, as the systemd unit files are. And that's how it should be. Lastly, the ebuilds for udev/eudev should work out of the box in a sane configuration. You have been told several times, both by users and developers, that USE="-*" is not really supported; you broke your system by using it, you get to keep the pieces. Gentoo is about choice (or so I keep hearing); that doesn't mean it shouldn't strive to have sane defaults that keep the majority happy: http://blogs.gentoo.org/mgorny/2013/07/23/keeping-the-majority-happy/ 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: Change from udev to eudev?
Jonathan Callen wrote: > On 06/09/2016 10:00 AM, Dale wrote: >> waltd...@waltdnes.org wrote: >>> On Thu, Jun 09, 2016 at 08:16:57AM -0500, Dale wrote >>>> k...@aspodata.se wrote: >>>>> Dale: >>>>> ... >>>>>> Can a system even boot without udev? >>>>> Yes, use sys-fs/static-dev (unless you have some special boot >>>>> requirements). >>>> Well, I was talking about if udev was removed and then a reboot >>>> was done. I would think it would boot to a certain point then when >>>> whatever started and needed devices to be created in /dev, it would >>>> start failing. I suspect this would vary depending on the install >>>> as well. >>> You need *A* device-manager. You can use udev, eudev, static-dev, >>> mdev, whatever, but you need something. Mind you, some software assumes >>> or requires udev/eudev. >>> >> >> What I was referring to was if during this switch from udev to eudev, >> someone rebooted without any dev manager at all. In other words, emerge >> -C udev and then reboot before emerging eudev or some other dev >> manager. I suspect that would get interesting pretty quick. >> >> Dale >> >> :-) :-) >> >> > Actually, you no longer need a user-space device manager at all, unless > you want to be able to access device nodes under /dev as a user that > isn't UID=0 or has CAP_DAC_OVERRIDE. The kernel provides a devtmpfs > filesystem that will have every single device node that udev used to > create (udev no longer even creates the devices -- it just relies on > devtmpfs doing so), but most of them will be owned by 0:0 (root:root) > with permissions 0600; excepting certain nodes like /dev/null or > /dev/zero, which will be owned by 0:0 with permissions 0666. One other > thing that udev does that you might rely on is to create symlinks like > /dev/disk/by-label/*, which can be used by mount(8) if you specify > LABEL=foo in /etc/fstab. The only other things that I'm aware of udev > doing is to rename network devices and (possibly) to notify other > applications of changes, somehow (but I'm not sure that it actually does > that). > > If you don't actually need any of that (you are working on an embedded > system where you only need root anyway, for instance), then you can just > use a bare devtmpfs without a device manager changing permissions, > adding links, etc. > That's interesting to read. I recall reading about the devtmpfs in the kernel but thought that was for just the very early stages of booting, reading /boot to get the kernel and such things required to start the boot process. I figured once it got started, it would eventually get to a point and sort of hang up because it couldn't find devices to read to keep going. Interesting. Still don't want to test the theory tho. ;-) Dale :-) :-)
Re: [gentoo-user] udev and baselayout2
Daniel Pielmeier schrieb: Justin schrieb: to which udev version should be upgraded for the baselayout2? Openrc requires >sys-fs/udev-118-r2. As far as i know udev-120 is going to be stabilized with openrc/baselayout-2 which I use too. Didn't have any problems so far! Regards, Daniel Thanks, that's what I wanted to know. Tried it yesterday in the IRC, but they only could quote what's beneath the ebuild. Thanks, justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] My USB camera no longer works.
Dale wrote: > Hi, > > I have a Canon PowerShot A95 camera that until today worked fine. Gtkam > could see it and download my pictures. I'm on the same old kernel but > did upgrade some stuff recently. UDEV? Also, there might be other stuff that messes with the udev rules (libgphoto2, which is the backend of gtkam, has its own udev rules). Check your /etc/udev/rules.d/ to see if there are any changes... Best regards Peter K
Re: [gentoo-user] Who mount sysfs?
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? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Cannot open root device "sda3" or unknown-block (0,0)
On 11/17/10 00:56, Dale wrote: It appears udev is renaming the network card so I would check the udev rules. They are usually in /etc/udev/rules.d and I think it starts from the higher numbers and works its way down. I'm not much of a expert on udev. Dale :-) :-) You are correct previous card setting was blocking eth0 name. Small modification fix it. -- Joseph
Re: [gentoo-user] OpenRC update to 0.11.5 - safe if using older udev (pinned to udev-181)?
On Tue, Nov 20, 2012 at 02:17:17PM -0500, Tanstaafl wrote: Hey, should be no worries now ... openrc-0.11.5 got moved to stable today, so it should work fine with >=sys-fs/udev-181 (stable udev atm). -- Happy Penguin Computers >') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] Coldplug deprecated by udev-103 update?
Hi! After a sync this morning I get this: Calculating world dependencies... done! [blocks B ] sys-apps/coldplug (is blocking sys-fs/udev-103) [blocks B ] >=sys-fs/udev-089 (is blocking sys-apps/coldplug-20040920-r1) [ebuild U ] sys-fs/udev-103 [087-r1] As far as I can read this, this means that coldplug is gone? Anyone else have a differing opinion? Or advice? Best regards Peter K -- gentoo-user@gentoo.org mailing list
[gentoo-user] Moving from old udev to eudev
Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone?
Re: [gentoo-user] Moving from old udev to eudev
On Sun, 11 Aug 2013 01:36:59 -0400, Walter Dnes 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 > > signature.asc Description: PGP signature
Re: [gentoo-user] Re: help with xorg-server-1.9.4 and no hal; broken mouse/keyboard/X
On Sat, Feb 19, 2011 at 12:35 PM, Nikos Chantziaras wrote: > On 02/19/2011 10:14 PM, Mark Knecht wrote: >> Should I be enabling udev globally in make.conf? I'm currently not. I >> do have it on xorg-server so I'm not seeing the OP's issue, but I >> never wanted to get into making my own udev rules. > > I can only comment on what individual packages do with the udev flag. I > can't possibly know what each and every package in portage does when udev is > enabled globally :-/ Of course. At the time I really meant the question to ask what people are doing. On my machines currently the only package with a udev flag is xorg-server so it's easy. Cheers, Mark
Re: [gentoo-user] emerge xfce-base/thunar: lobotomy needed
On Mon, Sep 10, 2012 at 9:57 PM, Canek Peláez Valdés wrote: > On Mon, Sep 10, 2012 at 9:37 PM, Chris Stankevitz > wrote: > [snip] >> # 2012-09-10: appease thunar >> xfce-base/thunar -udev > > This makes no sense; the udev flag in thunar only asks for >>=sys-fs/udev-171, which is stable. Are you sure you don't have > anything in /etc/portage/package.keywords? > > By the way, it will be difficult for you to find a stronger supporter > of udev/systemd than myself; and I don't have the global udev flag > set. One more thing; which profile (/etc/make.profile or /etc/portage/make.profile) do you have? 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: [ANNOUNCE] I like systemd now :)
在 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. -- __ < gentoo rocks > -- \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || ||
[gentoo-user] I'm confused by "[ebuild U #] virtual/udev-197 [171]". Help, please!
Hi, Gentoo! After synching, I've got a whole lot of programs to emerge, amongst them being udev-197. :-( I'd rather do this on its own, in peace and quiet, rather than together with 12 or 13 other programs. emerge -puND world generates these: [ebuild U #] sys-fs/udev-197-r4 [171-r9] USE="acl%* kmod%* openrc%* -doc% -static-libs%" [ebuild U #] virtual/udev-197 [171] . The # indicates the packages are masked in packages.mask, which indeed they are. The emerge man-page indicates that these new versions will nevertheless be merged. But surely this is what the entry in packages.mask is to prevent? Why does emerge want to merge udev-197 in this case? How do I stop it? What am I missing here? -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Re: Udev-197 : 4 show-stoppers
On Sun, 20 Jan 2013 16:57:59 + Peter Humphrey wrote: > On Sunday 20 January 2013 08:51:43 Philip Webb wrote: > > I just tried upgrading to udev-197 , which is supposed to be > > stable. There were multiple problems & I'm now back with udev-171 . > > My daily update pulled in udev-197-r3. The installation went smoothly > but I decided I ought to reboot to check that I could. I couldn't. > Udev couldn't start because my kernel config didn't have > CONFIG_DEVTMPFS=y. So I booted my rescue system on the same disk, > chrooted in and built a new kernel with that option. On rebooting > everything was fine. > > Just a note for anyone else who may not have that kernel option. This got me too. Now there's a discussion in -dev about making config warnings fatal.
Re: [gentoo-user] ALSA problems after UDEV-103 upgrade
On 12/17/06, Bo Ørsted Andresen <[EMAIL PROTECTED]> wrote: On Monday 18 December 2006 00:08, Mark Knecht wrote: > On 12/17/06, b.n. <[EMAIL PROTECTED]> wrote: > > Mark Knecht ha scritto: > > > That appears to be a testing version of udev. Do you always run > > > testing? > > > > FYI, udev-103 is stable udev. > > I run stable, and I have udev-103 as the last version (I still must > > upgrade, however...) > >Well, I see you are correct by looking at the Online Package > Database. However it hasn't shown up in my sync path yet: [SNIP] You are probably not using the same arch. It's stable on e.g. x86 but not on e.g. amd64... -- Bo Andresen Duhthanks Bo. Indeed I was sitting on my AMD64 machine at the time. Cheers, Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Who sets the symlink /dev/rtc => /dev/rtc0 ?
130825 Pavel Volkov suggested:
> On Sunday 25 August 2013 20:26:32 meino.cra...@gmx.de asked:
>> So...which ghost in my system dares to set the symlink /dev/rtc
>> to point to /dev/rtc0 instead of /dev/rtc1 ???
> I bet it's /usr/lib64/udev/rules.d/50-udev-default.rules
I have /usr/udev/rules.d/50-udev-default.rules (on a 64-bit system),
which contains the lines :
# select "system RTC" or just use the first one
SUBSYSTEM=="rtc", ATTR{hctosys}=="1", SYMLINK+="rtc"
SUBSYSTEM=="rtc", KERNEL=="rtc0", SYMLINK+="rtc",
OPTIONS+="link_priority=-100"
However, in /dev I have :
crw--- 1 root root 10, 135 Aug 25 07:39 /dev/rtc
ie it's not a symlink. I'm using udev-204 .
HTH
--
,,
SUPPORT ___//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] udev or Gentoo issue?
On 13/05/14 16:50, Grant wrote:
> I'm having a problem starting the USB network interfaces properly on
> one of my systems. I brought the problem to the udev list and they're
> indicating that it's a Gentoo problem:
>
> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>
> Should I file a bug?
>
> - Grant
>
Like pointed out in the upstream thread, it's either wrongly built
net-misc/dhcpcd (should be with USE="udev")
and if not using dhcpcd, it might be a bug in net-misc/netifrc's
/etc/init.d/net.lo depend() { } section --
it's possible it's missing dependency that forces /etc/init.d/udev start
first, specially if OpenRC is using parallel
startup
So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
OR bug in dependencies of netifrc's net.lo script
- Samuli
Re: [gentoo-user] eudev/udev changeover: a warning to Linode customers
On Wed, 1 Dec 2021 20:07:11 -0500, Rich Freeman wrote: > > With udev the filenames you want are: > > 80-net-name-slot.rules > > 80-net-setup-link.rules > > > > Or at least, that is what I am using with the systemd-bundled udev and > > my physical interface is eth0. > > Disregard that. I'm also using net.ifnames=0 - I'm guessing the > filename changed at some point. You probably can dig around in the > package-supplied udev rules to figure out which one needs to be > overridden now. I'm not using any udev rules for network devices. If all you want is the old eth?/wlan? names back the kernel parameter is sufficient. This works with openrc and systemd here. -- Neil Bothwick Consciousness: that annoying time between naps. pgpv5K4GVu5nM.pgp Description: OpenPGP digital signature
Re: [gentoo-user] too many devs in /dev since udev
The problem with this is udev doesnt know about a lot of devices. I cant see the sense of trying to replace a simple makdev when needed while having a large directory of nodes (that dont take up any space) versus using often flaky, complex and problematic utilities like devfs and udev where you have to do a fair bit of reading, ask on mail lists and sacrifice chickens to get your new bluetooth dongle working! Wheres the gain? - I certainly have had my share of pain (bluetooth, cdroms, dvd's, ...) with both udev and devfs - devfs does seem less problematic but I guess thats because its older. Overall, I find myself wishing for the old system ... BillK On Mon, 2005-06-20 at 04:07 +0200, Sven Köhler wrote: > Hi, > > i liked the idea of having very few devices in /dev. Since i installed > udev, i got plenty of them. AFAIK, the deives are saved on shutdown and > restored on boot. How can start my gentoo with an empty /dev directory > which is re-populated by udev? > > Thx > Sven -- William Kenworthy <[EMAIL PROTECTED]> Home! -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] make dev / udev question (1394 related)
Mark Knecht wrote: What's throwing me is that the libraw1394 emerge makes this limited complaint: Required /dev/raw1394 device file not found. Run 'make dev' to create it. This is more suited for the old-style 'static' /dev, where /dev was just a load of device nodes stored on disk. With more modern solutions (devfs/udev), you don't ever have to worry about creating device nodes, they are created automatically when the appropriate driver is loaded. Its safe to ignore this warning on Gentoo. It seems to me that if the device was moved by either udev or the Gentoo developers then shouldn't this package have been modified to understand that and not throw a message like this? Or is there possibly supposed to be a link of some type from /dev/raw1394 to /dev/raw/raw1394? I forgot about this one. This is a udev rule problem, which is supposed to deal with other raw devices, but not raw1394. It's been fixed for future udev versions, but for now, you can do this: # echo 'KERNEL="raw1394", SYMLINK="%k"' > /etc/udev/rules.d/10-raw1394.rules # udevstart Daniel -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On 2012-01-05 08:43, Alan McKinnon wrote: > I fiddle around a lot with the hardware on those and udev deals with > that nicely considering udev is designed to deal with that nicely. I confess to being quite ignorant when it comes to what magic udev does behind the scenes but what makes it different to any other device manager (well, I don't know any other than mdev but...)? I.e. what technical problem(s) does udev solve that no other device manager can't? What is the technical need for something else than a device file under /dev that can be used to communicate with the kernel? What I mean is: If you say "... considering udev is designed to deal with that..." you seem to indicate that you know what it does and why it does what it does... and henceforth the technical reason why the rearrangements of the file system hierarchy is necessary... > Becoming rather lazy in my old age is getting to be a factor too Ho hum... so "you lazy old fart" is true then? ;-) Best regards Peter K
Re: [gentoo-user] LVM boot problem
On 12/6/06, Mirco Bakker <[EMAIL PROTECTED]> wrote: Hi For the archives: Problems solved. The missing ethernet interface resulted from two missing links in /sbin (udev_run_devd, udev_run_hotplugd). I've created them now manually. I think they should get installed when emerging udev. A this point I have no idea why they were missing on my system (if someone has an idea please reply). Anyway it works fine again. No, you should not have any udev utilities in /sbin now. They now live in /lib/udev. In the udev rules files, you should not specify any path for any utilities that you want to run (use PROGRAM="foo" instead of PROGRAM="/path/foo"). Also rules files owned by udev (like 50-udev.rules) should show an update required when you run etc-update, and you should accept the new file, rather than keeping any changes you made. You should only make changes to 10-local.rules. Also, there might be some orphans in /etc/udev/rules.d. You can find these with "equery belongs /etc/udev.d/rules.d/". Anything that doesn't belong to a package (other than 10-local.rules, and 70-persistent-*.rules) could probably be removed. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ... fails to open device '/dev/hda2' after update
On 1/28/06, Fredrik Lundgren <[EMAIL PROTECTED]> wrote: > Sorry for my misstake, > --- > uname -a > Linux(none) 2.6.10-gentoo-r6 #8 Thu Feb 17 13:15:44 CET 2005 i686 > Intel(R) Pentium(R) > M processor 1.70 Ghz Centurion Intel GNU/Linux > > etc-update > mkdir: cannot create directory '/var/tmp/1162': Read only file system Try (assuming you don't have a separate /var filesystem): mount / -o remount,noatime,rw etc-update Once you have worked through that, edit /etc/conf.d/rc, which contains many of the things that were once in /etc/rc.conf, including RC_DEVICES. Since you are still on 2.6.10, a udev migration is not /necessary/ to fix your system, but I would still recommend it when you have some time. The basic steps are going to be: emerge udev coldplug hotplug edit /etc/conf.d/rc to set RC_DEVICES=udev remove any udev/devfs options from the kernel command line in /boot/grub/grub.conf remove /dev/.devfs if it exists reboot You can find a lot more information on udev here: http://www.gentoo.org/doc/en/udev-guide.xml -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] New kernel and udev
read this udev guide too: http://www.gentoo.org/doc/en/udev-guide.xml On 10/7/05, gentuxx <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > I went to do my routine "emerge -Duptv world" and it came back with > devfsd blocking gentoo-sources-2.6.13-r3. I'm not sure whether I'm > using udev now or not. I remember compiling into the kernel last time > I did a kernel compile. Naturally, when I did the "emerge -Cpv > devfsd" it complained that I was unemerging something in the system > profile, and that it could damage my system. So I just thought I > would check here before hurting anything. ;-) > > So, does the v2.6.13-r3 gentoo-sources use udev? (Am I confusing this > with something else?) How can I tell if I'm using udev now, and/or if > I will hurt anything by uninstalling it, to get the new kernel sources? > > Thanks. > > - -- > gentux > echo "hfouvyAdpy/ofu" | perl -pe 's/(.)/chr(ord($1)-1)/ge' > > gentux's gpg fingerprint ==> 34CE 2E97 40C7 EF6E EC40 9795 2D81 924A > 6996 0993 > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFDRd/6LYGSSmmWCZMRApEjAJ95zhCxlNCIZW1e71555qUy/8HLDgCghDdK > 8H9sLDiT4Mfh+I+5SOHXIJs= > =w92s > -END PGP SIGNATURE- > > -- > gentoo-user@gentoo.org mailing list > > -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How do I use 2.6.14 and remove udev and go back to devfs
Am Mittwoch, 16. November 2005 09:22 schrieb ext W.Kenworthy: > (I think, without checking) devfs has been removed from 2.6.14 and > everything is supposed to be udev from now on. Nope, not yet. Only the config options have been commented out. > First udev, install udev according to the gentoo guide and that should > work fine. Check the udev USE flag so and "emerge world --newuse" if > neccessary. Strongly reccomended: use the tarball method, not pure > udev! you have enough problems without trying to sort that out. I would recommend to _not_ use the tarball method :-). I've always had problems when I forgot to set RC_DEVICE_TARBALL="no" in /etc/conf.d/rc after baselayout update (can't remember what kind of problems, though). It is, however, a good idea to create permanent /dev/null and /dev/console nodes with mknod beforehand. Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Hambornerstraße 55 | Web: http://www.capgemini.com D-40472 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net pgpozIUDSQTLo.pgp Description: PGP signature
Re: [gentoo-user] Modules autoloading?
On Fri, Apr 28, 2006 at 03:39:02PM -0400, Penguin Lover Willie Wong squawked: > A message would pop-up saying to the effect that "udev is processing > kernel events" and then proceeds to load a bunch of kernel modules > which I didn't specify for loading in /etc/modules.autoload.d > > Any clue as to where I can turn off this behaviour? I checked the > config files for udev and /etc/conf.d/rc, and I don't see anything > obvious. > I downgraded to the stable udev-087 as a work around. I compared the files provided by udev-090 and udev-087, in particular, the file /etc/udev/rules.d/50-udev.rules For the 090 version, there's an extra section dealing with Modules autoloading compared to the 087 version, which I suspect it is what was causing me the trouble. Thanks again W -- M: Hey, do that again! Make the computer beep... W: As you wish! M: ah~~ ah~~... hum, that beep was a G. W: how can you tell? (turn around) oh... no fair... a tuner Sortir en Pantoufles: up 168 days, 10:46 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Moving from old udev to eudev
On Thu, Aug 01, 2013 at 12:28:38PM -0400, Tanstaafl wrote > Hi all, > > Ok, rehashing this, but please don't turn it into another udev vs > systemd thread. > > I have an older server that I have been putting off this update, > debating on whether to update to the regular udev, or to eudev. > > I've googled until my fingers are blue, but cannot for the life of me > find any explicit instructions for *how* to switch from udev to eudev. Step 1) keyword sys-fs/eudev-1_beta2-r2 Step 2) ensure that "kmod" and "openrc" and "-modutils" USE flags are set (at least for sys-fs/eudev). "tools" flag needs to be set for sys-apps/kmod (usually a system default) Step 3) unmerge udev sys-apps/modutils (You *MUST* specify "sys-apps/modutils" to avoid confusion with "virtual/modutils") Step 4) emerge eudev (should pull in kmod) Step 5) The following message shows up in elog. Do as it says... > WARN: postinst > > You need to restart eudev as soon as possible to make the > upgrade go into effect: > /etc/init.d/udev --nodeps restart -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Screen: Cannot open your terminal '/dev/tty1' - please check [Update]
wrote: > Peter Humphrey wrote: > > > On Friday 13 March 2015 23:28:32 Neil Bothwick wrote: > > > > > I have this in /lib/udev/rules.d/50-udev-default.rules: > > > > > > SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", GROUP="tty", MODE="0620" > > > > # grep tty /lib/udev/rules.d/50-udev-default.rules > > SUBSYSTEM=="tty", KERNEL=="ptmx", GROUP="tty", MODE="0666" > > SUBSYSTEM=="tty", KERNEL=="tty", GROUP="tty", MODE="0666" > > SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", GROUP="tty", MODE="0620" > > SUBSYSTEM=="tty", KERNEL=="sclp_line[0-9]*", GROUP="tty", > > MODE="0620" SUBSYSTEM=="tty", KERNEL=="ttysclp[0-9]*", GROUP="tty", > > MODE="0620" SUBSYSTEM=="tty", KERNEL=="3270/tty[0-9]*", > > GROUP="tty", MODE="0620" SUBSYSTEM=="vc", KERNEL=="vcs*|vcsa*", > > GROUP="tty" > > KERNEL=="tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", > > GROUP="uucp" > > > > Can't say where all those came from. > > > > I have the same entries in /lib/udev/rules.d/50-udev-default.rules but > nevertheless after login the permissions for group tty are gone. Before login: crw--w 1 root tty 4, 10 13. Mär 15:12 /dev/tty4 After login: crw--- 1 wabe tty 4, 1 13. Mär 17:49 /dev/tty1 -- Regards wabe
[gentoo-user] rc_hotplug and udev network interface renaming
Hi! I'm running into problems combining network device hotplugging and udev network device renaming rules. Everything on its own works well: - I have a udev rule in /etc/udev/rules.d/... telling udev to rename an ethernet device based on its MAC address from say eth_old to eth_new. When I plug the device in its name it correctly changed by udev. - I have rc_hotplug="net.eth_old !net.*" in /etc/rc.conf. When I plug in the device it is automatically started and the dhcpcd client runs for it. When I combine both by using rc_hotplug="net.eth_new !net.*" then the device is renamed but no hotplugging occurs. When I use rc_hotplug="net.eth_old !net.*" then OpenRC tries to start up eth_old but fails to do so, because it has already been renamed to eth_new. Am I missing something here? Any help? Regards Matthias -- Matthias Gerstner, Dipl.-Wirtsch.-Inf. (FH) Entwicklung NCP engineering GmbH Dombühler Straße 2, D-90449, Nürnberg Geschäftsführer Peter Söll, HRB-Nr: 77 86 Nürnberg Telefon: +49 911 9968-153, Fax: +49 911 9968-229 E-Mail: matthias.gerst...@ncp-e.com Internet: http://www.ncp-e.com signature.asc Description: Digital signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On March 13, 2012 at 5:22 PM "Canek Peláez Valdés" wrote: > On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr. > wrote: > > > > > > > > On March 13, 2012 at 4:27 PM "Canek Peláez Valdés" > > wrote: > > > >> > >> "Fringe" programs will not require udev, or it will be optional; but > >> the moment a "fringe" program reaches critical mass to become > >> "maistream", the probability of it needing udev (directly or > >> indirectly) will increase. > >> > >> I'm willing to bet a beer on that prediction. > >> > >> Regards. > >> -- > >> Canek Peláez Valdés > > > > > > > > It _sounds_ like your definition of a "fringe" program is one that does not > > need udev; but when it becomes "mainstream" it will need udev. If not, you > > write us the definition of a "fringe" program and a "mainstream" program. > > > > Excuse me, but that's just incredibly _arrogant_! > > Relax man. That's why "fringe" is written QUOTE fringe UNQUOTE, and > "mainstream" is written QUOTE mainstream UNQUOTE. If it makes you > happy, replace "fringe" with "GNOME/KDE/XFCE/lvm2-not-related" and > "mainstream" with "GNOME/KDE/XFCE/lvm2-related". That's using the very > same definition that Walter (the guy behind the mdev-instead-of-udev > effort) used just three mails below (or above, depending on your email > client). > > Please chill, no need to get all worked out. > > And I maintain my prediction. > > Regards. > -- > Canek Peláez Valdés So, what qualifies for "the moment a "fringe" program reaches critical mass to become "maistream", the probability of it needing udev (directly or indirectly) will increase." Again, quoting _your_ definition. I gave you examples of programs which have reached critical mass, which don't require udev. And, I'm not attaching your character, for I know you not ... just attacking your FUD! -- 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] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 14, 2012 7:10 AM, "Canek Peláez Valdés" wrote: > >8 snippage > 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. So you need to handle the events > associated with the connections (or discovery, for things like > Bluetooth) of the devices, and since udev is already handling the > database and the detection of connections/discovery, I agree with the > decision of leting udev to execute programs when something gets > connected. You could get that function in another program, but you are > only moving the problem, *and it can also happen very early at boot > time*, so lets udev handle it all the time. > > I hope you see where I'm going. As I said before, mdev could (in > theory) do the same that udev does. But then it will be as complicated > as udev, *because it is a complicated problem* in general. And I again > use my fuel injection analogy: it is not *necessary*. It is just very > damn convenient. > FWIW, mdev is perfectly capable of handling device events, and (optionally) firing an arbitrary script. The way I see it, udev is trying to be everything regarding devices, while mdev is purposefully limiting itself to creating proper nodes under /dev. That (udev's wanting to do *everything*) to me seems counter against the philosophy of Unix-y apps: do one thing, and do it well. And that's why I don't like udev; for it to be able to do everything under the sun, it needs stuffs. Rgds,
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Tue, Jan 3, 2012 at 17:04, Walter Dnes wrote:
> In the instructions here, I've set up a revised dev-manager ebuild in
> an overlay. I've requested the changes to be incorporated into the
> official ebuild and it appears to have been accepted. See...
>
> https://bugs.gentoo.org/show_bug.cgi?id=395319
>
> It should be rolled out eventually, and the overlay won't be necessary.
>
Cool! :D
> I think I've found one item so far that requires udev. My laptop's
> graphics chip needs a binary blob from radeon-ucode. That binary blob,
> in turn, requires the presence of /usr/lib/libudev.so.0 which is a
> symlink to /usr/lib/libudev.so.0.9.3 (which is also required). I can
>
> emerge udev
> move or copy the 2 files over to /root
> unmerge udev
> move or copy the 2 files from /root to /usr/lib/
>
> and it still works. Note that /usr/lib/ is a symlink to /usr/lib64 on my
> 64-bit gentoo.
>
Well it doesn't need udev itself, just libudev.
But if the binary blob is hard-coded to search for
/usr/lib/libudev.so.0{,.9.3}, that means /usr must exist at
boot-time...
... or at least /usr/lib/libudev.so.0{,.9.3}
IMO, providing 1 file (+ 1 symlink) is still much better than having
to provide the *whole* /usr tree during boot-time.
Now, what's needed is to "catalog" (1) essential boot-time devs that
can't be handled by mdev, and (2) essential files that need to exist
under /usr during boot-time.
#1 should be interesting for busybox upstream, while #2 will be
necessary for those trying to wean themselves off udev :-)
We're one step closer to an udev-free Gentoo, yay!
(Come to think of it, has *any* distro ever attempted this...
'unconventional of going udev-free?)
Rgds,
--
FdS Pandu E Poluan
~ IT Optimizer ~
• LOPSA Member #15248
• Blog : http://pepoluan.tumblr.com
• Linked-In : http://id.linkedin.com/in/pepoluan
Re: [gentoo-user] udev: renaming eth0 to eth1 ???
Paul Hartman wrote: On Sat, Dec 4, 2010 at 11:39 AM, Dale wrote: The reason I know this, I have three ethernet cards on my rig. I replaced one of them and it was a mess. They were laid out as 2, 3 then 1 and it took me a while to figure out which is which. I deleted the rules file and restarted udev and the first one was 1 and so on. Because of situations like yours I think it's better to suggest editing the file to change/delete the affected devices rather than suggesting to delete the whole thing (though that may depend on the user's skill level). Maybe there are other nics in the machine that are fine and don't need to be changed, maybe they will auto-detect in a different order than before, perhaps they've been moved around slots, and blowing away the whole config might lead to other confusion later on when eth0 is fixed but now eth1 and eth2 have been reversed, or whatever. But I am a pessimist. :) Well, it has been recommended here many times. Someone posted a udev problem just a bit ago. If I were the poster, I would reemerge udev and reboot. If it still has problems, I would emerge a older version, delete the udev rules and reboot. Unless you know what goes in those udev files, removing them is the simplest way. When udev restarts, it will generate those files in a flash. Keep in mind, when you shut down, udev removes most everything in /dev too unless you have it set to save them. Also, I posted here on how to fix my little naming problem. I was told to delete the files and reboot. That's how I know it is safe to remove them. Can a person just edit them sure. Why tho? Dale :-) :-)
Re: [gentoo-user] Semi OT: hotplug / coldplug / udev ...
On Thursday 09 November 2006 10:01, Arnau Bria <[EMAIL PROTECTED]> wrote about '[gentoo-user] Semi OT: hotplug / coldplug / udev ...': > I have some doubts about the way hotplug / coldplug / udev work. > > What really happen when you plug a (again, > i.e.) pendrive in your computer? Which programs take care in that > process? What about kernel? Here's my understanding, I'm sure others will correct me, and possibly exapnd on it: First, there's either a HW interrupt or the kernel scans the bus and sees a new device. Then, the kernel queries the device and populates /sys (and possibly /proc) and notifies udev. udev is responsible for loading the appropriate module, if not already loaded, and creating the device nodes. In the past, hotplug and coldplug where responsible for loading the module, and devfs would create device nodes under control of the module. Neither hotplug nor coldplug are required with recent udev (w/ module loading support). Hotplug and/or coldplug can provide module loading for early versions of udev (in addition to their role with devfs). In ancient times, device nodes had to be created by the user (static /dev), possibly in response to kernel events (put that would require a module for the kernel hooks) or en masse for all possible devices. One (dis?)advantage to static /dev was that device nodes would persist across reboots, which does not happen under devfs or udev -- unless your distro. provided /dev tarballs (ala Gentoo) or another method to save /dev on shutdown and restore it on startup. -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-01, Michael Mol wrote: > > On 04/01/2013 03:26 PM, William Hubbs wrote: > >> 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 wro= > ng. > > So long as eudev keeps its install path at / instead of /usr, admins in > group 1 will probably be perfectly happy. I'd guess nothing prevents the udev ebuild from doing so, too. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
gentoo-user@lists.gentoo.org
Am 08.08.2015 um 00:28 schrieb Rich Freeman: > Udev installs into such a path, and currently does not depend on > systemd (in fact, they block each other). They block each other because udev is part of systemd. So if you install systemd you already have udev and don't need the separate udev package. Regarding the separate udev package, at least regarding eudev I would consider this a bug, because those systemd directories are systemd specific and don't belong to the FHS. If Poettering wants to break Unix, Linux and POSIX standards, it's up to him. Packages that don't belong to Poettering's software are supposed to follow those standards and do it so far. But remember, udev is part of systemd and announced to break on non-systemd systems. So udev is not a valid example here. > Obviously you don't use udev, but in general as more stuff ends up in > systemd you'll probably find more important stuff with "systemd" in > the filename. Why would it? This again would be a reason for a bug report. Or do you consider every important stuff to be part of systemd? Do you really believe that there will be no other important stuff than systemd resp. that systemd will be the only init system or system managing system? Question again: That sounds exactly like those Poetterix fanboys, particularly when they forced systemd on every user of certain distros whether they wanted it or not. I don't need to be worried, that this will happen with Gentoo either anytime soon? > I'd suggest taking the time to understand what it is > before you decide that you don't want it (speaking generally, I'm not > suggesting that you didn't know what you're doing when you switched to > eudev). Heck, even gummiboot is being merged into systemd. Bad example again. Gummiboot was originally developed by Kay Sievers, one of Poettering's fanboys and co-developer of systemd. So a no-go anyway, and no surprise that it got merged into systemd.
Re: [gentoo-user] Re: clean-up root partition
Neil Bothwick wrote: > On Sun, 22 Nov 2015 21:32:01 -0600, Dale wrote: > >>> You can build a list of orphaned files with qfile >>> >>> qfile -o $(find / -xdev -type f) >>> >>> You may want to exclude /etc/ from the search path as that produces a >>> lot of hits. >> I get a few hits on this, so far. If it reports that it is a orphan, >> just how sure is it that it is? Is it 100% and safe to delete or 90% >> and could break something? > As with everything Gentoo, it is 100% safe to look at the output and > make your own decisions. Generally, if its in /lib or /usr/lib it's > usually fair game, but not if it's in /etc. > > I have some in lib directories. I skipped the ones in /etc and home directories. This is a example: /lib64/firmware/LICENCE.iwlwifi_firmware /lib64/firmware/liquidio/lio_410nv_nic.bin /lib64/firmware/liquidio/lio_210nv_nic.bin /lib64/firmware/liquidio/lio_210sv_nic.bin /lib64/firmware/iwlwifi-6000g2b-6.ucode /lib64/firmware/LICENCE.atheros_firmware /lib64/firmware/TDA7706_OM_v2.5.1_boot.txt /lib64/firmware/intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq /lib64/firmware/intel/fw_sst_22a8.bin /lib64/modules/3.2.11-gentoo/modules.isapnpmap /lib64/modules/3.2.11-gentoo/modules.ieee1394map /lib64/modules/3.2.11-gentoo/modules.pcimap /lib64/modules/3.2.11-gentoo/modules.order /lib64/modules/3.2.11-gentoo/modules.symbols.bin /lib64/modules/4.1.2-gentoo/modules.dep /lib64/udev/scsi_id /lib64/udev/rules.d/60-persistent-input.rules /lib64/udev/rules.d/64-md-raid-assembly.rules /lib64/udev/rules.d/63-md-raid-arrays.rules /lib64/udev/rules.d/90-alsa-restore.rules /lib64/udev/rules.d/99-fuse.rules /lib64/udev/rules.d/77-mm-huawei-net-port-types.rules /lib64/udev/rules.d/95-upower-wup.rules That is just a small snippet. There are so many, it seems odd that that many would be left behind but equery shows they belong to nothing for the ones I tested on. Thought it better to ask first. ;-) May just leave it alone. Dale :-) :-)
Re: [gentoo-user] another old box to update
Am 07.01.2015 um 14:06 schrieb Alan McKinnon: > The tricky one is going to be that persistent interface names from udev > 18 months or so back. When you get to that, you'll probably want to > re-read the huge threads from that time, as you only get one chance to > get it right. One addition: at the reboot time a fellow IT-guy will be there in front of the console so if the NIC doesn't come up correctly I will be able to instruct him to get the box up and reachable for me. I also use to disable persistent names for such updates ... and get good old eth0 UP instead of enpXsY unconfigured ;-) > I see in your reply to Neil you have glibc conflicts. I don't know what > will happen if you do it with --nodeps, but I wouldn't try that. The box > is remote, if something goes wrong... Rather go with Tomas' suggestion > of yearly portage snapshots and update in stages. skip that ... I leave glibc for now and focus on udev and openrc, see below. > openrc should be seamless. I forget the exact timelines, but IIRC you > will also hit baselayout-2 migration. That one was very smooth and well > documented so you shouldn't have much trouble. openrc needs an updated udev and I am currently working on getting at least sys-fs/udev-208-r1 installed now (conflicts with lvm2 and stuff ...) Some circular dep between udev and udev-init-scripts blocks things ... I fiddled with this and now decided to gor for a "--nodeps" ... while I type this udev, lvm2 and udev-init-scripts get emerged OK now. Phew. openrc installs now as well ... so now for "dispatch-conf" and "disabling the persistent nic names" Seems as if the biggest problems are solved right now? S
Re: [gentoo-user] Systemd as drop-in replacement for udev?
On Thu, 5 Dec 2013 15:18:54 -0600 Canek Peláez Valdés wrote: > On Thu, Dec 5, 2013 at 2:36 PM, Róbert Čerňanský > wrote: > > Hello all, > > > > I am currently updating my system and Portage wants to replace udev > > (204) with systemd (208). My question is (hopefully) simple: > > > > Can I use systemd as drop-in replacement for udev? In other words, > > can I pretend that systemd is udev and continue using OpenRC as > > with udev itself? I would then apply just udev 204 to 208 update > > instructions (http://wiki.gentoo.org/wiki/Udev/upgrade). > > > > I am using WindowMaker and systemd was pulled in by > > gnome-settings-daemon which in turn was pulled in by gdm. I would > > like to stick with gdm. > > The GNOME stuff that requires systemd will not work under OpenRC from > 3.10 on, you could get strange fails with gdm and > gnome-settings-daemon. If it's gdm-3.8, then I think you can use > systemd as udev replacement together with OpenRC, and I believe some > people did it successfully. Thanks. I have enabled openrc-force use flag found this in gnome-settings-daemon emerge log, which confirms what you have said: "gnome-settings-daemon needs Systemd to be *running* for working properly. Please follow the this guide to migrate: http://wiki.gentoo.org/wiki/Systemd You are enabling 'openrc-force' USE flag to skip systemd requirement, this can lead to unexpected problems and is not supported neither by upstream neither by Gnome Gentoo maintainers. If you suffer any problem, you will need to disable this USE flag system wide and retest before opening any bug report." So the it is clear to me now. I will try openrc-force as temporal solution until I'll find a new display manager and give heart breaking good by to GDM. Regards, Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Mar 11, 2012 6:30 PM, "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. > > I'm one of the long-suffering beta-tester for Walt ;-) I've tested all his procedures (except this one), and up to now found no problems. One caveat: my tests are all on servers (test-dev-staging-production). We -- that is, Gentoo users who want to go udev-less -- will certainly appreciate feedback from desktop users. Rgds,
Re: [gentoo-user] udev + /usr
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 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.
>
> Yes, except that udev ONLY handles kernel-events and doesn't process any
> "actions" itself.
> These are placed on a seperate queue for a seperate process.
The problem with this is that you now need to manage synchronization
between the kernel event processor and the action processor, which is
actually more complicated than keeping them together in a
single-threaded, single-process scenario.
--
:wq
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 14:37, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 05:01 AM, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE="firmware-loader" is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli * you are not telling the whole story about what happened and why the fork came into life in the first place. It's not as simple as you seem True, I didn't mention people were needlessly unwilling to join the Gentoo udev team despite being invited to. to suggest. There were good reasons at that point. Some changes were merged by udev upstream and there are still more differences than you point out. That has been discussed numerous of times. * claiming that eudev didn't improve anything is wrong and can be proven I can easily prove eudev is nothing but udev and deleted code, plus restored broken 'rule generator', plus useless kept static nodes creation which was moved to kmod, plus needlessly changed code for uclibc support -- uclibc now has the functions udev needs. * that eudev is behind udev most of the time is correct * that it causes tons of breakage for users... well, I don't know, not for me since almost the beginning * eudev will not be treecleaned until the gentoo devs who maintain it agree (at best, it may be masked) and even if eudev will be obsolete at some point, then it has been a success * I don't understand why you add those rants all over different mailing lists. I have seen it numerous of times and your precision about explaining the situation does not improve. If you think that people need to be warned about eudev, then you should provide a reason to mask it or drop it back to ~arch. Anything else is not constructive and causes confusion. True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. - Samuli
Re: [gentoo-user] no /dev/v4l devices after switching to udev? (possibly)
Brett, Thanks for your help. One way or another it finally started working. I don't know yet whether it will survive a reboot. I'll probably do that test later this evening or tomorrow but at least I'm finally getting v4l devices. I think it was most likely a combination of not using the existing tarball (whatever and whereever that is!) and then running the right drivers. Even after rebooting the dev/v4l devices weren't there, but then when I started running some programs that try to use them they suddenly showed up. All I hope for now is that they don't suddenly disappear! Anyway, thanks for the ideas. cheers, Mark On 5/22/05, Brett I. Holcomb <[EMAIL PROTECTED]> wrote: > Try the tarball no. It may be using the old devfs tarball. > > On Sun, 22 May 2005, Mark Knecht wrote: > > > On 5/22/05, Brett I. Holcomb <[EMAIL PROTECTED]> wrote: > >> Okay. That's not it. Here's what I have in /etc/conf.d/rc that pertains > >> to udev/devfs. I assume you have RC_DEVFSD_STARTUP set to no but what > >> about the tarball? > >> > >> # Set to "yes" if you want to save /dev to a tarball on shutdown > >> # and restore it on startup. This is useful if you have a lot of > >> # custom device nodes that udev do not handle/know about. > >> # (ONLY used by UDEV enabled systems!) > >> > >> RC_DEVICE_TARBALL="no" > >> > >> # Set to "yes" if you want devfsd to start upon bootup. This is > >> # the default for Gentoo. > >> # Set to "no" only if you understand the full implications. A > >> # number of files may need to be altered (i.e. /etc/inittab, > >> # /etc/fstab, etc.). > >> # Also note that it does _NOT_ start for UDEV enabled systems, > >> # even if RC_DEVFSD_STARTUP="yes" ... > >> > >> RC_DEVFSD_STARTUP="no" > >> > > Brett, > > My /etc/conf.d/rc file looks a bit different but good enough I > > hope. I do not have a variable called RC_DEVFSD_STARTUP. None the less > > I've rebuilt the kernel yet again (5th time today?) completely > > removing devfs and even with these settings I am not getting /dev/v4l > > devices: > > > > # Use this variable to control the /dev management behavior. > > # auto - let the scripts figure out what's best at boot > > # devfs - use devfs (requires sys-fs/devfsd) > > # udev - use udev (requires sys-fs/udev) > > # static - let the user manage /dev > > > > #RC_DEVICES="auto" > > RC_DEVICES="udev" > > > > # UDEV OPTION: > > # Set to "yes" if you want to save /dev to a tarball on shutdown > > # and restore it on startup. This is useful if you have a lot of > > # custom device nodes that udev does not handle/know about. > > > > RC_DEVICE_TARBALL="yes" > > > > udev is starting and the messages at boot time look OK to me. > > > > I'm thinking I must somehow be barking up the wrong tree. I do not > > understand the udev language but it would seem that it cannot be that > > difficult. Why are there no v4l devices? > > > > # v4l devices KERNEL="video[0-9]*", NAME="v4l/video%n", > > SYMLINK="video%n", GROUP="video" > > KERNEL="radio[0-9]*", NAME="v4l/radio%n", GROUP="video" > > KERNEL="vbi[0-9]*", NAME="v4l/vbi%n", SYMLINK="vbi%n", GROUP="video" > > KERNEL="vtx[0-9]*", NAME="v4l/vtx%n", GROUP="video" > > > > The rules do not seem to be the problem. They are standard in the > > rules file. Therefore there must be something not happening to cause > > them to get invoked, or possibly something that did happen taht caused > > them to be invalid. > > > > Problem is I don't have a clude what makes this happen? Why do any of > > these get involed in the first place? Is there some caracter device I > > need to create to make them happen the first time? I haven't found > > evidence of that in the wiki's but maybe I've missed it. > > > > Thanks much, > > Desperately Mark > > > > > > -- > > Brett I. Holcomb > [EMAIL PROTECTED] > Registered Linux User #188143 > Remove R777 to email > -- > gentoo-user@gentoo.org mailing list > > -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How do I use 2.6.14 and remove udev and go back to devfs
(I think, without checking) devfs has been removed from 2.6.14 and everything is supposed to be udev from now on. A suggestion made out of frustration with 2.6.14 - use 2.6.13-r3 first. Some kernel versions have had glitches with udev, and I know -r2 and -r3 are working for me on the i82k. The reason is that 2.6.14 has made some rather large leaps that created problems for me (so far all 3 machines, inc. desktops Ive tried have headaches!) First udev, install udev according to the gentoo guide and that should work fine. Check the udev USE flag so and "emerge world --newuse" if neccessary. Strongly reccomended: use the tarball method, not pure udev! you have enough problems without trying to sort that out. Once its working and reliable, make the step to 2.6.14-r2 Traps for 2.6.14 are: dont select both the log and ulog targets together in the netfilter modules or you wont have any logging (changes mean only a single target can be selected at a time - of course in true unix fashion they dont tell you that, or prevent you from doing it:( Only wpa_supplicant version 0.4.5 seems to work pcmcia stuff seems to have changed somewhat, and I changed to pcmciautils which was probably not necessary looking back, but it works nicely and pcmcia-cs is on the way out. wireless (madwifi) is now working fine (still got to check no encryption which I have not been able to get to work under 2.6.13) - I turned all kernel wireless stuff off and use wpa_supplicant and madwifi softwaresuspend2 rc9 works with 2.6.14 - r10 and r11 have bugs, the earlier ones dont apply cleanly. The cisco-vpnclient wont compile against 2.6.14 until you delete some lines out of one of the files: there's patches/instructions on the forums. Also, with the latest security bug in one of the protocols it uses, an update will be along soon I'd say. Ive had no problems with the 6629 series nvidia drivers, manually patched for suspend2, but this was on a desktop (gforce4) as the i82k uses a radeon card. Had to use the ~x86 x11-drm to compile the radeon drm driver against 2.6.14 2.6.14 is looking like a major pita so far. I have another machine to do tonight, but hopefully there wont be any new dramas. BillK On Tue, 2005-11-15 at 23:56 -0800, Daevid Vincent wrote: > I've been running 2.6.10 for some time. Then I started reading some stuff > that I should update my Dell Inspiron 8200 notebook to UDEV. So I followed > the gentoo wiki page and used kernel 2.6.13. This caused (known) issues with > my nvidia driver and I couldn't get the USB mouse to work (yet the alps pad > AND track point both worked fine). I didn't know what else was going to not > work, so I said the hell with this as I'd already wasted enough time and > went back to my old kernel image (until the udev people get their shit > together and this is more stable). > > I unmerged 'udev' > > I re-emerged devfsd > > Things were generally working fine (with 2.6.10) > > Tonight I tried to make a new 2.6.14 kernel (using make oldconfig) and when > it booted, there was some message that I don't have DEVFS or UDEV installed > and so many things didn't work including sound, nvidia, wireless, etc. > > I re-read the udev wiki page and tried to find the 'make menuconfig' options > they suggest and can't find them. I also grepped my .config for both "UDEV" > and "DEVFS" and found nothing. WTF! > > How do I use the good old devfs with the 2.6.14+ kernels?! Where are the > freakin' settings? What do I need to change/fix to get it to work again. > UGH! > -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Moving from old udev to eudev
On 08/12/2013 02:06 PM, Samuli Suominen wrote: > On 12/08/13 14:37, hasufell wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 08/02/2013 05:01 AM, Samuli Suominen wrote: >>> On 02/08/13 05:48, Dale wrote: >>>> Samuli Suominen wrote: >>>>> >>>>> Huh? USE="firmware-loader" is optional and enabled by default >>>>> in sys-fs/udev Futhermore predictable network interface names >>>>> work as designed, not a single valid bug filed about them. >>>>> >>>>> Stop spreading FUD. >>>>> >>>>> Looking forward to lastrite sys-fs/eudev just like >>>>> sys-apps/module-init-tools already was removed as unnecessary >>>>> later on. >>>> >>>> So your real agenda is to kill eudev? Maybe it is you that is >>>> spreading FUD instead of others. Like others have said, udev was >>>> going to cause issues, eudev has yet to cause any. >>> >>> Yes, absolutely sys-fs/eudev should be punted from tree since it >>> doesn't bring in anything useful, and it reintroduced old bugs from >>> old version of udev, as well as adds confusing to users. And no, >>> sys-fs/udev doesn't have issues, in fact, less than what >>> sys-fs/eudev has. Like said earlier, the bugs assigned to >>> udev-bugs@g.o apply also to sys-fs/eudev and they have even more in >>> their github ticketing system. And sys-fs/udev maintainers have to >>> constantly monitor sys-fs/eudev so it doesn't fall too much behind, >>> which adds double work unnecessarily. They don't keep it up-to-date >>> on their own without prodding. >>> >>> Really, this is how it has went right from the start and the double >>> work and user confusion needs to stop. >>> >>> - Samuli >>> >>> >> >> * you are not telling the whole story about what happened and why the >> fork came into life in the first place. It's not as simple as you seem > > True, I didn't mention people were needlessly unwilling to join the > Gentoo udev team despite being invited to. That's a bit unrelated. It wasn't just about the gentoo ebuild. > >> to suggest. There were good reasons at that point. Some changes were >> merged by udev upstream and there are still more differences than you >> point out. That has been discussed numerous of times. >> * claiming that eudev didn't improve anything is wrong and can be proven > > I can easily prove eudev is nothing but udev and deleted code, plus > restored broken 'rule generator', plus useless kept static nodes > creation which was moved to kmod, plus needlessly changed code for > uclibc support -- uclibc now has the functions udev needs. > Wonder why udev upstream merged back changes if it was all that bad. >> * that eudev is behind udev most of the time is correct >> * that it causes tons of breakage for users... well, I don't know, not >> for me since almost the beginning >> * eudev will not be treecleaned until the gentoo devs who maintain it >> agree (at best, it may be masked) and even if eudev will be obsolete >> at some point, then it has been a success >> * I don't understand why you add those rants all over different >> mailing lists. I have seen it numerous of times and your precision >> about explaining the situation does not improve. If you think that >> people need to be warned about eudev, then you should provide a reason >> to mask it or drop it back to ~arch. Anything else is not constructive >> and causes confusion. > > True, it won't be dropped for long as people are maintaining it. That's > how maintainership works. > But trying to lie to people it's somehow solving something currently is > annoying as 'ell and should be corrected where seen. > Who lied?
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 16:39, hasufell wrote: On 08/12/2013 02:06 PM, Samuli Suominen wrote: On 12/08/13 14:37, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 05:01 AM, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE="firmware-loader" is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli * you are not telling the whole story about what happened and why the fork came into life in the first place. It's not as simple as you seem True, I didn't mention people were needlessly unwilling to join the Gentoo udev team despite being invited to. That's a bit unrelated. It wasn't just about the gentoo ebuild. That's all it was. to suggest. There were good reasons at that point. Some changes were merged by udev upstream and there are still more differences than you point out. That has been discussed numerous of times. * claiming that eudev didn't improve anything is wrong and can be proven I can easily prove eudev is nothing but udev and deleted code, plus restored broken 'rule generator', plus useless kept static nodes creation which was moved to kmod, plus needlessly changed code for uclibc support -- uclibc now has the functions udev needs. Wonder why udev upstream merged back changes if it was all that bad. Merged back what changes? That'd be news to me. I think you might be confusing something. * that eudev is behind udev most of the time is correct * that it causes tons of breakage for users... well, I don't know, not for me since almost the beginning * eudev will not be treecleaned until the gentoo devs who maintain it agree (at best, it may be masked) and even if eudev will be obsolete at some point, then it has been a success * I don't understand why you add those rants all over different mailing lists. I have seen it numerous of times and your precision about explaining the situation does not improve. If you think that people need to be warned about eudev, then you should provide a reason to mask it or drop it back to ~arch. Anything else is not constructive and causes confusion. True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. Who lied? Let's rephrase lying with FUD for correctness.
Re: [gentoo-user] Bad luck with new installation: Compilation issues (eudev)
Have you seen this thread in the forums? It looks like your problem:
https://forums.gentoo.org/viewtopic-t-1057500-view-previous.html?sid=9c8b57325eef824a0748ec4ca94ac8b1
Found via a quick google search. Keywords: "eudev 3.2.1 error gentoo".
No offense, really. But you do not need to wait for an answer if you
search for yourself. :-)
On 02/05/2017 03:08 PM, meino.cra...@gmx.de wrote:
> Hi,
>
> I am still compiling my new root...
>
> After some of the rebuild/sinc/revdep/ cycles I got this while trying
> to update sys-fs/eudev
>
> (ACCEPT_KEYWORDS is set to ~amd64 globally right before any
> compilations)
>
> /var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1/src/udev/udev-builtin-keyboard.c:31:26:
> note: previous declaration of 'keyboard_lookup_key' was here
> static const struct key *keyboard_lookup_key(const char *str, unsigned len);
> ^
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
> -I/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1/src/udev -I../..
> -include ../../config.h -DROOTPREFIX=\"\"
> -DUDEV_HWDB_DIR=\"/etc/udev/hwdb.d\" -DUDEV_HWDB_BIN=\"/etc/udev/hwdb.bin\"
> -DUDEV_CONF_DIR=\"/etc/udev\" -DUDEV_ROOT_RUN=\"/run\"
> -DUDEV_RULES_DIR=\"/lib/udev/rules.d\" -DUDEV_LIBEXEC_DIR=\"/lib/udev\"
> -DUDEV_VERSION=\"220\" -I
> /var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1/src/shared -I
> /var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1/src/libudev -I
> ../../src/udev -march=native -msse -msse2 -msse3 -O2 -pipe -c -o
> udevadm-monitor.o
> /var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1/src/udev/udevadm-monitor.c
> make[4]: *** [Makefile:813: libudev_core_la-udev-builtin-keyboard.lo] Error 1
> make[4]: *** Waiting for unfinished jobs
> make[4]: Leaving directory
> '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1-abi_x86_64.amd64/src/udev'
> make[3]: *** [Makefile:500: all] Error 2
> make[3]: Leaving directory
> '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1-abi_x86_64.amd64/src/udev'
> make[2]: *** [Makefile:394: all-recursive] Error 1
> make[2]: Leaving directory
> '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1-abi_x86_64.amd64/src'
> make[1]: *** [Makefile:446: all-recursive] Error 1
> make[1]: Leaving directory
> '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1-abi_x86_64.amd64'
> make: *** [Makefile:378: all] Error 2
> * ERROR: sys-fs/eudev-3.2.1::gentoo failed (compile phase):
> * emake failed
> *
> * If you need support, post the output of `emerge --info
> '=sys-fs/eudev-3.2.1::gentoo'`,
> * the complete build log and the output of `emerge -pqv
> '=sys-fs/eudev-3.2.1::gentoo'`.
> * The complete build log is located at
> '/var/tmp/portage/sys-fs/eudev-3.2.1/temp/build.log'.
> * The ebuild environment file is located at
> '/var/tmp/portage/sys-fs/eudev-3.2.1/temp/environment'.
> * Working directory:
> '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1-abi_x86_64.amd64'
> * S: '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1'
>
>>>> Failed to emerge sys-fs/eudev-3.2.1, Log file:
>
> eix eudev shows:
> solfire ~ # eix sys-fs/eudev
> [U] sys-fs/eudev
> Available versions: 1.9-r2 1.10-r2 3.1.2 3.1.5 (~)3.2 (~)3.2.1 **4.
> ** {+blkid doc efi gudev +hwdb introspection +keymap +kmod +modutils
> +openrc (+)rule-generator selinux smack static-libs test ABI_MIPS="n32 n64
> o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
> Installed versions: 3.1.5(05:33:42 02/02/17)(hwdb kmod -introspection
> -rule-generator -selinux -static-libs -test ABI_MIPS="-n32 -n64 -o32"
> ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
> Homepage:https://github.com/gentoo/eudev
> Description: Linux dynamic and persistent device naming support
> (aka userspace devfs)
>
>
> I dont want to poison the mailing list with long logs in case of
> someone knows what's going on here...but if wanted, I will post them
> of course... :)
>
> Cheers
> Meino
>
>
>
>
>
Re: [gentoo-user] Bad luck with new installation: Compilation issues (eudev)
Hi Alexander,
thanks for the link!
Had found the culprit myself and fixed it with
a user patch...
Cheers
Meino
Alexander Openkowski [17-02-05 18:28]:
> Have you seen this thread in the forums? It looks like your problem:
>
> https://forums.gentoo.org/viewtopic-t-1057500-view-previous.html?sid=9c8b57325eef824a0748ec4ca94ac8b1
>
> Found via a quick google search. Keywords: "eudev 3.2.1 error gentoo".
> No offense, really. But you do not need to wait for an answer if you
> search for yourself. :-)
>
> On 02/05/2017 03:08 PM, meino.cra...@gmx.de wrote:
> > Hi,
> >
> > I am still compiling my new root...
> >
> > After some of the rebuild/sinc/revdep/ cycles I got this while trying
> > to update sys-fs/eudev
> >
> > (ACCEPT_KEYWORDS is set to ~amd64 globally right before any
> > compilations)
> >
> > /var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1/src/udev/udev-builtin-keyboard.c:31:26:
> > note: previous declaration of 'keyboard_lookup_key' was here
> > static const struct key *keyboard_lookup_key(const char *str, unsigned
> > len);
> > ^
> > x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
> > -I/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1/src/udev -I../..
> > -include ../../config.h -DROOTPREFIX=\"\"
> > -DUDEV_HWDB_DIR=\"/etc/udev/hwdb.d\" -DUDEV_HWDB_BIN=\"/etc/udev/hwdb.bin\"
> > -DUDEV_CONF_DIR=\"/etc/udev\" -DUDEV_ROOT_RUN=\"/run\"
> > -DUDEV_RULES_DIR=\"/lib/udev/rules.d\" -DUDEV_LIBEXEC_DIR=\"/lib/udev\"
> > -DUDEV_VERSION=\"220\" -I
> > /var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1/src/shared -I
> > /var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1/src/libudev -I
> > ../../src/udev -march=native -msse -msse2 -msse3 -O2 -pipe -c -o
> > udevadm-monitor.o
> > /var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1/src/udev/udevadm-monitor.c
> > make[4]: *** [Makefile:813: libudev_core_la-udev-builtin-keyboard.lo] Error
> > 1
> > make[4]: *** Waiting for unfinished jobs
> > make[4]: Leaving directory
> > '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1-abi_x86_64.amd64/src/udev'
> > make[3]: *** [Makefile:500: all] Error 2
> > make[3]: Leaving directory
> > '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1-abi_x86_64.amd64/src/udev'
> > make[2]: *** [Makefile:394: all-recursive] Error 1
> > make[2]: Leaving directory
> > '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1-abi_x86_64.amd64/src'
> > make[1]: *** [Makefile:446: all-recursive] Error 1
> > make[1]: Leaving directory
> > '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1-abi_x86_64.amd64'
> > make: *** [Makefile:378: all] Error 2
> > * ERROR: sys-fs/eudev-3.2.1::gentoo failed (compile phase):
> > * emake failed
> > *
> > * If you need support, post the output of `emerge --info
> > '=sys-fs/eudev-3.2.1::gentoo'`,
> > * the complete build log and the output of `emerge -pqv
> > '=sys-fs/eudev-3.2.1::gentoo'`.
> > * The complete build log is located at
> > '/var/tmp/portage/sys-fs/eudev-3.2.1/temp/build.log'.
> > * The ebuild environment file is located at
> > '/var/tmp/portage/sys-fs/eudev-3.2.1/temp/environment'.
> > * Working directory:
> > '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1-abi_x86_64.amd64'
> > * S: '/var/tmp/portage/sys-fs/eudev-3.2.1/work/eudev-3.2.1'
> >
> >>>> Failed to emerge sys-fs/eudev-3.2.1, Log file:
> >
> > eix eudev shows:
> > solfire ~ # eix sys-fs/eudev
> > [U] sys-fs/eudev
> > Available versions: 1.9-r2 1.10-r2 3.1.2 3.1.5 (~)3.2 (~)3.2.1
> > **4. ** {+blkid doc efi gudev +hwdb introspection +keymap +kmod
> > +modutils +openrc (+)rule-generator selinux smack static-libs test
> > ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
> > Installed versions: 3.1.5(05:33:42 02/02/17)(hwdb kmod -introspection
> > -rule-generator -selinux -static-libs -test ABI_MIPS="-n32 -n64 -o32"
> > ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
> > Homepage:https://github.com/gentoo/eudev
> > Description: Linux dynamic and persistent device naming
> > support (aka userspace devfs)
> >
> >
> > I dont want to poison the mailing list with long logs in case of
> > someone knows what's going on here...but if wanted, I will post them
> > of course... :)
> >
> > Cheers
> > Meino
> >
> >
> >
> >
> >
>
>
Re: [gentoo-user] udev-181 saga continues with udisks (~amd64)
On Sun, Aug 12 2012, Canek Peláez Valdés wrote: > On Sun, Aug 12, 2012 at 12:47 PM, Allan Gottlieb wrote: >> I have been masking udev-181 so that I can continue to keep my current >> system with / and /usr separate partitions. >> >> This has required masking pciutils and usbutils as well. >> /etc/portage/package.mask/udev-181 contains >> >=sys-fs/udev-181 >> >=sys-apps/pciutils-3.1.9-r2 >> >=sys-apps/usbutils-005-r1 >> >> Now udisks-1.99.0-r1 wants to pull in a new package udev-init-scripts. >> I currently have udisks-1.98.0 which is fine. >> >> I added >> >=sys-fs/udisks-1.99.0 >> to package.mask/udev-181 and emerge --pretend --update world reports no >> conflicts. >> >> I was about to proceed when I looked at eix udisks and noticed that >> 1. "my" udisk -1.98.0 is no longer there >> 2. The 1-99.0-r1 is now in slot 2 and new 1.0.4-r[23] are in slot 0. >>I looked at -r3 and it wants >=udev-171-r5. Since I have -r6 my sys. >>should meet the requirement. >> >> So I wonder if my mask >=sys-fs/udisks-1.99.0 is a bad idea and I should >> instead be forcing/encouraging udisks-1.0.4-r3 (and, if so, how?). > > Not a bad idea per se, but you do realize that you cannoy keep masking > some stuff and upgrading the rest, right? Right. > If you are happy with udisks 1.98, get the ebuild > /var/db/pkg/sys-fs/udisk-1.98.0 (if still there), and keep it in a > personal overlay. The same with all the stuff you need for not > upgrading udev. > > I believe (for reading your posts into the list) that you really don't > want an initramfs, or at least dracut. I would give it a try; I'm > pretty sure is easier than juggling package masks. You are certainly correct that this is a stopgap method. I am trying to order a new system from dell and when successful will definitely install / and /usr together on one partition and hence have the modern udev. Once I am comfortably on that new system I will re-install my three old systems to also have a combined / /usr. I just don't want to have my main system down. thanks, allan
[gentoo-user] Re: Anyone switched to eudev yet?
On 2012-12-24, Bruce Hill wrote: > On Mon, Dec 24, 2012 at 05:06:41PM +0200, Nuno J. Silva wrote: >> >> Now, also, from my understanding, this was already the case for some >> time (maybe even years?). And that's why I've asked for more details. >> >> So, if the udev you use is OK with no initrd, what is in the new udev >> that actually requires the initrd? > > "eselect news read" is yore frnd ;) > > 2012-03-16-udev-181-unmasking > Title udev-181 unmasking > AuthorWilliam Hubbs > Posted2012-03-16 > Revision 1 > > udev-181 is being unmasked on 2012-03-19. > > This news item is to inform you that once you upgrade to a version of > udev >=181, if you have /usr on a separate partition, you must boot your > system with an initramfs which pre-mounts /usr. > > An initramfs which does this is created by >>=sys-kernel/genkernel-3.4.25.1 or >>=sys-kernel/dracut-017-r1. If you do not want to use these tools, be > sure any initramfs you create pre-mounts /usr. > > Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9. > > For more information on why this has been done, see the following URL: > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > You can read that systemd is *THE* problem, not udev, and that until the > primma donnas fubared udev by jamming systemd into it, There Was No Such > Problem (TM). > > And that explains where the train jumped the track... No, actually it doesn't. It just has the same kind of very generic claim that has been repeated several times in this thread (which is "why? because it won't work") and links to an article that explains why some udev rules would silently fail for all this time (for *years* now, I'd guess). The article does not describe a change introduced with 181, it describes what already happened with previous versions. I am not using >= 181 and I do see the issues the article mentions (it does not break here because I do not have a separate /usr, but I can see some rules that use stuff from /usr). -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] udev-197 moves from /usr/lib to /lib
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. First Kay... http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html > We promised to keep udev properly *running* as standalone, we never > told that it can be *build* standalone. And that still stands. > > We never claimed, that all the surrounding things like documentation > always fully match, if only udev is picked out of systemd. > > I would welcome if people stop reading that "promise" into the > announcement, it just wasn't written there. And then Lennart... http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html > (Yes, udev on non-systemd systems is in our eyes a dead end, in case > you haven't noticed it yet. I am looking forward to the day when we > can drop that support entirely.) > > Lennart > > -- Lennart Poettering - Red Hat, Inc. The only assumption I'm making is that Kay and Lennart aren't lying. Kay tells us that we may eventually not be able to build udev standalone; i.e. we may have to build systemd in order to run udev. Gentoo users are familiar with cascading dependancies which tend to bloat our systems, as well as introducing additional points of failure. Lennart goes one step further and looks forward to the day that we may not be able to run udev without running systemd. For those of us who do not want to build, let alone run, systemd, these 2 messages are more than sufficient justification for the eudev fork. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] udev-191 bit me. Insufficient ptys
On Wed, 30 Jan 2013 22:35:06 -0500 Michael Mol wrote: > So, I botched the upgrade to udev-191. I thought I'd followed the > steps, but I apparently only covered them for one machine, not both. > > The news item instructions specified that I had to remove > udev-postmount from my runlevels. I didn't have udev-postmount in my > runlevels, so I didn't remove it. Turns out, that dictum also applies > to udev-mount. So after removing that[1], I was able to at least boot > again. > > Udev also complained about DEVTMPFS not being enabled in the > kernel.[2] I couldn't get into X, but I could log in via getty and a > plain old vt, so I enabled it, rebuilt the kernel, installed it and > rebooted...and now that's presumably covered. > > I'm now able to get into X, but when I try to run an xterm, it fails. > Checking ~/.xsession_errors, I find: > > xterm: Error 32, error 2: No such file or directory > Reason: get_pty: not enough ptys > > I find this bizarre, as I'd never had any trouble with xterm in this > way before. What'd I do wrong, and how do I recover? I don't trust > emerging at this point; I tried re-emerging udev, and I aborted after > I saw an stderr line about failing to open a pty, even though portage > does quiet builds for parallel building by default...so I doubt > whatever emitted that line on stderr was being properly guarded > against the failure. > > [1] I didn't have a boot cd or similar to work with, so I used the old > init=/bin/sh trick on the command line. That was functional. And then > I tried init=/usr/bin/vim, and things got real. :) > > [2] Sparking a bemused discussion with a friend at tonight's LUG > meeting over the devfs->udev->udev+devtmpfs progression, but that's a > different story. I can't get any kernel >=gentoo-sources-3.7.1 to work properly with vtys either. 3.7.1 is fine, anything earlier is fine. I haven't bothered tracking it down further than that (have a severe dose of laziness right now...) What kernel are you running on these affected hosts? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] udev-191 bit me. Insufficient ptys
On Thu, Jan 31, 2013 at 10:23 AM, Alan McKinnon wrote: > On Wed, 30 Jan 2013 22:35:06 -0500 > Michael Mol wrote: > >> So, I botched the upgrade to udev-191. I thought I'd followed the >> steps, but I apparently only covered them for one machine, not both. >> >> The news item instructions specified that I had to remove >> udev-postmount from my runlevels. I didn't have udev-postmount in my >> runlevels, so I didn't remove it. Turns out, that dictum also applies >> to udev-mount. So after removing that[1], I was able to at least boot >> again. >> >> Udev also complained about DEVTMPFS not being enabled in the >> kernel.[2] I couldn't get into X, but I could log in via getty and a >> plain old vt, so I enabled it, rebuilt the kernel, installed it and >> rebooted...and now that's presumably covered. >> >> I'm now able to get into X, but when I try to run an xterm, it fails. >> Checking ~/.xsession_errors, I find: >> >> xterm: Error 32, error 2: No such file or directory >> Reason: get_pty: not enough ptys >> >> I find this bizarre, as I'd never had any trouble with xterm in this >> way before. What'd I do wrong, and how do I recover? I don't trust >> emerging at this point; I tried re-emerging udev, and I aborted after >> I saw an stderr line about failing to open a pty, even though portage >> does quiet builds for parallel building by default...so I doubt >> whatever emitted that line on stderr was being properly guarded >> against the failure. >> >> [1] I didn't have a boot cd or similar to work with, so I used the old >> init=/bin/sh trick on the command line. That was functional. And then >> I tried init=/usr/bin/vim, and things got real. :) >> >> [2] Sparking a bemused discussion with a friend at tonight's LUG >> meeting over the devfs->udev->udev+devtmpfs progression, but that's a >> different story. > > I can't get any kernel >=gentoo-sources-3.7.1 to work properly with > vtys either. > > 3.7.1 is fine, anything earlier is fine. > I haven't bothered tracking it down further than that (have a severe > dose of laziness right now...) > > What kernel are you running on these affected hosts? gentoo-sources-3.6.11 Note my vtys worked fine, it was just the ptys which failed. -- :wq
[gentoo-user] devfs to udev upgrade issues
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 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How do I use 2.6.14 and remove udev and go back to devfs
Am Mittwoch, 16. November 2005 08:56 schrieb ext Daevid Vincent: > I've been running 2.6.10 for some time. Then I started reading some stuff > that I should update my Dell Inspiron 8200 notebook to UDEV. So I > followed the gentoo wiki page and used kernel 2.6.13. This caused (known) > issues with my nvidia driver and I couldn't get the USB mouse to work > (yet the alps pad AND track point both worked fine). How did you set it up? Where didn't it work, X, gpm? > I didn't know what > else was going to not work, so I said the hell with this as I'd already > wasted enough time and went back to my old kernel image (until the udev > people get their shit together and this is more stable). Udev works fine for me since months, now. > I unmerged 'udev' > > I re-emerged devfsd > > Things were generally working fine (with 2.6.10) > > Tonight I tried to make a new 2.6.14 kernel (using make oldconfig) and > when it booted, there was some message that I don't have DEVFS or UDEV > installed and so many things didn't work including sound, nvidia, > wireless, etc. > I re-read the udev wiki page and tried to find the 'make menuconfig' > options they suggest and can't find them. I also grepped my .config for > both "UDEV" and "DEVFS" and found nothing. WTF! Config options for devfs were removed in 2.6.14. However, the code is still there (for now). > How do I use the good old devfs with the 2.6.14+ kernels?! Where are the > freakin' settings? What do I need to change/fix to get it to work again. They are commented out. Just grep your kernel source tree for "CONFIG_DEVFS" and comment them in again. However, sooner or later the devfs code will be removed from the kernel, maybe already in 2.6.15 or .16. If you tell us more details about your problems with udev, people here on the list will try to help you sort them out. Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Hambornerstraße 55 | Web: http://www.capgemini.com D-40472 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net pgpXLfZF2dqZy.pgp Description: PGP signature
[gentoo-user] Udev trouble: Non working rule...or...
Hi,
may bet this is part of the theory about the relationship
between the forest and the trees...I am trying this already
for a longer time.
I have one of these:
When plugged in, lsusb reports those as:
Bus 006 Device 018: ID 16d0:0753 MCS Digistump DigiSpark
and in the verbose form:
Bus 006 Device 018: ID 16d0:0753 MCS Digistump DigiSpark
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x16d0 MCS
idProduct 0x0753 Digistump DigiSpark
bcdDevice1.06
iManufacturer 0
iProduct0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 18
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 0
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
On the web site of digistump there is listed the following udev-rule,
which I copy-pasted into
ls -l /etc/udev/rules.d/49-micronucleus.rules
-rw-r--r-- 1 root root 809 2017-09-28 16:23
/etc/udev/rules.d/49-micronucleus.rules
the contents of that rule is:
# UDEV Rules for Micronucleus boards including the Digispark.
# This file must be placed at:
#
# /etc/udev/rules.d/49-micronucleus.rules(preferred location)
# or
# /lib/udev/rules.d/49-micronucleus.rules(req'd on some broken systems)
#
# After this file is copied, physically unplug and reconnect the board.
#
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0753",
MODE:="0666"
KERNEL=="ttyACM*", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0753",
MODE:="0666", ENV{ID_MM_DEVICE_IGNORE}="1"
#
# If you share your linux system with other users, or just don't like the
# idea of write permission for everybody, you can replace MODE:="0666" with
# OWNER:="yourusername" to create the device owned by you, or with
# GROUP:="somegroupname" and mange access using standard unix groups.
#
After inserting that rule I did a
udevadm control --reload-rules
as root and inserted the Digispark.
As listed above, lsusb could list the Digispark...but udev ignores it.
I can find the device under /dev/bus/, though.
But there is no device created by udev directly in /dev.
Since the Arduino-IDE needs any port to send the firmware to I am
currentlu out of business.
I can see the trees...but where is the forest?
Thanks a lot for any enlightment in advance!
Cheers
Meino
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 31/03/2013 20:30, Tanstaafl wrote: > On 2013-03-31 1:10 PM, Yohan Pereira wrote: >> What you need to do is add the original ebuild for udev-171 to your >> local overlay as is. Then run emerge using the -g option see man >> emerge. > > Hmmm... I had thought that the local ebuild was gone due to it being > removed from portage, but yep, there it is: > > myhost : Sun Mar 31, 13:42:50 : ~ > # ls -al /usr portage/sys-fs/udev > total 292 > drwxr-xr-x 3 portage portage512 Mar 30 12:01 . > drwxr-xr-x 128 portage portage 3488 Mar 31 10:31 .. > -rw-r--r-- 1 rootroot 23718 Mar 30 12:01 ChangeLog > -rw-r--r-- 1 rootroot105929 Mar 15 06:01 ChangeLog-2009 > -rw-r--r-- 1 rootroot 10729 Mar 15 05:38 ChangeLog-2010 > -rw-r--r-- 1 rootroot 11721 Mar 15 05:38 ChangeLog-2011 > -rw-r--r-- 1 rootroot 23242 Mar 15 05:38 ChangeLog-2012 > drwxr-xr-x 2 portage portage 88 Mar 31 10:31 files > -rw-r--r-- 1 rootroot 10407 Mar 30 12:01 Manifest > -rw-r--r-- 1 rootroot 1401 Mar 28 18:01 metadata.xml > -rw-r--r-- 1 rootroot 16093 Feb 2 11:31 udev-171-r10.ebuild > -rw-r--r-- 1 rootroot 15057 Mar 6 15:31 udev-197-r8.ebuild > -rw-r--r-- 1 rootroot 14100 Mar 24 06:45 udev-198-r6.ebuild > -rw-r--r-- 1 rootroot 13431 Mar 29 03:01 udev-199-r1.ebuild > -rw-r--r-- 1 rootroot 13384 Mar 30 12:01 udev-200.ebuild > -rw-r--r-- 1 rootroot 13388 Mar 30 12:01 udev-.ebuild > myhost : Sun Mar 31, 13:42:52 : ~ > # > > So, do I also copy the manifest file? metadata.xml? files dir? Or do I > just copy the ebuild then regenerate the manifest file? You will need the files dir. metadata.xml is not necessary in your personal overlay. You will almost always regenerate the manifest anyway so copy the original by all means, but you'll likely overwrite it soon -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
First hint: it's a mess -- don't do it on a critical machine. (My main machine is ~amd64 and that's why I'm doing it on virtual ~amd64 machines first.) The new gnome-shell demands that systemd be installed, even if you don't intend to use it. The latest systemd conflicts with udev because the udev project has been rolled into systemd, which now provides all of the files previously installed by udev. Therefore your machine will still boot without udev because systemd installs all the udev files. You don't need to start or use systemd if you don't want to, but the systemd package must be installed *before* you reboot and after removing udev. Removal of udev has caused a few (temporary) problems with useflags, because a few packages still depend directly on udev instead of the newer (!systemd ? udev) which means accept either one but not both. That will get fixed soon, I'm sure. The right way to upgrade gnome is probably to remove every gnome package on the machine, which will avoid many of the conflicts I've had to fight for the last two days -- but of course I did it the hard way instead :) You can try emerge -au gnome-light early in the update, which is simpler than emerging gnome in all its immensity, but that's no guarantee of success -- I'm sure you'll still run into conflicts between packages and useflags, but it might be a bit easier. When you see conflicting packages that won't install, I suggest deleting both packages immediately -- let portage sort out the conflicts. Just keep removing packages until portage finally stops complaining. Beware of pambase, however. I finally took Canek's advice and removed consolekit from the machine and unset the useflag for all packages, including pambase and polkit. I'd suggest you get pambase and polkit re-installed with the proper useflags before you try to reboot. Dunno if that's mandatory, but I did it that way and had no problems (yet). I've finished updating my virtual gentoo systemd machine now, but I'm still fighting with the virtual openrc machine and I'm not sure how it will turn out. More tomorrow :)
[gentoo-user] Re: udev (probably)
On Mon, 2009-11-23 at 15:05 -0600, Michael Sullivan wrote: > I've been working all day rearranging furniture in my apartment. I got > the my computer to its new spot and hooked everything up and booted and > I saw a message that said something about some kernel option that was > turned on that shouldn't be, and that udev might not work. When I got > logged in, I found that Mythtv was all screwed up and that it said I > didn't have any programs set to record. LiveTV didn't work at all. My > tv card (dev/video0); ls says it's there, but cat says it's not. When I > used /etc/init.d/udev I got a message saying that the udev initscript > only works with baselayout 2 and that I shouldn't use it with baselayout > 1. I didn't even know I was using baselayout 1! Anyway, is there a > way, after I've booted the computer, to access those messages shown at > startup? I found it in /var/log/messages. It said: Nov 23 15:37:07 camille kernel: udev: missing sysfs features; please update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED option; udev may fail to work correctly Nov 23 15:00:01 camille sudo: michael : TTY=pts/4 ; PWD=/home/michael ; USER=root ; COMMAND=/etc/init.d/udev restart I'm rebuilding the kernel with that option disabled, but in the meantime why did Mythtv forget my programs set to record? I checked that mysql is running, and it is, I checked mythbacked. The only discrepancy I can find is the existence of /dev/video0...
Re: [gentoo-user] possible udev problem?
Panics Robert wrote: Hello ! I have a problem, some days ago with the /dev directory. Some or all blocking devices despaired like /dev/vg/ /dev/loop/ /dev/sda and some others also. After a reboot I see that my server couldn't boot in, couse it try to find the root filesystem from /dev/vg/root (using lvm) At the boot process when I see that Activating mdev, I see that the logical volume groups found ok, so after I rewrite the fstab to /dev/mapper/vg-root I can boot in. But also couldn't see /dev/sda and others. When I use this command udevadm test /sys/block/sda/sda1 then it appears at under /dev/sda1 , this also true for the loop device ram devices and others. I use kernel 2.6.32-xen-r1 , and sys-fs/udev-151-r4. any help will be appreciated. Well, I was hoping someone that knows more about udev would post something. This is what I would check into. Did you upgrade udev recently? If so, try downgrading and rebooting. If that doesn't help, I would delete the udev rules and reboot. They should be in /etc/udev/rules.d/. If neither of those helps, maybe try a newer version that is not supposed to be stable. I am using the same version of udev you are but I don't use lvm so I can't say that it works, just that it works for me without lvm. If you are still stuck, post again with what you tried. Maybe someone will come up with something. Dale :-) :-)
Re: [gentoo-user] Firmware loading problem
2011/1/17 :
> I am running a vanilla linux kernel version 2.6.37 .
>
> Furthermore in
>
> /lib/firmware
>
> there is a folder called
>
> av7110
>
> which I think contains the firmware for that card.
I don't think this card needs a firmware. You just enabled to much dvb
related stuff in your kernel configuration which results in the
creation of this folder. I need the av7110 stuff here for my FF DVB-S
card.
What problem do you have with this card, normally dmesg should spit
something out if there is firmware missing.
> I read, that I need "hotplug" to load this firmware while booting.
>
> I did a
>
> emerge hotplug
>
> which runs fine but gave me warning that I should emerge coldplug.
>
> Ok, so I did an additional
>
> emerge coldplug
>
> which fails with
>
> solfire:/home/mccramer>sudo emerge coldplug
> Calculating dependencies... done!
> [ebuild N ] sys-apps/coldplug-20040920-r1
> [blocks B ] sys-apps/coldplug ("sys-apps/coldplug" is blocking
> sys-fs/udev-151-r4)
> [blocks B ] >=sys-fs/udev-089 (">=sys-fs/udev-089" is blocking
> sys-apps/coldplug-20040920-r1)
>
> * Error: The above package list contains packages which cannot be
> * installed at the same time on the same system.
>
> (sys-apps/coldplug-20040920-r1, ebuild scheduled for merge) pulled in by
> coldplug
>
>
> If I understand this correctly, I have to downgrade udev from udev-151
> down to udev-089 to be able to install coldplug.
>
> Is this really needed? How can I install the firmware?
I think the functionality from hot- and coldplug is now provided by
udev thus the blocker.
--
Daniel Pielmeier
[gentoo-user] Fwd: [gentoo-project] With regard to udev stabilization
Original Message Subject:[gentoo-project] With regard to udev stabilization Date: Mon, 12 Nov 2012 21:40:53 -0500 From: Richard Yao Reply-To: gentoo-proj...@lists.gentoo.org To: gentoo-proj...@lists.gentoo.org Richard Yao wrote: > Dear Everyone, > > It is no secret that many of us are unhappy with the direction that udev > has taken under the leadership of the systemd developers. That includes > Linus Torvalds, who is 'leery of the fact that the udev maintenance > seems to have gone into some "crazy mode" where they have made changes > that were known to be problematic, and are pure and utter stupidity.' > > https://lkml.org/lkml/2012/10/2/505 > > After speaking with several other Gentoo developers that share Linus' > concerns, I have decided to form a team to fork udev. Our plan is to > eliminate the separate /usr requirement from our fork, among other > things. We will announce the project later this week. > > I understand that the council is scheduled to vote on a topic related to > udev stabilization. Would it be possible to delay the vote for another > month so that we have time to get organized? > > Yours truly, > Richard Yao > 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. I wonder what they will name it tho. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Fwd: [gentoo-project] With regard to udev stabilization
Am 13.11.2012 04:20, schrieb Dale: > > > Original Message > Subject: [gentoo-project] With regard to udev stabilization > Date: Mon, 12 Nov 2012 21:40:53 -0500 > From: Richard Yao > Reply-To: gentoo-proj...@lists.gentoo.org > To: gentoo-proj...@lists.gentoo.org > > > Richard Yao wrote: > >> Dear Everyone, >> >> It is no secret that many of us are unhappy with the direction that udev >> has taken under the leadership of the systemd developers. That includes >> Linus Torvalds, who is 'leery of the fact that the udev maintenance >> seems to have gone into some "crazy mode" where they have made changes >> that were known to be problematic, and are pure and utter stupidity.' >> >> https://lkml.org/lkml/2012/10/2/505 >> >> After speaking with several other Gentoo developers that share Linus' >> concerns, I have decided to form a team to fork udev. Our plan is to >> eliminate the separate /usr requirement from our fork, among other >> things. We will announce the project later this week. >> >> I understand that the council is scheduled to vote on a topic related to >> udev stabilization. Would it be possible to delay the vote for another >> month so that we have time to get organized? >> >> Yours truly, >> Richard Yao >> > > 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. > > I wonder what they will name it tho. > > Dale > > :-) :-) > What about gdev (gentoo dev) :)
Re: [gentoo-user] touch Error: Function not implemented
I guess you used a livecd to boot into your computer, and then chrooted into your existing environment? Problem with the newest udev is that you need a kernel 2.6.15 or newer. And the reason why touch is complaining, is because you forgot to mount proc when you chrooted. If you're outside chroot: mount proc -t proc /mnt/gentoo/proc If you're inside chroot: mount proc -t proc /proc Then you're able to compile a new kernel :) /erik "Ryan Viljoen" <[EMAIL PROTECTED]> writes: > Hey all, > > I recently (yesterday) completed an emerge sync and then emerge world. > I rebooted my PC today and my system failed to come up. It moaned > about udev or such... > > After some inspection, it seems I have an error with touch. I cant > emerge anything, it does not get past unpacking the source. The > following error is the same for all packages: > > Quote: >>>> Unpacking source... >>>> Unpacking udev-089.tar.bz2 to /var/tmp/portage/udev-089/work > touch: setting times of `/var/tmp/portage/udev-089/.unpacked': > Function not implemented > > !!! ERROR: sys-fs/udev-089 failed. > Call stack: > ebuild.sh, line 1526: Called dyn_unpack > ebuild.sh, line 698: Called die > > !!! IO Failure -- Failed 'touch .unpacked' in /var/tmp/portage/udev-089 > !!! If you need support, post the topmost build error, and the call > stack if relevant. > > wiig / # > > > Any idea as to the cause? Solution? > > > -- > Ryan Viljoen Bsc(Eng) (Electrical) > > There are sadistic scientists who hurry to hunt down errors instead of > establishing the truth. >- Marie Curie > > -- > gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] udev blocks systemd etc
On Mon, Mar 25, 2013 at 5:18 PM, Mike Gilbert wrote: > On Mon, Mar 25, 2013 at 4:59 PM, Stefan G. Weichinger wrote: >> >> 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 >> >> > > I feel your pain. That bug report got out of control so I wanted to > put a stop to the comments. > > I am happy to help you work out your blocker issue here, or in a new bug > report. Oh, some suggestions: 1. Make sure your portage tree is up to date. 2. Make sure your use flags for virtual/udev and sys-apps/systemd are synced up. 3. Run equery d sys-fs/udev to see if you have any packages depending on it directly. 4. Add sys-fs/udev and sys-fs/eudev to /etc/portage/package.mask to see if you can get portage to emit a more useful message.
Re: [gentoo-user] Moving from old udev to eudev
On 02/08/13 00:49, Dale wrote: Samuli Suominen wrote: On 01/08/13 19:28, Tanstaafl wrote: Hi all, Ok, rehashing this, but please don't turn it into another udev vs systemd thread. I have an older server that I have been putting off this update, debating on whether to update to the regular udev, or to eudev. I've googled until my fingers are blue, but cannot for the life of me find any explicit instructions for *how* to switch from udev to eudev. The eudev project page is sparse, to say the least. Anyone? First of all, eudev only has IUSE="rule-generator" that is backported from udev-171. It's otherwise same in users point of view with sys-fs/udev, except sys-fs/eudev is constantly out of date and the code forwarding from upstream is not very reliable process. Futhermore sys-fs/udev is not 'old' but it's the new one and will be the default for OpenRC for long as OpenRC is in Portage. I don't want to bash anything or anybody but sys-fs/eudev as-is in the Portage is currently useless and a bit buggy. That's odd. I been using eudev since like the second version that came out and have had zero issues with it. Ask anyone here, if it had a problem, I'd be found it by now. lol Then you haven't been following. It's multiple issues per week, if not even day. And like said, you don't gain anything by using sys-fs/eudev. The package is useless.
Re: [gentoo-user] Moving from old udev to eudev
Tanstaafl wrote: > On 2013-08-02 8:15 AM, Dale wrote: >> Tanstaafl wrote: >>> But what about removing the udev-postmount init script? I guess that >>> is the last question I need answered before jumping down the rabbit >>> hole Sunday... > >> This is what I have for that from rc-update show: >> >> udev-postmount | default > > Yes, that is what I still have (because I haven't upgraded udev yet)... > > I was just making sure that the instructions for upgrading udev (to > remove this script) didn't apply to eudev. > >> If you have something that says different, can you post a link? I'd >> like to see that. I don't recall removing any script but again, I was a >> early switcher. >> >> Please excuse the agenda posts by Samuli. If you chose eudev, like me >> and plenty of others, use eudev. It's your system and you know what you >> need to use. > > No worries... he is why I asked not to use my question to start > another flamewar, although I guess I should have specified udev <> > systemd AND udev <> eudev... > > ;) > > Thanks again, looking forward to getting this behind me. Its been a > long time since I've had zero results when doing an emerge -pvuDN > world after eix-syncing... > > As always, have a sysrescue stick/CD/DVD handy. If nothing else, it warns the evil stuff to stay away. ;-) I usually keep a mini sledge hammer close by but . . . . Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Moving from old udev to eudev
On Mon, 5 Aug 2013 21:10:27 -0400, Walter Dnes wrote:
> > I can't remember what it was now, and it may have been avoidable by
> > making virtual/udev-206 (or whichever version it was that needed a
> > higher udev version than eudev could provide). It's moot now as eudev
> > has been updated and portage is happy again, but it would be a
> > concern if this happened regularly.
>
> I ran into this. Here is what I think happened...
>
> - I specified "sys-fs/eudev-1.2-r1-beta ~amd64" (or something similar)
> in my /etc/portage/package.keywords file
> - I ran "emerge --sync". On that particular day, it removed the beta
> version ebuild, and replaced it with eudev-1.2.ebuild
> - "emerge --changed-use --deep --update @world" could no longer find an
> unmasked version of sys-fs/eudev that satisfied virtual/udev. So it
> fell back to a version of sys-fs/udev
> - My workaround, *UNTIL SUCH TIME AS EUDEV HITS STABLE AMD64*, is...
>in my /etc/portage/package.keywords file.
>
> This specifies to accept the highest ebuild number that is smaller
> than (the "bleeding edge" version).
nothing that complicated, I have nothing in package.{un,}mask for eudev.
Something was pulling in virtual/udev-206, which no eudev releases at the
time could satisfy (except possibly the version but those are masked
by default) so portage needed to uinstall eudev and install udev to fulfil
the dependency.
--
Neil Bothwick
Sisko:"I won't be condescending to you this episode, Dr. Bashir."
signature.asc
Description: PGP signature
Re: [gentoo-user] some of the stuff in /usr that's become a problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2013 10:13 PM, William Hubbs wrote: > On Sun, Sep 29, 2013 at 09:21:01PM -0500, Daniel Campbell wrote: >>> /usr/lib/udev. /usr/lib/systemd. >>> >>> were both placed in /usr despite objections from a number of >>> folks. >>> >>> So claims that udev and systemd are not responsible are not >>> true. > > Udev is installed in / in gentoo. I am a co-maintainer of udev and > that was fixed quite some time back, it is the Gentoo systemd team > that installs their version of udev in /usr. > > Installing udev or eudev, however, doesn't really solve the issue > though, because it is possible to run arbitrary programs from > within udev rules. > > Another unrelated concern is if you install a program in / that > needs to access something in /usr/share, this will be broken by not > having /usr mounted. This means that, for example, the locale logic > of most software can't work without /usr since it accesses files in > /usr/share/locale. > > William > I believe you misquoted. Greg said those things; I was merely quoting him. :) You're right, though; it's a problem that lots of programs have. I guess it's the natural result of modular software that has interdependencies. You basically need *everything* available on boot. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSSPLCAAoJEJUrb08JgYgHFaEH/ietryULwNCbYdoLYFNJXoT1 vjecOzD0nKxY/dN26X5nZfBuuLkN/SARdrk/xqlp7Fw4UKEuP6XwcJWSoP2/o8t7 TxdlbqAAxNGytOpUlqZmJd53c3pivD11PS467Iy4UsRmpH0TbOerqESi9lR+X7bI OR6ghVpOqkBrNjwNtSREOHjApjQ6h451bGHW2rHUUbOlzoOZYiIBCxBxsCYc/fEc jS8LbNioj9BeipRFeIAqr+LPhpPDq7KE3EA/tcOb2WT5ro0yy6MAAdoBJSRKiFmI woSKmEWgFVAa6eGJjTmTRTJjra0L9EWcxHSRDBBNuJTsV1AfMR8stRPD6+FUkaE= =b8AN -END PGP SIGNATURE-
Re: [gentoo-user] Few blockers left
On 03/26/2017 05:34 PM, Neil Bothwick wrote: > On Sat, 25 Mar 2017 16:58:25 -0600, the...@sys-concept.com wrote: > >>> To repeat what I said before, a virtual and the package satisfying it >>> must have matching USE flags. If your flags for virtual/libudev and >>> eudev don't match, portage will try to install the default for >>> libudev, which is udev. That then causes a conflict as you can't have >>> udev and libudev installed at the same time. >> >> Here is the output: >> >> grep -r udev /etc/portage >> /etc/portage/package.use:sys-fs/udev extras >> /etc/portage/package.use:=sys-fs/eudev-1.10-r2 abi_x86_32 >> /etc/portage/package.use:>=virtual/libudev-215-r1 abi_x86_32 >> /etc/portage/package.use:>=sys-fs/udev-225-r1 abi_x86_32 >> /etc/portage/package.use:>=dev-libs/libgudev-230-r1 abi_x86_32 > > There's the problem, you have enabled the abi_x86_32 USE flag for all > versions of udev and the libudev virtual, bit only for one specific > version of eudev, so the only way portage can upgrade virtual/libudev is > to install udev, which conflicts with eudev. Fix package.use to the > entries for libudev and eudev match. Yes, that might have been a problem. I got tired rebuilding the same packages over again and adding with each new version "abi_x86_32" flag to package.use. I just added to make.conf ABI_X86="32 64" After upgrading several 1-year old systems I think best approach is to make a backup of "world" emerge -C world Restore the world from backup and do emerge world -- Thelma
Re: [gentoo-user] Re: udev (viable) alternatives ?
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: > 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)? Or... maybe eudev (or mdev, or both) could or would have to be [re]written so as to be fulfill the 'kdbus userspace' role Lennart mentions above? Being 'not a dev' (or programmer at all), I guess it is entirely possible it isn't as bad as it sounds, but his "Gentoo folks, this is your wake-up call." comment is what really stands out to me, as a gentoo user. I don't care about dbus/kdbus - if it is in the kernel, and under Linus' control, and I need to enable it to use my systems, that is fine with me. What I want is to always have the option - a *stable* option - to not have to install/use systemd if I don't want to.
Re: [gentoo-user] Switch from devfs to udev?
Because no one mentioned it. There is also a Gentoo udev Guide: http://www.gentoo.org/doc/en/udev-guide.xml max -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] no /dev/v4l devices after switching to udev? (possibly)
You're welcome. It may have been getting rid of the tarball and then when something needed it the devices got created. If I remember correctly devfs did that - when you needed it the device was created but I haven't looked into udev. I moved to it when I went from 2.4.x to 2.6.x a while back and it just worked! On Sun, 22 May 2005, Mark Knecht wrote: Brett, Thanks for your help. One way or another it finally started working. I don't know yet whether it will survive a reboot. I'll probably do that test later this evening or tomorrow but at least I'm finally getting v4l devices. I think it was most likely a combination of not using the existing tarball (whatever and whereever that is!) and then running the right drivers. Even after rebooting the dev/v4l devices weren't there, but then when I started running some programs that try to use them they suddenly showed up. All I hope for now is that they don't suddenly disappear! Anyway, thanks for the ideas. cheers, Mark On 5/22/05, Brett I. Holcomb <[EMAIL PROTECTED]> wrote: Try the tarball no. It may be using the old devfs tarball. On Sun, 22 May 2005, Mark Knecht wrote: On 5/22/05, Brett I. Holcomb <[EMAIL PROTECTED]> wrote: Okay. That's not it. Here's what I have in /etc/conf.d/rc that pertains to udev/devfs. I assume you have RC_DEVFSD_STARTUP set to no but what about the tarball? # Set to "yes" if you want to save /dev to a tarball on shutdown # and restore it on startup. This is useful if you have a lot of # custom device nodes that udev do not handle/know about. # (ONLY used by UDEV enabled systems!) RC_DEVICE_TARBALL="no" # Set to "yes" if you want devfsd to start upon bootup. This is # the default for Gentoo. # Set to "no" only if you understand the full implications. A # number of files may need to be altered (i.e. /etc/inittab, # /etc/fstab, etc.). # Also note that it does _NOT_ start for UDEV enabled systems, # even if RC_DEVFSD_STARTUP="yes" ... RC_DEVFSD_STARTUP="no" Brett, My /etc/conf.d/rc file looks a bit different but good enough I hope. I do not have a variable called RC_DEVFSD_STARTUP. None the less I've rebuilt the kernel yet again (5th time today?) completely removing devfs and even with these settings I am not getting /dev/v4l devices: # Use this variable to control the /dev management behavior. # auto - let the scripts figure out what's best at boot # devfs - use devfs (requires sys-fs/devfsd) # udev - use udev (requires sys-fs/udev) # static - let the user manage /dev #RC_DEVICES="auto" RC_DEVICES="udev" # UDEV OPTION: # Set to "yes" if you want to save /dev to a tarball on shutdown # and restore it on startup. This is useful if you have a lot of # custom device nodes that udev does not handle/know about. RC_DEVICE_TARBALL="yes" udev is starting and the messages at boot time look OK to me. I'm thinking I must somehow be barking up the wrong tree. I do not understand the udev language but it would seem that it cannot be that difficult. Why are there no v4l devices? # v4l devices KERNEL="video[0-9]*", NAME="v4l/video%n", SYMLINK="video%n", GROUP="video" KERNEL="radio[0-9]*", NAME="v4l/radio%n", GROUP="video" KERNEL="vbi[0-9]*", NAME="v4l/vbi%n", SYMLINK="vbi%n", GROUP="video" KERNEL="vtx[0-9]*", NAME="v4l/vtx%n", GROUP="video" The rules do not seem to be the problem. They are standard in the rules file. Therefore there must be something not happening to cause them to get invoked, or possibly something that did happen taht caused them to be invalid. Problem is I don't have a clude what makes this happen? Why do any of these get involed in the first place? Is there some caracter device I need to create to make them happen the first time? I haven't found evidence of that in the wiki's but maybe I've missed it. Thanks much, Desperately Mark -- Brett I. Holcomb [EMAIL PROTECTED] Registered Linux User #188143 Remove R777 to email -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] activating swap by udev event
On Thu, 1 Jul 2010 15:49:08 +0200, SpaceCake wrote: > I would like to increase the speed of my machine by putting some swap > on a fast pendrive. It is working manually by starting a script > > swapon -s > swapon -p -1 /dev/sdb1 > swapoff /dev/sda6 > swapon -p -2 /dev/sda6 > swapon -s > > but, I would like to make it automatic by creating an udev rule, so > when I plug in that device the swap space is automatically activated > and the priority is changed. Create the udev rule in the usual way and add RUN="/path/to/your/script" You must use a full path when running a program from a udev rule and the program should exit quickly as udev blocks while it is running. -- Neil Bothwick What colour is a chameleon on a mirror? signature.asc Description: PGP signature
[gentoo-user] How can I make udev play nicely with my palm pilot
I can sync my palm fine using jpilot by hitting sync on the palm, then sync on jpilot. udev creates the nodes (I have set them as /dev/tts/USB0 and /dev/tts/USB1) when the palm sync is run, and deletes them when finished. The problem is that most software (pilot-link, gnome-pilot, ...) seems to expect the nodes to be present all the time - and udev keeps deleting them! Even if I manually create the nodes udev will politely delete them after a sync - causing gnome-pilot to never sync again (until killed/restarted) Manually creating the nodes and commenting out the rule in 50-udev.rules didnt work either (the nodes stayed, just didnt work - no sync). How can I make udev play nicely? BillK -- William Kenworthy <[EMAIL PROTECTED]> Home! -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Who mount sysfs?
On Tuesday 24 March 2009 10:34:40 Mick wrote: > 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. it's done by udev, so there is no separate init script for sysfs -- alan dot mckinnon at gmail dot com
[gentoo-user] Huh? udev-182 package collision with own files
Hi there! emerge --update --newuse @world wants to re-install sys-fs/udev-182 due to changed USE flags (static-libs), but this package just failed to compile because of file collisions. * package sys-fs/udev-182 NOT merged * * Detected file collision(s): * * /usr/share/gtk-doc/html/libudev * /usr/share/gtk-doc/html/gudev * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * 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. What's this, a portage bug? I'm running 2.2.0_alpha94. Yes, I know how to turn this collision check off, but I wonder what's going on and if I should file a portage bug report. Wonko
[gentoo-user] HAL or UDEV...
Hello, I just have one question, reciently I read in a forum that HAL might be deprecated on Gentoo, so, I started using UDEV: USE=" -hal udev" But, then I have this problem, updating xorg-server won't work, every new version of xorg-server just give me a blank screen, so I thought it might be something with HAL or UDEV. I would like to know if someone could tell me if I should be using HAL or UDEV? I want to know more, differences, etc. Anyway, my system is: ~AMD64 My current xorg-server version: x11-base/xorg-server-1.9.5 I have masked the following xorg-server versions, because they don't work for me: =x11-base/xorg-server-1.10.0.901 =x11-base/xorg-server-1.10.0.902 =x11-base/xorg-server-1.10.1 Thank you for your help and answer. Regards, -- Carlos Sura.-
Re: [gentoo-user] udev + /usr
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! allan
[gentoo-user] udev-186 error messages after upgrade
Hi,
After upgrading to udev-186 I saw some errors when the service was restarted:
Jul 9 14:54:57 virtual udevd[30356]: unknown key 'RUN{builtin}' in
/lib/udev/rules.d/80-drivers.rules:10
Jul 9 14:54:57 virtual udevd[30356]: invalid rule
'/lib/udev/rules.d/80-drivers.rules:10'
Jul 9 14:54:57 virtual udevd[30356]: failed to create queue file: No
such file or directory
Jul 9 14:54:57 virtual udevd[30356]: failed to create queue file: No
such file or directory
I haven't rebooted it yet. Do you think it is safe to do so? I can't
find any clues about these errors. The rule mentioned in the first
error is unchanged from that contained in the systemd tarball. In
fact, they're all vanilla rules, I have no custom rules on this box,
and no /etc/udev/rules.d/ files at all.
Thanks,
Paul
[gentoo-user] Re: udev-197 moves from /usr/lib to /lib
On 11/01/13 19:51, Stefan G. Weichinger wrote: Am 11.01.2013 16:14, schrieb Nikos Chantziaras: Running this command (all in one line): emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do echo "=$p"; done) should re-emerge all packages that still have files there. After that, /usr/lib/udev should no longer exist. If it still does, then there are files in it that don't belong to any package. Check them manually and delete them as needed or move them over. Then delete /usr/lib/udev. on my thinkpad I had app-laptop/laptop-mode-tools which had its 99-mode-laptop-mode.rules in /usr/lib/udev/rules.d even after re-emerging. moved that file manually ... Should that be filed as a bug? Most probably yes.
