Re: [gentoo-user] dhcpd always shows "crashed" even though it's running
On 9/4/2015 3:06 AM, Mick wrote: You can increase its verbosity in /etc/init.d/dhcpcd, so that the logs show more of what is happening to cause the crash. Also, here at least, I have /run/dhcpcd/ with its subdirectories as well as /run/dhcpcd-enp11s0.pid both owned by root:root, but this is a laptop and the dhcpcd is launched by ifplugd. This isn't dhcpcd (the client), it's dhcpd (the server), and the problem is, it's *not* crashing. It's running fine, and the service logs have nothing unusual in them. It's only rc-status that seems to be confused. --Mike
Re: [gentoo-user] dhcpd always shows "crashed" even though it's running
On 9/3/2015 8:59 PM, Fernando Rodriguez wrote: On Thursday, September 03, 2015 8:09:02 PM Mike Edenfield wrote: What makes rc-status think something is crashed, and how can I fix this? basement log # rc-status -v | grep crashed dhcpd [ crashed ] basement log # ps aux | grep dhcpd root 2214 0.0 0.0 8268 876 pts/0S+ 19:47 0:00 grep --colour=auto dhcpd dhcp 2648 0.0 0.6 30028 12136 ?Ss Aug29 0:00 /usr/sbin/dhcpd -cf /etc/dhcp/dhcpd.conf -q -pf /var/run/dhcp/dhcpd.pid -lf /var/lib/dhcp/dhcpd.leases -user dhcp -group dhcp -chroot /chroot/dhcp enp0s7 This is just a guess but it could be the permissions on the pid file on /chroot/dhcp/var/run/dhcp/. So stop the daemon, delete the file, check that the directory is owned by dhcp:dhcp and start the daemon again. That was a good guess -- I did find something else unrelated wrong with the log file permissions :) But it didn't help here. The directory is owned by dhcp:dhcp, and when I stop the service, the pid file is deleted automatically, which I assume means the permissions are correct: basement log # dir /chroot/dhcp/var/run/dhcp total 8 drwxr-xr-x 2 dhcp dhcp 4096 Sep 4 07:21 ./ drwxr-xr-x 3 root root 4096 Oct 4 2009 ../ basement log # /etc/init.d/dhcpd start * Starting chrooted dhcpd ... [ ok ] basement log # dir /chroot/dhcp/var/run/dhcp total 12 drwxr-xr-x 2 dhcp dhcp 4096 Sep 4 07:21 ./ drwxr-xr-x 3 root root 4096 Oct 4 2009 ../ -rw-r--r-- 1 root root6 Sep 4 07:21 dhcpd.pid basement log # rc-status -v | grep crashed dhcpd [ crashed ] Also, just for reference, I already tried "zap"; that didn't help because "stop" puts it correctly into the stopped state anyway. --Mike
[gentoo-user] dhcpd always shows "crashed" even though it's running
For some reason, whenever I check the status of my startup scripts, dhcpd registers as "crashed". However, dhcpd is up and running and working fine. Normally I don't worry about it, but on those occasions where dhcpd does stop working, it's hard to tell if it's "fixed" or not. What makes rc-status think something is crashed, and how can I fix this? basement log # rc-status -v | grep crashed dhcpd [ crashed ] basement log # ps aux | grep dhcpd root 2214 0.0 0.0 8268 876 pts/0S+ 19:47 0:00 grep --colour=auto dhcpd dhcp 2648 0.0 0.6 30028 12136 ?Ss Aug29 0:00 /usr/sbin/dhcpd -cf /etc/dhcp/dhcpd.conf -q -pf /var/run/dhcp/dhcpd.pid -lf /var/lib/dhcp/dhcpd.leases -user dhcp -group dhcp -chroot /chroot/dhcp enp0s7
Re: [gentoo-user] Boot up error messages. Init thingy needed now??
On 2/8/2015 10:35 AM, Dale wrote: would build correctly, both compile and create the init thingy. So, I now have a couple kernels that have a init thingy, testing with that, Has anyone ever pointed out that init thingy actually takes more effort to type than initramfs or initrd?
RE: [gentoo-user] Re: unix philosophy question for old farts: the original purpose for /tmp ?
From: Alan McKinnon [mailto:alan.mckin...@gmail.com] Sent: Tuesday, December 16, 2014 2:46 PM On 16/12/2014 20:05, walt wrote: On 12/15/2014 11:17 PM, Alan McKinnon wrote: /tmp is still very much in use and very much needed, it isn't going anywhere soon. The FHS has something interesting to say about /tmp, along the lines of: A general use scratch pad area where files written are not expected to survive successive invocations of the program that wrote them. That's interesting as it means the sysadmin can delete everything in /tmp at any time for any reason, bofh can delete them for no reason at all while you're still using them :) Exactly :-) And as long as the app doesn't close the file descriptor, everything will continue to work just fine. I used to do this for fun about once a week or so on a many multiuser host, then tell users to tell upstream to fix the stupid bugs in any apps that broke. I've calmed down since then, must have something to do with the onset of senility... I used to do this myself every so often, in a fit of hard drive neatness OCD. Then I discovered that ssh-agent decided that a good default place to put its domain socket was /tmp/ssh-XX and deleting it breaks ssh key forwarding, among other things :\ --Mike
RE: [gentoo-user] Intermittent USB device failures
From: Volker Armin Hemmann [mailto:volkerar...@googlemail.com] Sent: Monday, August 25, 2014 11:59 AM Am 22.08.2014 um 02:05 schrieb Mike Edenfield: From: Volker Armin Hemmann [mailto:volkerar...@googlemail.com] Sent: Thursday, August 21, 2014 12:41 PM you said you used 6 different kernel versions - which one? Did you use vanilla or gentoo sources? And... maybe config? I've used all gentoo-sources so far, but I can give vanilla a try. According to my portage logs, I've installed: sys-kernel/gentoo-sources-3.10.17 sys-kernel/gentoo-sources-3.12.6 sys-kernel/gentoo-sources-3.12.7 sys-kernel/gentoo-sources-3.12.8 sys-kernel/gentoo-sources-3.13.1 sys-kernel/gentoo-sources-3.13.2 sys-kernel/gentoo-sources-3.14.1 sys-kernel/gentoo-sources-3.14.5-r1 sys-kernel/gentoo-sources-3.16.0 I think I may have skipped a couple of the minor revisions in there but that's about the right range of versions I've tried since I started. Dumb question: are you really sure you booted the different kernels - and not just installing the kernel sources and maybe some make'ing (Yeah, I'm confident that I booted these different versions; I installed and reconfigured grub and booted them as soon as I saw them in portage just in case they had fixed a bug I was hitting.) Also: if you have a problem that might be kernel related: always(!) try vanilla sources first. The bug might go away - and if it does not go away, you can go straight to lkml. This actually seems to have helped. When I switched over to the vanilla sources, I was able to use the machine for a lot longer than usual before something bad happened, and the new problem seems unrelated to the mouse/keyboard. At least, the machine is locking up completely, not just the mouse or keyboard, which I guess is progress? I'll probably be back later for help on that one. --Mike
RE: [gentoo-user] Intermittent USB device failures
From: Volker Armin Hemmann [mailto:volkerar...@googlemail.com] Sent: Thursday, August 21, 2014 12:41 PM you said you used 6 different kernel versions - which one? Did you use vanilla or gentoo sources? And... maybe config? I've used all gentoo-sources so far, but I can give vanilla a try. According to my portage logs, I've installed: sys-kernel/gentoo-sources-3.10.17 sys-kernel/gentoo-sources-3.12.6 sys-kernel/gentoo-sources-3.12.7 sys-kernel/gentoo-sources-3.12.8 sys-kernel/gentoo-sources-3.13.1 sys-kernel/gentoo-sources-3.13.2 sys-kernel/gentoo-sources-3.14.1 sys-kernel/gentoo-sources-3.14.5-r1 sys-kernel/gentoo-sources-3.16.0 I think I may have skipped a couple of the minor revisions in there but that's about the right range of versions I've tried since I started. Config for the latest working kernel (3.16.0 with OHCI EHCI) is: http://pastebin.com/PrgwNZYH Thanks, --Mike
RE: [gentoo-user] Intermittent USB device failures
(BTW: I'm terribly sorry for the horrid formatting and duplicate mails; I'm stuck using Outlook until I get this resolved) From: Volker Armin Hemmann [mailto:volkerar...@googlemail.com] Sent: Wednesday, August 20, 2014 12:55 PM Am 20.08.2014 um 02:28 schrieb Mike Edenfield: From: Volker Armin Hemmann [mailto:volkerar...@googlemail.com] Sent: Monday, August 18, 2014 8:01 PM Am 17.08.2014 um 12:33 schrieb Mick: On Sunday 17 Aug 2014 02:56:58 Mike Edenfield wrote: If I try to do the same thing after the mouse has locked up, modprobe stalls trying to unload the first module: wombat kutulu # modprobe -r -v ohci_pci rmmod ohci_pci wombat kutulu # dmesg [38091.627389] ohci-pci :00:0b.0: remove, state 1 [38091.627400] usb usb2: USB disconnect, device number 1 Do you need ohci-pci? Have you tried running a kernel without it and check if your hardware still works as intended? I would try that too,,, I booted a kernel without ohci-pci and no, it doesn't quite work, though I'm pretty confused by it. With OHCI removed from my kernel, neither my mouse nor my keyboard register as attached, but it doesn't seem to matter which ports I put them in. I have 6 USB ports, 2 pair on the motherboard and a third pair in the front of the case, and I expected that the back four would be OCHI and the front two EHCI (or something similr), but they don't seem to follow that pattern. Anywhere I plug my flash drive or camera in, it gets routed through the ECHI controller, while anywhere I plug my keyboard or mouse in gets routed through the OHCI controller. For example, I have my keyword and a flash drive plugged into the two front-mounted ports, and when I boot, I get this: Is that normal? well, today almost all usb controllers 'decide' what to use depending on the device plugged in. There are no dedicated 1.1 or 2.0 ports. And yes, not able to see the devices without ohci might be the norm. Do you have the problems with all ports? Yes, I've tried the mouse and keyboard in all 6 ports and haven’t seen any significant change in behavior. --Mike
RE: [gentoo-user] Intermittent USB device failures
From: Volker Armin Hemmann [mailto:volkerar...@googlemail.com] Sent: Monday, August 18, 2014 8:01 PM Am 17.08.2014 um 12:33 schrieb Mick: On Sunday 17 Aug 2014 02:56:58 Mike Edenfield wrote: When I `modprobe -r ochi_pci` while the system is operating normally, I see all four modules (ohci-pci, ohci-hcd, ehci-pci, and ehci-hcd) unloading properly: [25603.37] ohci-pci :00:0b.0: remove, state 1 [25603.370395] usb usb2: USB disconnect, device number 1 [25603.370414] usb 2-6: USB disconnect, device number 2 [25603.383451] usb 2-7: USB disconnect, device number 3 [25603.384217] ohci-pci :00:0b.0: USB bus 2 deregistered [25603.384597] ehci-pci :00:0b.1: remove, state 1 [25603.384611] usb usb1: USB disconnect, device number 1 [25603.386306] ehci-pci :00:0b.1: USB bus 1 deregistered If I try to do the same thing after the mouse has locked up, modprobe stalls trying to unload the first module: wombat kutulu # modprobe -r -v ohci_pci rmmod ohci_pci wombat kutulu # dmesg [38091.627389] ohci-pci :00:0b.0: remove, state 1 [38091.627400] usb usb2: USB disconnect, device number 1 Any ideas what's going wrong here? Any chance I can salvage this hardware? Do you need ohci-pci? Have you tried running a kernel without it and check if your hardware still works as intended? I would try that too,,, From: Volker Armin Hemmann [mailto:volkerar...@googlemail.com] Sent: Monday, August 18, 2014 8:01 PM Am 17.08.2014 um 12:33 schrieb Mick: On Sunday 17 Aug 2014 02:56:58 Mike Edenfield wrote: When I `modprobe -r ochi_pci` while the system is operating normally, I see all four modules (ohci-pci, ohci-hcd, ehci-pci, and ehci-hcd) unloading properly: [25603.37] ohci-pci :00:0b.0: remove, state 1 [25603.370395] usb usb2: USB disconnect, device number 1 [25603.370414] usb 2-6: USB disconnect, device number 2 [25603.383451] usb 2-7: USB disconnect, device number 3 [25603.384217] ohci-pci :00:0b.0: USB bus 2 deregistered [25603.384597] ehci-pci :00:0b.1: remove, state 1 [25603.384611] usb usb1: USB disconnect, device number 1 [25603.386306] ehci-pci :00:0b.1: USB bus 1 deregistered If I try to do the same thing after the mouse has locked up, modprobe stalls trying to unload the first module: wombat kutulu # modprobe -r -v ohci_pci rmmod ohci_pci wombat kutulu # dmesg [38091.627389] ohci-pci :00:0b.0: remove, state 1 [38091.627400] usb usb2: USB disconnect, device number 1 Any ideas what's going wrong here? Any chance I can salvage this hardware? Do you need ohci-pci? Have you tried running a kernel without it and check if your hardware still works as intended? I would try that too,,, I booted a kernel without ohci-pci and no, it doesn't quite work, though I'm pretty confused by it. With OHCI removed from my kernel, neither my mouse nor my keyboard register as attached, but it doesn't seem to matter which ports I put them in. I have 6 USB ports, 2 pair on the motherboard and a third pair in the front of the case, and I expected that the back four would be OCHI and the front two EHCI (or something similr), but they don't seem to follow that pattern. Anywhere I plug my flash drive or camera in, it gets routed through the ECHI controller, while anywhere I plug my keyboard or mouse in gets routed through the OHCI controller. For example, I have my keyword and a flash drive plugged into the two front-mounted ports, and when I boot, I get this: With OHCI: kutulu@wombat ~ $ dmesg | grep usb [0.074276] usbcore: registered new interface driver usbfs [0.074460] usbcore: registered new interface driver hub [0.074658] usbcore: registered new device driver usb [0.245705] usbcore: registered new interface driver usbhid [0.245879] usbhid: USB HID core driver [7.420249] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [7.420426] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [7.420735] usb usb1: Product: EHCI Host Controller [7.420908] usb usb1: Manufacturer: Linux 3.16.0-gentoo-wombat-3 ehci_hcd [7.421089] usb usb1: SerialNumber: :00:0b.1 [7.631143] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 [7.631328] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [7.631618] usb usb2: Product: OHCI PCI host controller [7.631789] usb usb2: Manufacturer: Linux 3.16.0-gentoo-wombat-3 ohci_hcd [7.631964] usb usb2: SerialNumber: :00:0b.0 [7.753477] usb 1-7: new high-speed USB device number 2 using ehci-pci [7.968033] usb 1-7: New USB device found, idVendor=14cd, idProduct=6500 [7.968179] usb 1-7: New USB device strings: Mfr=1, Product=3, SerialNumber=2 [7.968312] usb 1-7: Product: USB 2.0 Flash drive [7.968442] usb 1-7: Manufacturer: MOAI INC. [7.968568] usb 1-7: SerialNumber: 4FD30F4B00C5 [8.165667] usb-storage 1-7:1.0: USB
RE: [gentoo-user] Intermittent USB device failures
From: Volker Armin Hemmann [mailto:volkerar...@googlemail.com] Sent: Friday, August 15, 2014 7:53 PM Am 14.08.2014 um 03:52 schrieb Mike Edenfield: I've recently taken an old Windows XP system and rebuilt it to run Gentoo. Since then, I've been having issues using any type of USB input device (which is particularly bad, since it has no PS/2 input ports). After some indeterminate period of time, the input device simply stops responding. Typically, I can use the console for a few days at a time before the keyboard dies, but if I load up a GUI and start using the mouse it takes less than a few hours. I'm fairly sure this problem is USB-related, since I believe I've eliminated everything downstream of that: I've tried using both evdev and legacy mouse and keyboard drivers in both the kernel and X and all of them work the same way. evtest shows no activity from the device once it breaks, nor do the legacy /dev driver files. Most notably, removing and re-plugging the device doesn't register as a device attachment. If, for example, I take a working USB mouse and swap USB ports, I get this: [ 1219.418050] usb 2-8: USB disconnect, device number 3 [ 1225.258011] usb 2-7: new low-speed USB device number 4 using ohci- pci [ 1225.449627] usb 2-7: New USB device found, idVendor=046d, idProduct=c044 [ 1225.449946] usb 2-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1225.450240] usb 2-7: Product: USB-PS/2 Optical Mouse [ 1225.450740] usb 2-7: Manufacturer: Logitech [ 1225.464165] input: Logitech USB-PS/2 Optical Mouse as /devices/pci:00/:00:0b.0/usb2/2-7/2-7:1.0/input/input6 [ 1225.464666] hid-generic 0003:046D:C044.0003: input,hidraw1: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:0b.0-7/input0 If I do the same thing after the device has stopped functioning, I get the disconnect message but that's it: [199729.451060] i2c i2c-3: sendbytes: NAK bailout. [199733.215303] usb 2-7: USB disconnect, device number 4 [199814.495204] type=1006 audit(1394381639.494:3): pid=5861 uid=0 old auid=4294967295 new auid=1000 old ses=4294967295 new ses=2 res=1 you can use the power button + acpid to reload the usb modules (I hope you have usb support as modules and not built into the kernel) and see what happens next time usb acts up. Thanks for the suggestion! Fortunately network access to the machine works fine even with the USB down, so I was able to log in and unload/reload the USB modules remotely. When I `modprobe -r ochi_pci` while the system is operating normally, I see all four modules (ohci-pci, ohci-hcd, ehci-pci, and ehci-hcd) unloading properly: [25603.37] ohci-pci :00:0b.0: remove, state 1 [25603.370395] usb usb2: USB disconnect, device number 1 [25603.370414] usb 2-6: USB disconnect, device number 2 [25603.383451] usb 2-7: USB disconnect, device number 3 [25603.384217] ohci-pci :00:0b.0: USB bus 2 deregistered [25603.384597] ehci-pci :00:0b.1: remove, state 1 [25603.384611] usb usb1: USB disconnect, device number 1 [25603.386306] ehci-pci :00:0b.1: USB bus 1 deregistered If I try to do the same thing after the mouse has locked up, modprobe stalls trying to unload the first module: wombat kutulu # modprobe -r -v ohci_pci rmmod ohci_pci wombat kutulu # dmesg [38091.627389] ohci-pci :00:0b.0: remove, state 1 [38091.627400] usb usb2: USB disconnect, device number 1 Any ideas what's going wrong here? Any chance I can salvage this hardware? --Mike
[gentoo-user] Intermittent USB device failures
I've recently taken an old Windows XP system and rebuilt it to run Gentoo. Since then, I've been having issues using any type of USB input device (which is particularly bad, since it has no PS/2 input ports). After some indeterminate period of time, the input device simply stops responding. Typically, I can use the console for a few days at a time before the keyboard dies, but if I load up a GUI and start using the mouse it takes less than a few hours. I'm fairly sure this problem is USB-related, since I believe I've eliminated everything downstream of that: I've tried using both evdev and legacy mouse and keyboard drivers in both the kernel and X and all of them work the same way. evtest shows no activity from the device once it breaks, nor do the legacy /dev driver files. Most notably, removing and re-plugging the device doesn't register as a device attachment. If, for example, I take a working USB mouse and swap USB ports, I get this: [ 1219.418050] usb 2-8: USB disconnect, device number 3 [ 1225.258011] usb 2-7: new low-speed USB device number 4 using ohci-pci [ 1225.449627] usb 2-7: New USB device found, idVendor=046d, idProduct=c044 [ 1225.449946] usb 2-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1225.450240] usb 2-7: Product: USB-PS/2 Optical Mouse [ 1225.450740] usb 2-7: Manufacturer: Logitech [ 1225.464165] input: Logitech USB-PS/2 Optical Mouse as /devices/pci:00/:00:0b.0/usb2/2-7/2-7:1.0/input/input6 [ 1225.464666] hid-generic 0003:046D:C044.0003: input,hidraw1: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:0b.0-7/input0 If I do the same thing after the device has stopped functioning, I get the disconnect message but that's it: [199729.451060] i2c i2c-3: sendbytes: NAK bailout. [199733.215303] usb 2-7: USB disconnect, device number 4 [199814.495204] type=1006 audit(1394381639.494:3): pid=5861 uid=0 old auid=4294967295 new auid=1000 old ses=4294967295 new ses=2 res=1 (the i2c errors, I believe, are unrelated; they seem to be caused by the nouveau driver I'm using). I've gone through at least 6 different kernel versions and they all exhibit this same behavior. At this point I'm not even sure what else I can do to troubleshoot this problem, so any advice would be appreciated! Thanks, --Mike
RE: [gentoo-user] openpty() failing with UNIX98 ptys
-Original Message- From: Peter Humphrey [mailto:pe...@humphrey.ukfsn.org] Sent: Sunday, January 27, 2013 9:51 PM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] openpty() failing with UNIX98 ptys On Sunday 27 January 2013 04:46:22 Mike Edenfield wrote: At some point recently, one of my systems has begun having problems allocating pseudo-terminals via the UNIX98 pty scheme. I am using the same kernel configuration I've had for years, and running the latest ~amd64 version of all the relevant packages. The problem manifests itself on any program that attempts to allocate a pseudo-terminal, including portage and openssh. I first noticed the problem when I could no longer ssh into the server because it would not allocate a pty. I have the latest udev installed, and udev-mount is running on boot. Both /dev and /dev/pts are mounted, and /dev/ptmx exists and is world-readable: What does 'grep devtmpfs /etc/fstab' reveal? (Long shot - I misread the latest news article and changed one of the tmpfs fields to devtmpfs and got similar results to what you describe.) I don't have any devtmpfs in my /etc/fstab; I think I removed a lot of pseudo-mount points a while back when I added udev-mount to my runlevel. --Mike
RE: [gentoo-user] openpty() failing with UNIX98 ptys
From: Alan McKinnon [mailto:alan.mckin...@gmail.com] Sent: Sunday, January 27, 2013 1:49 PM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] openpty() failing with UNIX98 ptys On Sat, 26 Jan 2013 23:46:22 -0500 Mike Edenfield kut...@kutulu.org wrote: I have the latest udev installed, and udev-mount is running on boot. Both /dev and /dev/pts are mounted, and /dev/ptmx exists and is world-readable: basement package.use # mount | grep /dev /dev/root on / type ext3 (rw,seclabel,noatime,errors=continue,barrier=1,data=writeback) devpts on /dev/pts type devpts (rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) shm on /dev/shm type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,seclabel,nosuid,relatime,size=10240k,nr_inodes=248584,mode=755) basement package.use # ls -alF /dev/ptmx /dev/pts crw-rw-rw-. 1 root tty 5, 2 Jan 26 13:18 /dev/ptmx /dev/pts: total 0 drwxr-xr-x. 2 root root40 Jan 26 13:18 ./ drwxr-xr-x. 10 root root 13300 Jan 26 13:18 ../ When I trace sshd's attempt to open a new pty, I see it doing this: * open /dev/ptmx * stat /dev/pts * stat /dev * try (and fail) to open /dev/ptyp0 Since I know that last bit is openssh trying to open an old-style BSD pty, I can only assume that something is going wrong trying to allocate the pty the correct way. For the time being I've added BSD pty support into my kernel and everything seems to be working now, but I'm at a loss as to what I did to break things in the first place. I had something similar (details are different though): In my case it's kernel 3.7 - no version of gentoo-sources-3.7-* worked and 3.6.11 works fine. What kernel are you on? Have you tested this on 3.6? I first notice the problem on 3.4.2, upgraded to 3.6.4 and the problem persisted. I have not upgraded to 3.7 to see if it's still a problem. --Mike
[gentoo-user] openpty() failing with UNIX98 ptys
At some point recently, one of my systems has begun having problems allocating pseudo-terminals via the UNIX98 pty scheme. I am using the same kernel configuration I've had for years, and running the latest ~amd64 version of all the relevant packages. The problem manifests itself on any program that attempts to allocate a pseudo-terminal, including portage and openssh. I first noticed the problem when I could no longer ssh into the server because it would not allocate a pty. I have the latest udev installed, and udev-mount is running on boot. Both /dev and /dev/pts are mounted, and /dev/ptmx exists and is world-readable: basement package.use # mount | grep /dev /dev/root on / type ext3 (rw,seclabel,noatime,errors=continue,barrier=1,data=writeback) devpts on /dev/pts type devpts (rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) shm on /dev/shm type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,seclabel,nosuid,relatime,size=10240k,nr_inodes=248584,mode=755) basement package.use # ls -alF /dev/ptmx /dev/pts crw-rw-rw-. 1 root tty 5, 2 Jan 26 13:18 /dev/ptmx /dev/pts: total 0 drwxr-xr-x. 2 root root40 Jan 26 13:18 ./ drwxr-xr-x. 10 root root 13300 Jan 26 13:18 ../ When I trace sshd's attempt to open a new pty, I see it doing this: * open /dev/ptmx * stat /dev/pts * stat /dev * try (and fail) to open /dev/ptyp0 Since I know that last bit is openssh trying to open an old-style BSD pty, I can only assume that something is going wrong trying to allocate the pty the correct way. For the time being I've added BSD pty support into my kernel and everything seems to be working now, but I'm at a loss as to what I did to break things in the first place.
RE: [gentoo-user] Ekopath compiler failing to build - something about glibc development files
On 13 January 2013, at 06:53, Andrew Lowe wrote: ... From all of the above, I think the important part is that I need to install some glibc developement files. A google search doesn't point me in the direction of what these might be. According to eix glibc, I have debug turned OFF - is this the problem? The part about the glibc development [sic] files is mostly a red herring. I'm not sure where it's coming from (I can't find that misspelling of development in the portage source or any eclass, and it's not part of the actual ebuild.) The error happens any time the ekopath installation fails. AFAICT, the ekopath ebuild doesn't really do anything except unpack the tarball and, in the post-install step, run the binary installation program that ships with ekopath. If anything at all happens when the installer is running, you get the same error from portage. What is actually going wrong here is down the bottom: /usr/include/bits/byteswap.h: In function 'unsigned int __bswap_32(unsigned int)': /usr/include/bits/byteswap.h:46: error: '__builtin_bswap32' was not declared in this scope /usr/include/bits/byteswap.h: In function 'long long unsigned int __bswap_64(long long unsigned int)': /usr/include/bits/byteswap.h:110: error: '__builtin_bswap64' was not declared in this scope Last time I saw this is was because a package assumed I had gcc4.3 and I was using an older version, but I highly doubt that's your problem. One thing you can try is to run the installer manually. If you emerge the package and let it fail, all the bits are left in the temporary work folders, so you can do this: cd /var/tmp/portage/dev-lang/ekopath-4.0.12.1_pre20121102/work ./ekopath-4.0.12.1_pre20121102.run --prefix /var/tmp/portage/dev-lang/ekopath-4.0.12.1_pre20121102/image/opt/ekopath and walk through the installation manually. It's an agonizingly slow process but it should work, or give you a better idea of what failed. --Mike
RE: [gentoo-user] Re: Anyone switched to eudev yet?
From: Alan McKinnon [mailto:alan.mckin...@gmail.com] Sent: Thursday, December 27, 2012 6:08 PM On Tue, 25 Dec 2012 10:56:52 +0700 Pandu Poluan pa...@poluan.info wrote: In case you haven't noticed, since Windows 7 (or Vista, forget which) Microsoft has even went the distance of splitting between C: (analogous to /usr) and 'System Partition' (analogous to /). The boot process is actually handled by the 100ish MB 'System Partition' before being handed to C:. This will at least give SysAdmins a fighting chance of recovering a botched maintenance. (Note: Said behavior will only be visible if installing onto a clean hard disk. If there are partitions left over from previous Windows installs, Win7 will not create a separate 'System Partition') So, if Microsoft saw the light, why does Red Hat sunk into darkness instead? I'm not sure about Microsoft's motivations in what you describe. My first reaction is that the Great Circle of IT Life is turning and MS are trying something new for them. Whether it's applicable to us here as an illustration remains to be seen - I know very little about Windows so can't even begin to draw sensible parallels. I know little about the history of UNIX before 1993, and the sum of my experience with Linux is that I have never personally run into any case where I had a single /+/usr and regretted it, but I *have* encountered situations where I could not get /usr mounted and ended up merging it with /. FWIW, YMMV, etc. I can tell you that Pandu's analogy vis a vis Windows is a bit flawed. What Windows has done recently is (by default for clean installs) to split the boot loader and related bootstrap code into a separate partition from the actual operating system. Claiming that this is analogous to / and /usr is quite a stretch. It is much more accurate to make it analogous to / and /boot. The System Partition has no Windows files on it, just the equivalent to grub (and it's also used if you have BitLocker, to decrypt your boot partition). Which, to me, means it has absolutely nothing to do with the current discussion one way or the other :) --Mike
[gentoo-user] courier-imap cannot find courier-authlib
I recently upgraded my courier setup (imap and authlib):
basement lib64 # eix -Ic courier
[I] net-libs/courier-authlib (0.65.0-r1@11/01/2012): Courier authentication
library.
[I] net-mail/courier-imap (4.8.0@11/01/2012): An IMAP daemon designed
specifically for maildirs.
After I was finished, the imap server stopped accepting new connections. I
managed to track the problem down to missing shared libraries from
courier-authlib needed by imaplogin:
basement authlib # ldd /usr/sbin/imaplogin
linux-vdso.so.1 (0x029ae5055000)
libcourierauth.so = not found
libcourierauthsasl.so = not found
libc.so.6 = /lib64/libc.so.6 (0x029ae4a8f000)
/lib64/ld-linux-x86-64.so.2 (0x029ae4e36000)
basement lib64 # strace imaplogin 21 | grep libcourierauth.so
open(/lib64/tls/x86_64/libcourierauth.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
open(/lib64/tls/libcourierauth.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
open(/lib64/x86_64/libcourierauth.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
open(/lib64/libcourierauth.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
open(/usr/lib64/tls/x86_64/libcourierauth.so, O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
open(/usr/lib64/tls/libcourierauth.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
open(/usr/lib64/x86_64/libcourierauth.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
open(/usr/lib64/libcourierauth.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
writev(2, [{imaplogin, 9}, {: , 2}, {error while loading shared
libra..., 36}, {: , 2}, {libcourierauth.so, 17}, {: , 2}, {cannot
open shared object file, 30}, {: , 2}, {No such file or directory, 25},
{\n, 1}], 10imaplogin: error while loading shared libraries:
libcourierauth.so: cannot open shared object file: No such file or directory
The libraries in question are actually present, but apparently not where
imaplogin expects them to be:
basement lib64 # equery files courier-authlib | grep libcourierauth
/usr/lib64/courier-authlib/libcourierauth.so
/usr/lib64/courier-authlib/libcourierauth.so.0
/usr/lib64/courier-authlib/libcourierauthcommon.so
/usr/lib64/courier-authlib/libcourierauthcommon.so.0
/usr/lib64/courier-authlib/libcourierauthsasl.so
/usr/lib64/courier-authlib/libcourierauthsasl.so.0
/usr/lib64/courier-authlib/libcourierauthsaslclient.so
/usr/lib64/courier-authlib/libcourierauthsaslclient.so.0
I've rebuilt both packages and somehow, imaplogin is *building* fine with
the shared library in the wrong place, but refuses to load it at run time.
I have temporarily fixed the problem by symlinking the two missing libraries
into /lib64 but I don't see that as a good long-term solution. I'm really
stumped as to what changed to break things all of the sudden, or how to fix
it.
Is anyone else seeing this problem, or know how to make it go away?
--Mike
RE: [gentoo-user] Python TK
From: Silvio Siefke [mailto:siefke_lis...@web.de] On Thu, 26 Jul 2012 12:36:37 -0400 Michael Mol mike...@gmail.com wrote: Just don't use -march=native when cross-compiling. :) Now i use native. Is there a problem, i know from FreeBSD, there on ML have say me i should use. Using -march=native if you are only building for your local machine is fine. If you plan to use the setup proposed by Neil, and build your packages on a faster machine, *then* you have to be careful not to use -march=native because the compiled programs will be built for the faster native CPU, and may not run on the slower architecture. --Mike
Re: [gentoo-user] convert wmv to mp4?
On 5/1/2012 6:14 PM, Mark Knecht wrote: Sort of painful to start maintaining a 32-bit chroot just to handle this sort of thing. I suspect there's some freeware for the Windows world that might allow me to do the conversion in a VM. I'll start looking for that. The web site that advertised conversion didn't work as it bombed out after an hour. ffmpeg runs on Windows, why not just use that? --Mike
RE: [gentoo-user] Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
From: Michael Mol [mailto:mike...@gmail.com] Sent: Thursday, April 26, 2012 9:54 PM I can no longer ssh into either inara or kaylee. Clearly they are busy fsck'ing /malcom and /simon
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On 4/2/2012 11:12 PM, Dale wrote: Canek Peláez Valdés wrote: Actually, the initramfs finished without a single error: between [1.962007] dracut: + source_conf /etc/conf.d and [2.395576] dracut: Switching root there is not a single error. The initramfs did what it needed to do; the user space failed *after* initramfs switched root. Did you recreated the initramfs after the kernel recompilation? 1st rule of non-trivial initramfs: you need to recreate it everytime you change kernels. Which partition is the LVM one? /home or /data? Either way, either partition should not matter to boot the system correctly. We need to see the errors *after* the initramfs switched root; maybe you can delete /var/log/messages, reboot, and post it? Regards. So the init thingy is going to print all that stuff each time? Or is that the debug stuff you had me add to the grub line? Please say it is so. It's one reason I checked my email. I was counting and realized the debug stuff that was added may haver done all that. Taking a deep breath helped tho. ;-) I still want my hands on that neck tho. lol It was the debug stuff; every line that look like dracut: + stuff here was debugging information; AFAICT dracut mounted /dev/sda3 as root then it mounted the two other partitions it found. But this could be a problem (from your other email): root@fireball / # dracut -H -f /boot/init-thingy E: Dracut module lvm cannot be found. E: Dracut module lvm cannot be found. dracut couldn't find it's lvm module, even though your USE flags are set correctly. Can you try re-emerging dracut with its current USE flags? You should have a folder in /usr/lib/dracut/modules named 'lvm' that has a 'module-setup.sh' script in it, plus probably some other support files, if everything got installed correctly. --Mike
RE: [gentoo-user] Happy 10th birthday (in advance)
From: Jason Weisberger [mailto:jbdu...@gmail.com] Sent: Saturday, March 31, 2012 2:11 PM It would figure that some in the Linux community would consider a sub 1.0 release as the birthday of a project :). You were sub-1.0 when you were born, why not Gentoo? Besides, the 1999 birthday reflects the registration of the gentoo.org domain and thus when the project was officially named Gentoo; otherwise it would have been 10 years old in 2010, not 2009.
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Alan Mackenzie [mailto:a...@muc.de] Hi, Mike. On Wed, Mar 28, 2012 at 12:24:14AM -0400, Mike Edenfield wrote: From: Alan Mackenzie [mailto:a...@muc.de] Hi, Alan. On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: On Tue, 27 Mar 2012 21:24:22 + Alan Mackenzie a...@muc.de wrote: Why is nobody else on this thread willing to take up its main point, the exact equivalence between the known, ugly, initramfs solution and the as yet half-baked idea of putting the same binaries into /sbin? Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. (ii) What's more, these two copies are often different, one being built with static libraries, the other with dynamic ones. (iii) This situation is not (as far as I know) yet handled by Portage, which means in building such software statically, you've got to save the dynamic version somewhere else whilst you're doing it. (iv) The initramfs requires a potentially long script to make it work. My idea was for /sbin to vanish from $PATH just as soon as the boot had been completed; PATH gets set anyway on the initialisation of something or other, so this would happen automatically, just like the initramfs disappears when the switch_root is done. The criticisms you made about an initramfs are valid, and your basic point is correct: the ugliness of having a shadow /sbin is no worse than the ugliness of an initramfs. I admit that much of my criticism here is not of the idea but of trying to come up with a working implementation. The major benefit of an initramfs solution is that it fits into the existing Linux boot process with minimal impact: all of the ugliness you pointed out vanishes as soon as it has completed its work, and the existing /sbin/init startup code is launched exactly as it would be without an initramfs. Your process would require either changing that existing /sbin/init process, or changing the steps the kernel takes on startup, in ways that I can't articulate because I haven't gone through the exercise of making it work. Taking /sbin out of the path, though works for me. As I understand it, /sbin *used* to be for static binaries, and only later did it retroactively become system binaries, which is silly. That's what DAC is for. The only benefit of a separate /bin and /sbin is to have different binaries with the same name in both places, which is just begging for trouble. Your approach actually seems to be bringing /sbin back to its roots. :) I can think of a few useful options, though; perhaps what you're calling /sbin is actually /boot/bin; like now, /boot is rarely mounted once the live system comes up. Perhaps the kernel is configured to look for and run a /boot/bin/init before it tries to mount it's rootfs. You are basically replicating the initramfs solution, just on the boot partition, as this is almost exactly what happens now. Alternatively, perhaps /sbin/init can get smarter; much of this problems with getting /usr mounted at the right time stems from difficulties in expressing the required order and dependency information in the init scripts. If /sbin/init could be explicitly told this is the 'mount my /usr' script and knew to run it or not, based on the existence of a /usr mount point, that could happen very early in the boot process. [ more criticism, a lot of which I accept. ] I think I have the elegant solution: that would be for the kernel to be able to mount several partitions at system initialisation rather than just the root partition. With this, all the issues we've been discussing simply wouldn't arise. That's one possible solution; I think there are several places where the kernel could potentially be made smarter about what is going on in the userland environment; for example, if udev always received block device events first, *it* could be tasked with mounting /usr when it saw that /dev/sda3 was available and in /etc/fstab, then it could happily run alsaconf or bluetoothd or whatever else when those devices popped up. I also admit I don't really understand autofs too much, but it seems like automounter support should be able to do something like this as well. Keep in mind, though, that the point of an initramfs is not to get /usr mounted. It's to get / mounted; if your rootfs happens to be on some hardware, network, or logical block device that needs special handling before it can be used, you need *somewhere* to put those utilities that the kernel can find them. The fact that you can also use an initramfs for all of these other pre-init steps is just added benefit. --Mike
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Dale [mailto:rdalek1...@gmail.com] I had to reboot so I made a new init thingy with the -H switch. It works in Console but nothing root works in KDE. I get the same error. Heck, Konsole won't even try to come up much less ask for my password. Krusader asks for password and says that su is not in the path. This is similar to what I got when I was in a Console too. It sounds like your path might be getting messed up. What are the output/results of the following commands: $ which su $ echo $PATH $ su - For each of the following: logged in to a normal virtual console as root, logged in to a normal virtual console as a normal user, and running Konsole as a standard user when logged in via KDM? --Mike
RE: [gentoo-user] Re: InitRAMFS - boot expert sought
From: Alan McKinnon [mailto:alan.mckin...@gmail.com] OK, semantics. Let me re-phrase: Why is a third party script, running in the context of the udev universe, indiscriminately allowed to launch daemons at early boot time? I don't think I agree with Neil in that this is a udev design flaw (as any fix will be worse than the flaw). Instead it looks to me like a classic case of You are free to do anything you want but if you break it you keep the pieces. If you do something stupid, it's not my problem and you're on your own. This is, unfortunately, the biggest drawback to having a commercial entity in charge of doing the software development: this kind of attitude stops applying. Gentoo's developers, for example, would really like for people to use Gentoo, and work hard to make Gentoo useable, but if you start with the threats of I'm gonna stop using your OS unless you fix this RIGHT NOW! they'll probably just roll their eyes and ignore you. RedHat has a *commercial* interest in people using RedHat, even the non-commercial versions, and if their *customers* start filing bugs like I cannot make my Bluetooth keyboard work with my nfs mounted /usr that plays a ring tone through alsa when I mount it, they are much more motivated to fix it. I see nothing wrong with udev applying some reasonable constraints such as clearly documenting at what point in the boot process udev is in a position to arbitrarily run anything. Earlier than that point, anything does not actually apply. I don't think it's a design flaw, as much as it's a possible point of improvement for udev. It would be useful if udev could somehow distinguish between early and late devices. This doesn't eliminate the problem entirely: nothing is stopping you from, say, telling udev that mounting /usr requires /usr/mountme. But if you did something that silly, it would obviously be your fault. I think there are some options for how udev could be better here, it's just that they all seem to be a lot of risk; as much risk or more as just saying don't do that or use an initramfs. Off the top of my head: * udev could enforce that point you mention, and allow device scripts to explicitly say defer trying to configure me until after $KEYPOINT has been reached. * udev could keep track of dependencies between devices or device scripts and allow one to say don't run me until $DEVICE is also present * udev could keep track of prerequisite triggers for device scripts, and allow one to say don't run me until /usr/bin/alsaconf exists, but run me as soon as that appears. * udev could keep track of failed devices, and include a command-line switch like --reprocess; the init process could launch udev, allow whatever fails to fail, mount /usr, then tell udev to try again. As I understand it, the architecture of udev (and the kernel) makes many of these difficult; udev events are processed individually, isolated from each other. It has no concept of things like when I'm done configuring devices or devices that are waiting to be configured after this one. Though keeping track of failed devices seems like it would not be terribly difficult, as long as you could distinguish btween devices that are fatal failures vs. transient ones. Again, I'm not faulting the udev team for not doing those things. They either do a lot of work to update the behavior of udev to support a configuration they think is invalid and broken, or they simply tell people to stop using the invalid or broken configuration. If there were a clear consensus that the configuration was not, in fact, broken, then I could possibly see where they might be expected (from a /community/ perspective, clearly they have no /formal/ obligations to any of us) to put in that effort. But the consensus seems largely weighted towards agreeing with them, or at least not caring either way. --Mike
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Neil Bothwick [mailto:n...@digimed.co.uk] Sent: Thursday, March 29, 2012 8:04 PM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs? On Thu, 29 Mar 2012 14:35:36 -0400, Michael Mol wrote: Don't forget boot-time X-based animation, too. That's an extraordinarily common feature of mainstream desktop distributions. And there will be other things, I'm sure. I don't get involved with those, but I'd hope something intended to be run so early would have minimal dependencies, if any. There's a pretty firm distinction between what things get used for, and what they're intended for. The udev developers presumably were reacting to this when they decided to support an anything goes policy regarding plugscript behavior. And while I'm generally the kind of person to find unintended (but perfectly compatible with their spec) uses for things, I don't figure on being one to do so in my init sequence. That said, someone else will. I know what you mean, but here we are discussing something being used for its intended purpose. If a bootsplash program is not designed to work well a the start of the boot process, you have to wonder what it will be good for. splashutils, which is the package dracut uses to generate a boot splash image, has a lot of dependencies but requires they all be built USE=static-libs. Plymouth, which does animated boot splash, is a bit worse; it installs a few dozen files, about half of that data. Then again, if you're putting an animated boot splash image on your initramfs, I don't think you're all that worried about space :) --Mike
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Canek Peláez Valdés [mailto:can...@gmail.com] I agree with most of what you say; however, I believe you are mistaken about the static nature of the binaries in the initramfs created by dracut. I use dracut with the whole bang (plymouth, systemd, udev, you name it), and I don't have *any* of my packages compiled with static-libs. Even more, my system right now runs everything with -static-libs. I like to think (and, unless I missed something, that's in fact the truth) that my initramfs is actually more or less in sync with my running system, and I update it a lot, since it's trivial to do so with dracut. You're right, it wasn't plymouth, it was gensplash and crypt that wanted me to add static-libs. It was a USE-flag dependency so I could not proceed with the dracut install until I rebuilt those other packages. plymouth just needed wanted USE=libkms on libdrm.
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Pandu Poluan [mailto:pa...@poluan.info] On Mar 28, 2012 11:27 AM, Mike Edenfield kut...@kutulu.org wrote: Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. Check out the email from William Kenworth in this mailing list; he's having trouble with initramfs being a blackbox. I don't see how you can really call initramfs a 'black box; it's certainly as open, or moreso, as the kernel, or grub, or /sbin/init; it's just a mini-filesystem with its own init: apollo kutulu # lsinitrd /boot/initramfs-3.2.7-hardened-apollo-0.img /boot/initramfs-3.2.7-hardened-apollo-0.img: 2.6M drwxr-xr-x 15 root root0 Mar 28 13:32 . drwxr-xr-x 2 root root0 Mar 28 13:32 dev drwxr-xr-x 2 root root0 Mar 28 13:32 root drwxr-xr-x 2 root root0 Mar 28 13:32 bin -rws--x--x 1 root root 105584 Feb 28 17:46 bin/mount -rwxr-xr-x 1 root root26536 Feb 28 17:46 bin/dmesg -rwxr-xr-x 1 root root30696 Feb 21 17:12 bin/uname -rwxr-xr-x 1 root root34776 Feb 21 17:12 bin/chroot -rwxr-xr-x 1 root root 137624 Mar 27 13:14 bin/dash -rwxr-xr-x 1 root root71640 Feb 21 17:12 bin/stty -rwxr-xr-x 1 root root30680 Feb 21 17:12 bin/basename -rwxr-xr-x 1 root root34776 Feb 21 17:12 bin/mknod lrwxrwxrwx 1 root root4 Mar 28 13:32 bin/sh - dash . . . -rwxr-xr-x 1 root root14176 Feb 28 17:46 sbin/switch_root -rwxr-xr-x 1 root root12622 Feb 15 12:05 init drwxr-xr-x 2 root root0 Mar 28 13:32 tmp drwxr-xr-x 2 root root0 Mar 28 13:32 proc drwxr-xr-x 5 root root0 Mar 28 13:32 lib64
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Alan Mackenzie [mailto:a...@muc.de] Incidentally, dracut says it won't work on a kernel without modules. I don't know if it's true or not. dracut wants you to have loadable module /support/ in your kernel so it can scan for modules needed by the rootfs. The kernel-module support in dracut is just another module; you could omit that module and I believe dracut will carry on fine. Of course, if you have nothing compiled as a module then your initramfs just won't have any modules built into it either way. --Mike
RE: [gentoo-user] InitRAMFS - boot expert sought
From: Neil Bothwick [mailto:n...@digimed.co.uk] On Tue, 27 Mar 2012 18:50:04 -0500, Dale wrote: So throw out my plans and just do it their way? In that case, I may as well use Fedora since it sort of started there. Maybe that is what they wanted and planned. According to Greg K-H, who I tend to trust, this did not come from Red Hat. It's just that a couple of the devs are employed by them. Others are not. I was particularly interested to find out that Solaris started merging / and /usr 15 years ago, so in reality, the true UNIX way that Linux is following has long since been abandoned by UNIX :) --Mike
Re: [gentoo-user] InitRAMFS - boot expert sought
On 3/27/2012 6:36 AM, Helmut Jarausch wrote: Hi, I've been looking for simple method to create a simple initramfs to just mount the /usr partition. I've found http://wiki.gentoo.org/wiki/Basic_initramfs_used_to_check_and_mount_/usr If this is all you need, I recommend you use dracut. The default installation (no use-flags or optional modules) will product an initramfs that loads whatever you current rootfs and /usr partitions are. I've been working on updating the wiki with more detailed instructions; for your case what's there now ought to be plenty: http://wiki.gentoo.org/wiki/Dracut
RE: [gentoo-user] After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Alan Mackenzie [mailto:a...@muc.de]
Sent: Tuesday, March 27, 2012 9:37 AM
My question: what, technically, prevents me from copying the booting
software instead to /sbin and booting the system that way?
Nothing; in fact, this was the general solution to the problem of something
else in /usr/{sbin,bin,lib} is needed at boot for a long time. More and
more software was getting moved into /{s,}bin, and in particular into /lib,
to make it available in the early boot stages.
There's nothing wrong with that, as long as you can ensure that any
hard-coded paths to those binaries are updated properly.
As you move more and more software off of /usr into / you start to realize
that the idea of tiny partition that contains just what I need to boot and
mount /usr is becoming not so tiny anymore. The distinction between what
is boot software versus user software gets less clear. Then it's just
question of how far you take this process before you reach your personal
threshold of questioning why you have two partitions at all. Whether you
reach that point or not depends on how complex your boot process is, what
you actually need running to boot, and how personally invested in a split
/usr you happen to be :)
--Mike
RE: [gentoo-user] InitRAMFS - boot expert sought
If this is all you need, I recommend you use dracut. The default installation (no use-flags or optional modules) will product an initramfs that loads whatever you current rootfs and /usr partitions are. I've been working on updating the wiki with more detailed instructions; for your case what's there now ought to be plenty: http://wiki.gentoo.org/wiki/Dracut Dracut is masked on ~amd64. Bugs me, as I'd rather use something like that than genkernel (I very much like building my own kernels; it helps me keep things lean, and keeps me familiar with the capabilities of current and future systems). But now I have to find time to learn how to use Genkernel. If we're going to be shoved into tight space like this, I'd be nice if the you can just use $x tools work on stable. I've got three previously-working systems at home I can't risk rebooting right now because of this udev+/usr nonsense. I almost invariably put /usr and /home on top of LVM, RAID or both. I'm pretty sure that a stable Dracut is a prerequisite for a stable udev-182+. Hopefully with more people taking interest in using an initramfs it will stabilize quickly. It's working for me on all of the systems I'm tried it, so I'm going to try switching a couple of servers at work over to using it. But none of them have anything particularly complex (no net boots, for example) so I don't know how much of a test case they'll be :) --Mike
RE: [gentoo-user] After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Alan Mackenzie [mailto:a...@muc.de]
Sent: Tuesday, March 27, 2012 10:27 AM
On Tue, Mar 27, 2012 at 10:02:02AM -0400, Mike Edenfield wrote:
From: Alan Mackenzie [mailto:a...@muc.de]
Sent: Tuesday, March 27, 2012 9:37 AM
My question: what, technically, prevents me from copying the booting
software instead to /sbin and booting the system that way?
Nothing; in fact, this was the general solution to the problem of
something else in /usr/{sbin,bin,lib} is needed at boot for a long
time. More and more software was getting moved into /{s,}bin, and in
particular into /lib, to make it available in the early boot stages.
There's nothing wrong with that, as long as you can ensure that any
hard-coded paths to those binaries are updated properly.
Surely this is the same, whether one copies the booting software to
initramfs
or /sbin, isn't it?
No, because very little of my booting software is on my initramfs; it
contains the kernel modules for my SATA drive and a script to mount /usr
before launching /sbin/init. You *could* build an initramfs that included
all of those other items, including udev and fsck tools if you wanted to,
but you don't have to. (You might want to, for example, to have a more
fully-features rescue shell, but I have a LiveCD for that.)
The difference is what part of the booting process you need the software
for. Without an initramfs, your boot loader loads your kernel, your kernel
launches /sbin/init, and /sbin/init starts running your startup scripts.
Everything that needs to happen must happen in those startup scripts. The
problems occur when script #1 (say, start udev) sometimes needs script #2
(mount /usr) to have run, but script #2 sometimes needs script #1 to have
run. You can solve this in a number of ways:
* Fix script #1 to never need script #2 (move everything you need off /usr)
* Fix script #2 to never need script #1 (put /usr on the same partition as
/sbin/init)
* Adjust the order of the scripts on a case-by-case bases (move script #2 to
an initrd when needed)
Option one has traditionally been the way to solve these kinds of problems,
but with dynamic linking and external hooks the reach of the boot-time
software is getting overly broad. Option #2 is the simplest and lowest-risk
option, but not everyone has a hardware configuration that makes that a
viable choice. So option #3 is basically you do whatever you have to do to
get a /usr before /sbin/init runs.
As you move more and more software off of /usr into / you start to
realize that the idea of tiny partition that contains just what I
need to boot and mount /usr is becoming not so tiny anymore. The
distinction between what is boot software versus user software gets
less clear.
Again, isn't this the same for an initramfs?
This part is, true, but the point of an initramfs is that, once you switch
over to init, the initramfs is out of the picture. With a traditional boot,
the stuff you move into your rootfs to make booting work is there forever.
With an initramfs, you don't need (for example) all of the udev rules and
libraries and such; you just need enough statically linked binaries to mount
/usr; when the init switch happens, your real, production binaries show up
and the trimmed-down copies from your initramfs go away.
Then it's just question of how far you take this process before you
reach your personal threshold of questioning why you have two
partitions at all. Whether you reach that point or not depends on how
complex your boot process is, what you actually need running to boot,
and how personally invested in a split /usr you happen to be :)
I've decided that, if push comes to shove, I'm going to go for /usr on /
rather
than a fragile initramfs system. I've got everything bar / on RAID 1/LVM
at
the moment, but I don't really use LVM, so I could dismantle that too,
losing
all the baggage that brings with it.
I'm using both on most of my systems now, though admittedly on my laptop
it's just to get the boot animation from plymouth :)
Having said that, my system (including Gnome) is working perfectly well
with
mdev, and see no reason why that shouldn't continue.
And that's a perfectly legitimate option; you're continuing to use a process
that has worked for decades. The problem with that option is not that it
doesn't work for plenty of people, it's that it doesn't *scale* very well.
If you're writing the software that needs to work out-of-the-box for every
Fedora/Debian/Gentoo/etc system installed from this point forward, you need
to worry about scale. If you're setting up a few hundred nearly identical
servers with much more limited hardware that is under your direct control,
you can focus your solution to a much narrow scope.
RE: [gentoo-user] InitRAMFS - boot expert sought
From: Dale [mailto:rdalek1...@gmail.com] Mike Edenfield wrote: I'm pretty sure that a stable Dracut is a prerequisite for a stable udev-182+. Hopefully with more people taking interest in using an initramfs it will stabilize quickly. It's working for me on all of the systems I'm tried it, so I'm going to try switching a couple of servers at work over to using it. But none of them have anything particularly complex (no net boots, for example) so I don't know how much of a test case they'll be :) I'm still trying to figure out why my dracut init thingy isn't working right. If I use the init thingy, I can't su to root from a user. If I don't use the init thingy, I can su just fine. By the way, I boot the exact same kernel either way I boot. So, just to make sure I'm understanding you here (cuz it sounds kinda crazy) If you specify a dracut-created inittramfs in your grub.conf, your machine boots, but using 'su' to go from root - non-root fails? If you remove the initrd line from grub.conf and boot the exact same kernel, 'su' works fine? What's the error? Cuz once the pivot_root step happens and the real init is running, things in user-space should be *exactly* the same as if you had no initramfs. --Mike
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: c...@chrekh.se [mailto:c...@chrekh.se] Neil Bothwick n...@digimed.co.uk writes: On Tue, 27 Mar 2012 14:26:46 +, Alan Mackenzie wrote: As you move more and more software off of /usr into / you start to realize that the idea of tiny partition that contains just what I need to boot and mount /usr is becoming not so tiny anymore. The distinction between what is boot software versus user software gets less clear. Again, isn't this the same for an initramfs? No, because an initramfs only needs enough to mount / and /usr, then everything else comes from the usual source. If you're not using and fancy block devices, the initramfs only needs busybox and an init script. Even adding LVM, RAID and encryption only requires three more binaries - and those are all disposed of once switch_root is run and the tmpfs released. The question remains. If it's possible to do that from an initramfs, then shouldn't it be possible to put the same tools and binarias on /, and mount /usr early? Yes , of course it's /possible/, it's just not /practical/. Changing the contents of your initramfs is a decision you, as an admin, make that affects your system(s). Changing the installed location of, say, udevd and bluetoothd and whatever other tools need to get pulled out of /usr is a decision that affects everyone who is using those packages. Changing the order of init scripts is an even bigger mess, but mostly because of the software requirements to make it function. Most Linux users, by a vast but very silent majority, are plenty happy to put / and /usr on one partition, wipe their hands on their pants, and move on with life. Thus, the people developing and packaging those required boot packages can leave them right where they are, and everything works. Some Linux users have reasons (largely legitimate ones) why this is not a valid option. Those users have three choices * Move the required packages away from their default installation locations on their machines, as you're suggestion, and fix the order of your boot scripts to mount /usr earlier than anything that needs it. * Install (or develop) alternative versions of the tools that do not have the same boot-time requirements, thus allowing you to ignore the whole mess. This is what Walt and his mdev team are making happen. * Use an initramfs to do whatever specific thing your machine(s) need to do to make the rest of the software work out-of-the-box. So, it's not a matter of one choice working and one not. It's a matter of one choice being much lower maintenance for the people donating their time to produce the software in the first place. If someone (maybe you) were to figure out the actual steps needed to mount /usr early in the boot, without and initramfs, without swapping out udev for busybox or whatever, I'm sure a lot of people would be interested in seeing how that's done. There's a possibility that it turns out to be way easier than anyone thought, and that supporting a split /usr becomes no big deal. In practice, I'm going to guess that it turns out to be a way bigger maintenance nightmare (and probably more fragile) than: root # emerge dracut root # dracut -H And probably won't be something that the developers or package maintainers are going to commit to supporting. --Mike
RE: [gentoo-user] InitRAMFS - boot expert sought
From: Neil Bothwick [mailto:n...@digimed.co.uk] Yes it is, I now I used to waste my time like that. Now I have a config file that lists what needs to go into the initramfs and the kernel build automatically pulls everything in for me. The only other thing I need is the init script. So I get the benefit of hand crafting everything with the ease of automated building. Are you saying your kernel build automatically rebuilds your initramfs for you? I'm using dracut now and I'm looking for a way to automate the rebuild and installation of the initramfs image. I have them manually symlinked in /boot to /boot/initramfs.img and /boot/initramgs.img.old, to match the vmlinuz and vmlinuz.old symlinks from `make install`. Unfortunately I have to manage those by hand, now, or the initramfs images get out of sync. I guess I could write my own shell script to do it but is there an existing mechanism to hook into for this? --Mike
RE: [gentoo-user] InitRAMFS - boot expert sought
From: Dale [mailto:rdalek1...@gmail.com] Thing is, I can't get dracut to boot a system as I use it. See my other post. Right now, my plan is to mask udev at what it is and either switch to another distro, hope someone figures out why dracut isn't working or just move everything to / and hope it doesn't ever screw up right after I go to bed and full up / with errors in the messages file. I had this happen once. Having /var on it's own partition was the only thing that saved my butt. Ok, silly question time: if this is a concern for you, why not leave /var on its own partition? Just merge / and /usr and leave it at that? --Mike
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Alan Mackenzie [mailto:a...@muc.de] Hi, Alan. On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: On Tue, 27 Mar 2012 21:24:22 + Alan Mackenzie a...@muc.de wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Two words: shared libraries Copying binaries is not enough. You have to find and copy every shared library those binaries use. Plus all the data and other files they might need. This is non-trivial. silently screams. It's equally non-trivial for initramfs, yet nobody seems to be raising this objection for that. Why is nobody else on this thread willing to take up its main point, the exact equivalence between the known, ugly, initramfs solution and the as yet half-baked idea of putting the same binaries into /sbin? Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. That notwithstanding: The binaries on the initramfs are not always the same as the ones installed in the system; frequently they are statically linked versions, or stripped-down versions, or otherwise unsuitable for being used after the full system is booted. (Dracut, for example, forces you to add USE=static-libs to a lot of the packages it wants to put into your initramfs image.) Putting those binaries into the execution path of the system is a bad idea because you don't always them to run once the system has booted -- I want the full set of udev rules, not the bare handful that my initramfs has on it. You could fix this by arranging for them to be put somewhere outside the normal path, where they can be found by the init system at boot-time but then ignored once /usr was up. This would also mean managing two copies of these packages on your system, which means the package manager would need to ensure that both static and dynamic versions, or full and minimal version, or whatever else, were built and installed in the correct locations. And this is ignoring the possible side-effects of reordering the boot scripts to unilaterally try to mount /usr very early; I don't know what, if any, those would be but someone would need to figure those out. The initramfs solution doesn't change the order of boot scripts, so people who are not using one see no change. Again, this is all *possible*. It is one option for solving the missing-/usr-at-boot problem, it is just not the option that has taken hold in the community. The people who are writing the software consider an initramfs a more elegant, cleaner, *less* ugly solution that what you are proposing, in the context of a general-purpose solution suitable for the most number of users. As they are the ones doing all the work, they get to make that call. The fact that most of us seem to agree with, or at least not actively disagree with, that opinion is just an added bonus. Your solution would be equally as successful at solving the problem, once someone put in the effort to actually make it work, make it repeatable, make it stable, and document/automate it for others to use. All of those steps have /already happened/ for an initramfs, so until someone comes up with a concrete reason why initramfs will not work, there is absolutely no motivation to waste time on anything else. --Mike
RE: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
From: Walter Dnes [mailto:waltd...@waltdnes.org] Sent: Thursday, March 22, 2012 5:14 PM On Wed, Mar 21, 2012 at 09:35:55PM -0400, Michael Mol wrote What we're talking about with systemd vs openrc, and things like ssh'd first-time initialization is all within the realm of responsibility of the packager. It's a shift in the way the distribution itself works. We're not talking about a scenario where you shunt things upstream, so the whole your position would have rejected Linux angle is a red herring. This is a frustrating game of whack-a-mole. Person A comes up with a position, I rebut it, and then person B comes up with a different position, and I have to rebut it.. There have been people in this thread who have said that the program best knows what it needs, and should handle its own initialization. That was what I was replying to. I'll reply to your position now. You know the old adage, if you ask 5 geeks a question you get 6 different answers. This whole discussion is somewhat surreal to me, when taken in conjunction with the other heated debate we just finished having: * udev is evil and horrible because it's trying to do too much and is too complex. * system is evil and horrible because it isn't doing enough and is too simple. And I'm pretty I've seen at least one person making both arguments simultaneously. Why does that spawned process have to be sshd? Why can't it be some shell script which does the one-time checks, and then launches sshd itself? So instead of the initscript doing the checking+setup and launching the service, it launches a a second script... which does the checking+setup and launches the service FACEPALM. See my post with the joke of digging a second hole to dump the dirt from the first hole into. Instead of one script, we now have two scripts. This is *NOT* simplification. It works fine for mysql, or postfix, or apache, or any of the dozens of other programs that have helper scripts whose sole purposes is to act as an entry point to starting up the actual service. It's a common and well-accepted way of performing required initialization on startup. I don't see why sshd has to be special here. Why does that shell script need to be distributed as part of the init system's package, and not part of the package associated with the service? I don't understand what you're arguing here. *THE INITSCRIPT IS OWNED BY THE SERVICE PACKAGE*, not by the init package. E.g. net-misc/openssh, not sys-apps/openrc. You are absolutely correct; the discussion of who owns the init script is completely tangential to the system vs openrc argument; in both cases, the required startup files will be provided by the package maintainer and installed by the ebuild, not by the rc system. I think the confusion may have started way back when Canek tried to compare the simplicity of sshd.service to the complexity of /etc/init.d/sshd. That's the unfair, apples-to-oranges comparison that triggered this entire debate. The part that's been lost here is that system doesn't run init scripts(*); it launches configured services. These are *not* shell scripts; they are ini-file-like things that define parameters, much like xinetd's configuration files. Of course, I don't see why this is a problem: configure system to launch sshd's init script, which keeps doing the same thing it always has been doing. This is why the comparison between systemd's service config and openrc's script is unfair. You /cannot/ get rid of the complexity of /etc/init.d/sshd, you can only make it so that openrc and systemd can *both* take advantage of that complexity when starting sshd. That may, of course, require the package maintainer to provide 3 items instead of one: an openrc init script, a systemd service description, and an rc-agnostic helper script, in order to be fully systemd-compatible. In the meantime, the systemd package maintainer will likely be forced to provide some kind of compatibility shims to run existing openrc scripts that have not yet been refactored, but that's the cost of choice. It may already do this, I don't know. I have not yet installed systemd anywhere but I am curious enough to try it on my laptop. So I will be that much more informed in the near future :) (*) As I understand it, systemd *can* run SysV-style init scripts, but Gentoo's startup scripts are too dependent on openrc-supplied logic to be reusable in any meaningful sense. --Mike
RE: [gentoo-user] mdev for udev substitution instructions web page is up
Walter Dnes wrote: The instructions for replacing udev with mdev are now up at http://www.waltdnes.org/mdev/ validator.w3.org complains about a couple of extensions I used, but it appears to work OK in both Firefox and Midori. Any comments from users of other browsers? The page will be Looks fine in IE/Firefox/Chromium; you shouldn't have any problems with any browsers since the validation errors are on deprecated attributes that are still in wide use. If you really want to fix them so it validates, change: a name=foo -- a id=foo ol type=a -- ol style=list-style-type: lower-alpha
RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
From: Dale [mailto:rdalek1...@gmail.com] 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. I had a long reply to Walt that I (probably wisely) decided not to send, but the basic point of it is also relevant here. My response to his (IMO needlessly aggressive) email was basically this: Why *shouldn't I* be able to go but a Bluetooth keyboard and mouse if I wanted to? Those things *work perfectly fine with udev*. And why wouldn't I want to use the *same* solution for all of my various machines, even if that solution is overkill for half of them? Just because my laptop doesn't need bluetoothd support in udev doesn't mean using udev there *is bad*. (I don't need 80% of what's in the Linux kernel but I still install one...) I am not in any way denigrating the work he's doing. I think it's awesome and I've tried to help where I can. But I'm pretty fed up with people like him acting as if the current udev solution is the end of the world. I've heard it called everything from design mistake to out of control truck full of manure. I have three PCs in my home running Gentoo. Two of them would boot correctly using Walt's new solution (mdev and no /usr mounted at boot) and one would not. *All three of them* boot correctly using udev. 100% success 66% success, so clearly the udev solution is a perfectly legitimate solution to a real world problem. At work, those numbers are likely different, and Walt's solution might be a working approach -- if udev didn't already work fine in 100% of those cases, too. Instead of asking why everyone else should be forced to use the udev solution *that already works*, you should be focusing on explaining to everyone else the reasons why it is worth the time and effort to configure *something different* for those same machines. There was a reason why people stopped using static /dev, and devfs; maybe there is a reason why people should stop using udev, but thus far that reason seems to be initramfs makes us cranky. There's no need to get mean-spirited just because you choose a different audience that freedesktop.org as the target for your solution. It just makes you look petty and childish. Produce an alternative to udev/initramfs/single root that works, provide (accurate) details on the differences, and let users pick which one they want. --Mike
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] 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
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] 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] Re: LVM, /usr and really really bad thoughts.
From: Dale [mailto:rdalek1...@gmail.com] Sent: Monday, March 12, 2012 7:23 PM I like that quote. I may not be dev material but I know this /usr mess is not right. The only reason it is happening is because of one or two distros that push it to make it easier for themselves. If that's honestly what you think then I suspect you don't understand the problem as well as you believe. 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. The requirement to ensure that /usr is *somehow available* before launching udevd is a configuration that, I am told, causes problems in some specialized real-world, practical situations. (I am ignoring problems such as initramd might possibly break maybe or that's more work than I want to do as being the expected griping that always happens when you ask a group of geeks to change something.) It is impossible for udev to solve the problem for all users in all configuration. Given the three readily available options, the one that makes the most sense from a software engineering standpoint is to choose option three, thus ensuring that your solution pisses off the smallest subset of users. Those users are then free to create a solution that better suits their needs, such as replacing udev with different software which made a different choice. To call one option a mess that is not right is both an unrealistic oversimplification of a complex problem and utterly unfair to the people trying to solve that problem. --Mike
Re: [gentoo-user] Somewhat OT: Any truth to this mess?
On 2/18/2012 5:26 AM, Dale wrote: Howdy, I ran across this and though it was a joke. Did a news search and sure enough, it is reported in lots of places. Random linky: http://www.dailymail.co.uk/news/article-2102856/Will-FBI-shut-Internet-March-8-virus-concerns.html?ito=feeds-newsxml Is there any truth to this mess? My bigger and better question, how is shutting down the internet going to fix this? When the net comes back up, they are still going to be infected. Right? As usual, the headline has things completely backwards; if you actually read the article and ignore the headline you will get something closer to reality: * There is a fairly large botnet that works by hijacking the DNS settings of the machines it infects, and redirecting them to rogue DNS servers. * The rogue DNS servers resolve all DNS requests by returning the IPs of various scam sites etc. that the botnet owners get paid for. * The FBI and the Dutch national police, stepped in and arrested those in charge of the botnet. * 120 days ago -- Nov 8 -- they dismantled the botnet's core network and replaced the rogue DNS servers with legitimate ones serving legitimate DNS zone information. * On March 8 the FBI will turn off their stand-in DNS servers. If you aren't infected by this botnet you won't notice anything. If you are still infected by this botnet your DNS servers will vanish (and, in theory, someone could step in and replace them, depending on what happens to the allocated IPs). --Mike
RE: [gentoo-user] [OT as it gets. Sorry] Windoze 7 and reinstalling error.
From: Dale [mailto:rdalek1...@gmail.com] Sent: Wednesday, February 01, 2012 6:39 PM Howdy, I got a neighbour that has a computer issue. First, the hard drive went out. We ordered a new one and installed it. Then he realized he didn't have the restore discs. We ordered those from Gateway. I went up today and tried to install winders 7 on the new drive. I put the system disc in and it booted. Then it asked for the recovery disc #1. It copied that over then asked for disc 2. After a bit it wanted the Language disc. Then it said to reboot and it spit out the DVD. When it reboots from the hard drive, it comes up and says it is setting up the hardware and it seems to finish it. Then a window pops up and says this: Windows Setup could not configure windows to run on this computers hardware. Does this help? http://support.microsoft.com/kb/2466753 You may have accidentially set the new drive in the BIOS as RAID: the KB article has steps to find the error logs and get more details.
RE: [gentoo-user] [OT as it gets. Sorry] Windoze 7 and reinstalling error.
From: Dale [mailto:rdalek1...@gmail.com] Sent: Wednesday, February 01, 2012 8:06 PM Your reply made me think of something. I had a XP reinstall once that required a number from MS because of the new mobo and hard drive. They said it recognized the change in the serial numbers. When I ran into that before tho, it installed fine but gave 30 days to put in the number. Does winders 7 have something similar? Yes but that has nothing to do with your problem. If you change your hardware too much, it will deactivate your license, but you'll get a pretty clear error about that being the problem. I *think* you get a grace period after that to re-activate your system but it's been a while since I had that happen to me. --Mike
RE: [gentoo-user] [OT as it gets. Sorry] Windoze 7 and reinstalling error.
From: Dale [mailto:rdalek1...@gmail.com] Sent: Wednesday, February 01, 2012 9:43 PM Mike Edenfield wrote: From: Dale [mailto:rdalek1...@gmail.com] Sent: Wednesday, February 01, 2012 6:39 PM Howdy, I got a neighbour that has a computer issue. First, the hard drive went out. We ordered a new one and installed it. Then he realized he didn't have the restore discs. We ordered those from Gateway. I went up today and tried to install winders 7 on the new drive. I put the system disc in and it booted. Then it asked for the recovery disc #1. It copied that over then asked for disc 2. After a bit it wanted the Language disc. Then it said to reboot and it spit out the DVD. When it reboots from the hard drive, it comes up and says it is setting up the hardware and it seems to finish it. Then a window pops up and says this: Windows Setup could not configure windows to run on this computers hardware. Does this help? http://support.microsoft.com/kb/2466753 You may have accidentially set the new drive in the BIOS as RAID: the KB article has steps to find the error logs and get more details. Printed that page to try tomorrow. I didn't change anything in the BIOS tho. It saw the drive right off. I even used the same cable and power plug as the old drive so it sees them as C: or whatever. I bet it has something to do with AHCI or IDE settings tho. I hope that is it. After I get the install done, I can then upgrade the drivers and switch it back. Make sure you check the ACHI setting before you install Windows: it's a pain in the butt to change the settings later because Windows disables the ACHI driver if it's not in use, and you have to manually re-enable it or your boot will fail. (Kinda like having to enable the module for your root drive). Of course, if you get it wrong you just lose some performance but it's easy enough to just check first :) --Mike
Re: [gentoo-user] Floppy support question for old farts. lol
On 1/29/2012 1:14 PM, Michael Mol wrote: 2) On PC clones, floppies never had auto-insert detection. (Though maybe you'd get something like that if you used a superfloppy or LS-120 drive to read them) Technically, they did, it was just impossible for an OS to make it actually work: http://blogs.msdn.com/b/oldnewthing/archive/2009/04/02/9528175.aspx
RE: [gentoo-user] Floppy support question for old farts. lol
From: Michael Hampicke [mailto:gentoo-u...@hadt.biz] Sent: Monday, January 30, 2012 8:10 AM Technically, they did, it was just impossible for an OS to make it actually work: http://blogs.msdn.com/b/oldnewthing/archive/2009/04/02/9528175.aspx Quote And you certainly don't want to make the user go through this training session when they unpack their computer on Christmas morning. Thank you for using Window 95. Before we begin, please insert a floppy disk in drive A:. I wish they would have tought of that when they forced users to activate and/or register Windows. Thank you for using Window XP. Before we begin, please enter your 100 digit serial number Sweet. I had 15 minutes in the office how long before someone makes a pointless, unrelated Windows insult out of my post pool; I just won $5.
RE: [gentoo-user] Floppy support question for old farts. lol
From: James Broadhead [mailto:jamesbroadh...@gmail.com] Sent: Monday, January 30, 2012 8:15 AM On 30 January 2012 13:09, Michael Hampicke gentoo-u...@hadt.biz wrote: Technically, they did, it was just impossible for an OS to make it actually work: http://blogs.msdn.com/b/oldnewthing/archive/2009/04/02/9528175.aspx Honestly, given that it's a single bit check per hardware change, it doesn't seem like all that challenging of a feature. We could have had autorun.inf viruses almost 5 years earlier! The problem, IIRC, is that the floppy bus has no way of identifying a hardware change even happened, so there would be nothing to trigger the hardware re-check. Of course you could make it work with all kinds of heuristics but most of them involve getting the auto-insert check wrong at least once. That means either spinning up the drive when it's empty (Dear /.: Windows is stupid! It keeps trying to read from my floppy drive when there's no disk.), or failing to spin up when a disk is inserted and requiring user intervention (Dear /.: Windows is stupid! It used to know when I put a disk in my floppy and now it stopped!). By the time Windows 95 came along floppies were on the way out and really not worth the hassle. Windows auto-mounts all drives on demand, so it didn't really need to know when you put a disk in, and none of the software that came on floppies had autorun setup. I'm kinda surprised they even spent as much time as they did looking at it :)
RE: [gentoo-user] Google privacy changes
From: Frank Steinmetzger [mailto:war...@gmx.de] Sent: Thursday, January 26, 2012 11:05 AM This backs me up in using noscript and flashblock. Sometimes I doubt myself when I get asked once more why I would use NoScript in times when most of the web relies on JS. I then say that privacy and comfort is more important to me than having to allow JS on a site from time to time. Of course, by using NoScript and FlashBlock when most people no longer do so, you are making yourself *more* unique and *more* trackable by Google's standards. :) --Mike
Re: [gentoo-user] Cross Compiling in Gentoo
On 1/17/2012 1:55 AM, Chris Walters wrote: Hi, I have a question about cross compiling in Gentoo - specifically cross compiling for W32/W64. I tried their preferred method and didn't like it, so I downloaded the appropriate Mingw64 build files, set up a cross compile account, with the appropriate paths, variables, etc. Most packages compile correctly (though it sometimes takes some code hacking - and yes they do run in Win 7), but there are some I can't seem to get to build properly - usually the ones that have make files for MS Visual Studio. I have no interest in purchasing Visual Studio. Just a point of interest: Visual Studio doesn't use Makefiles; Visual C++ can import Makefile projects if you ask it to, but it has its own project file format. If you're seeing actual make files (and not, say, a .sln file or .cproj file) then you don't need Studio, just an nmake-compatible version of make. If you do have project and solution files from Visual Studio, they are just MSBuild projects (think ant for Windows). I'm pretty sure there are open-source variants of MSBuild, possibly in the Mono project? And of course, Visual C++ Express is free, though you'd need to find somewhere to set it up. My question is, does anyone know of any good resources (mailing lists, sites, etc.) on cross compiling on a GNU/Linux platform for a W32/W64 platform? The searches I've run have directed me to sites that talk about using MSYS and Mingw on a W32 platform (I don't have all year to build a single package). I am looking to build GraphicsMagick, and some helpful tools for W64 (though I'd accept W32, if that's the only way). Chris
Re: [gentoo-user] Cross Compiling in Gentoo
On 1/17/2012 6:41 AM, Joerg Schilling wrote: Chris Walterscjw20...@comcast.net wrote: I have a question about cross compiling in Gentoo - specifically cross compiling for W32/W64. I tried their preferred method and didn't like it, so I downloaded the appropriate Mingw64 build files, set up a cross compile account, with the appropriate paths, variables, etc. Most packages compile correctly (though it sometimes takes some code hacking - and yes they do run in Win 7), but there are some I can't seem to get to build properly - usually the ones that have make files for MS Visual Studio. I have no interest in purchasing Visual Studio. My question is, does anyone know of any good resources (mailing lists, sites, etc.) on cross compiling on a GNU/Linux platform for a W32/W64 platform? The searches I've run have directed me to sites that talk about using MSYS and Mingw on a W32 platform (I don't have all year to build a single package). I am looking to build GraphicsMagick, and some helpful tools for W64 (though I'd accept W32, if that's the only way). For your specific problem: it is most unlikely that you will get a MS cross compiler that runs on other platforms than WIN-DOS. I've had very good luck with gcc's x86_64-w64-mingw32 target, and gcc has supported Win32 builds for years, so I dunno why you think this is unlikely. My biggest problem with MingW has been their occasional lag behind gcc in versions, but I believe gcc 4.5 can cross-compile for 64-bit Windows. The setup is rather a pain but then again, if you wanted easy, you probably wouldn't be using Gentoo :) http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler For the OP's specific problem, I'll have to try and build GraphicsMagick on Gentoo and see what kind of build structure is uses that is giving him problems but its possible he just needs xbuild (the Mono msbuild implementation.) Worst case it has an old VC++-style workspace but those are usually just auto-generated out of the makefiles anyway. --Mike
RE: [gentoo-user] Cross Compiling in Gentoo
From: Chris Walters [mailto:cjw20...@comcast.net] Sent: Tuesday, January 17, 2012 9:27 AM On 1/17/2012 08:39 AM, Mike Edenfield wrote: On 1/17/2012 1:55 AM, Chris Walters wrote: that have make files for MS Visual Studio. I have no interest in purchasing Visual Studio. Just a point of interest: Visual Studio doesn't use Makefiles; Visual C++ can import Makefile projects if you ask it to, but it has its own project file format. If you're seeing actual make files (and not, say, a .sln file or .cproj file) then you don't need Studio, just an nmake-compatible version of make. If you do have project and solution files from Visual Studio, they are just MSBuild projects (think ant for Windows). I'm pretty sure there are open-source variants of MSBuild, possibly in the Mono project? And of course, Visual C++ Express is free, though you'd need to find somewhere to set it up. Just a note: I used to do all of my programming in Visual Studio. I stopped when I needed to do things that VS wouldn't let me do, and also because I discovered GNU/Linux. While I program a lot on my Linux machines, I haven't actually found an IDE that doesn't make me wish VS ran on Linux. MonoDevelop isn't horrible but if I wanted to write .NET code I'd just use Windows; Eclipse makes me want to drill my brain out with a corkscrew and the only other decent IDE's I've seen are KDE-specific. I've falling back to the default of Emacs at this point; it's powerful enough, especially when I'm doing Lisp or Scheme, but I have an internal mental limit of 150,110 hotkey combinations that I think is holding me back. If you have any suggestions I'm all ears :) As for the types of files I've seen, I have seen both VS Solution/Project files, and nmake files. Most of the time, I just use the configure script with x86_64-w64-mingw32 as my host, and it works fine. Do you, by chance, know where I can find an nmake-compatible version of make? Also, do you have a link for Visual C++ Express? I like to do most programming in C/C++ anyway (though this is OT). Well, if you're willing to go the install a Windows OS route, everything you need command-line wise is found in the Windows SDK: http://msdn.microsoft.com/en-us/windowsserver/bb980924.aspx. Visual C++ 2010 Express can be downloaded from: http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express Mostly what you lose with Express are the TFS integrations, unit testing, and other application lifecycle management stuff they pack into the full editions. Express editions can't build debug 64-bit applications, but the 64-bit compilers come with the SDK. Depends on how much effort you're willing to put into it. If you don't want to install Windows you're options are going to be mostly limited to the GNU binutils and GCC, which support targeting Win32 and Win64. In theory you could run the command-line tools, for example, under Wine, but I've never tried it. I don't actually know of a make for Linux that is compatible with NMAKE. If you can't find one then you'll need to do a lot of work to build any applications that require it. However, I think the number of applications using Microsoft make files is vanishingly small: they're either going to produce a GNU makefile (since GNU make runs on Windows) or an MSBuild project. And yes, ATT also released a tool called nmake that is not compatible with Microsoft NMAKE (or either of the other two incompatible makes), so don't get them confused. --Mike
RE: [gentoo-user] Resetting the root passwd
From: Alan McKinnon [mailto:alan.mckin...@gmail.com]
Sent: Wednesday, January 11, 2012 7:31 PM
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Resetting the root passwd
On Wed, 11 Jan 2012 18:09:40 -0500
Mike Edenfield kut...@kutulu.org wrote:
I agree. Longer pass{words,phrases} only increases the difficulty of
the problem, but not significantly so.
After I read the aforementioned xkcd comic, my main question was how
he defined the various bits of entropy for each thing done to a
password. That seemed to be a crucial determining factor in why the
common words password appeared so much harder than the goofy
gibberish one. Some seemed more obvious to me than others.
I'm also curious, using the latest modern password-cracking
techniques, if his assessment really is accurate. As in, which of the
following two passwords would take longer to crack:
#purpl3.R$!n#
dovesymbolcarprince
I noticed something about your first sample password, and it reveals a
lot, I
hinted at it in my reply to Dale. Look at the pattern one must type to
enter
that password (assuming a qwerty keyboard):
A symbol, a partial word, then 7 nonsense symbols. The pattern of those
symbols is highly significant - composed entirely of keystrokes in the
upper
left area and lower right area of the keyboard with a few Shifts thrown in
for
good measure. Almost as if you dropped both hands on the keyboard and
wiggled your fingers without moving the entire hand much.
Actually, it's just the words purple RAIN with e/a/I replaced with 3/4/1;
I chose l33t-sp33k since I figured it was so over-used for password
generation that everyone would recognize it immediately :) But yes, I think
Randall's point is much the same as yours: once the cracker tools figure
out this pattern of character replacements it becomes significantly less
secure. I'm just curious if there are any real metrics as to how much less
secure that is...
(Clearly my pop culture reference was too obscure, or you'd also have picked
up on the connection between the four random words. :) )
--K
RE: [gentoo-user] Resetting the root passwd
From: Alan McKinnon [mailto:alan.mckin...@gmail.com]
Sent: Wednesday, January 11, 2012 5:48 PM
On Wed, 11 Jan 2012 17:08:04 -0500
Michael Mol mike...@gmail.com wrote:
I'm seriously unconvinced that concatenating words significantly
increases the difficulty of the problem. Just as a mentalist will
presume you're thinking about '7', your average demographic would
probably draw from a small pool of source words, even latching on to
catchphrases and other memes. You're likely to see
steamingmonkeypile, nyanyanyan, dontsaycandleja- and
hasturhasturhast- used more than once, for example. I'd give a
better list of likely results, but I don't want to run too far afoul
of good taste in public posting. :)
I agree. Longer pass{words,phrases} only increases the difficulty of the
problem, but not significantly so.
After I read the aforementioned xkcd comic, my main question was how he
defined the various bits of entropy for each thing done to a password.
That seemed to be a crucial determining factor in why the common words
password appeared so much harder than the goofy gibberish one. Some seemed
more obvious to me than others.
I'm also curious, using the latest modern password-cracking techniques, if
his assessment really is accurate. As in, which of the following two
passwords would take longer to crack:
#purpl3.R$!n#
dovesymbolcarprince
--K
Re: [gentoo-user] What happened to OpenRC 0.9.6?
On 12/11/2011 1:10 PM, James Broadhead wrote: On 11 December 2011 10:41, Andrea Contia...@alyf.net wrote: On 27/11/11 16.36, Nikos Chantziaras wrote: sys-apps/openrc-0.9.6 is just... gone? Not even masked, but completely gone from portage. FYI, sys-apps/openrc-0.9.7 is out. Apparently, the solution to the rc_parallel issues was to remove every mention of rc_parallel from the default /etc/rc.conf Brilliant. I didn't take this email at face value when I read it earlier, but I just merged my openrc-0.9.7 config file. Wow, what a cynical move. Its only cynical in that it reflects a basic failing of human psychology, namely, thst warning doesn't apply to me syndrome. I imagine their thought process went something like this: We exposed this experimental feature that's hard to get right and only moderately useful, with explicit instructions not to complain if it doesn't work unless you are personally going to put in the time and effort to fix it. People blithely ignored our warning, enabled it, then complained loudly when it did not work. Since no one bothers to read the warning in rc.conf about this feature, and we have neither the time, manpower, nor overwhelming need to make it work, we'll just stop mentioning it. HOPEFULLY anyone smart enough to find and re-enable a hidden, explicitly unsupported feature will be smart enough not to complain when it doesn't work. --Mike
Re: [gentoo-user] 200MB waste from /usr/share/locale ?
On 11/27/2011 1:10 PM, Sebastian Pipping wrote: On 11/26/2011 07:32 AM, Mike Edenfield wrote: Can anyone explain what is going on ? Different packages include different levels of support for filtering their installed localization messages, typically one of install everything, install what's requested, or whats a locale? In case I find time to blog about this on Planet Gentoo: would you allow using the above text under some Creative Commons license, say CC-BY-SA/3.0? Since I didn't write it at work it's all yours. :) --Mike
Re: [gentoo-user] 200MB waste from /usr/share/locale ?
On 11/25/2011 10:00 PM, Philip Webb wrote: 26 Florian Philipp wrote: Am 26.11.2011 01:28, schrieb Sebastian Pipping: It seems that /usr/share/locale is keeping files for many languages not of any use to me: around 200MB in total. Is there a way to configure this away that I am not aware of? Please follow the section glibc Locales in the Gentoo handbook. http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1#book_part1_chap6 Yes, but that may not be the problem. I have just 2 locales requested, but /etc/share/locale/ contains 90 MB of material. A quick look suggests that most of it is in subdirs LC_MESSAGES , wh seem to come from emerges at various dates; they are binary, so I don't know what they were reporting. Even under /usr/share/locale/en_US , which should show my 2 locales, there are only such messages. The locales do seem to work. Can anyone explain what is going on ? Different packages include different levels of support for filtering their installed localization messages, typically one of install everything, install what's requested, or whats a locale? The reason you mostly have files under LC_MESSAGES is because that's 99% of what is needed to localize a package. The files in there are string resource packages, translations of the strings used by the program, which are picked up by the localization library (gettext) automatically based on your locale settings. (coreutils installs file into LC_TIME for locales with date/time formatting requirements; I don't think I've ever seen any other locale files.) The standard way to inform a package which languages you want is to set your LINGUAS variable in /etc/make.conf to the locale name(s) you want installed (without the charset specifier). LINGUAS works like any other portage expansion variables: for those packages that support it, you get a set of USE-flag-like language keywords set on build. (LINGUAS is the well-known environment variable used by most autotools-based packages to select languages, but portage provides support above and beyond that.) Unfortunately, proper locale support is spotty -- mostly due to upstream maintainers being too lazy to properly add it to their builds. Instead, the package will install every message file it has available all the time. You can safely delete any folders from /usr/share/locale for locales that you don't have installed, since the normal locale support in glibc will never ask for them. But they'll just get put back next time you upgrade the package. --Mike
Re: [gentoo-user] Something weird and I'm confused. BIOS and SATA is empty
On 11/9/2011 2:04 AM, Mick wrote: On Wednesday 09 Nov 2011 02:43:43 Mike Edenfield wrote: On 11/6/2011 8:54 PM, Dale wrote: Mine is like this: -rw-r--r-- 1 root root 4547936 Aug 22 03:53 /boot/bzImage-3.0.3-1 -rw-r--r-- 1 root root 4548640 Sep 1 07:19 /boot/bzImage-3.0.4-1 -rw-r--r-- 1 root root 5162752 Oct 12 21:49 /boot/bzImage-3.0.4-2 -rw-r--r-- 1 root root 5167840 Oct 13 00:05 /boot/bzImage-3.0.6-1 -rw-r--r-- 1 root root 5167776 Oct 19 02:14 /boot/bzImage-3.0.7-1 The last number is how many times it took to get a stable one. Sometimes it is one, sometimes two. I would also like to see how make install does it nowadays. Maybe worth another try. Oh, I name the config files the same as the kernel too. Am I OCD? o_O Nope, that's also how `make install` does it: basement boot # ls -l total 7060 lrwxrwxrwx. 1 root root 41 Aug 18 15:35 System.map - System.map-2.6.39-hardened-r10-basement-1 -rw-r--r--. 1 root root 1484083 Aug 18 15:26 System.map-2.6.39-hardened-r10-basement-0 -rw-r--r--. 1 root root 1484083 Aug 18 15:35 System.map-2.6.39-hardened-r10-basement-1 lrwxrwxrwx. 1 root root 41 Aug 18 15:26 System.map.old - System.map-2.6.39-hardened-r10-basement-0 lrwxrwxrwx. 1 root root 1 Oct 3 2009 boot - . lrwxrwxrwx. 1 root root 37 Aug 18 15:35 config - config-2.6.39-hardened-r10-basement-1 -rw-r--r--. 1 root root 51983 Aug 18 15:26 config-2.6.39-hardened-r10-basement-0 -rw-r--r--. 1 root root 51983 Aug 18 15:35 config-2.6.39-hardened-r10-basement-1 lrwxrwxrwx. 1 root root 37 Aug 18 15:26 config.old - config-2.6.39-hardened-r10-basement-0 drwxr-xr-x. 2 root root4096 Aug 18 15:37 grub drwx--. 2 root root 16384 Oct 3 2009 lost+found lrwxrwxrwx. 1 root root 38 Aug 18 15:35 vmlinuz - vmlinuz-2.6.39-hardened-r10-basement-1 -rw-r--r--. 1 root root 2027168 Aug 18 15:26 vmlinuz-2.6.39-hardened-r10-basement-0 -rw-r--r--. 1 root root 2026816 Aug 18 15:35 vmlinuz-2.6.39-hardened-r10-basement-1 lrwxrwxrwx. 1 root root 38 Aug 18 15:26 vmlinuz.old - vmlinuz-2.6.39-hardened-r10-basement-0 Note that, to get the name/number scheme, I also have: basement linux # cd /usr/src/linux basement linux # cat localversion1 -basement- basement linux # cat localversion2 2 basement linux # ls -l localversion* -rw-r--r--. 1 root root 11 Aug 14 09:07 localversion1 lrwxrwxrwx. 1 root root 8 Aug 18 15:34 localversion2 - .version Are you saying then that every time you download new source files you have to create or cp new localversion* files in /usr/src/linux/ for this auto-numbering to work? Yeah, though I wouldn't be surprised if there was already a way to automate this that I just haven't bothered to learn. For now I just create them again each time I change my /usr/src/linux symlink: basement ~ # cd /usr/src/linux basement linux # cp ~/localversion* . basement linux # ln -sf localversion2 .version --Mike
Re: [gentoo-user] Something weird and I'm confused. BIOS and SATA is empty
On 11/9/2011 8:55 AM, Neil Bothwick wrote: On Wed, 09 Nov 2011 08:47:07 -0500, Mike Edenfield wrote: Are you saying then that every time you download new source files you have to create or cp new localversion* files in /usr/src/linux/ for this auto-numbering to work? Yeah, though I wouldn't be surprised if there was already a way to automate this that I just haven't bothered to learn. There is, but the file is called .version. The contents of this are appended to the kernel name when you have the relevant options set. There is no manual intervention needed. But I still need to create .version every time I compile a new set of kernel sources for the first time, right? That's what I'm doing now (localversion2 is a symlink to .version) --Mike
Re: [gentoo-user] Something weird and I'm confused. BIOS and SATA is empty
On 11/6/2011 8:54 PM, Dale wrote: Mine is like this: -rw-r--r-- 1 root root 4547936 Aug 22 03:53 /boot/bzImage-3.0.3-1 -rw-r--r-- 1 root root 4548640 Sep 1 07:19 /boot/bzImage-3.0.4-1 -rw-r--r-- 1 root root 5162752 Oct 12 21:49 /boot/bzImage-3.0.4-2 -rw-r--r-- 1 root root 5167840 Oct 13 00:05 /boot/bzImage-3.0.6-1 -rw-r--r-- 1 root root 5167776 Oct 19 02:14 /boot/bzImage-3.0.7-1 The last number is how many times it took to get a stable one. Sometimes it is one, sometimes two. I would also like to see how make install does it nowadays. Maybe worth another try. Oh, I name the config files the same as the kernel too. Am I OCD? o_O Nope, that's also how `make install` does it: basement boot # ls -l total 7060 lrwxrwxrwx. 1 root root 41 Aug 18 15:35 System.map - System.map-2.6.39-hardened-r10-basement-1 -rw-r--r--. 1 root root 1484083 Aug 18 15:26 System.map-2.6.39-hardened-r10-basement-0 -rw-r--r--. 1 root root 1484083 Aug 18 15:35 System.map-2.6.39-hardened-r10-basement-1 lrwxrwxrwx. 1 root root 41 Aug 18 15:26 System.map.old - System.map-2.6.39-hardened-r10-basement-0 lrwxrwxrwx. 1 root root 1 Oct 3 2009 boot - . lrwxrwxrwx. 1 root root 37 Aug 18 15:35 config - config-2.6.39-hardened-r10-basement-1 -rw-r--r--. 1 root root 51983 Aug 18 15:26 config-2.6.39-hardened-r10-basement-0 -rw-r--r--. 1 root root 51983 Aug 18 15:35 config-2.6.39-hardened-r10-basement-1 lrwxrwxrwx. 1 root root 37 Aug 18 15:26 config.old - config-2.6.39-hardened-r10-basement-0 drwxr-xr-x. 2 root root4096 Aug 18 15:37 grub drwx--. 2 root root 16384 Oct 3 2009 lost+found lrwxrwxrwx. 1 root root 38 Aug 18 15:35 vmlinuz - vmlinuz-2.6.39-hardened-r10-basement-1 -rw-r--r--. 1 root root 2027168 Aug 18 15:26 vmlinuz-2.6.39-hardened-r10-basement-0 -rw-r--r--. 1 root root 2026816 Aug 18 15:35 vmlinuz-2.6.39-hardened-r10-basement-1 lrwxrwxrwx. 1 root root 38 Aug 18 15:26 vmlinuz.old - vmlinuz-2.6.39-hardened-r10-basement-0 Note that, to get the name/number scheme, I also have: basement linux # cd /usr/src/linux basement linux # cat localversion1 -basement- basement linux # cat localversion2 2 basement linux # ls -l localversion* -rw-r--r--. 1 root root 11 Aug 14 09:07 localversion1 lrwxrwxrwx. 1 root root 8 Aug 18 15:34 localversion2 - .version
[gentoo-user] XEmacs build hangs loading update-elc.el
I'm trying to build XEmacs on my laptop (Hardened ~amd64), and it appears to be stuck near the end trying to load and/or execute update-elc.el (it's been on this step for approaching 6 hours now). This happens every time I attempt to build xemacs (I've re-synched and restarted the build multiple times.) I thought it might be related to having PaX in my kernel, but when I switched softmode on, the build actually segfaults almost immedately! Is it supposed to be taking this long for this step, and if not, what can I do to see why it's locked up? The last thing on my screen is this: really long gcc linker command ./xemacs -nd -no-packages -batch -l /var/tmp/portage/app-editors/xemacs-21.5.31/work/xemacs-21.5.31/src/../lisp/ update-elc.el --Mike
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On 10/15/2011 4:42 AM, Canek Peláez Valdés wrote: Which one? That /var is not going into /? It's not disinformation, it is th true. If not, please be so kind of showin one single developer reference that says so. One. Single. One. Email, blog post, wiki, you choose it. But one single one. I don't think anyone is claiming that there are *currently* plans to require /var, either on / or via initramfs. The claim being made is that /var suffers from the exact same problem that /usr does, with regard to udev, namely that arbitrary programs running from within udev rules could (and some do) require /var to be present to function. Thus, the arguments being applied to /usr *currently* can be applied equally to /var, once it becomes an issue. The classic example being given is a bluetooth keyboard: to make a bluetooth keyboard available, udev executes a rule which requires /var/bluetooth to be present. (Certain other rules similarly require data from /var, such as sound cards or printers.) The extremely logical deduction being made is as follows: Some udev rules require /usr to be preset to properly execute. The solution favored by the udev maintainer is to simply make /usr always required for udev to run. Running udev without /usr present will become unsupported. Similarly, some udev rules require /var to be present to properly execute. The solution that will be favored by the udev maintainer, when such an issue is raised, is most likely going to be similar to the solution proposed for /usr: the mandating of /var being present before udev runs. Running udev without /var present will most likely become unsupported. Programs designed to run out of /bin expect to be run without any other locations present. Programs designed to run out of /usr/bin generally assume that the rest of the system, including /var, is available for use. You can't have one without the other. --Mike
Re: [gentoo-user] hardened-sources...what?
On 9/22/2011 5:51 PM, Francisco Blas Izquierdo Riera (klondike) wrote: El 22/09/11 22:20, Michael Mol escribió: My question is...what kinds? Well mainly the PaX and the grsecurity patches. I also heard there is a WIP in bringing RSBAC back again too. Does gentoo-sources include the SELinux patches, or was it just being forgotten as usual? :) --Mike
Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)
On 9/15/2011 8:22 PM, Michael Mol wrote: I don't show an ebuild for eclipse (I see dev-java/ant-eclipse-ecj, dev-java/eclipse-ecj and dev-util/eclipse-sdk). Last time I poked eclipse, it was a royal pain using any *DT unless one downloaded it as a packaged deal. Version dependencies were a pain. (That said, I settled into it fairly quickly. But that was a long time ago) You want the one called eclipse-sdk. The actual Eclipse product is just a shell that you can then plug in development environments -- the JDT (for Java) is the default but you can also install the CDT (for C/C++) or tons of others. If you want the latest release of Eclipse you'll have to download or build it yourself; the Ganymeade (3.5) in the ebuild works fine but it doesn't support some of the newer plug-ins built for Helios (3.6) or Indigo (3.7). But 3.6 introduced a *ton* of new dependencies that the Gentoo folks haven't been able to work out properly in portage.[1] Of course, that's also likely an indication that Eclipse is getting way to big for it's own good, especially if you don't want to do any Java development, so you may just want to pass :) --Mike [1] https://bugs.gentoo.org/325271?id=325271
Re: [gentoo-user] udev + /usr
On Wednesday, September 14, 2011 01:36:56 PM Dale wrote: Canek Peláez Valdés wrote: But that's the thing: we (you and me) don't see the situation the same way. To me, the proposed changes are for the better. You are one of very few that feel this way. You are probably correct that he's one of the relatively few people (along with the udev developer, and those few people for whom it will fix their problems) who think these changes are a real improvement. I would estimate that the vast, vast, vast majority of users are those such as myslelf, who have no opinion whatsoever, and either will not be affected at all by these changes (because they don't separate / and /usr), or will simply apply the proposed initramfs solution and move on. Then there are those relatively few people, such as the handful making up the rest of this thread, who think that these changes are a horrible idea and will have a severe deterimental affect on their systems. Not that the relative size of the various sides in this debate is really the issue, but despite the tone of this and the other thread, I don't think there's really a huge, overwhelming outcry against these changes. --Mike
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 11:16:03 PM Joost Roeleveld wrote: On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote: I would estimate that the vast, vast, vast majority of users are those such as myslelf, who have no opinion whatsoever, and either will not be affected at all by these changes (because they don't separate / and /usr), or will simply apply the proposed initramfs solution and move on. You also don't have /var (or /var/log) seperated? Or any of the other parts of the filesystem that might be required by udev-rules? Speaking solely for myself, no. Years ago I routinely split /, /usr, and /var when setting up my FreeBSD systems, and found that it only ever caused problems when I could not get /usr or /var mounted when I needed them. At least since I switched to Gentoo, I've simply set up one partition with everything on it, and kept regular backups in case of failure. I clearly recognize that there are valid reasons to split your partitions, I have just never found any of them applicable to my situations. --Mike
Re: [gentoo-user] udev + /usr
On 9/12/2011 1:17 PM, Alan Mackenzie wrote: Well, I'm a hacker. udev is free source, therefore fair game. I don't intend to put up with this nonsense without a fight. As far as I can make out, this is just one guy, Kay Sievers, who's on a power trip. Are there any indications at all that he actually talked to anybody in the wide world before making such a far reaching decision? http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Re: [gentoo-user] udev + /usr
On 9/13/2011 10:40 AM, Alan Mackenzie wrote: On Mon, Sep 12, 2011 at 07:50:13PM +0200, Michael Schreckenbauer wrote: it works for you, because your udev-rules need nothing from /usr/* It's *not* udev requiring /usr, it's the scripts triggered by the rules. Ah. OK. Maybe I've misunderstood the whole thing. Could it be that there's no explicit requirement for early mounting of /usr, providing one has the discipline to keep everything needed for booting in the / partition? I don't think you are misunderstanding things. According to the originally referenced email thread: --- (From KS@Fedora): We are actually currently planning to move all tools from the rootfs to /usr, where they belong and sort out the chaotic split of install locations. There will be only compat symlinks left in / then. --- The udev package (and, apparently, everything else from Fedora) will, as distributed by the upstream developers, install itself to /usr instead of /. *Right now* udev fails to load a specific device if /usr is not mounted and the udev rule tries to access something in /usr. *In the future* udev will fail to load at all if /usr is not mounted, if the changes progress as they are being proposed. --Mike
Re: [gentoo-user] udev + /usr
On 9/13/2011 8:45 AM, Neil Bothwick wrote: On Tue, 13 Sep 2011 08:38:30 -0400, Mike Edenfield wrote: Well, I'm a hacker. udev is free source, therefore fair game. I don't intend to put up with this nonsense without a fight. As far as I can make out, this is just one guy, Kay Sievers, who's on a power trip. Are there any indications at all that he actually talked to anybody in the wide world before making such a far reaching decision? http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Apart from vague references to us and many upstream developers there is no real indication that this is motivated by any more than the one individual, from his RedHatesque perspective. To be fair, there are *two* names in the wiki edit history :) Though I also recall Mr. Poettering's name being mentioned elsewhere in this thread, also in an anti-everything-thats-not-Fedora context, though I have no personal experience in that arena. --Mike
Re: [gentoo-user] [off-topic] - can /var be placed in a separate partition?
On 9/11/2011 8:28 PM, Albert W. Hopkins wrote: On Sunday, September 11 at 18:54 (-0500), Dale said: I think I saw it mentioned on -dev that some time shortly /usr and /var will be needed on / or you will need the init* thingy to boot. Hmm, that doesn't smell right to me. What I think you may have heard is about /run. systemd and some other things are preferring to move /var/run to /run. The reason being is that /var does not have to be on the root fs. sysdemd needs /run early (before mounting filesystems) so the idea was to put /var/run on the rootfs, thus /run. I don't think /usr should or ever will be required to be on the rootfs. That's just dumb. The reason we have /bin /sbin, etc. is so that /usr need not be on the rootfs. It doesn't make sense to change that well known/established notion. Nope, Dale is exactly correct. If the upcoming changes to udev make it into Gentoo unaltered and unscathed, it will become necessary to have essentially your full system available very early in the boot process -- at least as early as when udev runs. This includes /usr, where I believe the udev scripts and libraries are being moved, and anything that any program in those scripts might access, which almost definitely includes /var. Any setup where only / is mounted when udev's device population happens will become unsupported (if not impossible). The proposed alternative to a single huge partition is to use an initramfs that mounts your separate /usr (and /var) very early in the boot process. --Mike
Re: [gentoo-user] /dev/sda* missing at boot
On 9/12/2011 3:12 AM, Joost Roeleveld wrote: On Saturday, September 10, 2011 02:54:58 AM Dale wrote: If we are so skilled, why is the Fedora dev not listening you reckon? Is the Fedora dev aware of non-Fedora installations? He is, because a Gentoo user/dev explicitly pointed out the problems this will cause Gentoo. His response, to me, appeared to be a heavy dose of way more people use Fedora/Debian/etc than Gentoo so I'm tailoring my fix to those people combined with a touch of if you're running Gentoo you're smart enough to figure this out on your own. Possibly with a subtle, hidden hint of that's what you get for not running Fedora, but I could be imagining that. --Mike
Re: [gentoo-user] /dev/sda* missing at boot
On 9/10/2011 5:28 PM, Alan McKinnon wrote: On Sat, 10 Sep 2011 12:19:10 -0400 Michael Molmike...@gmail.com wrote: On Sat, Sep 10, 2011 at 12:09 PM, Dalerdalek1...@gmail.com wrote: Mick wrote: From my understanding, the dev is not listening. That is another thing that bothers me. When devs stop listening to users, that causes a problem. Remember hal? How many people complained early From what I read, he's listening, he just isn't being swayed by the argument. From his perspective, udev doesn't support a split /,/usr because of the arbitrarily complex udev rules. This is causing users to fill their bug queue with errors when needed binaries are unavailable at boot, and thus their hardware doesn't work. Apparently he has concluded that the number of people who require a separate /usr partition but cannot use an initramfs is smaller than the number of people who need udev to have access to all of /usr. Unfortunately it appears that he's taking a pretty extreme approach to solving the problem that will actually *break* the systems of that second group, which I don't quite understand the reasoning behind. As I understand it, nothing of udev itself is in /usr, but instead packages and scripts which plug themselves into udev to be triggered by various events. Perhaps the real solution is to circumvent udev and get those other packages and scripts to not put hotplug-active files under /usr. That's my understanding too, and I agree with your conclusions. The distros can easily (give enough man-power) deal with this too - they simply have to modify their rpms/debs/pkgs/ebuilds to install specific identified things to / instead of /usr. They *already* do this for packages that natively install to peculiar locations. It would make perfect sense to me for the udev maintainer to simply declare a split /,/usr not supported and let us deal with the issues. The problem, if I'm reading correctly, is that he's taken things one step further and decided to move udev *itself* back into /usr. Even still, I would think that a Gentoo patchset to revert the paths back to /lib would be a feasible workaround to this mess. --Mike
Re: [gentoo-user] Gentoo, new computer, still a bit confused
On 7/22/2011 9:53 PM, CJoeB wrote: Because this will be a new computer and I may essentially void the warranty if I alter the pre-configuration, I seriously thought about leaving the status quo and putting up with Windows 7. However, I would lose practically as much as losing my first born! I would have to put up with all the things that bug me about Windows and I wouldn't have all the programs that I love in Linux. If you are truly concerned about the warranty issue then you would, of course, want to have someone read the actual warrant paperwork that you have. However, typically the only way to void a hardware warranty is to tamper with the hardware. If you replace Windows with Linux on a new PC, you will may lose any free technical support (for software, drivers, etc( you may be entitled to as long as you continue to run this unsupported condition. But if you actually have faulty hardware, they aren't going to refuse to replace or repair it just because you installed software. Plus, Dell in particular supports Linux in a marginally useful way on some of their laptops, so they do have self-help information that would be relevant to you on their site. In the worst case, if you needed to ship your machine back to the manufacturer for repairs, you should receive a set of restore media with any new PC that would allow you to put your system back to factory default, and make your manufacturer more than satisfied. What would you recommend that I used for the iso an stage 3? As a reminder my computer is a Dell XPS 8300 with an Intel Core -i7-2600 processor. I'm a little confused between the choices x86 (which seems to only apply to Pentium 4 systems and only utilizes 32-bit processing), amd64 and ia64. x86 is the name for 32-bit PC processor architecture, such as the older Pentium family, that has been around for decades. (They originally had Intel model numbers like 8086, 80386, 80486, etc.) Very few new PCs are x86 natively, but they will run programs that are meant for x86 machines. This one will work on your Core i7 but is probably not the best choice. amd64 is the name for the 64-bit PC processor architecture, like the Intel Core family processor you have. This is what you'll want to get for your machine. (It's called amd64 in Gentoo because it was originally produced by AMD, but Intel and AMD's current 64-bit processors are compatible and run the same software. Other operating systems call this x64, but it's the same exact hardware.) An x64-based CPU will run x86 programs, but for a source-based distribution like Gentoo there isn't really much benefit to doing so. ia64 is an older and mostly-obsolete Intel attempt at 64-bit processing that was completely incompatible with x86, and came and went very quickly. You can ignore it.
Re: [gentoo-user] Gentoo, new computer, still a bit confused
On 7/23/2011 7:47 AM, Mick wrote: On Saturday 23 Jul 2011 07:25:42 Mike Edenfield wrote: I seem to recall a case where a user wiped their drive clean and installed Ubuntu or some such. The laptop went faulty and the person asked for it to be repaired/replaced under warranty, only to be told that this could not be honoured without the original OS on the machine! I think it was this one: I'm actually speaking from experience here: the first thing I did on my Inspiron was wipe the HD and install Gentoo, only to learn that the wireless card was faulty. And since I could not run the standard Windows diagnostics they couldn't (wouldn't?) help me. So I booted the restore CD, put Windows back, and got a new NIC within about a week. --Mike
Re: [gentoo-user] Gentoo, new computer, still a bit confused
On 7/23/2011 12:49 PM, Neil Bothwick wrote: On Sat, 23 Jul 2011 10:55:11 -0400, Mike Edenfield wrote: I'm actually speaking from experience here: the first thing I did on my Inspiron was wipe the HD and install Gentoo, only to learn that the wireless card was faulty. And since I could not run the standard Windows diagnostics they couldn't (wouldn't?) help me. So I booted the restore CD, put Windows back, and got a new NIC within about a week. What would you have done if the hard drive had failed? I always image the windows disk and then wipe it, but I'm aware that this is not completely reliable. some failures make restoration impossible. If the hard drive failed to the point that I couldn't restore it to factory defaults I suspect they would have a hard time telling if I was running Windows or not :)
Re: [gentoo-user] Re: Thunderbugs
On 7/10/2011 5:20 AM, john wrote: Had a pesky invasion of little insects behind my screen. Of which a lot have seemed to stop moving. Think I'll a get sealed tft next time. I'll try sucking them out with a hoover. Damn things, tft was 350 pounds, you think it should have anti critters device. Thank god. I was starting to wonder at your fixation for British girl groups: http://en.wikipedia.org/wiki/Thunderbugs
[gentoo-user] KDE4 NetworkManager applet?
I've just switched my laptop over to KDE4 to see how it feels on the smaller screen, and I can't find the KDE equivalent of nm-applet. KDE 3's knetworkmanager doesn't compile for me, and when I run the GNOME nm-applet it adds and then immediately removes itself from the notification area. I use NetworkManager for VPN connections so I'd rather not have to switch ti wicd if possible. Is there a KDE equivalent applet or plasmoid or whatever? --Mike
Re: [gentoo-user] Re: Do we have to build gcc with fortran now?
On 6/26/2011 4:01 PM, Dale wrote: Michael Schreckenbauer wrote: Am Sonntag, 26. Juni 2011, 10:28:47 schrieb Dale: Michael Schreckenbauer wrote: Try euse -I fortran. If anything besides gcc pops up, you should have one. That doesn't appear to work like it should then. I get this: root@fireball / # euse -I fortran global use flags (searching: fortran) [+ CD ] fortran - Adds support for fortran (formerly f77) Installed packages matching this USE flag: sys-devel/gcc-4.4.5 local use flags (searching: fortran) no matching entries found root@fireball / # Thing is, I switched it back and programs on here now need fortran to build. So, euse is not reporting it but R and Cantor won't build without fortran. Basically, euse should also report R and cantor but it isn't. If mine isn't reporting that, then Peter's may not either. Neither of those packages has a fortran USE flag, and cantor doesn't know anything about FORTRAN. cantor has an R USE flag, to switch it's R backend on/off. R doesn't have a USE flag for FORTRAN because that would be pointless -- it *requires* an f77 compiler, so it depends on virtual/fortran unconditionally. You would probably be better off using root@platypus ~ # equery depends virtual/fortran dev-python/numpy-1.6.0 (lapack ? virtual/fortran) You will probably have both R and blas in that list as well. If so, you will need to continue to enable gcc[fortran] to build those. (The fact that gcc has a fortran USE flag is only relevant because it's the default compiler; you could also potentially have ifc installed to satisfy virtual/fortran, rendering gcc's USE flag irrelevant.) --Mike
Re: [gentoo-user] Re: Do we have to build gcc with fortran now?
On 6/25/2011 8:04 AM, Dale wrote: We restructured the dependency chain for fortran support, which includes a compile test now. The failure can be seen above. The Problem was in short, USE=fortran was enabled by default for linux arches, but people tend to disable it. Depending on gcc[fortran] doesn't work completely as gcc:4.4[fortran] and gcc:4.5[-fortran] with gcc-4.5 select can be installed, which would full fill the dependency but nevertheless doesn't give a working compiler. So now packages depend on virtual/fortran and use an eclass to check for a working compiler. So if you see this message, this means you somehow worked around gcc[fortran]. That make sense? Yes. He's saying they didn't change the USE flag, they changed the fortran dependency test to actually do a run-time check for fortran because the USE flag alone wasn't sufficient. Which means you most likely had a non-working cantor and no fortran compiler before and just didn't notice :) --Mike
Re: [gentoo-user] Do we have to build gcc with fortran now?
On 6/23/2011 8:31 PM, Neil Bothwick wrote: On Thu, 23 Jun 2011 18:54:14 -0400, Mike Edenfield wrote: It's one package (cantor) that has one dependency (R) that is optional (USE=-R) that falls squarely into the if you aren't sure if you need it then you probably don't category. So for most users, no, you don't need to build gcc with fortran. That's not the only one. Digikam has a hard depend on clapack, which requires virtual/blas and thus a Fortran compiler. Hrm. I installed kde-meta and it didn't pull in Digikam. But I don't remember turning it off (though I would have). I have a completely unreasonable and unjustifiable dislike for FORTRAN so I go out of my way to keep it off my system :)
Re: [gentoo-user] Do we have to build gcc with fortran now?
On 6/24/2011 8:03 AM, Todd Goodman wrote: * Mike Edenfieldkut...@kutulu.org [110623 18:34]: It's one package (cantor) that has one dependency (R) that is optional (USE=-R) that falls squarely into the if you aren't sure if you need it then you probably don't category. So for most users, no, you don't need What seems strange then is that if everyone keeps telling Dale that he most likely doesn't need cantor and R then why is R enabled in the profile by default? It's not enabled in the profile, it's enabled in the ebuild: IUSE=debug ps +R and likely for the same reason there's a scary warning. If you're installing cantor, because you plan to use it (and not because kde-meta is a bloat monster), you need one of the two backends to make it work. R is the preferred option there, so the cantor maintainers assume if you want cantor, you probably want R, and the cascade begins. --Mike
Re: [gentoo-user] Re: Do we have to build gcc with fortran now?
On 6/23/2011 1:04 AM, Dale wrote: Mike Edenfield wrote: On 6/22/2011 2:35 PM, Dale wrote: You have decided to build cantor with no backend. To have this application functional, please do one of below: # emerge -va1 '='kde-base/cantor-4.6.4 with 'R' USE flag enabled # emerge -vaDu sci-mathematics/maxima The odds of you ever needing to use cantor are practically nil. And if you did, you'd probably already have R installed and know what FORTRAN was. So, don't worry about it. I never noticed it being there. So, naw I don't need it. Good ole kde-meta pulled it in tho. My point was, you can install cantor without R (or maxima) and it will complain loudly that I'm installing myself broken!... but it *will* install. And if you never run it, you never need R, thus you never need +fortran, and your gcc will be much happier. --Mike
Re: [gentoo-user] Do we have to build gcc with fortran now?
On 6/23/2011 6:22 PM, Peter Humphrey wrote: On Wednesday 22 June 2011 16:50:10 Dale wrote: If you use KDE like me, be prepared to put the thing back tho. Some KDE packages depend on things that seem to need it enabled. Looks like it's only packages that are pulled in by kdeedu-meta. Do you need all those? It's one package (cantor) that has one dependency (R) that is optional (USE=-R) that falls squarely into the if you aren't sure if you need it then you probably don't category. So for most users, no, you don't need to build gcc with fortran. Dale's just playing it safe, I guess, after the admittedly scary I'm all broken and stuff! warning message cantor throws at you. --Mike
Re: [gentoo-user] portage getting mixed up with USE?
On 6/23/2011 6:31 PM, Alan McKinnon wrote: On Thursday 23 June 2011 23:06:00 Neil Bothwick did opine thusly: b) it breaks the way portage displays his informations. Without autounmask the display of emerge shows what he is going to do. With autounmask it shows what needs to be done. That is probably the most evil of all your reasons. There's an old dev joke about The Law Of Unintended Consequences, and it applies here - portage is now suddenly doing something new and 180 different from what it used to do. The normal response if WTF? followed by lots of indignation Ah, the old we do it that way because that's the way it's always been done argument. Yes, it is different, yes, it may be confusing when you first encounter the change - but that doesn't make it bad. The thing itself is neither inherently good nor bad. Implementing it in this way is bad. Why? Because the behaviour changed to something that is the exact opposite without any warning. Portage always used to tell what it will do. Now, simply by leaving the relevant options at the default, it tells me what it should do. How much more contrary to reasonable expectation can you get? I thought the old behavior was portage would tell me why it's not going to do anything, vs. the new behavior of portage will tell me why it's not going to do anything, plus offer to fix it for me. Unless I'm missing something about the pre-auto-unmask behavior? (Which is entirely likely..) --Mike
Re: [gentoo-user] Re: Do we have to build gcc with fortran now?
On 6/22/2011 9:33 AM, Dale wrote: Nikos Chantziaras wrote: On 06/22/2011 02:18 PM, Dale wrote: Nikos Chantziaras wrote: Uninstall sci-libs/blas-reference I guess. And probably whatever depends on it. Please do an emerge -pv --depclean blas-reference and post the output so we can see what's pulling it as a dep on your system. Here is the output: root@fireball / # emerge -pv --depclean blas-reference Calculating dependencies... done! sci-libs/blas-reference-20070226 pulled in by: virtual/blas-1.0 OK, that didn't help. Try: emerge -pv --depclean virtual/blas Here you go: root@fireball / # emerge -pv --depclean virtual/blas Calculating dependencies... done! virtual/blas-1.0 pulled in by: dev-lang/R-2.10.1 I think the point we're trying to arrive at here is why you need a FORTRAN compiler installed in the first place. Given that you didn't even know you needed one until recently, it seems odd that you've installed packages that require f77 to build. Did you install R on purpose? If not, what pulled that in, and did you install *that* on purpose? Odds are one of your 1.5quadrillion USE flags is pulling in FORTRAN when you don't even need it. --Mike
Re: [gentoo-user] Re: Do we have to build gcc with fortran now?
On 6/22/2011 11:35 AM, Dale wrote: Nikos Chantziaras wrote: I suppose you got the idea by now ;-) Do you need dev-lang/R? If not, then emerge -pv --depclean dev-lang/R. Do you need the package(s) that this brings up? If not, continue --depclean those until you reach something that has no other dependencies; meaning you reached the top level. Do you need *that*? If not, unmerge it, then depclean everything (just emerge -a --depclean.) This should get rid of all stuff you don't actually need/want. Well, that leads back to KDE. So, looks like it stays. Ah. I remember KDE trying to pull in R once before. $ /etc/portage/package/use/kde kde-base/cantor -R
Re: [gentoo-user] Re: Do we have to build gcc with fortran now?
On 6/22/2011 2:35 PM, Dale wrote: When I did that, it complained that cantor was built with no backend. Did you get the same thing? It said this here: WARN (postinst) You have decided to build cantor with no backend. To have this application functional, please do one of below: # emerge -va1 '='kde-base/cantor-4.6.4 with 'R' USE flag enabled # emerge -vaDu sci-mathematics/maxima The odds of you ever needing to use cantor are practically nil. And if you did, you'd probably already have R installed and know what FORTRAN was. So, don't worry about it. --Mike
Re: [gentoo-user] chrome and everything
On 6/2/2011 10:40 AM, Paul Hartman wrote: On Thu, Jun 2, 2011 at 9:23 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Thu, Jun 2, 2011 at 3:49 AM, András Csányi sayusi.a...@gmail.com wrote: Hi All, Something strange happen here. I have seen few things in Linux world but this is very new for me! I have this fantastic browser called Chromium (12.0.742.68) and I really like it. But, sometimes, when I see flash videos on different sites (youtube, cnn, bbc) the whole chromium become frozen and basicly impossible to kill it Flash is behaving like this in every browser on my Gentoo ~amd64 box ever since Flash plugin 10.3 was released. Constantly freezing UI, flash video still showing when when window is closed, etc. With earlier 10.x series it was (mostly) okay, it was definitely usable. With 10.3 so far it is basically a waste of time to try loading any flash objects. Noscript/adblock to the rescue. ;) Replying to myself, it looks like flash plugin 10.3 is only available as 32-bit on linux (so it's using the nspluginwrapper), while 10.2 was 64-bit. So maybe that's part of the explanation in my case. According to Adobe, they have closed the Flash Player 10 for 64-bit Linux program. Given that the only reason I bothered with Flash on Linux was the native 64-bit support, I've masked off adobe-flash-10.3* and have been quite happy with the last 10.2 so far. --Mike
Re: [gentoo-user] Cleaning redundant configuration files
On 6/1/2011 5:47 AM, Alan McKinnon wrote: Apparently, though unproven, at 11:31 on Wednesday 01 June 2011, Indi did opine thusly: On Wed, Jun 01, 2011 at 02:00:01AM +0200, Peter Humphrey wrote: Personally, I'd be livid if portage were to remove my carefully crafted work from time immemorial, without so much as a by-your-leave. Anyone who wants to delete his own work is free to do so, but the rest of us ought not to be required to suffer it. Doesn't matter to me, my longstanding rsync habit ensures there are always a couple of copies of my last known good configuration. Doesn't your carefully crafted work from time immemorial deserve rsync too? [cue rsync jingle] :) That's like saying that just because I have panel-beating skills and lots of scrap metal in the back yard that it's perfectly OK for marauding gangs of thugs to have at my car in the parking lots with baseball bats. Best analogy ever.
Re: [gentoo-user] Two portage questions
On 5/14/2011 11:38 AM, Kevin O'Gorman wrote: On Sat, May 14, 2011 at 3:51 AM, Alan McKinnon /etc/make.profile is a symlink to something in $PORTDIR/profiles/ and that Odd. Not on my system, it's not. I bet it is: kutulu@basement ~ $ ls -l /etc/make.profile lrwxrwxrwx 1 root root 44 Nov 25 12:21 /etc/make.profile - ../usr/portage/profiles/hardened/linux/amd64
Re: [gentoo-user] chicken -- egg (NFS tty video)
On 5/14/2011 12:01 PM, Indi wrote: On Sat, May 14, 2011 at 05:53:56PM +0200, Alan McKinnon wrote: Apparently, though unproven, at 16:37 on Saturday 14 May 2011, Indi did opine thusly: True, just be aware that if you enable gtk *globally* you will end up building the gtk interface for absolutely everything which has that option. Far better (IMO, YMMV) is to use /etc/portage/package.use specify such things per package. Unless, of course, you like having a gtk GUI for everything. :) No, it is much better to enable such a flag globally and *disable* it using package.use where you do *not* want it. Personally, I have better things to do than examine every new or changed package that shows up after avuND world and edit package.us for every single flag in that huge list. Sounds like the old 6 of one, a half-dozen of the other to me... What makes the subtractive method better? Actually its more like the old use whichever way makes sense for the situation. :) Its mostly a matter of probability. If I'm using a GNOME desktop then I probably *do* want the GTK+ for any packages that support it; the same argument goes for KDE and Qt. Similarly, if my system is on a Windows AD domain, I probably want samba, ldap, and kerberos support for any utilities that have it. If I'm using bash completion packages, I don't want to worry about which packages do/don't have one, I just want them installed. These type of flags have essentially the same effect on every package, and as Alan said, there's no need to waste time checking if each package does or doesn't support GTK individually if you're always going to enable it anyway. OTOH, I probably don't want to set a USE flag like 'extras' or 'doc' globally. In those cases I'll turn it on when needed. Similarly, USE flags that only applies to one package (like net-print/hplip snmp scanner hpcups new-hpcups hpijs) don't make sense globally, so they are best left to package.use. --Mike
Re: [gentoo-user] Re: How's the openrc update going for everyone?
On 5/12/2011 5:21 AM, Dale wrote: Mike Edenfield wrote: On 5/11/2011 6:51 PM, Dale wrote: Does this look more better? root@fireball / # locale LC_PAPER=en_US.UTF8 LC_NAME=en_US.UTF8 LC_ADDRESS=en_US.UTF8 LC_TELEPHONE=en_US.UTF8 LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=en_US.UTF8 The others are for tracking: proper name format (e.g. family name first or last); postal address format; telephone number format (local, international, etc); units of measurement (imperial vs. metric); and the standards that govern the rest of the formats. Support for them is pretty sketchy and you can probably safely ignore them :) I wouldn't mind setting them myself. It may not matter much right now but we all know how things change. Going to see what Google can find. They're already set, as your locale output showed :) The definitions of those various formats are built into the locale definitions, so they should have the same value as all your other LC_* variables. You can see your locale's idea of what those things mean in the localedef file (bring alone a Unicode character chart): /usr/share/i18n/locale/en_US --Mike
Re: [gentoo-user] Re: How's the openrc update going for everyone?
On 5/12/2011 9:25 AM, Alan McKinnon wrote: Apparently, though unproven, at 14:54 on Thursday 12 May 2011, Dale did opine thusly: Neil Bothwick wrote: The pattern I see is that of selecting only changes that failed and implying they are the norm. Why not add other improvements that were so bad, like the switch from floppy disks to hard disks, or CDs to DVDs? Companies try to predict where the market should go so they can lead. No one gets it right all the time, the ones that survive are those that get it right often enough. The ones that are most likely to fail are those that never try to innovate in case someone doesn't like it. The important point is that KDE wanted something better, it's unfortunate that it took so much longer than planned, but it would have taken even longer if they had not tried. I just hope they also learned from their mistakes. Dropping KDE3 support long before KDE4 was ready was a big one. That shouldn't be repeated. They can do any damn thing they want to with their code. They also you owe support for it in exactly the same amount you paid for it. Which is to say nothing. It's not a question of should, it's only a question of Dale would prefer it if parent Just because you can do something doesn't mean you should. /parent Of course the KDE3 team had every right to drop KDE3 support whenever they pleased. And we as free consumers had no real recourse other than to stop using KDE and/or deal with it. But it was still a bad decision from a software development standpoint, and one that ideally should not be made again. Perhaps it would be more accurate to say If the KDE4 team expects users to continue to use the software they spend so much of their time making, they shouldn't make that kind of decision again. --Mike
