Re: [gentoo-user] suspend/hibernate and genkernel.
On Wed, 2012-03-14 at 11:49 +0800, William Kenworthy wrote: On Wed, 2012-03-14 at 11:13 +0800, William Kenworthy wrote: I am trying to get my system(s) ready for the new (read crappy) way mandated by udev and am having some issues. I usually manually compile my kernels, use tuxonice and dont use an initrd/initramfs. As ToI is not available for the latest kernels, I updated openrc and installed genkernel but then found I couldnt use in-kernel suspend to disk - googling implies that genkernel doesnt support suspend/hibernate but there are various kludges to get it to work. So whats the least invasive, but workable kludge? hibernate, pmhibernate, swsuspend, uswsuspend, ... Are there any (up to date) docs? BillK According to the docs I have found you need to patch genkernel to run /sbin/resume - it was a longstanding argument between two now retired devs with the result that genkernel wont (ever) support hibernation. I dont know from reading the bugs if it was ever fixed now the dev who wouldnt has retired, or is genkernel is still broken. Also, I have no /sbin/resume on any of my systems (some are years old and have been successfully running ToI for most of that time) - so how can the initramfs actually start resumimg? Though I have a more immediate problem - hangs on hibernation and no log messages. BillK Well, patching genkernel worked so its still broken as regards suspend/resume - so I can now suspend/resume still with some errors. Next problem is that there are error messages implying /usr might not be mounted by the initramfs (some /usr files not found) ... is there anything else that needs doing? Once the system is up /usr and all other directories are correctly mounted (most are on LVM). Is there a way to get a detailed log of what the initrd is doing/has done? BillK
Re: [gentoo-user] suspend/hibernate and genkernel.
On Wed, Mar 14, 2012 at 12:20 AM, William Kenworthy bi...@iinet.net.au wrote: On Wed, 2012-03-14 at 11:49 +0800, William Kenworthy wrote: On Wed, 2012-03-14 at 11:13 +0800, William Kenworthy wrote: I am trying to get my system(s) ready for the new (read crappy) way mandated by udev and am having some issues. I usually manually compile my kernels, use tuxonice and dont use an initrd/initramfs. As ToI is not available for the latest kernels, I updated openrc and installed genkernel but then found I couldnt use in-kernel suspend to disk - googling implies that genkernel doesnt support suspend/hibernate but there are various kludges to get it to work. So whats the least invasive, but workable kludge? hibernate, pmhibernate, swsuspend, uswsuspend, ... Are there any (up to date) docs? BillK According to the docs I have found you need to patch genkernel to run /sbin/resume - it was a longstanding argument between two now retired devs with the result that genkernel wont (ever) support hibernation. I dont know from reading the bugs if it was ever fixed now the dev who wouldnt has retired, or is genkernel is still broken. Also, I have no /sbin/resume on any of my systems (some are years old and have been successfully running ToI for most of that time) - so how can the initramfs actually start resumimg? Though I have a more immediate problem - hangs on hibernation and no log messages. BillK Well, patching genkernel worked so its still broken as regards suspend/resume - so I can now suspend/resume still with some errors. Next problem is that there are error messages implying /usr might not be mounted by the initramfs (some /usr files not found) ... is there anything else that needs doing? Once the system is up /usr and all other directories are correctly mounted (most are on LVM). Did you run genkernel with --lvm? Sorry, I don't use genkernel, but dracut has several options to include arbitrary files on the initramfs. I'm sure genkernel has something similar; why don't you try to add the /usr missing files in the initramfs? Good luck. Is there a way to get a detailed log of what the initrd is doing/has done? BillK -- 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] virt-manager-0.9.1 broken?
Am 13.03.2012 23:17, schrieb Alan McKinnon: On Tue, 13 Mar 2012 23:13:33 +0100 Stefan G. Weichinger li...@xunil.at wrote: Anyone else seeing this? No bugreport yet, and I rebuilt and revdeped Stefan I'm thinking you hit send before typing up the bit where you say what the issue is you are having. Oh, yes, sorry! see here: $ virt-manager Traceback (most recent call last): File /usr/share/virt-manager/virt-manager.py, line 393, in module _show_startup_error(str(run_e), .join(traceback.format_exc())) File /usr/share/virt-manager/virt-manager.py, line 63, in _show_startup_error from virtManager.error import vmmErrorDialog File /usr/share/virt-manager/virtManager/error.py, line 25, in module from virtManager.baseclass import vmmGObject File /usr/share/virt-manager/virtManager/baseclass.py, line 28, in module running_config, gobject, GObject, gtk = virtManager.guidiff.get_imports() File /usr/share/virt-manager/virtManager/guidiff.py, line 46, in get_imports import virtManager.util File /usr/share/virt-manager/virtManager/util.py, line 28, in module import virtinst File /usr/lib64/python2.7/site-packages/virtinst/__init__.py, line 37, in module from Guest import Guest, XenGuest File /usr/lib64/python2.7/site-packages/virtinst/Guest.py, line 27, in module import urlgrabber.progress as progress File /usr/lib64/python2.7/site-packages/urlgrabber/__init__.py, line 54, in module from grabber import urlgrab, urlopen, urlread File /usr/lib64/python2.7/site-packages/urlgrabber/grabber.py, line 427, in module import pycurl ImportError: /usr/lib64/python2.7/site-packages/pycurl.so: undefined symbol: gcry_control
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
The 13/03/12, Bruce Hill, Jr. wrote: 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! This is not FUD. And more importantly, what Canek says is certainly true. In the past, the kernel was handling devices alone. Since udev, the possibility for userland programs to hook themselves in this process became very easy. Some of them have use this feature very early but we can reasonably think the work is not totally achieved. Also, developers write code given the context at the time it is written. But the changing context doesn't necessarily imply other programs to be rewritten at the same time. Once the context changed, we can reasonably think that currently working code not going to be hacked soon will be rewritten in the longer run to take advantage of this udev facility. Pointing to this fact is not FUD. I'd say it is nice analysis which could even help the current udev - mdev effort by providing a different picture of the landscape. -- Nicolas Sebrecht
Re: [gentoo-user] suspend/hibernate and genkernel.
On Wed, 2012-03-14 at 00:26 -0600, Canek Peláez Valdés wrote: On Wed, Mar 14, 2012 at 12:20 AM, William Kenworthy bi...@iinet.net.au wrote: On Wed, 2012-03-14 at 11:49 +0800, William Kenworthy wrote: On Wed, 2012-03-14 at 11:13 +0800, William Kenworthy wrote: I am trying to get my system(s) ready for the new (read crappy) way mandated by udev and am having some issues. ... BillK Well, patching genkernel worked so its still broken as regards suspend/resume - so I can now suspend/resume still with some errors. Next problem is that there are error messages implying /usr might not be mounted by the initramfs (some /usr files not found) ... is there anything else that needs doing? Once the system is up /usr and all other directories are correctly mounted (most are on LVM). Did you run genkernel with --lvm? Sorry, I don't use genkernel, but dracut has several options to include arbitrary files on the initramfs. I'm sure genkernel has something similar; why don't you try to add the /usr missing files in the initramfs? Good luck. Is there a way to get a detailed log of what the initrd is doing/has done? BillK Good call! - was missing LVM. I thought the genkernel config file had LVM as a default ... but it didnt so no error messages now. BillK
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, 13 Mar 2012 23:43:54 +, Alan Mackenzie wrote: udev is not a device node system, it is a device manager. Requiring drivers to handle it gets us into the same mess as Windows, where each driver has to implement the same functionality itself. If a new modem is released with a different USB ID, but using the same driver, your way would require a new kernel, the current approach requires one line to be added to a config file. Right! Now this is beginning to look like a beginning of an answer to my lack of understanding. ;-) This config file - is this the udev rules? Or am I getting mixed up with something else? Yes. They are simple rules under /etc/udev/rules.d that determine what to do when a device appears on the system, from giving it a specific name or setting permissions to running a program. It is the latter that causes problems when /usr is not mounted. How so? It's central to the whole when do we need /usr? debate. I meant we'd already had a wide ranging discussion about early /usr. Yes we didi, but it's not going to go away any time soon :( You could use this to argue that /usr should be mounted before udev is started, but you could just as well use it to argue that udev should not be trying to run such rules at the boot runlevel. Or that udev shouldn't have rules. I still don't understand the basic concept driving this thing. My HDDs don't need rules - they just need a mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate drivers built into my kernel. I don't need it so no one needs it. It sounds like what you need is mdev, but many people want or need more from a device manager. There are many more and varied devices than simple hard disks. That's not fair. I'm convinced _I_ don't need more than mdev; I'm still trying to get a handle on why other devices need more. OK, here's another example. I have a box here with two USBRS232 adaptors, connected to completely different devices. The programs connecting to those devices need to be told which interface to communicate with, but you can't know in advance which will grab ttyUSB0 and which ttyUSB1. udev rules mean I can give them persistent names independent of the kernel assignments. One of the devices is a UPS, imagine the problems if both were UPSes and the software didn't know which was which - power fails to one and the software sends shutdown commands to the computers that still have power and let the others fail when the battery goes flat. What you don't see is why *you* need it, and that's fair enough. Just consider that it does things that others need, even if you don't. I'm not trying to be combative. In fact, I'm trying not to be combative. I'm just trying to get some sort of grasp on what it is I don't yet see. I want to understand what udev offers that mdev can't, and I'm getting very frustrated about not being able to find the right questions to ask. I wasn't suggesting you were being combative, hence the fair enough. You are seeing things from your perspective, as we all do (including the udev devs who made this decision) and it sounds like you have no need for any of this. Or maybe you do and don't know you are using it. Many programs install udev rulesets - for example sane-backends installs a 1500+ line (including comments) rule file, libgphoto's is not much smaller. all so you can connect a camera or scanner and not have to worry about how it is recognised or configured. But I still think the requirement for /usr to be mounted is a lazy, if understandable, solution to the way udev's operations are implemented. After all, the vast majority of PC Linux installations out there already use an initramfs. They do, and I understand that one - it is the necessity to have a one-size-fits-all kernel in a binary distribution. As gentooers, we don't suffer that constraint, therefore we don't (and shouldn't) need an initramfs, unless we want one. On the other hand, Gentoo's policy has been to follow upstream as closely as is practical, so if udev upstream wants /usr mounted early, that's what we do - or do without udev. Both are reasonable choices and Walt should be commended for his work on this, both on making it work and raising awareness of the alternative. I haven't yet decided which way I'll go, I'll probably give mdev a try on a non-desktop box, but it's good to have a choice and may the best option win. How do I set my laser printer to stun? How about a picture of Marilyn Monroe? ROFL. -- Neil Bothwick Will we ever get out of this airport? asked Tom interminably. signature.asc Description: PGP signature
Re: [gentoo-user] Very OT - Displaylink adapter and setting up X
V Mon, 12 Mar 2012 17:24:47 -0500 Michael Sullivan msulli1...@gmail.com napsáno: I feel really stupid asking this, but I want to use an HDMI component to output one of my PCs to the TV set. I've followed all of the wiki entry at http://wiki.gentoo.org/wiki/DisplayLink, but there's something else I need to know. I get the green screen on the TV that it mentions when the kernel module is being loaded correctly. The problem is that I use gdm in /etc/conf.d/xdm DISPLAYMANAGER variable to start X, and I don't know where the actual gdm configuration lives so I can tell it to use ~/.xinitrc2 from the wiki. My google searching hasn't been going well. Can anybody give me any hints as to how to make progress on this problem? Hi Michael, it depends on how you would like to use the external card. Please specify your scenario. Anyway, try to look in /etc/gdm, /etc/init.d/xdm, /etc/X11 (there can be specified which server start in file xdm/Xservers) I have DL adapter connected to my docking station and a simple script to activate the second xserver on docking and deactivate that when undocking. I simply run here second desktop using x2x. I just use that primary for web browser, so I dont need xinerama. You can also use DL with your primary card and xinerama. But it needs specific xorg.conf and needs to be connected when xserver starting. So nothing suitable for notebook and hotplug. Robert.
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6
On Tue, March 13, 2012 9:45 pm, Walter Dnes wrote: I've also found one situation where I need to take one extra step to run without udev. I have a laptop with a Radeon GPU that requires a binary blob for the video driver. emerging radeon-ucode downloads a whole slew of binary blobs, to support umpteen different models. If I leave all the binary blobs in the library directory, the kernwl needs udev to figure out which one of the many binary blobs to load. If I remove all the other binary blobs, and leave only the correct one in the library directory, it loads automatically. Wouldn't a good solution be to have the ebuild modified to only install those binary blobs you actually need? Eg. similar to how apache or sane modules are configured? -- Joost
Re: [gentoo-user] suspend/hibernate and genkernel.
On 03/14/2012 04:49 AM, William Kenworthy wrote: According to the docs I have found you need to patch genkernel to run /sbin/resume - it was a longstanding argument between two now retired devs with the result that genkernel wont (ever) support hibernation. I dont know from reading the bugs if it was ever fixed now the dev who wouldnt has retired, or is genkernel is still broken. I'd be interested to hear more details. Can you share links to your sources with me? Thanks, Sebastian
Re: [gentoo-user] Update of cryptsetup 1.4.1 fails
Sebastian Pipping sp...@gentoo.org schrieb am [Di, 13.03.2012 20:32]: Please report this as a bug on https://bugs.gentoo.org/ . You could give libgcrypt 1.5.0-r2 a try. Please add to the bug report, if the problem persists with libgcrypt 1.5.0-r2 or not. Thanks! I solved the problem with the help of a gentoo developper. If anyone is interested, see here: https://bugs.gentoo.org/show_bug.cgi?id=408133 Greetings, Uwe -- Reality is bad enough, why should I tell the truth? -- Patrick Sky pgpYEdQM3VSk0.pgp Description: PGP signature
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
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 Can you run a test for me? What happens when you... 1) insert the line sys-fs/udev into /etc/portage/package.mask 2) execute emerge -pv system 3) execute emerge -pv world 4) Remember to remove the sys-fs/udev line from package.maskG I expect that you should get an error message about not being able to emerge lvm2 due to udev being masked. This is something I intend to add to the instructions, so people can check ahead of time whether their particular setup is able to run without udev. OK. I took my meds a bit ago so I hope I got this right. I used copy and paste. lol I added udev to the mask file and here is the results. It's a doozy. root@fireball / # emerge -pv system These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] app-arch/xz-utils-5.0.3 USE=nls threads -static-libs 0 kB [ebuild R] sys-devel/gnuconfig-20110814 0 kB [ebuild R] sys-devel/patch-2.6.1 USE=-static -test 0 kB [ebuild R] app-arch/bzip2-1.0.6-r3 USE=-static -static-libs 0 kB [ebuild R] sys-apps/which-2.20 0 kB [ebuild R] sys-apps/texinfo-4.13 USE=nls -static 0 kB [ebuild R] virtual/os-headers-0 0 kB [ebuild R] virtual/man-0 0 kB [ebuild R] sys-apps/sed-4.2.1 USE=nls -acl (-selinux) -static 0 kB [ebuild R] sys-apps/less-444 USE=unicode 0 kB [ebuild R] sys-apps/grep-2.9 USE=nls pcre 0 kB [ebuild R] sys-apps/kbd-1.15.3 USE=nls 0 kB [ebuild R] sys-apps/busybox-1.19.3-r1 USE=ipv6 pam -make-symlinks -mdev -savedconfig (-selinux) -static 0 kB [ebuild R] app-shells/bash-4.1_p9 USE=net nls -afs -bashlogger -examples -mem-scramble -plugins -vanilla 0 kB [ebuild R] sys-apps/net-tools-1.60_p20110409135728 USE=nls -static 0 kB [ebuild R] virtual/modutils-0 0 kB [ebuild R] sys-apps/gawk-3.1.8 USE=nls 0 kB [ebuild R] sys-process/psmisc-22.14 USE=X ipv6 nls (-selinux) 0 kB [ebuild R] sys-apps/file-5.09 USE=zlib -python -static-libs 0 kB [ebuild R] app-arch/tar-1.26 USE=nls -static 0 kB [ebuild R] virtual/package-manager-0 0 kB [ebuild R] net-misc/rsync-3.0.9 USE=iconv ipv6 -acl -static -xattr 0 kB [ebuild R] virtual/editor-0 0 kB [ebuild R] sys-apps/coreutils-8.14 USE=nls unicode -acl -caps -gmp (-selinux) -static -vanilla -xattr 0 kB [ebuild R] sys-devel/make-3.82-r1 USE=nls -static 0 kB [ebuild R] sys-process/procps-3.2.8_p11 USE=unicode 0 kB [ebuild R] virtual/ssh-0 USE=-minimal 0 kB [ebuild R] virtual/dev-manager-0 0 kB [ebuild R] sys-apps/findutils-4.4.2-r1 USE=nls (-selinux) -static 0 kB [ebuild R] app-arch/gzip-1.4 USE=nls -pic -static 0 kB [ebuild R] net-misc/wget-1.12-r3 USE=ipv6 nls ssl -debug -idn -ntlm -static 0 kB [ebuild R] sys-apps/diffutils-3.0 USE=nls -static 0 kB [ebuild R] sys-apps/baselayout-2.0.3 USE=-build 0 kB [ebuild R] virtual/libc-0 0 kB [ebuild R] sys-apps/util-linux-2.20.1-r1 USE=cramfs loop-aes ncurses nls unicode -crypt -ddate -old-linux -perl (-selinux) -slang -static-libs (-uclibc) 0 kB [ebuild R] sys-devel/binutils-2.21.1-r1 USE=nls zlib -multislot -multitarget -static-libs -test -vanilla 0 kB [ebuild R] sys-apps/man-pages-3.35 USE=nls LINGUAS=-da -de -fr -it -ja -nl -pl -ro -ru -zh_CN 0 kB [ebuild R] net-misc/iputils-20101006-r2 USE=ipv6 ssl -SECURITY_HAZARD -doc -idn -static 0 kB [ebuild R] virtual/pager-0 0 kB [ebuild R] sys-apps/shadow-4.1.4.3 USE=cracklib nls pam -audit (-selinux) -skey 0 kB [ebuild R] sys-fs/e2fsprogs-1.42 USE=nls -static-libs 0 kB [ebuild R] sys-devel/gcc-4.5.3-r2 USE=cxx fortran gtk mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -graphite (-hardened) (-libssp) -lto -multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla 0 kB Total: 42 packages (42 reinstalls), Size of downloads: 0 kB !!! The following installed packages are masked: - sys-fs/udev-171-r5::gentoo (masked by: package.mask) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. root@fireball / # emerge -pv world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] app-arch/xz-utils-5.0.3 USE=nls threads -static-libs 0 kB [ebuild R] sys-devel/gnuconfig-20110814 0 kB [ebuild R] app-arch/bzip2-1.0.6-r3 USE=-static -static-libs 0 kB [ebuild R]
Re: [gentoo-user] suspend/hibernate and genkernel.
On Wed, 2012-03-14 at 14:27 +0100, Sebastian Pipping wrote: On 03/14/2012 04:49 AM, William Kenworthy wrote: According to the docs I have found you need to patch genkernel to run /sbin/resume - it was a longstanding argument between two now retired devs with the result that genkernel wont (ever) support hibernation. I dont know from reading the bugs if it was ever fixed now the dev who wouldnt has retired, or is genkernel is still broken. I'd be interested to hear more details. Can you share links to your sources with me? Thanks, Sebastian https://bugs.gentoo.org/show_bug.cgi?id=156445 - particularly the comment dated 2007-09-14 20:58:00 UTC. and google gets others as well. There are a number of guides describing the patching and related problems ... note that the above is 2007 ... and it still doesnt work. Basicly the question is does genkernel support some of the more complex setups, but as having suspend/resume on a laptop is almost mandatory its something genkernel should support out of the box. For my uses, if it has to be patched to add such basic support ... its broke. BillK
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
Hi, Walter. On Tue, Mar 13, 2012 at 04:09:46AM -0400, 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 I can mount and use my lvm2 partitions under mdev. As I said, I don't yet know whether lvm2's full functionality is available. I suspect there'll be quite a few packages which list udev as a dependency, yet work well enough under mdev. Can you run a test for me? What happens when you... 1) insert the line sys-fs/udev into /etc/portage/package.mask 2) execute emerge -pv system 3) execute emerge -pv world 4) Remember to remove the sys-fs/udev line from package.maskG I expect that you should get an error message about not being able to emerge lvm2 due to udev being masked. This is something I intend to add to the instructions, so people can check ahead of time whether their particular setup is able to run without udev. The solution to this, ugly though it might be, is to leave udev in the system so as to allow these other packages to be merged. -- Walter Dnes waltd...@waltdnes.org -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mar 14, 2012 9:45 PM, Alan Mackenzie a...@muc.de wrote: Hi, Walter. On Tue, Mar 13, 2012 at 04:09:46AM -0400, 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 I can mount and use my lvm2 partitions under mdev. As I said, I don't yet know whether lvm2's full functionality is available. I suspect there'll be quite a few packages which list udev as a dependency, yet work well enough under mdev. Can you run a test for me? What happens when you... 1) insert the line sys-fs/udev into /etc/portage/package.mask 2) execute emerge -pv system 3) execute emerge -pv world 4) Remember to remove the sys-fs/udev line from package.maskG I expect that you should get an error message about not being able to emerge lvm2 due to udev being masked. This is something I intend to add to the instructions, so people can check ahead of time whether their particular setup is able to run without udev. The solution to this, ugly though it might be, is to leave udev in the system so as to allow these other packages to be merged. ... or, put sys-fs/udev in package.provided Of course, if a package *actually* needs udev, that's a sure-fire recipe for catastrophe (for that package). Rgds,
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
Hello, Canek On Tue, Mar 13, 2012 at 06:07:32PM -0600, Canek Peláez Valdés wrote: On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie a...@muc.de wrote: The new hardware will just work if there are the correct drivers built in. That's as true of udev as it is of mdev as it is of the old static /dev with mknod. No, it is not. You are letting out the sine qua non of the matter: the device has to be built, *and the /dev file should exists*. I hope you are not suggesting that we put *ALL* the possible files under /dev, because that was the idea before devfs, and it doesn't work *IN GENERAL*. Previously you made appropriate /dev entries with mknod, giving the device major and minor numbers as parameters. This appeared to work in general - I'm not aware of any device it didn't work for. 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. That happened under the old static /dev system. What was that /dev system, if not a database matching /dev names to device numbers? I'm not sure what you mean by same device and same device name. 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. Early in boot time, you only need things like disk drives, graphic cards and keyboards. Anything else can be postponed till late boot 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. It may be a complicated problem in general, but many people do not need that generality. I suspect the vast majority don't need it. Neither the typical desktop, the typical server, nor typical embedded devices like routers. I have a really time understanding why you don't see the complexity on the problem. I explained above: it is a complicated problem (when dealing with the general case), and therefore the (general) solution is bound to be also complicated. I've had a hard time understanding, because up till now, nobody's described the problem in detail - there's only been hand-waving. You want it simple? Tha'ts fine, it is possible. It's just that it will not solve the general problem, just a very specific subset of it. That subset used by the vast majority of Linux users. And yes, I do want it simple, because elegant simplicity is the best way, IMAO. You, on the other hand, seem to love complicated solutions because they are the way forward. We'll have to agree to disagree on this one. Just as mdev is doing; Walt just posted an email explaining that if you use GNOME, KDE, XFCE, or LVM2, mdev is not for you. Walter is, I believe, mistaken here. I can mount and use my LVM2 partitions. Gnome looks like it comes up OK, but that could be moot, since right now I haven't got keyboard/mouse drivers under the X server. I will not be surprised if in the future the list of programs not for mdev only grows. There's a difference between needed by portage and doesn't work under mdev. As I say, it will all be moot if the evdev driver won't work under mdev. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On 2012-03-13 8:07 PM, Canek Peláez Valdés can...@gmail.com wrote: You want it simple? Tha'ts fine, it is possible. It's just that it will not solve the general problem, just a very specific subset of it. Just as mdev is doing; Walt just posted an email explaining that if you use GNOME, KDE, XFCE, or LVM2, mdev is not for you. Very interesting thread guys, and thanks for keeping it relatively civil despite the passion behind the objections being raised... I just wanted to point out one thing (and ask a question about it) to anyone who argues that servers don't need this - if LVM2 really does eliminate the possibility of using mdev for fundamental reasons (as opposed to arbitrary decisions), that rules out a *lot* of server installations. So, that is my question... what is it about LVM2 that *requires* udev? Or asked another way - Why is LVM2 incapable od using mdev?
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 11:20 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2012-03-13 8:07 PM, Canek Peláez Valdés can...@gmail.com wrote: You want it simple? Tha'ts fine, it is possible. It's just that it will not solve the general problem, just a very specific subset of it. Just as mdev is doing; Walt just posted an email explaining that if you use GNOME, KDE, XFCE, or LVM2, mdev is not for you. Very interesting thread guys, and thanks for keeping it relatively civil despite the passion behind the objections being raised... I just wanted to point out one thing (and ask a question about it) to anyone who argues that servers don't need this - if LVM2 really does eliminate the possibility of using mdev for fundamental reasons (as opposed to arbitrary decisions), that rules out a *lot* of server installations. So, that is my question... what is it about LVM2 that *requires* udev? Or asked another way - Why is LVM2 incapable od using mdev? The presumption is that lvm's dependent binaries would be found somewhere under a mount point other than / (such as /usr), which gives you a chicken-and-egg problem if mounting that mount point requires lvm. -- :wq
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 14, 2012 10:30 PM, Michael Mol mike...@gmail.com wrote:
On Wed, Mar 14, 2012 at 11:20 AM, Tanstaafl tansta...@libertytrek.org
wrote:
On 2012-03-13 8:07 PM, Canek Peláez Valdés can...@gmail.com wrote:
You want it simple? Tha'ts fine, it is possible. It's just that it
will not solve the general problem, just a very specific subset of it.
Just as mdev is doing; Walt just posted an email explaining that if
you use GNOME, KDE, XFCE, or LVM2, mdev is not for you.
Very interesting thread guys, and thanks for keeping it relatively civil
despite the passion behind the objections being raised...
I just wanted to point out one thing (and ask a question about it) to
anyone
who argues that servers don't need this - if LVM2 really does eliminate
the
possibility of using mdev for fundamental reasons (as opposed to
arbitrary
decisions), that rules out a *lot* of server installations.
So, that is my question... what is it about LVM2 that *requires* udev?
Or asked another way -
Why is LVM2 incapable od using mdev?
Alan has explained that LVM2 actually is able to run under mdev, and he's
investigating if there's any LVM2 feature that is not available.
So far, there's none, and I'm strongly suspicious that it's a case of
missing dev symlinks that prevented LVM2 to work; something later on the
default runlevel then created the proper dev entries that allow LVM2 to
work.
If that is the case -- which I strongly suspect -- then one can use mdev's
built-in ability to rename/move a device + create a symlink [1]
[1]
https://svn.mcs.anl.gov/repos/ZeptoOS/trunk/BGP/packages/busybox/src/docs/mdev.txt
The presumption is that lvm's dependent binaries would be found
somewhere under a mount point other than / (such as /usr), which gives
you a chicken-and-egg problem if mounting that mount point requires
lvm.
Uh... mounting filesystems is not the purview of {u,m}dev...
Rgds,
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 14, 2012 10:20 PM, Alan Mackenzie a...@muc.de wrote: 8 snippage Walter is, I believe, mistaken here. I can mount and use my LVM2 partitions. Gnome looks like it comes up OK, but that could be moot, since right now I haven't got keyboard/mouse drivers under the X server. This post here: http://lists.busybox.net/pipermail/busybox/2011-September/076662.html seems to indicate that Xorg communicates with udev (something mdev can't do, because that would increase the complexity of mdev by several orders of magnitude). BUT, in the same message, it is stated that Xorg *can* be compiled to *not* try to communicate with udev. I suspect a similar situation with Gnome. I will not be surprised if in the future the list of programs not for mdev only grows. There's a difference between needed by portage and doesn't work under mdev. As I say, it will all be moot if the evdev driver won't work under mdev. Do packages *actually* need udev's (over)features (read: bloat), or is it just the maintainers depend-ing on sys-fs/udev instead of virtual/device-manager ? For lots of packages claiming they depend on udev, I suspect it's the latter situation. Rgds,
RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
From: Alan McKinnon [mailto:alan.mckin...@gmail.com] Sent: Tuesday, March 13, 2012 3:14 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts. On Tue, 13 Mar 2012 11:54:58 +0700 Pandu Poluan pa...@poluan.info wrote: The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. I quite often read about this, and after some thinking, I have to ask: why? I've also thought about this and I also want to ask why? To be honest, I was simply taking for granted that all of the other people on this list who made a huge fuss about this were not lying. I, personally, have never had a use or need for a separate /usr; I know how big (approximately) /usr is going to get and I give it that much space. I guess I'm fortunate not to have ever managed a server where the hard drives were so tiny as to make that impractical. This whole udev/initrd/mdev/etc problem, for me, has been little more than an entertaining diversion, since I've been using a supported setup from the start. However, I'm confident that there are legitimate reasons why some sysadmins use certain configurations which require / and /usr to be different partitions; I'm less confident that initrd is not the real solution to their problem but that's not really my call to make. I'm *very* confident that a dismissal of this issue as the ego if one or two guys who happen to write udev is a blatant oversimplification that does not do justice to the complexities involved in making modern hardware work. --Mike
RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mar 14, 2012 11:19 PM, Mike Edenfield kut...@kutulu.org wrote: From: Alan McKinnon [mailto:alan.mckin...@gmail.com] Sent: Tuesday, March 13, 2012 3:14 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts. On Tue, 13 Mar 2012 11:54:58 +0700 Pandu Poluan pa...@poluan.info wrote: The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. I quite often read about this, and after some thinking, I have to ask: why? I've also thought about this and I also want to ask why? To be honest, I was simply taking for granted that all of the other people on this list who made a huge fuss about this were not lying. I, personally, have never had a use or need for a separate /usr; I know how big (approximately) /usr is going to get and I give it that much space. I guess I'm fortunate not to have ever managed a server where the hard drives were so tiny as to make that impractical. This whole udev/initrd/mdev/etc problem, for me, has been little more than an entertaining diversion, since I've been using a supported setup from the start. However, I'm confident that there are legitimate reasons why some sysadmins use certain configurations which require / and /usr to be different partitions; I'm less confident that initrd is not the real solution to their problem but that's not really my call to make. I'm *very* confident that a dismissal of this issue as the ego if one or two guys who happen to write udev is a blatant oversimplification that does not do justice to the complexities involved in making modern hardware work. This email [1] (and the correction email right afterwards) should give some much-needed perspective on why we're driving full-speed toward an overturned manure truck (which some of us, e.g., Walter and me, are desperately pulling at the handbrakes). [1] http://lists.busybox.net/pipermail/busybox/2011-September/076713.html Rgds,
Re: [gentoo-user] suspend/hibernate and genkernel.
On Wed, Mar 14, 2012 at 8:28 AM, William Kenworthy bi...@iinet.net.au wrote: On Wed, 2012-03-14 at 14:27 +0100, Sebastian Pipping wrote: On 03/14/2012 04:49 AM, William Kenworthy wrote: According to the docs I have found you need to patch genkernel to run /sbin/resume - it was a longstanding argument between two now retired devs with the result that genkernel wont (ever) support hibernation. I dont know from reading the bugs if it was ever fixed now the dev who wouldnt has retired, or is genkernel is still broken. I'd be interested to hear more details. Can you share links to your sources with me? Thanks, Sebastian https://bugs.gentoo.org/show_bug.cgi?id=156445 - particularly the comment dated 2007-09-14 20:58:00 UTC. and google gets others as well. There are a number of guides describing the patching and related problems ... note that the above is 2007 ... and it still doesnt work. Basicly the question is does genkernel support some of the more complex setups, but as having suspend/resume on a laptop is almost mandatory its something genkernel should support out of the box. For my uses, if it has to be patched to add such basic support ... its broke. Mmmmh. Again, as I said before, suspend/resume should have nothing to do with an initramfs. Hibernate it's the one that may need special support from the initramfs to work. Just to clarify, neither of them works for you without patching genkernel? Or are you talking only about hibernate? 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] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie a...@muc.de wrote: Hello, Canek On Tue, Mar 13, 2012 at 06:07:32PM -0600, Canek Peláez Valdés wrote: On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie a...@muc.de wrote: The new hardware will just work if there are the correct drivers built in. That's as true of udev as it is of mdev as it is of the old static /dev with mknod. No, it is not. You are letting out the sine qua non of the matter: the device has to be built, *and the /dev file should exists*. I hope you are not suggesting that we put *ALL* the possible files under /dev, because that was the idea before devfs, and it doesn't work *IN GENERAL*. Previously you made appropriate /dev entries with mknod, giving the device major and minor numbers as parameters. This appeared to work in general - I'm not aware of any device it didn't work for. Again, I believe you are not following me. In *general* the number of potential device files under /dev is not bounded. Given N device filess, I can give you an example where you would need N+1 device files. With your experience, I assume you know about huge arrays of SCSI disks, for example; add to that whatever number of USB devices (and the hubs necessary to connect them), whatever number of Bluetooth thingies, etc., etc. Therefore, mknod doesn't solve the problem in general, because I can always give an example where the preset device files on /dev are not enough. 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. That happened under the old static /dev system. What was that /dev system, if not a database matching /dev names to device numbers? I'm not sure what you mean by same device and same device name. That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. 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. Early in boot time, you only need things like disk drives, graphic cards and keyboards. Anything else can be postponed till late boot time. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. 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. It may be a complicated problem in general, but many people do not need that generality. ^ That's your mistake! (IMHO). I explain below. I suspect the vast majority don't need it. Neither the typical desktop, the typical server, nor typical embedded devices like routers. Alan, the vast majority of Linux users right now are phone users. That was my initial point some mails ago. What *you* believe are regular users (people like you, or maybe even me), stopped being true a couple of years ago. The days of the Unix admin and workstation user are going the way of the dodo. At least, that's how I see it. I have a really time understanding why you don't see the complexity on the problem. I explained above: it is a complicated problem (when dealing with the general case), and therefore the (general) solution is bound to be also complicated. I've had a hard time understanding, because up till now, nobody's described the problem in detail - there's only been hand-waving. You want it simple? Tha'ts fine, it is possible. It's just that it will not solve the general problem, just a very specific subset of it. That subset used by the vast majority of Linux users. Again, think about phones. And tablets. And TVs. And [insert-here-cool-gadgets-from-the-future]. And yes, I do want it simple, because elegant simplicity is the best way, IMAO. You, on the other hand, seem to love complicated solutions because they are the way forward. We'll have to agree to disagree on this one. No, it's not a matter of that's the way forward. It's a matter of trying to solve the general problem. And since the general solution also solves the simple cases, I don't see a reason to waste my time/resources in a
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On 13 March 2012, at 22:20, Alan Mackenzie wrote: … udev does a *lot* more than that, for example the persistent naming of network interfaces. More significantly, it can run programs based on device rules. This is where I start getting unhappy. Is there any need for this blurring? Having device nodes is essential to a linux system, and some programs use these nodes. Why must they be mashed together into a tasteless mush? Is there some advantage to this I haven't twigged yet? Ok, so my system has 2 network cards. Maybe I only use one of them, or maybe they need to be physically connected in a certain way (one to LAN, the other WAN). Before asking this question, with the knowledge and understanding that we all already have, don't you have to first have to explain how you're going to ensure that eth0 is always assigned by the system to the first NIC and eth1 always to the second NIC? You could use this to argue that /usr should be mounted before udev is started, but you could just as well use it to argue that udev should not be trying to run such rules at the boot runlevel. Or that udev shouldn't have rules. I still don't understand the basic concept driving this thing. My HDDs don't need rules - they just need a mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate drivers built into my kernel. I'm assuming, then, that you're happy opening a terminal and typing `mkdir /mnt/diskname` and mounting the device every time you plug a new disk in? Wouldn't it just be nice to plug in your USB devices - hard-drives and flash drives - and have them magically appear on the desktop like they do on every other desktop operating system? Stroller.
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 15, 2012 12:25 AM, Canek Peláez Valdés can...@gmail.com wrote: 8 snip That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. That could -- should -- be handled by a script or a program that looks up the database, do the checks, and rename the node accordingly. All the device manager got to do is to plug in into the hotplug kernel knob, whereby it will be invoked on every hotplug event, and depending on the nature if the device (which, in your example, fits the pattern wlan*) fires the script/program which performs the lookup+rename part. mdev can do that. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. Put it under /bin Done. Alan, the vast majority of Linux users right now are phone users. That was my initial point some mails ago. What *you* believe are regular users (people like you, or maybe even me), stopped being true a couple of years ago. The days of the Unix admin and workstation user are going the way of the dodo. At least, that's how I see it. The vast majority of Linux users, be they using PCs or smartphones, only need a mechanism to handle hotplugs. udev can do it, but so can mdev (with the help of helper scripts/programs). Again, think about phones. And tablets. And TVs. And [insert-here-cool-gadgets-from-the-future]. See above. No, it's not a matter of that's the way forward. It's a matter of trying to solve the general problem. And since the general solution also solves the simple cases, I don't see a reason to waste my time/resources in a solution that in the end will not solve the general problem. It will always be simpler -- and easier to debug -- if we separate the hotplug handler (whose function is merely to create a dev node with the proper permissions and (optionally) fire up a 'configurator') from the configurator itself. udev is going the kitchen sink route. mdev stays the lego brick path. Of course, as I have been saying from the beginning, this is OpenSource. Want to pour some effort into solving the simple cases that will not help all the community, and that it will only help in fact a minority, that's your prerogative (and Walt's, and Vapier's, and everyone else that don't like the complex but complete solution). Go nuts with it if you want. The code is there; it's called mdev. But your emails are nothing short of denigrating the code. Talk about double standards :-) But please don't dismiss the general solution as unnecessary complex when it's not the case, and don't think that the simple setups (whatever that means) are the majority. Again, think phones and tablets: those *are* the majority. Again, see above. Oh, for sure you can modify LVM2 to work under mdev. Also GNOME/KDE/XFCE, and everything under the sun. You have the source; you can do *anything* you want with it. But the effort wasted^Hpoured in that excercise will only serve a handful of users, and it will be never accepted upstream, because upstream is (rightfully) concerned with the general problem. And as I have explained, based on what Alan had posted, LVM2 (for an example) probably only needs certain device nodes to exist, while mdev's default behavior is to not change anything unless explicitly told. Solvable easily, IMO. I'm more interested in the general solution that will work not only for my current machines, but also for the ones I'm planning to have in the future. I'm dying to get a tablet where I can put GNOME 3 on it; I can bet you another beer that mdev will be not enough to handle that. Unfortunately I don't have any Gentoo with GUI, so I can't take up on your offer :-( With all due respect, Alan (and this is completely sincere, in this list you are of the guys I respect the most), I believe you are thinking too small. With all due respect, I believe *you* are too defensive in regards to udev. Right now Linux runs in my phone, my TV's, my routers and every computer I own. I have a couple of Windows installations, which I use once or twice every three months (I ported a PyGTK program to Windows last week, so I had to boot into Windows for the first time this year). I want Linux running on *everything*, and what is more: I don't want android in my handhelds, I want the full GNOME experience. To accomplish that we need udev; mdev it's just not enough. Again, not necessarily. What exactly in Gnome requires udev? Is it merely expecting some device nodes to exist while mdev's default behavior doesn't do that? That would be simple to solve. A bit more difficult is if Gnome communicates with udev via libudev; but busybox devs have looked into the code of libudev, and found that the functions provided by that lib is can be emulated relatively quickly [1]. But he then added that he won't do that, because that would make
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 1:22 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie a...@muc.de wrote: Hello, Canek On Tue, Mar 13, 2012 at 06:07:32PM -0600, Canek Peláez Valdés wrote: On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie a...@muc.de wrote: The new hardware will just work if there are the correct drivers built in. That's as true of udev as it is of mdev as it is of the old static /dev with mknod. No, it is not. You are letting out the sine qua non of the matter: the device has to be built, *and the /dev file should exists*. I hope you are not suggesting that we put *ALL* the possible files under /dev, because that was the idea before devfs, and it doesn't work *IN GENERAL*. Previously you made appropriate /dev entries with mknod, giving the device major and minor numbers as parameters. This appeared to work in general - I'm not aware of any device it didn't work for. Again, I believe you are not following me. In *general* the number of potential device files under /dev is not bounded. Given N device filess, I can give you an example where you would need N+1 device files. With your experience, I assume you know about huge arrays of SCSI disks, for example; add to that whatever number of USB devices (and the hubs necessary to connect them), whatever number of Bluetooth thingies, etc., etc. Therefore, mknod doesn't solve the problem in general, because I can always give an example where the preset device files on /dev are not enough. And I can always give an example where there can't be enough inodes (or perhaps even RAM) to contain enough device nodes. General Case is a beautiful thing for a theoretical system, but my computer is not a theoretical system. Neither is my phone, or my server. 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. That happened under the old static /dev system. What was that /dev system, if not a database matching /dev names to device numbers? I'm not sure what you mean by same device and same device name. That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. udev does something nice here, and I believe mdev is capable of similar. sysfs exports device attributes such as model and serial number, and you could trivially derive the node name from that. 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. Early in boot time, you only need things like disk drives, graphic cards and keyboards. Anything else can be postponed till late boot time. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. The userland bluetooth stack is an abomination. (Actually, the _whole_ bluetooth stack is an abomination. You don't want to know what embedded developers who build car stereos and the like have to go through to try to test things. Or what real packets fundamentally look like 'on the wire'.) It needs a real overhaul. I used to use a bluetooth keyboard, but I found it to be a real mess. I even joined the Linux Documentation Project with the intent of getting bluetooth profiles, apps and stacks indexed and cross-referenced, but there's just way too much going wrong with bluetooth. I eventually switched to using a propriety wireless keyboard, and relegated the bluetooth keyboard to secondary access and to controlling the PS3. Besides, your BIOS isn't going to support bluetooth, either; if you're concerned about failure-case recovery, and you don't have a keyboard you can navigate your BIOS with, you're very probably doing something wrong. 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. It may be a complicated problem in general, but many people do not need that generality. ^ That's your mistake! (IMHO). I explain below. I suspect the vast majority don't need it. Neither the typical desktop, the typical
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan pa...@poluan.info wrote: On Mar 15, 2012 12:25 AM, Canek Peláez Valdés can...@gmail.com wrote: 8 snip That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. That could -- should -- be handled by a script or a program that looks up the database, do the checks, and rename the node accordingly. All the device manager got to do is to plug in into the hotplug kernel knob, whereby it will be invoked on every hotplug event, and depending on the nature if the device (which, in your example, fits the pattern wlan*) fires the script/program which performs the lookup+rename part. mdev can do that. udev already does it. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. Put it under /bin Done. Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe I need a wireless connected NFS share). And... Not scalable. Doesn't solve the general case. You are seeing too small. Alan, the vast majority of Linux users right now are phone users. That was my initial point some mails ago. What *you* believe are regular users (people like you, or maybe even me), stopped being true a couple of years ago. The days of the Unix admin and workstation user are going the way of the dodo. At least, that's how I see it. The vast majority of Linux users, be they using PCs or smartphones, only need a mechanism to handle hotplugs. udev can do it, but so can mdev (with the help of helper scripts/programs). udev can do it *right now*, no hacks involved. Go and hack mdev until it handles *ALL* the cases udev handles, and see how complex it gets. Again, think about phones. And tablets. And TVs. And [insert-here-cool-gadgets-from-the-future]. See above. No, it's not a matter of that's the way forward. It's a matter of trying to solve the general problem. And since the general solution also solves the simple cases, I don't see a reason to waste my time/resources in a solution that in the end will not solve the general problem. It will always be simpler -- and easier to debug -- if we separate the hotplug handler (whose function is merely to create a dev node with the proper permissions and (optionally) fire up a 'configurator') from the configurator itself. Been there, tried that. What do you think devfs was? We tried this path already: it doesn't work, it doesn't scale. You couple together the device manager and the database handling and the firing of associated scripts because that's the technical correct solution. It *is* more complex, for sure, but so it's the general problem we are trying to solve. udev is going the kitchen sink route. mdev stays the lego brick path. And guess what? I don't want a toy solution built with lego blocks. I want a robust, general solution, that it is bound to work *now* and in the future. Of course, as I have been saying from the beginning, this is OpenSource. Want to pour some effort into solving the simple cases that will not help all the community, and that it will only help in fact a minority, that's your prerogative (and Walt's, and Vapier's, and everyone else that don't like the complex but complete solution). Go nuts with it if you want. The code is there; it's called mdev. But your emails are nothing short of denigrating the code. It's not my intention to denigrate anything. Just stating my opinion. Talk about double standards :-) When I hear Walt saying that mdev handles GNOME/KDE/XFCE/LVM2, you may say that. Right *now*, Walt says mdev doesn't handle those cases. But please don't dismiss the general solution as unnecessary complex when it's not the case, and don't think that the simple setups (whatever that means) are the majority. Again, think phones and tablets: those *are* the majority. Again, see above. Oh, for sure you can modify LVM2 to work under mdev. Also GNOME/KDE/XFCE, and everything under the sun. You have the source; you can do *anything* you want with it. But the effort wasted^Hpoured in that excercise will only serve a handful of users, and it will be never accepted upstream, because upstream is (rightfully) concerned with the general problem. And as I have explained, based on what Alan had posted, LVM2 (for an example) probably only needs certain device nodes to exist, while mdev's default behavior is to not change anything unless explicitly told. Solvable easily, IMO. Go and solve it then. I will keep using udev, which works right now, thank you. I'm more interested in the general solution that will work not only for my current machines, but also for the ones I'm planning to have in the future. I'm dying to get a tablet where I can put GNOME 3 on it; I can bet you another beer that mdev will be not enough to handle that. Unfortunately
[gentoo-user] How can I trigger kernel panic?
Hi, my question might seem silly, but I have reason for it: I have heard there is way to auto-reboot linux after kernel panic using kernel.panic=time in /etc/sysctl.conf. This might come handy as my server is far from me and I do not have any remote console. But I would like to test it and see if it works (first on my desktop). So my question is: Can I somehow deliberately trigger kernel panic (or kernel oops)? Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] How can I trigger kernel panic?
On Wed, Mar 14, 2012 at 11:23 AM, Jarry mr.ja...@gmail.com wrote: Hi, my question might seem silly, but I have reason for it: I have heard there is way to auto-reboot linux after kernel panic using kernel.panic=time in /etc/sysctl.conf. This might come handy as my server is far from me and I do not have any remote console. But I would like to test it and see if it works (first on my desktop). So my question is: Can I somehow deliberately trigger kernel panic (or kernel oops)? For panic, echo c /proc/sysrq-trigger Jarry -- __**__**___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted. -- Zhang Le, Robert Gentoo/Loongson(龙芯) Developer http://zhangle.is-a-geek.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 12:09 PM, Michael Mol mike...@gmail.com wrote: On Wed, Mar 14, 2012 at 1:22 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie a...@muc.de wrote: Hello, Canek On Tue, Mar 13, 2012 at 06:07:32PM -0600, Canek Peláez Valdés wrote: On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie a...@muc.de wrote: The new hardware will just work if there are the correct drivers built in. That's as true of udev as it is of mdev as it is of the old static /dev with mknod. No, it is not. You are letting out the sine qua non of the matter: the device has to be built, *and the /dev file should exists*. I hope you are not suggesting that we put *ALL* the possible files under /dev, because that was the idea before devfs, and it doesn't work *IN GENERAL*. Previously you made appropriate /dev entries with mknod, giving the device major and minor numbers as parameters. This appeared to work in general - I'm not aware of any device it didn't work for. Again, I believe you are not following me. In *general* the number of potential device files under /dev is not bounded. Given N device filess, I can give you an example where you would need N+1 device files. With your experience, I assume you know about huge arrays of SCSI disks, for example; add to that whatever number of USB devices (and the hubs necessary to connect them), whatever number of Bluetooth thingies, etc., etc. Therefore, mknod doesn't solve the problem in general, because I can always give an example where the preset device files on /dev are not enough. And I can always give an example where there can't be enough inodes (or perhaps even RAM) to contain enough device nodes. General Case is a beautiful thing for a theoretical system, but my computer is not a theoretical system. Neither is my phone, or my server. You are arguing that the mknod method should be used? Because that dicussion happened ten years ago; that train is long gone. If you want to argue with someone about it, it would not be me. 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. That happened under the old static /dev system. What was that /dev system, if not a database matching /dev names to device numbers? I'm not sure what you mean by same device and same device name. That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. udev does something nice here, and I believe mdev is capable of similar. sysfs exports device attributes such as model and serial number, and you could trivially derive the node name from that. I think (as does the udev maintainers) that there should be a strong coupling between the device manager, the database handling, and the firing of scripts. Otherwise. we get back to devfs, which again, that train is long gone. 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. Early in boot time, you only need things like disk drives, graphic cards and keyboards. Anything else can be postponed till late boot time. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. The userland bluetooth stack is an abomination. (Actually, the _whole_ bluetooth stack is an abomination. You don't want to know what embedded developers who build car stereos and the like have to go through to try to test things. Or what real packets fundamentally look like 'on the wire'.) It needs a real overhaul. I used to use a bluetooth keyboard, but I found it to be a real mess. I even joined the Linux Documentation Project with the intent of getting bluetooth profiles, apps and stacks indexed and cross-referenced, but there's just way too much going wrong with bluetooth. I eventually switched to using a propriety wireless keyboard, and relegated the bluetooth keyboard to secondary access and to controlling the PS3. Besides, your BIOS isn't going to support bluetooth, either; if you're concerned about failure-case recovery, and you don't have a keyboard you can navigate your BIOS with, you're very probably doing something wrong. BIOS is going the way
Re: [gentoo-user] How can I trigger kernel panic?
On 03/14/12 14:23, Jarry wrote: Hi, my question might seem silly, but I have reason for it: I have heard there is way to auto-reboot linux after kernel panic using kernel.panic=time in /etc/sysctl.conf. This might come handy as my server is far from me and I do not have any remote console. But I would like to test it and see if it works (first on my desktop). So my question is: Can I somehow deliberately trigger kernel panic (or kernel oops)? If you want to test the auto-reboot, try appending root=/dev/random to the command line.
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 15, 2012 1:22 AM, Canek Peláez Valdés can...@gmail.com wrote:
On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan pa...@poluan.info wrote:
On Mar 15, 2012 12:25 AM, Canek Peláez Valdés can...@gmail.com
wrote:
8 snip
That if I connect a USB wi-fi dongle, and it appears with the name
wlan23, I want *every* time that dongle to have the wlan23 name .Good
luck doing that without a database.
That could -- should -- be handled by a script or a program that looks
up
the database, do the checks, and rename the node accordingly.
All the device manager got to do is to plug in into the hotplug kernel
knob,
whereby it will be invoked on every hotplug event, and depending on the
nature if the device (which, in your example, fits the pattern wlan*)
fires the script/program which performs the lookup+rename part.
mdev can do that.
udev already does it.
So does mdev. If writing a simple script is so distressing for you, why in
the world are you using Gentoo, with all its manual labor?
Put it under /bin
Done.
Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe
I need a wireless connected NFS share). And...
Not scalable. Doesn't solve the general case. You are seeing too small.
*You* are not seeing _at all_. Witness how the Fedora devs want to merge
/bin and /sbin
It *is* scalable. Ever tried du /usr?
The problem was -- is -- that package maintainers blindly put binaries
required for booting into /usr
The vast majority of Linux users, be they using PCs or smartphones, only
need a mechanism to handle hotplugs.
udev can do it, but so can mdev (with the help of helper
scripts/programs).
udev can do it *right now*, no hacks involved. Go and hack mdev until
it handles *ALL* the cases udev handles, and see how complex it gets.
If you're so afraid of doing things manually, you have no business using
Gentoo in the first place.
Here's a prototype script to ensure that certain NICs will always end up
the way you want it named:
#!/bin/sh
mac=$( cat /proc/net/arp | awk -V dev=$MDEV 'NR==1{next} $6==dev {print
$4}')
name=$(awk -V mac=$mac '$1==mac {print $2}')
[ $name ] mv /dev/$MDEV /dev/$name
exit 0
(Prototype, because I don't have access to a Linux box atm, so I can't test)
Been there, tried that. What do you think devfs was? We tried this
path already: it doesn't work, it doesn't scale. You couple together
the device manager and the database handling and the firing of
associated scripts because that's the technical correct solution. It
*is* more complex, for sure, but so it's the general problem we are
trying to solve.
If you step down from your high chair for awhile and read the busybox
thread I've been linking, you'll know the difference. One of the emails in
that thread explained it.
udev is going the kitchen sink route. mdev stays the lego brick path.
And guess what? I don't want a toy solution built with lego blocks.
Obviously idioms went way over your head.
If you're taking the Lego brick allegory as literal, then good luck with
your kitchen sink. At least I know that with Lego bricks, amazing works of
art have been created. :-P
I
want a robust, general solution, that it is bound to work *now* and in
the future.
So? What makes you think that in the future suddenly mdev stops working?
The flip side: as udev gets more and more complex, how could you be sure it
won't catastrophically fail one day, just like HAL?
Talk about double standards :-)
When I hear Walt saying that mdev handles GNOME/KDE/XFCE/LVM2, you may
say that. Right *now*, Walt says mdev doesn't handle those cases.
Walt said that mdev doesn't work with LVM2, but then Alan said that
actually LVM2 works after booting. It just didn't work during booting.
Suspiciously a case of missing/misnamed dev nodes to me, easily fixable by
adding some mdev.conf rules.
Go and solve it then. I will keep using udev, which works right now,
thank you.
I am not using LVM, so I have no test case. But I certainly will pursue
this issue -- had you not derail the thread by slandering mdev with all
your might.
With all due respect, Alan (and this is completely sincere, in this
list you are of the guys I respect the most), I believe you are
thinking too small.
With all due respect, I believe *you* are too defensive in regards to
udev.
I'm not defending anything; just stating my opinion. You are free to
disagree, of course.
The way you write it, as if udev is the greatest thing since slice bread
while mdev is 'useless and destined to fail'?
Sounds like a fanboy rant to me :-)
Go and code if it's really easy and simple and doable. Me? I will
stick with udev, 'cause it works. And it works *right now*, in all my
use cases and even some I don't plan to have in the near future.
If it's a case of missing node, it's *very* easy: Identify what node it's
being expected, identify what node was created by mdev, edit mdev.conf to
perform a
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 15, 2012 2:24 AM, Pandu Poluan pa...@poluan.info wrote:
Here's a prototype script to ensure that certain NICs will always end up
the way you want it named:
#!/bin/sh
mac=$( cat /proc/net/arp | awk -V dev=$MDEV 'NR==1{next} $6==dev {print
$4}')
name=$(cat /etc/nic.conf | awk -V mac=$mac '$1==mac {print $2}')
[ $name ] mv /dev/$MDEV /dev/$name
exit 0
(Prototype, because I don't have access to a Linux box atm, so I can't
test)
Eh, forgot the input file for the second awk :-P
Rgds,
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 2:45 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Mar 14, 2012 at 12:09 PM, Michael Mol mike...@gmail.com wrote: On Wed, Mar 14, 2012 at 1:22 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie a...@muc.de wrote: Hello, Canek On Tue, Mar 13, 2012 at 06:07:32PM -0600, Canek Peláez Valdés wrote: On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie a...@muc.de wrote: The new hardware will just work if there are the correct drivers built in. That's as true of udev as it is of mdev as it is of the old static /dev with mknod. No, it is not. You are letting out the sine qua non of the matter: the device has to be built, *and the /dev file should exists*. I hope you are not suggesting that we put *ALL* the possible files under /dev, because that was the idea before devfs, and it doesn't work *IN GENERAL*. Previously you made appropriate /dev entries with mknod, giving the device major and minor numbers as parameters. This appeared to work in general - I'm not aware of any device it didn't work for. Again, I believe you are not following me. In *general* the number of potential device files under /dev is not bounded. Given N device filess, I can give you an example where you would need N+1 device files. With your experience, I assume you know about huge arrays of SCSI disks, for example; add to that whatever number of USB devices (and the hubs necessary to connect them), whatever number of Bluetooth thingies, etc., etc. Therefore, mknod doesn't solve the problem in general, because I can always give an example where the preset device files on /dev are not enough. And I can always give an example where there can't be enough inodes (or perhaps even RAM) to contain enough device nodes. General Case is a beautiful thing for a theoretical system, but my computer is not a theoretical system. Neither is my phone, or my server. You are arguing that the mknod method should be used? Because that dicussion happened ten years ago; that train is long gone. If you want to argue with someone about it, it would not be me. No, I was taking your argument to its perceived end result. You want the universal solution, but that requires limitless resources in things like memory and integer sizes. The software doesn't exist within such an environment. The assumptions which it's already depending on limit its utility in lower-end hardware. 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. That happened under the old static /dev system. What was that /dev system, if not a database matching /dev names to device numbers? I'm not sure what you mean by same device and same device name. That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. udev does something nice here, and I believe mdev is capable of similar. sysfs exports device attributes such as model and serial number, and you could trivially derive the node name from that. I think (as does the udev maintainers) that there should be a strong coupling between the device manager, the database handling, and the firing of scripts. Otherwise. we get back to devfs, which again, that train is long gone. From the sound of it, it sounds like mdev matches that description. mdev supports the renaming of devices, so there's your database. It supports firing scripts. 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. Early in boot time, you only need things like disk drives, graphic cards and keyboards. Anything else can be postponed till late boot time. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. The userland bluetooth stack is an abomination. (Actually, the _whole_ bluetooth stack is an abomination. You don't want to know what embedded developers who build car stereos and the like have to go through to try to test things. Or what real packets fundamentally look like 'on the wire'.) It needs a real overhaul. I used to use a bluetooth keyboard, but I found it to be a real mess. I even joined the Linux
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 1:24 PM, Pandu Poluan pa...@poluan.info wrote:
On Mar 15, 2012 1:22 AM, Canek Peláez Valdés can...@gmail.com wrote:
On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan pa...@poluan.info wrote:
On Mar 15, 2012 12:25 AM, Canek Peláez Valdés can...@gmail.com
wrote:
8 snip
That if I connect a USB wi-fi dongle, and it appears with the name
wlan23, I want *every* time that dongle to have the wlan23 name .Good
luck doing that without a database.
That could -- should -- be handled by a script or a program that looks
up
the database, do the checks, and rename the node accordingly.
All the device manager got to do is to plug in into the hotplug kernel
knob,
whereby it will be invoked on every hotplug event, and depending on the
nature if the device (which, in your example, fits the pattern wlan*)
fires the script/program which performs the lookup+rename part.
mdev can do that.
udev already does it.
So does mdev. If writing a simple script is so distressing for you, why in
the world are you using Gentoo, with all its manual labor?
Whoa, relax man. We are discussing (or at least I'm trying) in a civil
manner the technical merits of two proposed solutions for a problem.
No need to get personal.
(And BTW, I've been using Gentoo since 2003, and I maintain an overlay
to use systemd without the need of having openrc/baselayout
installed).
Put it under /bin
Done.
Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe
I need a wireless connected NFS share). And...
Not scalable. Doesn't solve the general case. You are seeing too small.
*You* are not seeing _at all_. Witness how the Fedora devs want to merge
/bin and /sbin
Yeah. I agree with their decision. Read:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
It *is* scalable. Ever tried du /usr?
Yeah, from time to time. Fail to see your point.
The problem was -- is -- that package maintainers blindly put binaries
required for booting into /usr
No problem with an intiramfs :D
The vast majority of Linux users, be they using PCs or smartphones, only
need a mechanism to handle hotplugs.
udev can do it, but so can mdev (with the help of helper
scripts/programs).
udev can do it *right now*, no hacks involved. Go and hack mdev until
it handles *ALL* the cases udev handles, and see how complex it gets.
If you're so afraid of doing things manually, you have no business using
Gentoo in the first place.
Again with the personal attacks; relax man. No need to get all worked out.
Here's a prototype script to ensure that certain NICs will always end up the
way you want it named:
#!/bin/sh
mac=$( cat /proc/net/arp | awk -V dev=$MDEV 'NR==1{next} $6==dev {print
$4}')
name=$(awk -V mac=$mac '$1==mac {print $2}')
[ $name ] mv /dev/$MDEV /dev/$name
exit 0
(Prototype, because I don't have access to a Linux box atm, so I can't test)
Yeah, I'm gonna try that instead of udev, which works out of the box.
I'm gonna pass, thank you.
Been there, tried that. What do you think devfs was? We tried this
path already: it doesn't work, it doesn't scale. You couple together
the device manager and the database handling and the firing of
associated scripts because that's the technical correct solution. It
*is* more complex, for sure, but so it's the general problem we are
trying to solve.
If you step down from your high chair for awhile and read the busybox thread
I've been linking, you'll know the difference. One of the emails in that
thread explained it.
Relax, I'm not on a high chair; again, I'm just stating my opinion. I
have read the mail, I think the day it was posted. I don't buy it, for
all the reasons I have been saying.
udev is going the kitchen sink route. mdev stays the lego brick path.
And guess what? I don't want a toy solution built with lego blocks.
Obviously idioms went way over your head.
If you're taking the Lego brick allegory as literal, then good luck with
your kitchen sink. At least I know that with Lego bricks, amazing works of
art have been created. :-P
:D
Actually, a Lego brick is a good analogy for mdev (in its current
state). It's a beautiful toy; but again, nobody has pointed out how to
make it work with bluetooth devices, for example. From Walt's mail
(his words, not mine):
This revision includes some checking to see if your system can run
without udev. In general, if you use any of...
* GNOME
* KDE
* XFCE
* lvm2
... you probably need udev, so mdev is not for you.
I
want a robust, general solution, that it is bound to work *now* and in
the future.
So? What makes you think that in the future suddenly mdev stops working?
I doesn't work, out of the box, right now. Again, see Walt's mail.
The flip side: as udev gets more and more complex, how could you be sure it
won't catastrophically fail one day, just like HAL?
Educated guess ;)
I have been using Linux since 1997. I
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 1:41 PM, Michael Mol mike...@gmail.com wrote: [ huge snip ] Each time, you've acted as though the new stance is what you've been arguing from all along, but because you haven't communicated that, it's impossible to reasonably discuss specifics in practicality. I think I'm done with this particular discussion. I think I'm done too. I just stated my opinion; do whatever you want with it. Including ignoring it, of course. 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] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
Good evening, Stroller. On Wed, Mar 14, 2012 at 05:56:34PM +, Stroller wrote: On 13 March 2012, at 22:20, Alan Mackenzie wrote: … udev does a *lot* more than that, for example the persistent naming of network interfaces. More significantly, it can run programs based on device rules. This is where I start getting unhappy. Is there any need for this blurring? Having device nodes is essential to a linux system, and some programs use these nodes. Why must they be mashed together into a tasteless mush? Is there some advantage to this I haven't twigged yet? Ok, so my system has 2 network cards. Maybe I only use one of them, or maybe they need to be physically connected in a certain way (one to LAN, the other WAN). Before asking this question, with the knowledge and understanding that we all already have, don't you have to first have to explain how you're going to ensure that eth0 is always assigned by the system to the first NIC and eth1 always to the second NIC? By kernel parameters? I once had a problem with the kernel not finding my hard drives. I solved it by putting the following kernel parameters into my lilo.conf: ide2=0xd000,0xd402,11 ide3=0xd800,0xdc02,11 The same could be done for network cards. You could use this to argue that /usr should be mounted before udev is started, but you could just as well use it to argue that udev should not be trying to run such rules at the boot runlevel. Or that udev shouldn't have rules. I still don't understand the basic concept driving this thing. My HDDs don't need rules - they just need a mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate drivers built into my kernel. I'm assuming, then, that you're happy opening a terminal and typing `mkdir /mnt/diskname` and mounting the device every time you plug a new disk in? You might be taking me just a wee bit _too_ literally there. But yes, I mount each removable device I plug in. Wouldn't it just be nice to plug in your USB devices - hard-drives and flash drives - and have them magically appear on the desktop like they do on every other desktop operating system? Yes. Stroller. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On 2012-03-14 19:45, Canek Peláez Valdés wrote: BIOS is going the way of the dodo too, but that's besides the point. I'm actually quite happy with the Linux bluetooth stack (which, if I'm not mistaken, is used by Android). I have several bluetooth thingies, they all work great. Sorry, but you're gravely mistaken if you think firmware[1] is going anywhere. You can have all the bluetooth thingies you want but why should they be available at boot time, before you can use them? Excepting a bluetooth keyboard, which to me seems broken by design; you're replacing a keyboard with a cable that just works with something that needs a system up and running to function... [1] (U)EFI is only replacing the runtime interface of BIOS (BIOS will remain). https://en.wikipedia.org/wiki/BIOS#Changing_role_of_the_BIOS And if you want to ditch BIOS altogheter you need to replace it with something like coreboot or Open Firmware. Best regards Peter K
RE: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
From: Alan Mackenzie [mailto:a...@muc.de] Sent: Tuesday, March 13, 2012 7:04 PM Huh? What's that to do with udev? You're talking at far too high a level of abstraction. The new hardware will just work if there are the correct drivers built in. That's as true of udev as it is of mdev as it is of the old static /dev with mknod. This idea works fine when your drivers are simple enough to go into a kernel, and can actually perform all of the functions your device needs. Many modern devices require complex things to happen before or after they appear in your /dev tree before they can *really* be useful. (Complex relative to the operations a kernel module is expected to perform). When I plug in my HP USB printer, the hplip system checks a locally installed database file to make sure I have support for that model before making it available as a device. When udev finds my Bluetooth keyboard or mouse, it launches bluetoothd so it will work. udev manages drives, sound cards and network cards that may appear and disappear in such a way that they are always given consistent names. I have custom rules that run when I plug an Android phone into my machine that preps it for being debugged via Eclipse, despite the kernel seeing it as just a generic USB device. The point is, udev suppors /arbitrary/ behaviors, defined by device vendors or even end users, which can be controlled and configured at runtime. Some of these operations would be hard to do safely from the kernel. Some of them may even trigger events to happen in userspace in the context of the logged-on user (such as automounting from GNOME.) Note that none of this is necessarily unique to udev; mdev could (and probably does, I don't know) provide userspace events for new devices just as easily as udev does. But in order for udev to maintain the broad level of complex hardware support that it has, it must make certain assumptions that may not hold true for /all/ cases, but are true in the /broadest general/ case: that it may be required to launch software or read data found in /usr or /home or wherever else a udev rule might point, and it may be required to do so before it has even seen the device nodes needed to mount non-root partitions. mdev's appeal here in this case is simply that it makes different, simpler assumptions: that it will /never/ need to access software or data that is not part of the root partition at boot time. If that assumption holds true for a given system, then mdev can behave as an effective drop-in replacement for udev. The choice is then to give up support for the broader case in exchange for a simpler system that supports enough to make all of your specific hardware function. --Mike
[gentoo-user] mdev: Has anybody managed to get the keyboard and mouse to work under X?
Hi, Gentoo. As I've said a few times in the current threads, the only thing preventing me from moving fully onto mdev is not having a working keyboard and mouse (evdev??) under X. Has anybody else tried this, and if so, what results have you had? -- Alan Mackenzie (Nuremberg, Germany).
RE: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
From: Pandu Poluan [mailto:pa...@poluan.info] Sent: Wednesday, March 14, 2012 12:13 PM BUT, in the same message, it is stated that Xorg *can* be compiled to *not* try to communicate with udev. I suspect a similar situation with Gnome. IIRC, GNOME only needs udev for auto-mount support. gvfs has a udev flag, disabling that might eliminate the need there. KDE has similar udev flags for things like pulseaudio. For GNOME, I suspect swapping udev for mdev may be tricky, since GNOME uses a custom-build library (libudev) for all of its communications. If libudev can be tricked into listening to mdev instead, and isn't communicating in a way that mdev doesn't support, then GNOME should just work. --Mike
RE: [gentoo-user] mdev: Has anybody managed to get the keyboard and mouse to work under X?
From: Alan Mackenzie [mailto:a...@muc.de] Sent: Wednesday, March 14, 2012 11:21 AM As I've said a few times in the current threads, the only thing preventing me from moving fully onto mdev is not having a working keyboard and mouse (evdev??) under X. Has anybody else tried this, and if so, what results have you had? I have not tried it since they removed the HAL dependency, but I believe you just need to compile xorg with USE=-udev and put the correct device information into the xorg.conf file. What X uses udev for is to enumeration your devices when it starts, and associate those devices automatically with the right drivers. From what Pandu has said, X cannot be made to poll mdev for the information it needs because the conversion is backwards from mdev's perspective: instead of mdev sending new-device events out to listening userspace applications, X is expecting to initiate a query into the device manager, which mdev cannot do. However, if you configure that all manually then X has no more need of a device manager, udev or otherwise. --Mike
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6
On Wed, Mar 14, 2012 at 02:15:52PM +0100, J. Roeleveld wrote Wouldn't a good solution be to have the ebuild modified to only install those binary blobs you actually need? Eg. similar to how apache or sane modules are configured? The tarball on the AMD website has all the binary blobs bundled together. The ebuild simply downloads the tarball and extracts it to the correct library directory. You could do it manually. The problem with separate ebuilds is that one ebuild would be replaced with a couple of dozen ebuilds, or one ebuild with a couple of dozen custom USE flags. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 03:16:20PM +, Alan Mackenzie wrote There's a difference between needed by portage and doesn't work under mdev. As I say, it will all be moot if the evdev driver won't work under mdev. I don't have x11-drivers/xf86-input-evdev installed and my desktops work fine. Of course, I'm running ICEWM, not GNOME or KDE. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6
On Wed, Mar 14, 2012 at 3:43 PM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Mar 14, 2012 at 02:15:52PM +0100, J. Roeleveld wrote Wouldn't a good solution be to have the ebuild modified to only install those binary blobs you actually need? Eg. similar to how apache or sane modules are configured? The tarball on the AMD website has all the binary blobs bundled together. The ebuild simply downloads the tarball and extracts it to the correct library directory. You could do it manually. The problem with separate ebuilds is that one ebuild would be replaced with a couple of dozen ebuilds, or one ebuild with a couple of dozen custom USE flags. You could use an use-expand variable, like INPUT_DEVICES or VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds like the smart thing to do. 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: LVM, /usr and really really bad thoughts.
From: Pandu Poluan [mailto:pa...@poluan.info] Sent: Wednesday, March 14, 2012 12:28 PM This email [1] (and the correction email right afterwards) should give some much-needed perspective on why we're driving full-speed toward an overturned manure truck (which some of us, e.g., Walter and me, are desperately pulling at the handbrakes). [1] http://lists.busybox.net/pipermail/busybox/2011-September/076713.html Actually, that email lost me in the second sentence (though I kept reading): It is incredibly biased towards huge desktop systems and behemoth software Every machine I run Linux on is a huge desktop system running behemoth software (Eclipse, GNOME, Chromium, LibreOffice, etc.). That's why it's called a free desktop system. The author of this email is clearly baised *against* desktop systems running desktop environments, as well as any other highly dynamic system that doesn't fit the model of a simple server running Linux the way it ran 10 years ago. He seems to be producing a rather vitriolic, and IMO uncalled-for, rant against the simple fact that computers do more stuff in 2012 than they did in 1972 and the udev developers are changing with the times. The reality is, the majority of people running Linux desktop systems using big software packages want a desktop system that works out of the box so they can just turn it on and get their work done. That is the audience that udev is targeted for, and it is doing a perfectly good job at meeting the needs of that audience. The fact that the largest major distributions are currently using udev (with an initrd) successfully is all the proof you need that it actually does work. The people who want or need a more specialized solution to this same problem (dynamic device management), are generally also smart enough to avoid using udev if they so choose. Again, the fact that, with merely a few months of effort, a handful of users on this list have produced exactly such a solution is all the proof I need that such a solution is possible. I also know that I have no reason to use their solution because the one I'm using now works just fine for me. As to the email itself, I see two major technical flaws in the argument as presented: First, the fundamental argument being made is that /usr should be allowed to remain a separate partition, and that the misinformed and/or dishonest and or [lacking in] good engineering practices systemd team somehow wants to force everyone to put /usr and / together. Except that's *absolutely not at all what they are proposing*. Their proposal is precisely this: the /usr partition contains binaries that are needed on many modern desktop systems to properly populate the device tree, and thus, the /usr partition must be available early enough in the boot process for that to happen, and thus, we can move forward with our software (udev) with the assumption that /usr will be available when we need it. Second, the idea that the entire collective Fedora/Debian/etc teams somehow made a mistake by install[ing] critical software into /usr. This argument falls flat when the author fails to identify what he or she considers to be critical vs. non-critical software. Is bluetoothd critical? On my laptop it is not. On my main development workstation it is not. On my wife's desktop it is because she has a Bluetooth keyboard/mouse combination. Should bluetoothd be moved from /usr/sbin to /sbin? Along with libglib and libdbus, which it depends on? How about usbmuxd, or alsactl? You could also argue, as some here have done, that these are not truly critical software because those are not critical devices; but now, you must teach udev to know the difference between device that can be added pre-mount and device that must wait until post-mount on a per-device-per-system-per-boot basis, since that designation may change at any time. And recognize the difference between device that failed because something went horribly wrong and I should drop into rescue mode vs device that failed because I tried too early and just need to try again later. And provide a way for udev to create the devices it can, pause while the rest of the filesystems come up, detect that the rest of the filesystems are present, then go back and re-do the devices that failed originally. All the while knowing that the solution of just make /usr available is such an easy and reasonable answer 99% of the time. I know which option I'd pick to spend my limited time and resources on. There's no need to get mean-spirited about it. You are not pulling at the hand-brakes of an out-of-control manure truck. You are producing one of many possible /perfectly valid/ alternative solutions to a complex problem, one which meets your needs but does not meet mine, and there is absolutely nothing wrong with that. --Mike
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On 2012-03-14 20:45, Canek Peláez Valdés wrote: Actually, a Lego brick is a good analogy for mdev (in its current state). It's a beautiful toy; but again, nobody has pointed out how to make it work with bluetooth devices, for example. From Walt's mail (his words, not mine): You're completely missing the point about lego. Lego in this context means small, well defined, interoperable parts with well defined interfaces (i.e. unix); small means easy to maintain (less complex). And if you wish to play it like that: Your system (systemd, pulseaudio, bluetooth, diverse gadgetry...) seems much more of a toy system to me... * XFCE Not sure why it would be a problem running Xfce without udev support: http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors ... maybe things will change though... Gnome and KDE *I* couldn't care less about; they're focused more on singing and dancing than productivity... * lvm2 Alan Mackenzie seems to be able to run it with mdev... I'm willing to bet yet another beer that udev will not have the fate HAL had. As complexity grows, bugs will too... which is why the unix concept have worked for so long (KISS = lego). Best regards Peter K
Re: [gentoo-user] Re: gmail smtp overwrites the sender
On Monday 12 Mar 2012 18:34:37 Grant Edwards wrote: On 2012-03-12, Stroller strol...@stellar.eclipse.co.uk wrote: On 12 March 2012, at 14:59, fe...@crowfix.com wrote: On Sun, Mar 11, 2012 at 02:22:34PM +0100, Andr??s Cs??nyi wrote: On 11 March 2012 13:49, Stroller strol...@stellar.eclipse.co.uk wrote: On 10 March 2012, at 20:56, Andr??s Cs??nyi wrote: ??? I would like to ask some help! I would like to use gmail smtp to send my email from my domain which is sayusi.hu, and the email address is sayusi.a...@sayusi.hu. Unfortunately, gmail smtp always overwrite the sender email address. ??? ??Do you know any solution for this? Use a different SMTP server. I don't believe there's any alternative. Have you considered Postfix? What do you mean when you say Postfix? I think Stroller may have confused gee-mail and queue-mail. The only reason I looked at this thread was becaue 'g' and 'q' do look similar, and I thought it might be about qmail. qmail is a mailer program, like Postfix, sendmail, and so on, whereas gmail is a mail domain, like yahoo, hotmail, etc. No, I simply meant that if you use Postfix you don't have to use anyone else's SMTP server, If you've got a static IP address, a domain, an MX record, and whatever other requirements a lot of sites are now placing upon senders of mail. I used to use my own SMTP server, 10 years ago it worked fine. More recently, too many destinations wouldn't accept mail from me -- so I had to start using mail relays. Perhaps your mail address was blacklisted? Many ISPs IP address blocks are blacklisted these days. Also some ISPs are blocking ports (like 25 and 2525) to minimise spam sent out of compromised boxen. They would typically allow you to relay through their mailservers though. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] suspend/hibernate and genkernel.
On 15/03/2012, at 0:54, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Mar 14, 2012 at 8:28 AM, William Kenworthy bi...@iinet.net.au wrote: On Wed, 2012-03-14 at 14:27 +0100, Sebastian Pipping wrote: On 03/14/2012 04:49 AM, William Kenworthy wrote: According to the docs I have found you need to patch genkernel to run /sbin/resume - it was a longstanding argument between two now retired devs with the result that genkernel wont (ever) support hibernation. I dont know from reading the bugs if it was ever fixed now the dev who wouldnt has retired, or is genkernel is still broken. I'd be interested to hear more details. Can you share links to your sources with me? Thanks, Sebastian https://bugs.gentoo.org/show_bug.cgi?id=156445 - particularly the comment dated 2007-09-14 20:58:00 UTC. and google gets others as well. There are a number of guides describing the patching and related problems ... note that the above is 2007 ... and it still doesnt work. Basicly the question is does genkernel support some of the more complex setups, but as having suspend/resume on a laptop is almost mandatory its something genkernel should support out of the box. For my uses, if it has to be patched to add such basic support ... its broke. Mmmmh. Again, as I said before, suspend/resume should have nothing to do with an initramfs. Hibernate it's the one that may need special support from the initramfs to work. Just to clarify, neither of them works for you without patching genkernel? Or are you talking only about hibernate? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México I have only tested hibernate - some major problems when starting this morning, buts that's probably tuning for in-kernel as against a system setup for ToI. I also am getting /usr errors again (both on boot and resume from hibernate, can't find some binaries on /usr, but mounts ok later in the sequence -maybe timing) - lack of detailed debug when in the initramfs is a problem - will have to start scattering print statements through it ... This is on a home gateway/server that's shutdown/powered off overnight. Startup has to be fast as when power comes on (via remote controlled relays) there are PXE diskless NFS systems (mythtv front ends) that time out if it goes through a full boot sequence. BillK
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6
On Wed, Mar 14, 2012 at 04:09:33PM -0600, Canek Pel??ez Vald??s wrote You could use an use-expand variable, like INPUT_DEVICES or VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds like the smart thing to do. The VIDEO_CARDS variable might be RADEON, but there are many different levels of Radeon GPU cards, each requiring its own specific binary blob. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6
On Mar 15, 2012 7:04 AM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Mar 14, 2012 at 04:09:33PM -0600, Canek Pel??ez Vald??s wrote You could use an use-expand variable, like INPUT_DEVICES or VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds like the smart thing to do. The VIDEO_CARDS variable might be RADEON, but there are many different levels of Radeon GPU cards, each requiring its own specific binary blob. So, detail it down... e.g. RADEON-HD-4650, RADEON-HD-6530, etc. Kind of like the xtables-addons package. Rgds,
Re: [gentoo-user] mdev: Has anybody managed to get the keyboard and mouse to work under X?
On Mar 15, 2012 3:52 AM, Alan Mackenzie a...@muc.de wrote: Hi, Gentoo. As I've said a few times in the current threads, the only thing preventing me from moving fully onto mdev is not having a working keyboard and mouse (evdev??) under X. Has anybody else tried this, and if so, what results have you had? Alan, could you post your init script here? I just happened upon this: http://blackfin.uclinux.org/gf/project/uclinux-dist/scmsvn/?action=browsepath=%2F%2Acheckout%2A%2Ftrunk%2Fuser%2Fbusybox%2Fbusybox-1.18.4%2Fdocs%2Fmdev.txt and I think the script might need an mdev -s line. Still a conjecture, no guarantees it will work, but if such line does not exist in your init script, won't hurt to try... Rgds,
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6
On Wed, Mar 14, 2012 at 5:59 PM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Mar 14, 2012 at 04:09:33PM -0600, Canek Pel??ez Vald??s wrote You could use an use-expand variable, like INPUT_DEVICES or VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds like the smart thing to do. The VIDEO_CARDS variable might be RADEON, but there are many different levels of Radeon GPU cards, each requiring its own specific binary blob. I meant coming up with a new use-expand variable, like RADEON_FIRMWARE or something like that. 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] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 05:56:34PM +, Stroller wrote I'm assuming, then, that you're happy opening a terminal and typing `mkdir /mnt/diskname` and mounting the device every time you plug a new disk in? Wouldn't it just be nice to plug in your USB devices - hard-drives and flash drives - and have them magically appear on the desktop like they do on every other desktop operating system? ...and auto-execute an INI file that loads a virus, or Sony rootkit? No thanks. BTW, even with mdev, a bunch of stuff gets spit out to /var/log/messages. The last line was... Mar 14 20:17:42 localhost kernel: [512417.398747] sd 7:0:0:0: [sdb] Attached SCSI removable disk This is probably what userspace automounters work with (directly or indirectly). -- Walter Dnes waltd...@waltdnes.org
[gentoo-user] Improvements for mdev-as-udev-replacement procedure
This reference I found: http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:mdev Can someone look into it? It seems that uclinux defaults to using mdev instead of udev, and the page provides interesting ... things we can try, e.g., mdev -s, plug/unplug helper script, etc. Rgds,
[gentoo-user] Xorg on HP Pavilion ZE2026ea
Hello, my neighbor gave me the notebook. First, I installed Sabayon, as a test. Now i has installed direct Gentoo and the Xorg.Server. When i run Xorg -configure and test the config i become error messages. No Screen found and No devices detected. On the system run a gen Kernel, because i not know what is in it. lspci 00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 02:09.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller 02:09.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller /lspci The xorg.log found on http://pastie.org/3597633. Has someone a idea what can do? Thx for help. Regards Silvio
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Wed, Mar 14, 2012 at 06:15:03PM -0400, Mike Edenfield wrote Every machine I run Linux on is a huge desktop system running behemoth software (Eclipse, GNOME, Chromium, LibreOffice, etc.). I have Abiword, Gimp, Gnumeric, Firefox, etc, running just fine, thank you, on ICEWM. He seems to be producing a rather vitriolic, and IMO uncalled-for, rant against the simple fact that computers do more stuff in 2012 than they did in 1972 and the udev developers are changing with the times. This argument falls flat when the author fails to identify what he or she considers to be critical vs. non-critical software. Is bluetoothd critical? On my laptop it is not. On my main development workstation it is not. On my wife's desktop it is because she has a Bluetooth keyboard/mouse combination. Should bluetoothd be moved from /usr/sbin to /sbin? Along with libglib and libdbus, which it depends on? How about usbmuxd, or alsactl? *YOUR WIFE'S LAPTOP* won't boot properly without /usr on /, or an initramfs. OK, put /usr on /, or an initramfs *ON YOUR WIFE'S LAPTOP*. I don't have a problem with that. What gets people really upset is the dog-in-the-manger attitude of if my complex/corner-case machine won't boot up without /usr on /, or an initramfs, then by golly *NOBODY'S* machine will be allowed to boot up without /usr on /, or an initramfs. My machine does not use bluetooth/other-weird-stuff. udev doesn't need to find bluetooth drivers on /usr on my machine. Why is udev being deliberately broken to not work on *EVERYBODY'S* machine if they don't have /usr on /, or an initramfs? -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] mdev: Has anybody managed to get the keyboard and mouse to work under X?
On Wed, Mar 14, 2012 at 03:20:48PM +, Alan Mackenzie wrote Hi, Gentoo. As I've said a few times in the current threads, the only thing preventing me from moving fully onto mdev is not having a working keyboard and mouse (evdev??) under X. Has anybody else tried this, and if so, what results have you had? I begin my USE variable with -* and add only the necessary stuff. If you want to run X without udev, then compile xorg-server with USE=-udev. I don't have evdev installed at all. I've run X without an xorg.conf. The only reason I have an xorg.conf now is to allow xrandr to force a weird 1536x864 video mode on my 1920x1080 monitor when watching one specific website. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] mdev: Has anybody managed to get the keyboard and mouse to work under X?
On Mar 15, 2012 8:19 AM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Mar 14, 2012 at 03:20:48PM +, Alan Mackenzie wrote Hi, Gentoo. As I've said a few times in the current threads, the only thing preventing me from moving fully onto mdev is not having a working keyboard and mouse (evdev??) under X. Has anybody else tried this, and if so, what results have you had? I begin my USE variable with -* and add only the necessary stuff. If you want to run X without udev, then compile xorg-server with USE=-udev. I don't have evdev installed at all. I've run X without an xorg.conf. The only reason I have an xorg.conf now is to allow xrandr to force a weird 1536x864 video mode on my 1920x1080 monitor when watching one specific website. Of course, needless to say (but I'll say it anyway), when you re-emerge X, you should re-emerge X drivers. Rgds,
Re: [gentoo-user] suspend/hibernate and genkernel.
On Wed, Mar 14, 2012 at 8:43 AM, William Kenworthy bi...@iinet.net.au wrote: I am trying to get my system(s) ready for the new (read crappy) way mandated by udev and am having some issues. I usually manually compile my kernels, use tuxonice and dont use an initrd/initramfs. As ToI is not available for the latest kernels, I updated openrc and installed genkernel but then found I couldnt use in-kernel suspend to disk - googling implies that genkernel doesnt support suspend/hibernate but there are various kludges to get it to work. So whats the least invasive, but workable kludge? hibernate, pmhibernate, swsuspend, uswsuspend, ... Are there any (up to date) docs? BillK Hibernate/suspend works for me like a charm using hibernate script with gentoo-sources genkernel 3.4.24 (~amd64 system). But it's a desktop not a laptop. -- Nilesh Govindarajan http://nileshgr.com
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
Walter Dnes wrote: On Wed, Mar 14, 2012 at 06:15:03PM -0400, Mike Edenfield wrote Every machine I run Linux on is a huge desktop system running behemoth software (Eclipse, GNOME, Chromium, LibreOffice, etc.). I have Abiword, Gimp, Gnumeric, Firefox, etc, running just fine, thank you, on ICEWM. He seems to be producing a rather vitriolic, and IMO uncalled-for, rant against the simple fact that computers do more stuff in 2012 than they did in 1972 and the udev developers are changing with the times. This argument falls flat when the author fails to identify what he or she considers to be critical vs. non-critical software. Is bluetoothd critical? On my laptop it is not. On my main development workstation it is not. On my wife's desktop it is because she has a Bluetooth keyboard/mouse combination. Should bluetoothd be moved from /usr/sbin to /sbin? Along with libglib and libdbus, which it depends on? How about usbmuxd, or alsactl? *YOUR WIFE'S LAPTOP* won't boot properly without /usr on /, or an initramfs. OK, put /usr on /, or an initramfs *ON YOUR WIFE'S LAPTOP*. I don't have a problem with that. What gets people really upset is the dog-in-the-manger attitude of if my complex/corner-case machine won't boot up without /usr on /, or an initramfs, then by golly *NOBODY'S* machine will be allowed to boot up without /usr on /, or an initramfs. My machine does not use bluetooth/other-weird-stuff. udev doesn't need to find bluetooth drivers on /usr on my machine. Why is udev being deliberately broken to not work on *EVERYBODY'S* machine if they don't have /usr on /, or an initramfs? This has been one of my points too. I could go out and buy me a bluetooth mouse/keyboard but I don't because it to complicates matters. Does my BIOS see these devices so that I can access BIOS, you know, press del to enter setup. I have a desktop computer but I use PS/2 connections. Why? It always works even with the BIOS and grub. I might also add, if my keyboard gets further away than my keyboard cable, I can't exactly use the computer since I can't see the monitor any more, not and read anything anyway. I may end up with a init thingy, which I am currently using. Thing is, the first time it breaks and I can't fix it, I'll install something else. I chose Gentoo because I could build a system that has a SIMPLE boot process. Turn on power, BIOS does it's thing, grub loads and I make a selection, kernel loads, init starts. Now, I have one more item that has broken for me before when I had a initfs based distro. If I have to have a init thingy, why use Gentoo? It was one reason I left Mandrake and chose Gentoo. Actually, it was a HUGE reason. I don't want to count the number of times I would try to boot my system and the init thingy fail to work. Thing is, it is MUCH easier and faster to install Kubuntu than it is Gentoo and Kubuntu takes care of the init thingy itself. If it breaks, just reinstall. Reinstalling Gentoo takes way to long for that to be a option. Back to my hole. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
[gentoo-user] mdev + xorg + Gnome up and running. :-)
Hi, Gentoo. Yes, I've got Gnome going under mdev. Thanks to Mike Edenfield for the tip about needing to configure things in xorg.conf. Here's how I did it: (i) Rebuild xorg-server without udev. * Insert this line into /etc/package.use: x11-base/xorg-server -udev * build the program with: emerge xorg-server (ii) Configure the keyboard and mouse explicitly in /etc/X11/xorg.conf (or wherever else you keep your xorg.conf). * Edit the two InputDevice sections to look like this. The critical lines are emphasised: Section InputDevice Identifier Keyboard0 Driver evdev -- Option Device /dev/input/event3 -- EndSection Section InputDevice Identifier Mouse0 Driver evdev -- Option Protocol auto Option Device /dev/input/event4 -- Option ZAxisMapping 4 5 6 7 EndSection Here's another section for your instructions, Walter. :-) -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] mdev + xorg + Gnome up and running. :-)
On Mar 15, 2012 11:22 AM, Alan Mackenzie a...@muc.de wrote: Hi, Gentoo. Yes, I've got Gnome going under mdev. Thanks to Mike Edenfield for the tip about needing to configure things in xorg.conf. Here's how I did it: (i) Rebuild xorg-server without udev. * Insert this line into /etc/package.use: x11-base/xorg-server -udev * build the program with: emerge xorg-server (ii) Configure the keyboard and mouse explicitly in /etc/X11/xorg.conf (or wherever else you keep your xorg.conf). * Edit the two InputDevice sections to look like this. The critical lines are emphasised: Section InputDevice Identifier Keyboard0 Driver evdev -- Option Device /dev/input/event3 -- EndSection Section InputDevice Identifier Mouse0 Driver evdev -- Option Protocol auto Option Device /dev/input/event4 -- Option ZAxisMapping 4 5 6 7 EndSection Here's another section for your instructions, Walter. :-) Great news! :-D What about LVM2 automounting? Rgds,
