Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Thu, March 22, 2012 12:55 am, Walter Dnes wrote: On Wed, Mar 21, 2012 at 12:02:32PM -0400, Michael Mol wrote I said this before, but it sounds useful to try to reiterate: * It's probable that service-specific files should not be included in the init system package. * Service-specific init files should probably be part of the distro-localized version of a service-providing package. This doesn't mean modifying binaries, this is part of bootstrapping a service's environment. Call it deferred installation stages, if you like; things which need to be done for the service to be configured and properly operate. My point is that the startup, sanity-checking, and initialization code has to go *SOMEWHERE*. Where do you propose moving it to? This discussion reminds me of an ethnic joke. A bunch of workers had dug out a hole for the basement and foundations where a new house was to be built. The workers ask their foreman what they should do with the pile of dirt they had from digging out the hole for the new house. Their foreman, who is tells them to go dig another hole in the ground and throw the dirt in there. G ... After pushing the foreman in ;) -- Joost
Re: [gentoo-user] InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 00:20:04 +0100 David W Noon dwn...@ntlworld.com wrote: On Thu, 29 Mar 2012 00:26:40 +0200, Alan McKinnon wrote about Re: [gentoo-user] InitRAMFS - boot expert sought: On Wed, 28 Mar 2012 23:01:24 +0100 David W Noon dwn...@ntlworld.com wrote: [snip] With the pending changes to udev scripts, you could well need /var -- and anything else -- before udev starts. So it is in the same category as /usr. Maybe, maybe not. However, no-one apart from you is even suggesting such a thing. For my part I'm going to ignore that possibility and concentrate on those things that are being seriously suggested. The Gentoo developers have been discussing just that. The reason is that many of the daemons that can be started by udev scripts require work files on /var, so we could well need /var mounted too. Which begs the obvious question, Why on earth is udev launching daemons in EARLY BOOT? -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] InitRAMFS - boot expert sought
I forgot one of the commands alan wanted to see. Here it is. allan ajglap gottlieb # fdisk -l Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x4f809fec Device Boot Start End Blocks Id System /dev/sda1 63 80324 40131 de Dell Utility /dev/sda2 * 819203080191915367 HPFS/NTFS/exFAT /dev/sda330801920 114667519419328007 HPFS/NTFS/exFAT /dev/sda4 114667520 976768064 431050272+ 5 Extended /dev/sda5 114667583 125162414 5247416 83 Linux /dev/sda6 125162478 14614330410490413+ 82 Linux swap / Solaris /dev/sda7 146143368 355871879 104864256 8e Linux LVM /dev/sda8 355873928 46073152752428800 83 Linux Disk /dev/mapper/vg-usr: 21.5 GB, 21474836480 bytes 255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/vg-usr doesn't contain a valid partition table Disk /dev/mapper/vg-local: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/vg-local doesn't contain a valid partition table Disk /dev/mapper/vg-var: 16.1 GB, 16106127360 bytes 255 heads, 63 sectors/track, 1958 cylinders, total 31457280 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/vg-var doesn't contain a valid partition table Disk /dev/mapper/vg-tmp: 5368 MB, 5368709120 bytes 255 heads, 63 sectors/track, 652 cylinders, total 10485760 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/vg-tmp doesn't contain a valid partition table Disk /dev/mapper/vg-opt: 5368 MB, 5368709120 bytes 255 heads, 63 sectors/track, 652 cylinders, total 10485760 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/vg-opt doesn't contain a valid partition table Disk /dev/mapper/vg-a: 37.6 GB, 37580963840 bytes 255 heads, 63 sectors/track, 4568 cylinders, total 73400320 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/vg-a doesn't contain a valid partition table
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, 28 Mar 2012 21:16:30 -0500, Dale wrote: It's not a blackbox, unlike a kernel or any other binary, it is a simple cpio archive that you can unpack and inspect. If you want total control, build your own, it is not rocket science. cough cough You sure about that? I have tried building one, then building it inside the kernel then using dracut. Still got issues. If not rocket science, what other degree does a person need? ROFL A degree in reading wiki pages help :P -- Neil Bothwick The facts, although interesting, are irrelevant. signature.asc Description: PGP signature
Re: [gentoo-user] InitRAMFS - boot expert sought
On Wed, 28 Mar 2012 22:21:11 -0400, Michael Mol wrote: There is so much BS being spewed around this topic, I'm genuinely disgusted. It's enough to lead me to suspect that Linux, as a platform, is *dying*. It's not dying, it's evolving - with the associated growing pains. Of course, that's not to say it couldn't evolve the way of the dodo. The true UNIX way is about KISS philosophy. Keep it Simple, Stupid. Keep things small, well-defined and modular. Break things into components, keep the components small and relatively well-defined. That, IMO, is the problem with the current filesystem layout. The split between / and /usr is anything but well-defined. Putting things in different boxes based on their function is good practice. Doing it based on some arbitrary size limit on the box is not. It makes me think of Ubuntu's insistence on fitting their installer on a single CD, even if it means omitting useful software or having the installer sneakily download components in the background. -- Neil Bothwick Bugs are Sons of Glitches signature.asc Description: PGP signature
Re: [gentoo-user] Anyone Else Ping-Ponging with fltk?
On Wed, Mar 28, 2012 at 05:43:00PM +0100, Penguin Lover David W Noon squawked: In that case, the source of the breakage is almost certainly Portage. If a slotted package is in the world file without a slot specification, Portage should really take that to mean all installed slots are required rather than any slot will do -- or, worse still, ignore the world entry and fall back to package dependencies. I disagree. Portage has always been very clear about this: atoms without slot or version specification means precisely **any slot/version will do**. The behaviour is entirely consistent between the command line, ebuilds, the world and set files, as well as other things in the profile (per package use flag and keyword specifications). W
Re: [gentoo-user] chicken/eff issue with suspend-to-disk/hibernate problem [Was: The End Is Near ... or, get the vaseline, they're on the way!]
On Mon, March 19, 2012 3:56 pm, Alex Schuster wrote: William Kenworthy writes: On Sun, 2012-03-18 at 18:30 -0600, Canek Peláez Valdés wrote: My laptop has used dracut since months ago, and suspends/resumes just fine, as it does my media center. Genkernel doesnt, bugs and work arounds on gentoo bugzilla, with angry comments from a dev that it wont be supported and to not file bugs for it - now that dev has moved on I dont know if enough has changed to test the waters and file a bug again. Its missing a hook in the initrd to call the binary that starts the resume process. Huh? I don't use this at the moment, because suspend-to-ram is enough for me, but it (that is, the initramfs part) used to work just fine out of the box for me, also opening my LUKS-encrypted root volume being on LVM. It also seemed to work on another Gentoo PC I installed recently, although TuxOnIce itself does not work so the resume fails. Argh, this suspend to disk stuff NEVER really worked for me, and I tried for years on different systems. I had it working a long time ago, but the last time I tried it I ended up with a bit of a problem: I don't want a swap-partition on the SSD in my netbook. So I want it to use the SD-card that's permanently plugged in. Problem is, it's connected via an internal USB-port and USB is killed before the writing-proces for the suspend-to-disk starts. Anyone know a solution short of rewriting the kernel? ;) -- Joost
Re: [gentoo-user] The End Is Near ... or, get the vaseline, they're on the way!
On Sun, March 18, 2012 8:30 am, Michael Mol wrote: On Sat, Mar 17, 2012 at 11:57 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 17, 2012 at 8:43 PM Mark Knecht markkne...@gmail.com wrote: snip initramfs side of things. I did have to use one to bring up my server with / on a RAID6, not because I needed it long term but in the short term I couldn't determine how mdadm was numbering the RAID so that I could get grub.conf correct. I'm somehow a bot worried something is going to slip by the devs and I'd be better off having an initramfs already running on the box when I do allow the upgrades. Planning on giving Dracut a try. Thanks, Mark The real short of this is that if you use 0.90 superblocks, and /boot on it's own little partition, your kernel can assembly your RAIDwhateverlevel without an initrd image. You will reboot with the /dev/md0 you created as /dev/md0. And unless you have partitions (or is it single drives) over 2TB, you can use metadata=0.90. As they say, Works For Me (R). I've yet to read a simple explanation of HOW-TO do this in a Gentoo doc (not that it doesn't exist), but you can follow this very simple README_RAID used in Slackware to build them on Gentoo: http://slackware.oregonstate.edu/slackware64-current/README_RAID.TXT I recall reading on this list a week or two ago that kernel autoassembly of 0.90 arrays was deprecated. :( Shhh! Please don't tell my production server ;) It might go at some point, especially if they decide that everyone uses initramfs or similar... -- Joost
Re: [gentoo-user] chicken/eff issue with suspend-to-disk/hibernate problem [Was: The End Is Near ... or, get the vaseline, they're on the way!]
On 29/03/2012, at 17:35, J. Roeleveld jo...@antarean.org wrote: On Mon, March 19, 2012 3:56 pm, Alex Schuster wrote: William Kenworthy writes: On Sun, 2012-03-18 at 18:30 -0600, Canek Peláez Valdés wrote: My laptop has used dracut since months ago, and suspends/resumes just fine, as it does my media center. Genkernel doesnt, bugs and work arounds on gentoo bugzilla, with angry comments from a dev that it wont be supported and to not file bugs for it - now that dev has moved on I dont know if enough has changed to test the waters and file a bug again. Its missing a hook in the initrd to call the binary that starts the resume process. Huh? I don't use this at the moment, because suspend-to-ram is enough for me, but it (that is, the initramfs part) used to work just fine out of the box for me, also opening my LUKS-encrypted root volume being on LVM. It also seemed to work on another Gentoo PC I installed recently, although TuxOnIce itself does not work so the resume fails. Argh, this suspend to disk stuff NEVER really worked for me, and I tried for years on different systems. I had it working a long time ago, but the last time I tried it I ended up with a bit of a problem: I don't want a swap-partition on the SSD in my netbook. So I want it to use the SD-card that's permanently plugged in. Problem is, it's connected via an internal USB-port and USB is killed before the writing-proces for the suspend-to-disk starts. Anyone know a solution short of rewriting the kernel? ;) -- Joost try tuxonice - allows you to suspend to a file on disk as well as ram or swap. Added bonus is its much more robust than in-kernel, and the dev (Nigel) is very responsive if help or bugfixes (usually for new kernel versions) are needed. BillK
Re: [gentoo-user] InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 10:28:36 +0200, Alan McKinnon wrote about Re: [gentoo-user] InitRAMFS - boot expert sought: On Thu, 29 Mar 2012 00:20:04 +0100 David W Noon dwn...@ntlworld.com wrote: [snip] The Gentoo developers have been discussing just that. The reason is that many of the daemons that can be started by udev scripts require work files on /var, so we could well need /var mounted too. Which begs the obvious question, Why on earth is udev launching daemons in EARLY BOOT? Your guess is as good as mine! At present, the first thing I see when udev starts is a failed attempt to run /usr/sbin/alsactl to restore the audio levels on my sound card. This occurs before localmount or any other services in the sysinit run-level have been started. Just why anybody wants sound before the disk volumes have been mounted baffles me; I guess people are just desperate for the comforts of stereo. Perhaps my mind simply lacks the sophistication to understand the design of udev. I guess I'll just stick to my 80-column Hollerith cards. ... :-) -- Regards, Dave [RLU #314465] == dwn...@ntlworld.com (David W Noon) == signature.asc Description: PGP signature
[gentoo-user] Re: InitRAMFS - boot expert sought
The 29/03/12, Alan McKinnon wrote: On Thu, 29 Mar 2012 00:20:04 +0100 David W Noon dwn...@ntlworld.com wrote: The Gentoo developers have been discussing just that. The reason is that many of the daemons that can be started by udev scripts require work files on /var, so we could well need /var mounted too. Which begs the obvious question, Why on earth is udev launching daemons in EARLY BOOT? udev launches nothing. udev scripts do. These scripts are not part of udev. -- Nicolas Sebrecht
Re: [gentoo-user] Anyone Else Ping-Ponging with fltk?
On Thu, 29 Mar 2012 11:33:50 +0200, Willie WY Wong wrote about Re: [gentoo-user] Anyone Else Ping-Ponging with fltk?: On Wed, Mar 28, 2012 at 05:43:00PM +0100, Penguin Lover David W Noon squawked: In that case, the source of the breakage is almost certainly Portage. If a slotted package is in the world file without a slot specification, Portage should really take that to mean all installed slots are required rather than any slot will do -- or, worse still, ignore the world entry and fall back to package dependencies. I disagree. Portage has always been very clear about this: atoms without slot or version specification means precisely **any slot/version will do**. In that case, it is a design flaw in Portage. The behaviour is entirely consistent between the command line, ebuilds, the world and set files, as well as other things in the profile (per package use flag and keyword specifications). When I set a flag in package.use without a version specification, it applies to *all* versions of that package that support that use flag. I have been doing this for quite some years for several slotted packages, e.g. wxWidgets. When I manually stabilize a package in package.accept_keywords without a version specification, *all* unmasked versions of that package become stable. I do this for only one package: paludis. -- Regards, Dave [RLU #314465] == dwn...@ntlworld.com (David W Noon) == signature.asc Description: PGP signature
Re: [gentoo-user] Re: InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 14:05:30 +0200, Nicolas Sebrecht wrote: Why on earth is udev launching daemons in EARLY BOOT? udev launches nothing. udev scripts do. These scripts are not part of udev. That is true, but udev provides no control over when these scripts are run. udev starts in early boot, because /some/ of its function is needed then, and it then tries to run rules for all detected hardware. This is a flaw in udev. -- Neil Bothwick In possession of a mind not merely twisted, but actually sprained. signature.asc Description: PGP signature
Re: [gentoo-user] chicken/eff issue with suspend-to-disk/hibernate problem [Was: The End Is Near ... or, get the vaseline, they're on the way!]
On Thu, March 29, 2012 12:40 pm, wdk@moriah wrote: On 29/03/2012, at 17:35, J. Roeleveld jo...@antarean.org wrote: On Mon, March 19, 2012 3:56 pm, Alex Schuster wrote: William Kenworthy writes: On Sun, 2012-03-18 at 18:30 -0600, Canek Peláez Valdés wrote: My laptop has used dracut since months ago, and suspends/resumes just fine, as it does my media center. Genkernel doesnt, bugs and work arounds on gentoo bugzilla, with angry comments from a dev that it wont be supported and to not file bugs for it - now that dev has moved on I dont know if enough has changed to test the waters and file a bug again. Its missing a hook in the initrd to call the binary that starts the resume process. Huh? I don't use this at the moment, because suspend-to-ram is enough for me, but it (that is, the initramfs part) used to work just fine out of the box for me, also opening my LUKS-encrypted root volume being on LVM. It also seemed to work on another Gentoo PC I installed recently, although TuxOnIce itself does not work so the resume fails. Argh, this suspend to disk stuff NEVER really worked for me, and I tried for years on different systems. I had it working a long time ago, but the last time I tried it I ended up with a bit of a problem: I don't want a swap-partition on the SSD in my netbook. So I want it to use the SD-card that's permanently plugged in. Problem is, it's connected via an internal USB-port and USB is killed before the writing-proces for the suspend-to-disk starts. Anyone know a solution short of rewriting the kernel? ;) -- Joost try tuxonice - allows you to suspend to a file on disk as well as ram or swap. Added bonus is its much more robust than in-kernel, and the dev (Nigel) is very responsive if help or bugfixes (usually for new kernel versions) are needed. True, but I don't want to have too many write-actions to the internal SSD, which means that I'd want the file on the SD as well... -- Joost
Re: [gentoo-user] InitRAMFS - boot expert sought
On Wed, March 28, 2012 12:49 am, Mark Knecht wrote: snipped Do nothing. Just read, watch, learn but most important don't do updates. Just wait. Patience is a virtue! I wonder how many threads we'll get with I haven't updated my Gentoo for over a year, how do I best do the upgrade? from people following this advice? -- Joost
Re: [gentoo-user] chicken/eff issue with suspend-to-disk/hibernate problem [Was: The End Is Near ... or, get the vaseline, they're on the way!]
On Thu, 29 Mar 2012 15:51:44 +0200, J. Roeleveld wrote: try tuxonice - allows you to suspend to a file on disk as well as ram or swap. Added bonus is its much more robust than in-kernel, and the dev (Nigel) is very responsive if help or bugfixes (usually for new kernel versions) are needed. I'd question this seeing as it hasn't been released for kernel 3.1 or later. Not that it is a bad choice, it is not, but it is certainly not keeping up. True, but I don't want to have too many write-actions to the internal SSD, which means that I'd want the file on the SD as well... TuxOnIce lets you specify where you want the hibernate file. -- Neil Bothwick X-Modem- A device on the losing end of an encounter with lightning. signature.asc Description: PGP signature
Re: [gentoo-user] InitRAMFS - boot expert sought
On Wed, Mar 28, 2012 at 19:20, David W Noon dwn...@ntlworld.com wrote: On Thu, 29 Mar 2012 00:26:40 +0200, Alan McKinnon wrote about Re: [gentoo-user] InitRAMFS - boot expert sought: On Wed, 28 Mar 2012 23:01:24 +0100 David W Noon dwn...@ntlworld.com wrote: [snip] With the pending changes to udev scripts, you could well need /var -- and anything else -- before udev starts. So it is in the same category as /usr. Maybe, maybe not. However, no-one apart from you is even suggesting such a thing. For my part I'm going to ignore that possibility and concentrate on those things that are being seriously suggested. The Gentoo developers have been discussing just that. The reason is that many of the daemons that can be started by udev scripts require work files on /var, so we could well need /var mounted too. But wait, that's what having /var/run being a link to /run was all about. This problem is supposed to be *solved* already, damnit -- Douglas J Hunley (doug.hun...@gmail.com) Twitter: @hunleyd Web: douglasjhunley.com G+: http://goo.gl/sajR3
Re: [gentoo-user] InitRAMFS - boot expert sought
On Thu, Mar 29, 2012 at 5:02 AM, Neil Bothwick n...@digimed.co.uk wrote: On Wed, 28 Mar 2012 22:21:11 -0400, Michael Mol wrote: There is so much BS being spewed around this topic, I'm genuinely disgusted. It's enough to lead me to suspect that Linux, as a platform, is *dying*. It's not dying, it's evolving - with the associated growing pains. Of course, that's not to say it couldn't evolve the way of the dodo. The problem is the lack of engineering sense. The true UNIX way is about KISS philosophy. Keep it Simple, Stupid. Keep things small, well-defined and modular. Break things into components, keep the components small and relatively well-defined. That, IMO, is the problem with the current filesystem layout. The split between / and /usr is anything but well-defined. Putting things in different boxes based on their function is good practice. Doing it based on some arbitrary size limit on the box is not. Except that's not what people are doing. According to what I've read, that was the original rationale a couple decades ago, but that hasn't been the driving case for it for a long time, and pointing to it in a modern context is silly. These days, you put things on different mount points because you want different underlying characteristics either in the filesystem or its underlying block device. The gripe about the filesystem layout strikes me as a it works, but it isn't clean or elegant complaint. That means changing it is change for change's sake. And we're going to experience these growing pains tenfold as the consequences of that play out. If I was comfortable with *any* other platform as much as I've been with Gentoo these past couple years, I'd be jumping ship immediately. It makes me think of Ubuntu's insistence on fitting their installer on a single CD, even if it means omitting useful software or having the installer sneakily download components in the background. -- :wq
Re: [gentoo-user] InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 10:21:15 -0400, Michael Mol wrote: That, IMO, is the problem with the current filesystem layout. The split between / and /usr is anything but well-defined. Putting things in different boxes based on their function is good practice. Doing it based on some arbitrary size limit on the box is not. Except that's not what people are doing. According to what I've read, that was the original rationale a couple decades ago, but that hasn't been the driving case for it for a long time, and pointing to it in a modern context is silly. No, that's not the reason for doing it now. The reason for doing it now has been applied to the previous solution (generally a bad idea) and is aimed at making / a self-contained bootable system, which is a movable target as hardware evolves. These days, you put things on different mount points because you want different underlying characteristics either in the filesystem or its underlying block device. And for the vast majority of use cases, separating /bin and /usr/bin does not make much sense. The gripe about the filesystem layout strikes me as a it works, but it isn't clean or elegant complaint. That means changing it is change for change's sake. And we're going to experience these growing pains tenfold as the consequences of that play out. It's never been clean or elegant, but it was tolerated and worked around. Now those that are trying to work around it have said they are no longer going to do so, which is their choice. If the separate /usr had been allowed to die when 20MB hard disks were around, this whole situation would never have arisen. The trouble with shit hitting the fan is that the longer you wait the more there is to spread around :( -- Neil Bothwick Oxymoron: Clearly Misunderstood. signature.asc Description: PGP signature
[gentoo-user] emerge haskell-opengl-2.2.1.1 failed
Hello list, this is my first posting to this mailinglist since I recently switched to Gentoo. I worked a few years with ArchLinux, then dumped it for FreeBSD and - due to getting a new Laptop (Thinkpad X220) - I considered switching back to Linux. So, here I am. I tried to install haskell-platform (the overlay, that is) and it got me into the following problem: emerging haskell-opengl-2.2.1.1 failed. I append the build.log. Thanks in advance, greetings from Cologne, Christian Lask. The build.log residing in /var/tmp/portage/dev-haskell/opengl-2.2.1.1/temp/: * Package:dev-haskell/opengl-2.2.1.1 * Repository: gentoo-haskell * Maintainer: hask...@gentoo.org * USE:amd64 elibc_glibc kernel_linux multilib userland_GNU * FEATURES: sandbox Unpacking source... Unpacking OpenGL-2.2.1.1.tar.gz to /var/tmp/portage/dev-haskell/opengl-2.2.1.1/work Source unpacked in /var/tmp/portage/dev-haskell/opengl-2.2.1.1/work Compiling source in /var/tmp/portage/dev-haskell/opengl-2.2.1.1/work/OpenGL-2.2.1.1 ... * Using cabal-1.14.0. /usr/bin/ghc -package Cabal-1.14.0 --make /var/tmp/portage/dev-haskell/opengl-2.2.1.1/work/OpenGL-2.2.1.1/Setup.hs -dynamic -o setup [1 of 1] Compiling Main ( /var/tmp/portage/dev-haskell/opengl-2.2.1.1/work/OpenGL-2.2.1.1/Setup.hs, /var/tmp/portage/dev-haskell/opengl-2.2.1.1/work/OpenGL-2.2.1.1/Setup.o ) /var/tmp/portage/dev-haskell/opengl-2.2.1.1/work/OpenGL-2.2.1.1/Setup.hs:3:1: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks Linking setup ... ./setup configure --ghc --prefix=/usr --with-compiler=/usr/bin/ghc --with-hc-pkg=/usr/bin/ghc-pkg --prefix=/usr --libdir=/usr/lib64 --libsubdir=opengl-2.2.1.1/ghc-7.4.1 --datadir=/usr/share/ --datasubdir=opengl-2.2.1.1/ghc-7.4.1 --ghc-option=-optl-Wl,-O1 --ghc-option=-optl-Wl,--as-needed --disable-executable-stripping --docdir=/usr/share/doc/opengl-2.2.1.1 --verbose Warning: defaultUserHooks in Setup script is deprecated. Configuring OpenGL-2.2.1.1... Dependency base -any: using base-4.5.0.0 Using Cabal-1.14.0 compiled by ghc-7.4 Using compiler: ghc-7.4.1 Using install prefix: /usr Binaries installed in: /usr/bin Libraries installed in: /usr/lib64/opengl-2.2.1.1/ghc-7.4.1 Private binaries installed in: /usr/libexec Data files installed in: /usr/share/opengl-2.2.1.1/ghc-7.4.1 Documentation installed in: /usr/share/doc/opengl-2.2.1.1 No alex found Using ar found on system at: /usr/bin/ar No c2hs found No cpphs found No ffihugs found Using gcc version 4.5.3 found on system at: /usr/bin/gcc Using ghc version 7.4.1 given by user at: /usr/bin/ghc Using ghc-pkg version 7.4.1 given by user at: /usr/bin/ghc-pkg No greencard found No haddock found No happy found No hmake found Using hpc version 0.6 found on system at: /usr/bin/hpc Using hsc2hs version 0.67 found on system at: /usr/bin/hsc2hs No hscolour found No hugs found No jhc found Using ld found on system at: /usr/bin/ld No lhc found No lhc-pkg found No nhc98 found Using pkg-config version 0.26 found on system at: /usr/bin/pkg-config Using ranlib found on system at: /usr/bin/ranlib Using strip found on system at: /usr/bin/strip Using tar found on system at: /bin/tar No uhc found sh configure --with-hc=/usr/bin/ghc --with-hc-pkg=/usr/bin/ghc-pkg --prefix=/usr --libdir=/usr/lib64 --datadir=/usr/share/ --with-gcc=/usr/bin/gcc checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for Windows environment... no checking how to run the C preprocessor... gcc -E checking for X... libraries , headers checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for atan... no checking for atan in -lm... yes checking for GL library... -lGL -lm checking for GLU library... -lGLU -lGL -lm checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
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. I think that qualifies the initramfs solution as ugly. 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. 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. [ 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. I accept that this solution will never happen. Sadly. --Mike -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] InitRAMFS - boot expert sought
On Thu, Mar 29, 2012 at 10:43 AM, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 29 Mar 2012 10:21:15 -0400, Michael Mol wrote: That, IMO, is the problem with the current filesystem layout. The split between / and /usr is anything but well-defined. Putting things in different boxes based on their function is good practice. Doing it based on some arbitrary size limit on the box is not. Except that's not what people are doing. According to what I've read, that was the original rationale a couple decades ago, but that hasn't been the driving case for it for a long time, and pointing to it in a modern context is silly. No, that's not the reason for doing it now. For the sake of sane conversation, then, don't use phrases like Putting things in different boxes based on their function is good practice. Doing it based on some arbitrary size limit on the box is not. unless it has present context. Referencing an environmental constraint from twenty years ago in current-context discussion about system engineering only clouds the issue. This is part of the problem around this whole conversation dating back to *last summer*; things are referenced outside of their useful context, are presumed to be part of the current context, and get mixed in. It all becomes a confusing mess. The reason for doing it now has been applied to the previous solution (generally a bad idea) and is aimed at making / a self-contained bootable system, which is a movable target as hardware evolves. I don't think I've seen this adequately described or explained, honestly. How is the target moving? If someone wants to put / on a filesystem that the kernel doesn't have automagic support for, I can see that. Otherwise...not really. These days, you put things on different mount points because you want different underlying characteristics either in the filesystem or its underlying block device. And for the vast majority of use cases, separating /bin and /usr/bin does not make much sense. For the vast majority of use cases, having more than one display or keyboard doesn't make sense, either. For the vast majority of use cases, one shouldn't need more than one desktop environment installed. For the vast majority of use cases, one shouldn't need more than one optical drive, or more than one USB stick, or more than one authentication backend. That doesn't mean those use cases should be discarded. It means the system should be designed to be flexible. It makes about exactly as much sense for /bin and /usr/bin to be separate directories as it makes sense to mirror the bulk of an OS into a cpio blob that will be loaded into RAM. The initramfs likely won't even fit into some production systems' RAM. I know a talented professional sysadmin/IT guy who has most of his production VMs running some variant of RHEL or CentOS, with only 64M of RAM apiece. Because that makes *sense* when physical RAM may be cheap, but your virtualization vendor bilks you for the difference. So, OK. System bloats again, we can deal. We've been dealing with increasing RAM, disk and CPU requirements for decades. We've even stopped deriding Microsoft for having a bloated platform, given that we can't fend off the bloat ourselves. We eat some crow and move on. Apple and Android's lightweight-by-comparison 'our way or the highway' platform mentalities gain traction and outperform us. So where do we go from here? We have an initramfs which is painfully difficult to keep up to date by hand, as more and more uber-cool things will evolve dependencies on being present early-on. We'll *need* an automated means of keeping the initramfs up-to-date, because not everything supports static linking, and hand-walking the dynamic linking chain is crazy talk. Which means automated tools. These automated tools are going to have to deal with at least as bad an issue of moving targets as keeping / bootable was; they're a full layer of abstraction away from the main system than / was. The gripe about the filesystem layout strikes me as a it works, but it isn't clean or elegant complaint. That means changing it is change for change's sake. And we're going to experience these growing pains tenfold as the consequences of that play out. It's never been clean or elegant, but it was tolerated and worked around. Now those that are trying to work around it have said they are no longer going to do so, which is their choice. I love how this is described as hey, the decision has been made. It's here to stay. I love how the people described as They are treated as infallible, and the decisions perfect and final. There have been dozens of intelligent suggestions coming from intelligent and well-meaning people, including people making arguments in good faith. They were told they have to either bend over or code. And when they started coding, they got mocked. It's really only going to be upstream's choice until someone takes the choice away from them, either from users
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, 29 Mar 2012 15:56:28 +, Alan Mackenzie 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. I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. Lots? For most people busybox is enough! If you want encrypted filesystems on LVM over RAID that rises to a total of four executables. (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. That's wrong. For example, LVM builds dynamic executable plus the lvm.static file for use in the initramfs. (iv) The initramfs requires a potentially long script to make it work. Mount /proc, /sys and /dev. Mount root Unmount /proc, /sys and /dev. switch_root I think that qualifies the initramfs solution as ugly. Only if you build the initramfs with USE=fud. 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 an excellent idea. I accept that this solution will never happen. Sadly. It's already happened here. My kernel mounts / and /usr thanks to the inbuilt initramfs -- Neil Bothwick I just bought a microwave fireplace... You can spend an evening in front of it in only eight minutes... signature.asc Description: PGP signature
Re: [gentoo-user] InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 10:08:40 -0400, Doug Hunley wrote about Re: [gentoo-user] InitRAMFS - boot expert sought: On Wed, Mar 28, 2012 at 19:20, David W Noon dwn...@ntlworld.com wrote: [snip] The Gentoo developers have been discussing just that. The reason is that many of the daemons that can be started by udev scripts require work files on /var, so we could well need /var mounted too. But wait, that's what having /var/run being a link to /run was all about. This problem is supposed to be *solved* already, damnit That's okay for PID files, but udev scripts are supposed to be allowed to run *anything*. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 29 Mar 2012 15:56:28 +, Alan Mackenzie 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. I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. Lots? For most people busybox is enough! If you want encrypted filesystems on LVM over RAID that rises to a total of four executables. And anything they might conceivably link to. Not everything supports static linking. 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. (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. That's wrong. For example, LVM builds dynamic executable plus the lvm.static file for use in the initramfs. That's exactly what Alan just noted in (ii), but perhaps portage handles (iii) in the case of LVM. (iv) The initramfs requires a potentially long script to make it work. Mount /proc, /sys and /dev. Mount root Unmount /proc, /sys and /dev. switch_root Things look much simpler when you abstract away the details. You still have to manage lvm, mdraid and whatever else is necessary for mounting things. That's where 'potentially long' came from, I expect. I think that qualifies the initramfs solution as ugly. Only if you build the initramfs with USE=fud. FUD: Fear, uncertainty and doubt In short, three things which are important to rationally examine and deal with on a case-by-case basis. Fear of risk is healthy when trying to maintain something. Uncertainty is expected when you first launch into some brave, new world, and it's necessary to to learn things well enough to be able to rule out uncertain conditions. That's an intrinsic part of systemic stability. Doubt is another word for risk analysis. What are the chances this will fail, versus the chance that that will fail? What's the cost of each of these failures. -- :wq
Re: [gentoo-user] InitRAMFS - boot expert sought
On 2012-03-29 01:20, Neil Bothwick wrote: I'm in favour of /bin and /lib, and I see the pros and cons of /sbin and am not too bothered about how that is done. But having two (or more) of each of these is an artificial mess that is a solution to a problem that As I said, it's a matter of taste. Red Hat employ devs working on many aspects of Linux, and we should be grateful for this (or do you prefer the Ubuntu approach of taking with little giving back?). One of the reasons Greg K-H left SUSE to work for I did say that my writing was speculative? And I never claimed Greg K-H is/was working for Redhat. Anyway, for the record I have always had a great respect and admiration for both Redhat and Greg K-H (which I see as a very good and knowledgeable kernel hacker) but this latest debacle has taken it down a few notches... On the other hand I would prefer Ubuntus approach to someone (anyone) pushing bad designs any day (speaking hypothetically and generally without pointing out anyone or any company). But this is quite pointless (my whining) since, as someone else mentioned, code talks Perhaps some day I can find the time to hack my own solution (which of course will be perfection ;-) ). :-) Best regards Peter K
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Evening, Neil. On Thu, Mar 29, 2012 at 05:35:35PM +0100, Neil Bothwick wrote: On Thu, 29 Mar 2012 15:56:28 +, Alan Mackenzie wrote: 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 an excellent idea. I accept that this solution will never happen. Sadly. It's already happened here. My kernel mounts / and /usr thanks to the inbuilt initramfs That's exactly what I didn't mean, and I think you might have been aware of that. What I did mean was being able to mount subsequent partitions by giving kernel parameters in the boot loader configuration file. Something like mount=8,3:/usr for mount /dev/sda3 /usr. This would avoid the need to spend any effort whatsoever on building an initramfs, yet /usr would be mounted early in boot. -- Neil Bothwick -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] InitRAMFS - boot expert sought
J. Roeleveld wrote: On Wed, March 28, 2012 12:49 am, Mark Knecht wrote: snipped Do nothing. Just read, watch, learn but most important don't do updates. Just wait. Patience is a virtue! I wonder how many threads we'll get with I haven't updated my Gentoo for over a year, how do I best do the upgrade? from people following this advice? -- Joost I was thinking about that. My system works right now. I could just not update for a good long while before doing any updates. Maybe the udev dev will do like the hal guy, admit he screwed up and fix it so that it runs as it should and leave it like it used to be. Also, it is getting warm here. I don't need the extra heat from compiling anyway. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, 29 Mar 2012 17:29:11 +, Alan Mackenzie wrote: It's already happened here. My kernel mounts / and /usr thanks to the inbuilt initramfs That's exactly what I didn't mean, and I think you might have been aware of that. Maybe, but it does fit your description. What I did mean was being able to mount subsequent partitions by giving kernel parameters in the boot loader configuration file. Something like mount=8,3:/usr for mount /dev/sda3 /usr. This would avoid the need to spend any effort whatsoever on building an initramfs, yet /usr would be mounted early in boot. That sounds like a simple and elegant idea, and the kernel already contains the code to mount filesystems. However, it doesn't handle dm-crypt or LVM and putting all that in the kernel could be more complex than putting the initramfs to do it in the kernel. However, if it could be made to work , it would be a neat approach. -- Neil Bothwick Master of all I survey (at the moment, empty pizza boxes) signature.asc Description: PGP signature
Re: [gentoo-user] InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 19:14:31 +0200, pk wrote: But this is quite pointless (my whining) since, as someone else mentioned, code talks Perhaps some day I can find the time to hack my own solution (which of course will be perfection ;-) ). I wait with bated breath. Even if less than perfect, it will be better than mine :) -- Neil Bothwick Found my .sig, it was in behind the cushion on the settee. signature.asc Description: PGP signature
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?
On Thu, 29 Mar 2012 13:13:40 -0400, Michael Mol wrote: On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick n...@digimed.co.uk wrote: I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. Lots? For most people busybox is enough! If you want encrypted filesystems on LVM over RAID that rises to a total of four executables. And anything they might conceivably link to. Not everything supports static linking. Those four all have static version, there are no libraries in my initramfs. 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. (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. That's wrong. For example, LVM builds dynamic executable plus the lvm.static file for use in the initramfs. That's exactly what Alan just noted in (ii), but perhaps portage handles (iii) in the case of LVM. Exactly, there are static and dynamic files, all handled by portage. (iv) The initramfs requires a potentially long script to make it work. Mount /proc, /sys and /dev. Mount root Unmount /proc, /sys and /dev. switch_root Things look much simpler when you abstract away the details. You still have to manage lvm, mdraid and whatever else is necessary for mounting things. That's where 'potentially long' came from, I expect. I think that qualifies the initramfs solution as ugly. Only if you build the initramfs with USE=fud. FUD: Fear, uncertainty and doubt In short, three things which are important to rationally examine and deal with on a case-by-case basis. Yes, ideally before you start spreading them instead of vague handwaving about initramfs being ugly and using lots of files (four only counts at lots when applied to wives). -- Neil Bothwick Loose bits sink chips. signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, Mar 29, 2012 at 2:11 PM, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 29 Mar 2012 13:13:40 -0400, Michael Mol wrote: On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick n...@digimed.co.uk wrote: I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. Lots? For most people busybox is enough! If you want encrypted filesystems on LVM over RAID that rises to a total of four executables. And anything they might conceivably link to. Not everything supports static linking. Those four all have static version, there are no libraries in my initramfs. Which is good. 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. That's been a long tradition in open source software and hacker culture. In short, depending on things only being used when they're intended to be used, in the circumstances they're intended to be used in, is sticking one's head into the sand. Workarounds will always arise to break such expectations and assumptions. (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. That's wrong. For example, LVM builds dynamic executable plus the lvm.static file for use in the initramfs. That's exactly what Alan just noted in (ii), but perhaps portage handles (iii) in the case of LVM. Exactly, there are static and dynamic files, all handled by portage. (iv) The initramfs requires a potentially long script to make it work. Mount /proc, /sys and /dev. Mount root Unmount /proc, /sys and /dev. switch_root Things look much simpler when you abstract away the details. You still have to manage lvm, mdraid and whatever else is necessary for mounting things. That's where 'potentially long' came from, I expect. I think that qualifies the initramfs solution as ugly. Only if you build the initramfs with USE=fud. FUD: Fear, uncertainty and doubt In short, three things which are important to rationally examine and deal with on a case-by-case basis. Yes, ideally before you start spreading them instead of vague handwaving about initramfs being ugly and using lots of files (four only counts at lots when applied to wives). Fine. NFS clients. Samba clients. Crypto. SSHFS. NTFS-3g. Security auditing. Virtualization tools. Perl, python or whatever is necessary to handle some case which required scripting. X. Graphics loading libraries. Cupsd, because some graphics library required by a bootsplash expressed a dependency on cairo, which expressed a dependency on something else, which expressed a dependency on cups. Perhaps crypto required a crypto daemon to be loaded, which required a smartcard, or required auth from a serial port or network connection. Perhaps an accurate clock is needed. Or perhaps a network policy demands that a machine be authorized to boot, so an LDAP client is required. It's easy to imagine entirely plausible circumstances which would bloat initramfs size and maintenance. At some point in time, these various things would normally be the simplest and most straightforward way to reach a quick end to some problem or another for some poor guy stuck in a private hell. And this initramfs crap increases the amount of work he has to do to solve his unique case. -- :wq
Re: [gentoo-user] InitRAMFS - boot expert sought
On 2012-03-29 20:06, Neil Bothwick wrote: I wait with bated breath. Even if less than perfect, it will be better than mine :) I'll be sure to let you know if I find perfection... Perhaps an AI system that takes care of it self and serves me drinks (with or without an umbrella) while I lay on my couch doing whatever I see fit (since the bots controlled by the AI have taken over the boring chores I have all this free time)? On the other hand such a solution would most likely malfunction and hit me on the head with the shaker, pour it's contents all over me and chase me around with something sharp... ;-) Best regards Peter K
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: Can you try doing dracut -H /boot/initramfs-kernel version here ?? The man page from dracut says that -H is for the current host instead of a generic host. Maybe the generic host configuration is messing up something with su that your actual host configuration needs. I use -H. As I have ben saying, my initramfs it's pretty up in sync with my normal system. Regards. Notice, I make the distinction between Console and Konsole by making the first letter capitalized. It kind of gets confusing. :/ 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. So, boot without init thingy, everything works fine. Boot with the init thingy, I can't access things in KDE as root. All I do is reboot. I don't change or edit anything other than selecting a different entry in grub. I use Konsole when I emerge and such as that. I use Krusader, since Konqueror developed a bug, to edit config files. I don't care to switch to a Console to emerge something or edit a config file. This is not going to work for me long term. Also, keep in mind, I boot the EXACT same kernel whether I use the init thingy or not. All I do is remove the stuff the init thingy needs to work. Go figure. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, Mar 29, 2012 at 2:15 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: Can you try doing dracut -H /boot/initramfs-kernel version here ?? The man page from dracut says that -H is for the current host instead of a generic host. Maybe the generic host configuration is messing up something with su that your actual host configuration needs. I use -H. As I have ben saying, my initramfs it's pretty up in sync with my normal system. Regards. Notice, I make the distinction between Console and Konsole by making the first letter capitalized. It kind of gets confusing. :/ 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. So, boot without init thingy, everything works fine. Boot with the init thingy, I can't access things in KDE as root. All I do is reboot. I don't change or edit anything other than selecting a different entry in grub. I use Konsole when I emerge and such as that. I use Krusader, since Konqueror developed a bug, to edit config files. I don't care to switch to a Console to emerge something or edit a config file. This is not going to work for me long term. Also, keep in mind, I boot the EXACT same kernel whether I use the init thingy or not. All I do is remove the stuff the init thingy needs to work. Go figure. I'm a little confused: you log in KDE as a regular user, open a Konsole, type su -, and what happens? What do you mean with Konsole won't even try to come up? In the shell that Krusader provides (which I assume you run as a regular user), what it's the result of which su? And also, what happens when (inside the shell from Krusader) you run /bin/su? If not for the fact that you say that in a virtual console su works, I would be willing to suggest that your initramfs never does the switch_root, and so you end up with the minimal / from the initramfs, and your normal /usr. That would be beyond bizarre, but if you *can* use su in a virtual console, then it should be there. I usally log in in GNOME, open a gnome-terminal, and set a fixed number of tabs in gnome-terminal where I su -, and work as root in there. I also can run an X11 program as root with su -lc /usr/bin/gedit, but I almost never do that (although it works; I just checked). I don't think I understand how do you use su. Could you explain it to me, please? One last thing: create a directory /tmp/whatever, and inside it unpack your initramfs: zcat /boot/init-thingie | cpio -i Could you do a ls -R /tmp/whatever so we can see what actually ends up in yout initramfs? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 14:05:30 +0200 Nicolas Sebrecht nsebre...@piing.fr wrote: The 29/03/12, Alan McKinnon wrote: On Thu, 29 Mar 2012 00:20:04 +0100 David W Noon dwn...@ntlworld.com wrote: The Gentoo developers have been discussing just that. The reason is that many of the daemons that can be started by udev scripts require work files on /var, so we could well need /var mounted too. Which begs the obvious question, Why on earth is udev launching daemons in EARLY BOOT? udev launches nothing. udev scripts do. These scripts are not part of udev. 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. 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. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 13:01:49 +0100 David W Noon dwn...@ntlworld.com wrote: On Thu, 29 Mar 2012 10:28:36 +0200, Alan McKinnon wrote about Re: [gentoo-user] InitRAMFS - boot expert sought: On Thu, 29 Mar 2012 00:20:04 +0100 David W Noon dwn...@ntlworld.com wrote: [snip] The Gentoo developers have been discussing just that. The reason is that many of the daemons that can be started by udev scripts require work files on /var, so we could well need /var mounted too. Which begs the obvious question, Why on earth is udev launching daemons in EARLY BOOT? Your guess is as good as mine! At present, the first thing I see when udev starts is a failed attempt to run /usr/sbin/alsactl to restore the audio levels on my sound card. This occurs before localmount or any other services in the sysinit run-level have been started. Just why anybody wants sound before the disk volumes have been mounted baffles me; I guess people are just desperate for the comforts of stereo. Perhaps the ability to hear the computer go bing when volumes mount is a killer marketing feature Reminds me of Sigourney Weaver's character in Galaxy Quest - she was the bimbo who announced to the room whenever the computer went bing Perhaps my mind simply lacks the sophistication to understand the design of udev. I guess I'll just stick to my 80-column Hollerith cards. ... :-) -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
* Dale rdalek1...@gmail.com [120329 16:22]: Canek Peláez Valdés wrote: Can you try doing dracut -H /boot/initramfs-kernel version here ?? The man page from dracut says that -H is for the current host instead of a generic host. Maybe the generic host configuration is messing up something with su that your actual host configuration needs. I use -H. As I have ben saying, my initramfs it's pretty up in sync with my normal system. Regards. Notice, I make the distinction between Console and Konsole by making the first letter capitalized. It kind of gets confusing. :/ 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. So, boot without init thingy, everything works fine. Boot with the init thingy, I can't access things in KDE as root. All I do is reboot. I don't change or edit anything other than selecting a different entry in grub. I use Konsole when I emerge and such as that. I use Krusader, since Konqueror developed a bug, to edit config files. I don't care to switch to a Console to emerge something or edit a config file. This is not going to work for me long term. Also, keep in mind, I boot the EXACT same kernel whether I use the init thingy or not. All I do is remove the stuff the init thingy needs to work. Go figure. Dale :-) :-) My dracut initramfs (created with just hostonly=yes changed from the config installed by Gentoo) is quite heavy and starts up udevd in the initramfs. That along with other things that happen in there could possibly be leading to your permission problems. If I were you, I'd manually create an initramfs the way that Neil has mentioned that simply mounts /usr and then does a switch_root and see if you still have problems. It's really not too hard if you can muddle through simple shell scripts. Todd
Re: [gentoo-user] InitRAMFS - boot expert sought
On 2012-03-29 22:58, Alan McKinnon wrote: Reminds me of Sigourney Weaver's character in Galaxy Quest - she was the bimbo who announced to the room whenever the computer went bing :-D An underrated movie which contains a lot of geek and Star Trek/SciFi in general parody... Thumbs up! :-D Best regards Peter K
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Todd Goodman wrote: * Dale rdalek1...@gmail.com [120329 16:22]: Canek Peláez Valdés wrote: Can you try doing dracut -H /boot/initramfs-kernel version here ?? The man page from dracut says that -H is for the current host instead of a generic host. Maybe the generic host configuration is messing up something with su that your actual host configuration needs. I use -H. As I have ben saying, my initramfs it's pretty up in sync with my normal system. Regards. Notice, I make the distinction between Console and Konsole by making the first letter capitalized. It kind of gets confusing. :/ 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. So, boot without init thingy, everything works fine. Boot with the init thingy, I can't access things in KDE as root. All I do is reboot. I don't change or edit anything other than selecting a different entry in grub. I use Konsole when I emerge and such as that. I use Krusader, since Konqueror developed a bug, to edit config files. I don't care to switch to a Console to emerge something or edit a config file. This is not going to work for me long term. Also, keep in mind, I boot the EXACT same kernel whether I use the init thingy or not. All I do is remove the stuff the init thingy needs to work. Go figure. Dale :-) :-) My dracut initramfs (created with just hostonly=yes changed from the config installed by Gentoo) is quite heavy and starts up udevd in the initramfs. That along with other things that happen in there could possibly be leading to your permission problems. If I were you, I'd manually create an initramfs the way that Neil has mentioned that simply mounts /usr and then does a switch_root and see if you still have problems. It's really not too hard if you can muddle through simple shell scripts. Todd I already tried making one from scratch and also making the one inside the kernel. Both belly flopped and left me with nothing but errors. It never even tried to leave the init thingy environment. I think I posted them a good long while back but no clue what they were know. I just moved on to what was supposed to be easy. Yea, right. :/ My concern is this, if it is this hard for me to get one working, if it ever breaks, I'm screwed. I know myself pretty well, if it breaks and I can't figure it out, I'll be looking for a install CD/DVD and fix it on a grand scale. This is how I got to Gentoo. I couldn't get Mandrake to work right and be stable, I switched. Well, it's supper time here. Maybe that will help, me at least. lol Dale :-) :-) P. S. Canek, will post in a bit for yours. -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
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?
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. -- Neil Bothwick Electrocution, n.: Burning at the stake with all the modern improvements. signature.asc Description: PGP signature
Re: [gentoo-user] chicken/eff issue with suspend-to-disk/hibernate problem [Was: The End Is Near ... or, get the vaseline, they're on the way!]
On 29/03/2012, at 22:04, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 29 Mar 2012 15:51:44 +0200, J. Roeleveld wrote: try tuxonice - allows you to suspend to a file on disk as well as ram or swap. Added bonus is its much more robust than in-kernel, and the dev (Nigel) is very responsive if help or bugfixes (usually for new kernel versions) are needed. I'd question this seeing as it hasn't been released for kernel 3.1 or later. Not that it is a bad choice, it is not, but it is certainly not keeping up. True, but I don't want to have too many write-actions to the internal SSD, which means that I'd want the file on the SD as well... TuxOnIce lets you specify where you want the hibernate file. -- Neil Bothwick X-Modem- A device on the losing end of an encounter with lightning. and dont forget, its not a swapfile so you only write once on hibernate, and read once on restart. and you can delete/recreate the file in between if you wish - its only used for hibernate. billK
Re: [gentoo-user] Re: InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 22:55:42 +0200, Alan McKinnon wrote: 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. 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. The reason I think it is a flaw is that udev is capable of doing some very clever stuff with nothing more than a simple device rule, but such clever stuff has no place in early boot. On the other hand, it also does basic stuff, like creating device nodes, that certainly does belong in early boot. The problem is that udev provides no way to distinguish between the early boot essentials and the clever stuff. Only a small subset of its work should be done when it is first started, possibly by tagging those rules, or simply postponing any rules with a RUN command. Or maybe a separate command (or invocation of the same command) that just creates device nodes, and any specified symlinks, much like mdev does, then kick in the full version later. However, as I type this, I can think of all sorts of arguments about what should be run early and what not. I'm beginning to understand why the devs decided if you want all this clever stuff, you'll just have to make /usr available. -- Neil Bothwick Windows Error:01F Reserved for future mistakes. signature.asc Description: PGP signature
Re: [gentoo-user] InitRAMFS - boot expert sought
On 29/03/2012, at 20:01, David W Noon dwn...@ntlworld.com wrote: On Thu, 29 Mar 2012 10:28:36 +0200, Alan McKinnon wrote about Re: [gentoo-user] InitRAMFS - boot expert sought: On Thu, 29 Mar 2012 00:20:04 +0100 David W Noon dwn...@ntlworld.com wrote: [snip] The Gentoo developers have been discussing just that. The reason is that many of the daemons that can be started by udev scripts require work files on /var, so we could well need /var mounted too. Which begs the obvious question, Why on earth is udev launching daemons in EARLY BOOT? Your guess is as good as mine! At present, the first thing I see when udev starts is a failed attempt to run /usr/sbin/alsactl to restore the audio levels on my sound card. This occurs before localmount or any other services in the sysinit run-level have been started. Just why anybody wants sound before the disk volumes have been mounted baffles me; I guess people are just desperate for the comforts of stereo. Perhaps my mind simply lacks the sophistication to understand the design of udev. I guess I'll just stick to my 80-column Hollerith cards. ... :-) -- Regards, Dave [RLU #314465] == dwn...@ntlworld.com (David W Noon) == that error was what clued me up to genkernels initramfs failing to mount /usr - the mount failure wasnt on screen long enough to see ... error reporting for the initramfs method needs fixing so users can faultfind problems more easily. flashing something on screen for a second and immediately pushing it offscreen doesnt count when there is lo logging to dmesg etc. par for the course - run an initramfs (complexity) means more WILL go wrong so ways to fix it for normal users need to be in place.. BillK
Re: [gentoo-user] AMD hdaudio: why do I have two audio devices and two mixers?
On Thu, Mar 29, 2012 at 9:37 PM, Hung Dang hungp...@gmail.com wrote: On 03/29/2012 09:18 PM, walt wrote: Fresh gentoo install on new lenovo desktop. Both linux and win7 (lenovo installed) tell me that this machine has two audio devices: 00:01.1 Audio device: Advanced Micro Devices [AMD] nee ATI BeaverCreek HDMI Audio [Radeon HD 6500D and 6400G-6600G series] Subsystem: Lenovo Device 3625 Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel 00:14.2 Audio device: Advanced Micro Devices [AMD] Hudson Azalia Controller (rev 01) Subsystem: Lenovo Device 3625 Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel crw-rw+ 1 root audio 14, 0 Mar 29 18:07 /dev/mixer crw-rw+ 1 root audio 14, 16 Mar 29 18:07 /dev/mixer1 crw-rw+ 1 root audio 116, 3 Mar 29 18:07 controlC0 crw-rw+ 1 root audio 116, 7 Mar 29 18:07 controlC1 crw-rw+ 1 root audio 116, 2 Mar 29 18:07 pcmC0D3p crw-rw+ 1 root audio 116, 6 Mar 29 18:07 pcmC1D0c crw-rw+ 1 root audio 116, 5 Mar 29 18:07 pcmC1D0p crw-rw+ 1 root audio 116, 4 Mar 29 18:07 pcmC1D2c crw-rw+ 1 root audio 116, 33 Mar 29 18:07 timer lrwxrwxrwx 1 root root 12 Mar 29 18:07 pci-:00:01.1 - ../controlC0 lrwxrwxrwx 1 root root 12 Mar 29 18:07 pci-:00:14.2 - ../controlC1 I spent an entire frustrating day discovering that the reason I have no sound is that every app wants to use /dev/mixer when only /dev/mixer1 actually works :( Only some apps (like audacious) will let me choose which mixer to use, and those apps work perfectly. Anyone else seen this before, I hope? Got a fix? Thanks :) I guess the second audio device is either HDMI or HD audio generic. You could verify this by opening alsamixer then select F6 to see a list of audio devices. If you use pulseaudio then you can select the default output device. Or use /etc/asound.conf to select your preferred default device. Well, technically, the first one is HDMI, and the second one is the more mundane one. -- :wq
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: Fine. NFS clients. Samba clients. Crypto. SSHFS. NTFS-3g. Security auditing. Virtualization tools. Perl, python or whatever is necessary to handle some case which required scripting. X. Graphics loading libraries. Cupsd, because some graphics library required by a bootsplash expressed a dependency on cairo, which expressed a dependency on something else, which expressed a dependency on cups. Perhaps crypto required a crypto daemon to be loaded, which required a smartcard, or required auth from a serial port or network connection. Perhaps an accurate clock is needed. Or perhaps a network policy demands that a machine be authorized to boot, so an LDAP client is required. It's easy to imagine entirely plausible circumstances which would bloat initramfs size and maintenance. At some point in time, these various things would normally be the simplest and most straightforward way to reach a quick end to some problem or another for some poor guy stuck in a private hell. And this initramfs crap increases the amount of work he has to do to solve his unique case. Setting up such a boot environment is decidedly non-standard and trying to put all that into a tool designed to get the core filesystem(s) loaded is ludicrous. But would you really want all of that available before init started to run? Mount / and /usr in the initramfs and run init. If you really need all that so early on, before /usr is mounted, maybe combining / and /usr is the cleanest approach. -- Neil Bothwick Fer sail cheep, Windows spel chekcer, wurks grate signature.asc Description: PGP signature
[gentoo-user] AMD hdaudio: why do I have two audio devices and two mixers?
Fresh gentoo install on new lenovo desktop. Both linux and win7 (lenovo installed) tell me that this machine has two audio devices: 00:01.1 Audio device: Advanced Micro Devices [AMD] nee ATI BeaverCreek HDMI Audio [Radeon HD 6500D and 6400G-6600G series] Subsystem: Lenovo Device 3625 Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel 00:14.2 Audio device: Advanced Micro Devices [AMD] Hudson Azalia Controller (rev 01) Subsystem: Lenovo Device 3625 Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel crw-rw+ 1 root audio 14, 0 Mar 29 18:07 /dev/mixer crw-rw+ 1 root audio 14, 16 Mar 29 18:07 /dev/mixer1 crw-rw+ 1 root audio 116, 3 Mar 29 18:07 controlC0 crw-rw+ 1 root audio 116, 7 Mar 29 18:07 controlC1 crw-rw+ 1 root audio 116, 2 Mar 29 18:07 pcmC0D3p crw-rw+ 1 root audio 116, 6 Mar 29 18:07 pcmC1D0c crw-rw+ 1 root audio 116, 5 Mar 29 18:07 pcmC1D0p crw-rw+ 1 root audio 116, 4 Mar 29 18:07 pcmC1D2c crw-rw+ 1 root audio 116, 33 Mar 29 18:07 timer lrwxrwxrwx 1 root root 12 Mar 29 18:07 pci-:00:01.1 - ../controlC0 lrwxrwxrwx 1 root root 12 Mar 29 18:07 pci-:00:14.2 - ../controlC1 I spent an entire frustrating day discovering that the reason I have no sound is that every app wants to use /dev/mixer when only /dev/mixer1 actually works :( Only some apps (like audacious) will let me choose which mixer to use, and those apps work perfectly. Anyone else seen this before, I hope? Got a fix? Thanks :) -- P.S. -- No, I don't use pulseaudio. Why do you ask?
Re: [gentoo-user] AMD hdaudio: why do I have two audio devices and two mixers?
On 03/29/2012 09:18 PM, walt wrote: Fresh gentoo install on new lenovo desktop. Both linux and win7 (lenovo installed) tell me that this machine has two audio devices: 00:01.1 Audio device: Advanced Micro Devices [AMD] nee ATI BeaverCreek HDMI Audio [Radeon HD 6500D and 6400G-6600G series] Subsystem: Lenovo Device 3625 Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel 00:14.2 Audio device: Advanced Micro Devices [AMD] Hudson Azalia Controller (rev 01) Subsystem: Lenovo Device 3625 Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel crw-rw+ 1 root audio 14, 0 Mar 29 18:07 /dev/mixer crw-rw+ 1 root audio 14, 16 Mar 29 18:07 /dev/mixer1 crw-rw+ 1 root audio 116, 3 Mar 29 18:07 controlC0 crw-rw+ 1 root audio 116, 7 Mar 29 18:07 controlC1 crw-rw+ 1 root audio 116, 2 Mar 29 18:07 pcmC0D3p crw-rw+ 1 root audio 116, 6 Mar 29 18:07 pcmC1D0c crw-rw+ 1 root audio 116, 5 Mar 29 18:07 pcmC1D0p crw-rw+ 1 root audio 116, 4 Mar 29 18:07 pcmC1D2c crw-rw+ 1 root audio 116, 33 Mar 29 18:07 timer lrwxrwxrwx 1 root root 12 Mar 29 18:07 pci-:00:01.1 - ../controlC0 lrwxrwxrwx 1 root root 12 Mar 29 18:07 pci-:00:14.2 - ../controlC1 I spent an entire frustrating day discovering that the reason I have no sound is that every app wants to use /dev/mixer when only /dev/mixer1 actually works :( Only some apps (like audacious) will let me choose which mixer to use, and those apps work perfectly. Anyone else seen this before, I hope? Got a fix? Thanks :) I guess the second audio device is either HDMI or HD audio generic. You could verify this by opening alsamixer then select F6 to see a list of audio devices. If you use pulseaudio then you can select the default output device. Or use /etc/asound.conf to select your preferred default device. Hung
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?
On Mar 30, 2012 9:14 AM, Mike Edenfield kut...@kutulu.org wrote: 8 snip 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 :) Sometimes I wonder why people want eye candy during boot... Linux startup -- sans splash screen -- brings back nostalgic memories of my early computing days using DOS... Plus, sharp-eyed users can catch a glimpse of something wrong ;-) Rgds,
