[gentoo-user] Re: Easy (cough) way to build earlier gentoo-sources 3.18.x kernel?
On Wed, Apr 01, 2015 at 10:17:45AM +0100, Bob Wya wrote: The experimental patchset is only applied if the experimental USE flag is enabled surely?? See I'm learning stuff now! :-) https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/gentoo-sources/metadata.xml?revision=1.13view=markup -- Nicolas Sebrecht
[gentoo-user] Re: Easy (cough) way to build earlier gentoo-sources 3.18.x kernel?
On Tue, Mar 31, 2015 at 10:17:27AM +0100, Bob Wya wrote: @Nicolas, I think I'm getting it now. The patchsets are cumulative and I just need the base patchset - right? base, extras and experimental are all applied. I'm still a little unclear as to what kernel source I should apply the base patchset to. The patchsets are applied on top of the vanilla sources. I want to rebuild the 3.18.8 kernel to double check it's free of the bug... Take the vanilla sources and apply the patches you want to test from the patchsets manually. I can see some nfs suspend patches here... So that could be culprit! [1]http://dev.gentoo.org/~mpagano/genpatches/trunk/3.18/1008_linux-3.18 .9.patch Perhaps, yes. You'll have to make your checks. ,-) -- Nicolas Sebrecht
[gentoo-user] Re: Easy (cough) way to build earlier gentoo-sources 3.18.x kernel?
On Mon, Mar 30, 2015 at 06:45:40PM -0400, Fernando Rodriguez wrote: You can use git. I believe gentoo patches are only for config options so if you configure it with make oldconfig it *should* be the same as using gentoo- sources. Actually no, gentoo-sources aren't vanilla kernel while efforts are made to avoid including intrusive patches. http://dev.gentoo.org/~mpagano/genpatches/about.htm http://dev.gentoo.org/~mpagano/genpatches ,-) -- Nicolas Sebrecht
[gentoo-user] Re: new linux router
On Fri, Mar 06, 2015 at 02:03:48AM +, James wrote: For the distribution, I'd recommend Alpine: http://www.alpinelinux.org/about Why would that be better than putting lilblue (gentoo) on the board. Maybe somebody who has success with booting off of usb (and that definitely is not me) could test lilblue on an alix2d3 board? I don't know much Lilblue but it looks like a somewhat recent project. Alpine started back in 2005. It's based on portage to build the distribution but uses the apk-tools that fit better for embedded systems, IMHO. Also, Alpine comes with a very lightweight minimal installation, reliable toolchain to build the distribution and uses openrc. The well known debian-like configuration files allow new maintainers to quickly be comfortable with the device. The recent move to musl over uClibc is a good thing too, FMPOV. I expect Alpine to have a wider community than Lilblue. How did you have your make.conf files (or similar under Alpine) set up? You don't have make.conf on the target. Embedded devices are bad at compiling. With Alpine, you cross-compile the target from your desktop/server/VM. If I go this route, I'd really rather run gentoo or something quite similar, rather than a distro I not familiar with. On the target device, apk-tools are very easy to use and requires MUCH less time/ressources than emerge. Quiet frankly, Alpine doesn't require specific skills. I've started with the binary provided by the maintainers and never had to compile any package myself. That's the combo I used in a recent past and it worked quiet fine (802.1q VLAN, traffic shaping with tc, advanced firewall with scripted iptables rules, ethernet cards controlled with ethtool (I could fix speed/duplex for incompatible network hardware), ssh, etc). I'm not familiar with Alpine linux. How many of your scripts would be useful on gentoo? If what you did is sensitive, just drop to me privately. Sorry, I can't. I don't have them anymore while I'm sure they are still used in production. It's something easy to do, though. The scripts themselves are distribution agnostic. E.g. my ipfilter service only used $IPTABLES. The only thing to update are the service files for openrc, systemd, upstart, whatever. -- Nicolas Sebrecht
[gentoo-user] Re: new linux router
On Wed, Mar 04, 2015 at 03:10:40PM +, James wrote: I'd like to be able to download some open source linux to the router hardware if updates and pathces are not maintained by the vendor? That way I do not purchase something that is to be abandoned in a few years by the vendor. It's just a small home/office so 3x100Mb E would be fine, but GigE ports would be better. I'm flexible on the CPU/arch of the hardware, so all discussion and suggestions are welcome. In an idealized world I'd pay extra for a gentoo_derivative based router; but all I find is the WRT, devil_linux and such, nothing really cool and interesting. For the hardware, you could get a alix2d3: http://www.pcengines.ch/alix2d3.htm For the distribution, I'd recommend Alpine: http://www.alpinelinux.org/about That's the combo I used in a recent past and it worked quiet fine (802.1q VLAN, traffic shaping with tc, advanced firewall with scripted iptables rules, ethernet cards controlled with ethtool (I could fix speed/duplex for incompatible network hardware), ssh, etc). While there is no wifi I found this MUCH better than WRT54GL, for example. -- Nicolas Sebrecht
Re: DKIM Re:[gentoo-user] opengl: missing symlink target for header
On Fri, Feb 13, 2015 at 10:24:26PM -0200, Urs Schütz wrote: On 02/13/15 16:19, Nicolas Sebrecht wrote: Hi guys, If you have mesa and eselect-opengl-1.3.X installed, could you please tell me if the symlink /usr/include/GL/glext.h is broken for you? Thanks, Valid symlink here: Thank you all! :-) -- Nicolas Sebrecht
[gentoo-user] opengl: missing symlink target for header
Hi guys, If you have mesa and eselect-opengl-1.3.X installed, could you please tell me if the symlink /usr/include/GL/glext.h is broken for you? Thanks, -- Nicolas Sebrecht
[gentoo-user] Re: Anyone familiar with virt-manager?
On Wed, Feb 11, 2015 at 08:14:52AM -0800, walt wrote: On 02/11/2015 03:38 AM, Nicolas Sebrecht wrote: On Tue, Feb 10, 2015 at 04:56:13PM -0800, walt wrote: Did you check the devices? I haven't yet figured out how to display the devices with virsh. I'm still experimenting :) virsh edit name How did you imported the winXP image into virt-manager? Clicked on File menu and chose New Virtual Machine which offers an import option. You might want to try by avoiding this option. Copy the disk image and just create a new VM. While asking for a disk, provide the copy of the image. I wonder if you have a recent declared ABI. Here it is pc-1.1, hvm: os type arch='x86_64' machine='pc-1.1'hvm/type ... /os Same here, except machine='pc-i440fx-2.3' I have no idea where that value comes from. It comes from the import but I wonder if default value hurts the guest. You have to check what is pc-i440fx-2.3 by yourself or ask the libvirt mailing list. Here is the background about ABI: https://www.berrange.com/posts/2010/02/15/stable-guest-machine-abi-pci-addressing-and-disk-controllers-in-libvirt/ -- Nicolas Sebrecht
[gentoo-user] Re: Anyone familiar with virt-manager?
On Tue, Feb 10, 2015 at 04:56:13PM -0800, walt wrote: Thanks, Nicolas. I also have a qemu guest win7 image, and the mouse capture works as expected when I run it with virt-manager. No idea why winXP behaves differently, though. Did you check the devices? How did you imported the winXP image into virt-manager? I notice that virt-manager runs qemu without the -enable-kvm flag, and win7 runs significantly slower because of that. Is there some way to convince virt-manager to use the -enable-kvm option? libvirt set the ,accel=kvm command line option, here. I wonder if you have a recent declared ABI. Here it is pc-1.1, hvm: os type arch='x86_64' machine='pc-1.1'hvm/type ... /os -- Nicolas Sebrecht
[gentoo-user] Re: Anyone familiar with virt-manager?
On Mon, Feb 09, 2015 at 02:43:30PM -0800, walt wrote: I just installed virt-manager to experiment with and this is the first time I've used it. I think I've misconfigured something but I don't know what: ... I'm running win7 just fine with these devices (virsh edit): input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' listen type='address' address='127.0.0.1'/ /graphics sound model='ac97' address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /sound video model type='vmvga' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video I had a winXP with such configuration, AFAIR. Be care with the bus and slot options to not take anything already assigned. -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo's future directtion ?
On Sat, Nov 29, 2014 at 07:09:07AM +, Martin Vaeth wrote: So for non-developers, downloading with git does not necessarily make sense. That being said, please do not consider this as an argument against a change to git: For developers it has only advantages, and AFAIK, it is not planned to cancel other download methods anyway. Of course. This is not going to be a requirement. Non-developers should stick with rsync. No one meant to replace rsync with Git. It is about replacing CVS with Git. -- Nicolas Sebrecht
[gentoo-user] Re: The future of linux, and Gentoo specifically now
On Thu, Nov 27, 2014 at 03:46:06PM -0600, Canek Peláez Valdés wrote: It sounds really cool Sabayon, I should probably try it one of these days. I'd say it's my favorite distro. Sadly, equo still doesn't know how to depclean. -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo's future directtion ?
On Sat, Nov 22, 2014 at 06:20:01PM -0500, Rich Freeman wrote: Don't get me wrong, I'm all for more overlay support. I'm all for reform when there is something to reform. However, in all your complaints about developers causing conflicts you're actually becoming part of the problem. I'd say the problem is not about the devs themselves causing conflicts but the environment and frame devs are working in the current workflow. Everybody look baffled with the current way of doing things in Gentoo. I agree with hasukel that the distributed Gentoo as proposed today is a wrong answer. Not that the issues raised are not valid. They do. Also, I agree with hasukel that the main problem is about having a correct distributed model. Posting on bugzilla for ebuilds updates or new ebuilds is seriously damaging when almost every where else it is just about sending your git patches. Becoming an official Gentoo dev is not a solution either due to the recruiting process. As you say, official devs can work on whatever they like and their contributions will likely hit the users at some point while at the same time occasional devs are asked to work with old tools like bugzilla. So yes, the whole review process is broken and the contribution process is broken too. About that, there's no other way than break the whole recruiting process and change of tools. Have your core team handle git repositories and let others request pull or send patches like almost all the other open source softwares in the world. Let's exploit the anarchy and openness instead of partitionning things into devs/non-devs or main-tree/overlays. Back to the original request. Here is how starts the distributed Gentoo model: Imagine you would say I like gentoo, but I don't like the way the toolchain is handled, so I want to do it differently. Currently, your only way is to fork the whole distro or do dangerous stuff with overlays. Imagine gentoo would actually be a small repository of core packages with lots of optional user contributed extenions of all kinds. You'd only need to fork the core and add those extensions you like. Similarly... you don't like the way ruby is handled? Well, apart from dev-lang/ruby maybe, there'd be no ruby gems in the tree anyway. So there can be different approaches of packaging ruby gems and you choose which to use or if you want to do it completely different. And there would be no complicated configuration required to prevent in-tree ruby packages getting pulled in, because there are none. Isn't this all stuff about handling some kind of pointers? Don't like the toolchain? Point to another one. Don't like the way ruby is handled? Point to another one. So, is it about overlays? No. I'd say overlays are some kind of poor pointers for many reasons. Hence, why not adding the pointers we are all missing and rethinking the other pointers? -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo's future directtion ?
On Sun, Nov 23, 2014 at 04:31:45PM +0100, Volker Armin Hemmann wrote: am I the only one who thinks that this way leads to madness? Version conflicts are bad enough. First, version conflicts have their roots in the support for versions of libraries in softwares. This is the best place to fix that when possible. When it comes to ebuilds maintainers, version conflicts are about all about DECLARATIONS. If software A need Y-v1..12, we should have a way for the maintainers to declare that A relies on Y-v1..12 and let the dependency softwares to the hard job and admin/users handle them the way they want. Today, this is badly managed with implicit expectations everywhere. Also, there are ways to overcome version conflicts. Slots are one of them. No multiply that with a bunch of overlays, all having their own libXY with just some tiny, tiny differences, and another bunch of overlays who want libXY from certain others That's a reason why I said that overlays are a poor kind of pointers. For overlay maintainers today, if the main portage tree does not offer what they expect, the only option they have is to rewrite their own static dependency tree with their own ebuilds. That sucks. Portage should support a way to expose ALL the conditions for a software to work and update installed libraries to match the requirements. -- Nicolas Sebrecht
[gentoo-user] Re: The future of linux, and Gentoo specifically now
On Sun, Nov 23, 2014 at 12:44:12PM -0500, Tanstaafl wrote: This is really an incorrect (and even borderline arrogant) answer... To answer the OPs question correctly... Since OpenRC is the *default* - for now at least - it is *king*, and systemd is the red-headed step-child, and as such OpenRC is and will be 100% fully supported. With that in mind, it is also 100% on the *systemd proponents* to make sure that *systemd* is 'fully supported' as an *alternate* init system. You're wrong. At first, Gentoo does with what software maintainers offer. -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo's future directtion ?
On Sun, Nov 23, 2014 at 07:25:26PM +0100, Volker Armin Hemmann wrote: and you want portage to finish on this site of eternity when looking for dependency resolution? I don't think having exposed requirements would explode the time needed to calculate the dependency tree because this does not add paths to the tree. It only validates or invalidates paths. And if time for dependency resolution would become a real problem, there are ways to solve that. One could be making pre-calcultated caches of parts of tree/paths. -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo's future directtion ?
On Sun, Nov 23, 2014 at 02:30:12PM -0500, Rich Freeman wrote: On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht nicolas.s-...@laposte.net wrote: Portage should support a way to expose ALL the conditions for a software to work and update installed libraries to match the requirements. This sounds nice in principle, but making it work is not trivial. Suppose my package works with gcc-1.2.3.4 with a list of 14 specific patches and no others, and glibc-1.2.3.4 with another list of 14 patches and no others. Now suppose 300 other packages have similar requirements. To make it simple, this is almost irrelevant IMHO. It won't happen because we are talking about patches required as dependency excluding other patches required as dependency on the same sources. IOW, we must notice that we would need multiple *installed* versions ONLY IF a dependency requirement is not met AND that this requirement is *excluding* one of the current gcc requirements. So, when they are non-compatible themselves in some way at the source level. On top of that, this would have to be an issue that has to be handled by the software devs. Second, good luck dealing with security patches and bugfixes. You now have 300 copies of glibc to update, and since your list of dependencies stated that you have 14 patches and no others you now need to update the 300 other packages to use the newer version of glibc. The current Gentoo way is far more limiting, but by having a single version of glibc with a single policy around versioning/etc packages don't have to micromanage what they depend on. Well, I wouldn't worry about that because having 300 versions of gcc (or any other package) is not the purpose. But it is a very good thing to restart the thread from patches handling like you did since it is the basis of software updates. When it comes to building a real and flexible meta-distribution (after all, this thread is all this issue), it is nice to have the packages management tools working for you. Also, it is good to keep in mind that everybody in the chain from the software developers to the users including fork developers, package-distro maintainers, sysadmin and the final users might want to tune their systems at some point. They are all some kind of forkers with the current Gentoo. Starting from there, the tools should not only allow them to do what they want but also help them in that task WHITOUT forking. If it's not the case, you end up with overlays or similar technics whose come which much more damaging problems in practice. All distributions manage vanilla sources + patches (including security patches and bugfixes). We start from vanilla with compilation options. Each one is declared so they are enabled/disabled easily (use flags...). Would it be that hard to declare if the patch add/remove/change a dependency? I don't think so. Now comes the series of patches management. Would it be hard to have the tools allowing to tune the series of patches that are going to be applied? I don't think so, either. Would it be hard to have the tools allow each role to tune/configure the system for both useflags and series of patches? Neither, we know how to do that kind of things since decades. So, when there are security fixes or bugfixes we don't need anything much crazy to handle them: the management of series of patches is already supported of the tools. Today, ebuilds don't even let a chance for an admin to apply a series of patches to the vanilla/distro-maintainer sources without having to rewrite/fork the ebuild. Whatever it is critical for them. The lone option is to fork+overlay. This is a serious issue FMPOV. If NixOS/etc have found a better solution I'm all ears, but it is hard to tell based on the info on their website. It seems hard to me to allow so much diversity in dependencies without basically having every package on your system running in its own container (thus consuming a lot more RAM), and while managing security updates in a sane way. I don't know about NixOS/etc. I'll look at that. About containers, they are usefull for solving other problems like testing, deployement or required isolation, IMO. -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo's future directtion ?
On Sun, Nov 23, 2014 at 08:15:26PM +0100, Volker Armin Hemmann wrote: which works so well with different useflags. Yes, things need improvements. -- Nicolas Sebrecht
[gentoo-user] Re: The future of linux, and Gentoo specifically now
On Sun, Nov 23, 2014 at 02:34:52PM -0600, Canek Peláez Valdés wrote: Oh my. So it's the name of the project and (one) author? All the design and ideas behind it are irrelevant then? You just gave me the most perfect justification to never ever take you seriously in this subject. Good day, sir. Please, stop feeding that troll! -- Nicolas Sebrecht
[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 25/03/14, J. Roeleveld wrote: It has already been determined that on this list we do not want extra CCs, I think you have determined this on your side (I'm not doing a personal attack, you is not you alone). Please respect that and don't reopen this discussion. Please don't tell us what we should do in the first place. You (including some others here) seem well comfortable with the idea of making Gentoo's mailing lists an exception with the glitchy way everyone is supposed to work with mails here. cc'ing is a mark of respect in accordance with both the technical norme and the persons involved in a discussion. You won't remove this from my education and local policies instored by legitimate (or not) policymakers won't change my practice and expectation. -- Nicolas Sebrecht
[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 21/03/14, Tom Wijsman wrote: On Fri, 21 Mar 2014 07:10:49 -0500 Dale rdalek1...@gmail.com wrote: So let's get this straight. You want most everyone on this list to change what they have to do to remove dups caused by you, instead of you changing what you do to fix the problem? Everyone else is okay with it, as only one in a thousand speaks up about it; the problem rather is with that 0.1% than that it is with me, as I just use mailing lists as they are supposed to be used. Yes. I want to be cc'ed on threads I'm involved in. That's just how it should be done and what almost everybody expects on technical mailing lists. -- Nicolas Sebrecht
[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 21/03/14, Dale wrote: Tom Wijsman wrote: On Fri, 21 Mar 2014 12:41:03 -0500 Dale rdalek1...@gmail.com wrote: FYI. Most people don't say anything, they just blacklist you. After that, you don't exist to them. Yes, that's up to those few; it could happen, but most respond instead. I just read the last message from you Tom. Good bye. Heh. Blacklisting just make things even worse because you won't blacklist other contributors responding to Tom. So, you'll have broken and partial threads. -- Nicolas Sebrecht
[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 26/02/14, Canek Peláez Valdés wrote: Sabayon uses binary packages, isn't? Yes. Then eselect perhaps uninstalls some packages and installs others? I don't know the code, sorry. Since I've already tried the 'eselect init' command, I'm pretty sure it doesn't install anything. I've no idea; I've never used Sabayon, although I'm interested in trying it. BTW, I'm pretty sure Fabio (cc'ed) will be fine to explain how he implemented the eselect init command and the whole magic behind it. ,-) -- Nicolas Sebrecht
[gentoo-user] Re: technical review of systemd
The 25/02/14, Canek Peláez Valdés wrote: Perhaps they are starting small? I don't know; I'm pretty sure they are. BTW, things are moving fast and the state has already changed since my last check (not so old). from what I've read, they want something small for simple cases, and if you need more you can use NetworkManager, connman, iproute2, or whatever. But then you had to configure it yourself. NetworkManager and ConnMan are the big ones. Wicked (the one I use on my laptop) looks a bit lighter. But none intend advanced, static, and easy text configuration files for admins as usually required for servers. Write your own tool is a bad advice for most people as I would expect either a poor alternative or a lot of work to get a descent one. I think experiented developers already know they can write their own and evaluate how hard it can be. So, they won't wait for this kind of advice on this list to get the job done. ,-p That beeing said, I think I understand why you write that again and again. From what I've read recently, I guess too much people do not clearly understand all of the refinements coming with FOSS in corporation relationships, innovation mentoring or software adoption constraints. The cabale remains tempting as it can explain everything. Anyway, systemd-networkd (introduced in systemd-209) is written to fill this gap. Good news. Nothing was taken from Arch, I believe. networkctl and netctl had nothing to do with each other. I'm sorry. I think I've read that networkd did take inspiration from netctl for the structure of configuration files at some point; not really what I said yesterday (hugh!). Don't even know if it actually was the case. I have to refresh my skills on the topic with a bit more homework, again. Didn't expect things have changed that much in a few time. :-) -- Nicolas Sebrecht
[gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
The 21/02/14, Andrew Savchenko wrote: Any decent security setup contains multiple layers of protection. Use of non-standard binaries, algorithms or implementations is just one of them and it is the simplest math to prove that security is _improved_ this way. The algorithms and implementations do not change with configuration options while they are almost always the cause of security issues of a software. Of course, building the same software on different architectures or with custom configuration options will change the assembler code and the binary fingerprint might be totally different. But considering this a layer of protection remains non-sense and is a dangerous approach. The nature of Gentoo does not help in this area compared to other binary distributions. I don't pretend that non-standard binaries NEVER protect against some kind of issues. I pretend they are ridiculously insignificant in the wild. -- Nicolas Sebrecht
[gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
The 21/02/14, hasufell wrote: So you are saying compiling a minimal kernel to minimize exposure to subsystem bugs is only obscurity? (I really wonder what Greg would say to this) Developers made the kernel to rely on modules. Distributions relies on them. Since they are almost always loaded on demand, Gentoo does not make things better in this area, either. -- Nicolas Sebrecht
[gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
The 21/02/14, Andrew Savchenko wrote: Are you considering Bruce Schneier's advice as a stupid nonsense? In his Applied cryptography he recommended one of the ways to straighten a system: to use not so frequently used algorithms instead of selected standards because less frequently used algorithms has no better math but are less targeted, have less specialized hardware built to crack them and so on. First, it is worth recalling he talks about algorithms used in cryptography especially considering the context of the supposed power of the NSA. Second, he never talks about compilation USE FLAGS. His point is about algorithms. Only that. Gentoo does not change algorithms in the (widely spread) softwares supported by the distribution. And I'm not going to talk about specialized hardware for cryptography that almost nobody here will ever use. I never talked about a sense of security just because system has non-standard binaries. I talked about high variance which brings a _bit_ more security. High variance applied to Gentoo or Debian IS non-sense. You won't get high variance in any of the supported softwares they provide. Have you ever considered how systems became broken in the wild? The most common way (in numbers of hosts, not significance) are automated robots and botnets. They just scan the net, try to bruteforce any login service they found and try to apply any exploit appropriate from their database. If one have a widely used and improperly configured (or not timely updated) setup, it will be hacked this way. ... However I want to notice one critical security issue quite common for production servers: an old software. It doesn't matter how many protection layers system have, how skilled person configured it was. When software is old it is quite trivial to look up for CVEs and break the system. Quite practical encounter from my own experience: I was asked to legitimately obtain root on the box (admin forgot password, reboot (with init=/bin/bash) was not an option and root access was needed for reconfiguration); a box was a year old RHEL with SELinux enforced. Third kernel exploit worked perfectly (I just found them on the net, not bothered to code myself). Agreed. That's why the efforts from distribution maintainers focus on taking care to _not_ provide such softwares enabled this way by default. A large security effort relies on the admins, first. Upstream have few responsability in security non-sense coming from the users. . Such trivia with Gentoo and its custom binaries is not possible. And Gentoo is quite good with recent software updates (RH sometimes is too slow with critical kernel/libc issues). Such security issue is not avoidable whatever it is Gentoo or not. Then, the best point is to have a wide community to ensure better support and surveillance on security issues in order to expect better support by the community to offer _updates_. My point is that Gentoo provides native techniques to raise the attack cost. That's all. And I'm afraid. -- Nicolas Sebrecht
[gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
The 26/02/14, hasufell wrote: I wasn't only talking about modules and yes... loading them on demand actually proves my point. No. We are talking about servers. -- Nicolas Sebrecht
[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 20/02/14, Canek Peláez Valdés wrote: Thinking about this more, since apparently using a separate profile may just be 'overkill', how about something simpler, like, for example, using eselect... Something like: # eselect init list Available init systems: [1] OpenRC * [2] systemd [3] runit (whatever choices are supported). Or am I just being ridiculous? The eselect command is already there in Sabayon. No, yo are not; but the switching requires reemerging things because you need to set some USE flags and quit others. That's the difficult (which is not, really) part; if you set the USE flags yourself or via a profile, or an eselect module, I don't think the difference matters at all. ... but I have no idea how it is done. That's why I asked what packages would require a reinstall (got no precise answer for now). -- Nicolas Sebrecht
[gentoo-user] Re: technical review of systemd
The 23/02/14, Canek Peláez Valdés wrote: networkd (again, netctl is the command-line front-end) is not for enterprise networks; on the contrary, is for the trivial cases. For example, in a little web server I administer I have: $ cat /etc/systemd/system/network.service [Unit] Description=Static network service After=local-fs.target Before=network.target Documentation=man:ifconfig(8) Documentation=man:route(8) [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/ifconfig enp2s12 192.168.1.2 broadcast 192.168.1.255 netmask 255.255.255.0 up ExecStart=/bin/route add default gw 192.168.1.1 enp2s12 [Install] WantedBy=multi-user.target (Yeah, I know, I should switch to ip, I'm sorry, I haven't had the time yet). I'm going to get rid of this trivial network.service unit file when 209 (or better 210) hits Gentoo. Cases like this are the use-cases for networkd. what i don't understand is if you look at how openRC does it, it only really cares about up/down events and the /etc/conf.d/net is very comprehensive, in part because it passes everything to iproute2 to handle, the only thing i can't do without an additional shell script is tc qdiscs. i don't need or want a network manager, just need something that applies confs on startup / stop of interfaces. I'm a little surprised that there isn't an iproute2 .service file reading through your example, in fact this is preferrable to me than using a network manager but using iproute2. I would rather you keep this example in, and have this shown on the wiki or somewhere as this neatly resolves my network concern. Mmmh. Maybe I wasn't clear; in your case, it seems that iproute2+OpenRC *is* your network manager. Perhaps at some point networkd will gain the ability to use iproute2 (or even absorb it), but right now is only for tiny little setups. The way systemd services handle network whatever network manager you enable is the last thing preventing me from using systemd on servers. Seting up manual advanced setups on systemd looks crappy (if even possible with the provided tools) compared to OpenRC. Notice that iproute2 is the default everywhere for long time, here. The OpenRC comprehensive configuration set for network management is actually what I would expect in systemd. ... Having a network manager doesn't necessarily means having a big monolithic thing that sets up your network. If you use some scripts+conf with iproute2 to set up your network, then *that's* your network manager. The point of networkd (if I understand correctly), is that if you *need* iproute2 (I don't have it installed in any of my machines), or highly dynamic non-trivial network configurations, then networkd will not be enough. And, by the way, someone make me notice that netctl is an Arch'ism, and that the command-line front-end for networkd is actually networkctl. Yes, it was taken from Arch in order to allow better network support for advanced configurations whitout requiring to write yet another tool. The thing is that I would expect systemd to handle the whole thing on its own (with the help of iproute2) so that services have nice grain-level dependencies. -- Nicolas Sebrecht
[gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
The 20/02/14, Nilesh Govindrajan wrote: Gentoo makes the best server os because it's a custom built os where the admin knows each and every aspect of the os. Security wise, there are no unwanted or unused stuff, so lesser bugs to deal with. While I agree with the less code is less bug argument, I disagree with your point. Tuning softwares mean that the binaries compiled on a machine are less used in the wild (other Gentoo systems have other hardware, enabled use flags, etc). Hence, the binaries executed on you local server are likely much less tested by others. So, we can't say what is the true impact of use flags on security or stability compared to any widely-used pre-compiled distribution. -- Nicolas Sebrecht
[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 20/02/14, Yuri K. Shatroff wrote: (see [2]) will print the status of the Apache web server, and also the last lines from the logs. You can control how many lines. You can check also with the journal, as I showed up. I believe it would be a 5-minutes job to add the capability of printing last N log entries for a service to `rc-service status`. Using cat, grep If I understand you correctly, what you're proposing is an analyzing tool which works after-the-facts. I mean extracting the per-daemon logs from a global log archive whereas systemd works the opposite way, AFAIU. You solution requires per-daemon extraction rules and have to be maintained over time. So, postponed to errors. Definetly not a 5-minutes job. -- Nicolas Sebrecht
[gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko wrote: And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. While excluding few security issues by compiling less code is possible, believing that non-standard binaries (in the sense of compiled for with local compilation flags) gives more security is a dangerous dream. -- Nicolas Sebrecht
[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 17/02/14, Canek Peláez Valdés wrote: It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Interesting. Didn't know that. What packages need to be recompiled? BTW, respect for your patience in this thread! -- Nicolas Sebrecht
[gentoo-user] Re: [O/T] RAID help - now won't boot
The 21/10/13, Mick wrote: I'm fast gravitating towards this option ... Although with metadata 0.90 I was able to progress with the installation (after I deselected the swap partitions) the grub-install script wanted to install in /dev/md127p1 but it failed. I had to override the Ubuntu installer since I could only install grub in the /dev/md127 block device. Which is the one we expect. /dev/md127p1 is the first partition of /dev/md127. BTW, I'm still at a loss as to why for Ubuntu the RAID 1 is seen as /dev/md127 and not /dev/md0 which I created originally with sysrescuecd. Names of RAID devices are built at boot time. It depends on /etc/mdadm.conf which should be part of the initramfs. Otherwise, consider the name random. Either way, it won't boot again. Now it stays on a blank screen, no error at all shown. I don't understand why this blank screen. Or do you mean a black screen? I'll have another go with sysrescueCD to see if I install grub on /dev/sda and /dev/sdb and if this does not work either, It should work. Linux software RAID is assembled once the kernel is up and running. Before, the system boot as usual on a single disk. Though, I'm not sure how mdadm will handle the disk change behind his back. Once the installed system is bootable, I suggest you to try to reinstall grub. This will be required at some point in time in the future to update it either way. I'll stop wasting time and follow your suggestion of installing on a single disk first, before I mirror it thereafter. -- Nicolas Sebrecht
[gentoo-user] Re: [O/T] RAID help - now won't boot
The 21/10/13, J. Roeleveld wrote: Ha! Yes, this made a difference, thanks! With metadata 0.90 I can see the same partitions I set up on /dev/md0, also on /dev/sda and /dev/sdb. Sorry to come back late in this thread. As other contributors pointed out correctly, the problem was RAID metadata at the beginning. The only problem now is that the Ubuntu server CD wants to format /dev/sda2 as swap and fails at that stage. :-/ Not sure how to by-pass this. Yes. Most of the installers suck at that game. What I would do (already done this way) is: - install the disks in another machine with virtualization capacity; - create the RAID 1 (metadata=0.90); - create a virtual machine with the built RAID as single disk; - boot on the CD to install any distro; - move the disk out to the target bare metal machine; - update fstab and grub if needed. This has the advantage to not require to bypass the installer at some stage at the price of a temporary installation of the disks somewhere else. I may also try metadata=1.0 to see if this makes a difference, which also positions the RAID data superblock at the end of the device: Sub-Version Superblock Position on Device --- - 0.9 At the end of the device 1.0 At the end of the device 1.1 At the beginning of the device 1.2 4K from the beginning of the device To bypass the swap format you could try either deselecting the format option (if it exists) or setting the partition type to something else. The partition type can be set back to swap later from a livecd without having to reinstall. Other option: 1 install to single disk 2 using sysresccd create a degraded raid1 using the 2nd drive 3 copy the partitions and date from drive 1 to the degraded raid device What is copy the date? 4 add disk 1 to the raid I might miss something but I guess you're going to erase the installed system (on disk 1) from the unused disk (disk 2), here. I believe it would only be possible by installing the system on the degraded RAID, which will likely mean coming back to the original swap problem. 5 wait for the raid device is synchronized 6 change fstab and grub config to reflect the new disklayout -- Nicolas Sebrecht
[gentoo-user] Re: RAID help
On Tue, Oct 15, 2013 at 10:42:18PM +0100, Mick wrote: mdadm --create --auto=mdp --verbose /dev/md_d0 --level=mirror --raid-devices=2 /dev/sda /dev/sdb which is thereafter partitioned with fdisk. This is the one I have used in the past. Which one is preferable, or what are the pros cons of each? For a basic RAID1, the best is to keep it as simple as possible. So mirroring while disk looks better. It will also keep MBR/GPT synced. I tend to make manual partitions that I mirror but this is because I usually require to do more complex setups (e.g. mixing mirror types), or because I need to have the setup more flexible. -- Nicolas Sebrecht
[gentoo-user] Re: RAID help
On Wed, Oct 16, 2013 at 08:10:40PM +0200, Nicolas Sebrecht wrote: On Tue, Oct 15, 2013 at 10:42:18PM +0100, Mick wrote: mdadm --create --auto=mdp --verbose /dev/md_d0 --level=mirror --raid-devices=2 /dev/sda /dev/sdb which is thereafter partitioned with fdisk. This is the one I have used in the past. Which one is preferable, or what are the pros cons of each? For a basic RAID1, the best is to keep it as simple as possible. So mirroring while disk looks better. It will also keep MBR/GPT synced. s/while/the whole/ I tend to make manual partitions that I mirror but this is because I usually require to do more complex setups (e.g. mixing mirror types), or because I need to have the setup more flexible. -- Nicolas Sebrecht
[gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
The 10/10/13, Volker Armin Hemmann wrote: if something like sshd crashes, you either have a hardware problem or sshd is buggy. Either way, better not be pampered over with a silent service restart. So, restarting a service should not be silent (I think it isn't) and might need better alerts. Oh, don't the admin have the tools for this already (sendmail, motd, snmp, whatever)? I'm not pretending the current situation is perfect but if admins are tired to configure alerts on their own, it should not be that hard to improve and factorize efforts (at Gentoo at least, if not upstream). -- Nicolas Sebrecht
[gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?
On Wed, Oct 09, 2013 at 04:53:56PM +0200, Stefan G. Weichinger wrote: Would someone please take a look at this dmesg: https://dl.dropboxusercontent.com/u/24516209/dmesg.txt and tell me what those ugly messages around the CPUs could mean? I still see suboptimal performance on this hardware ... I would think about a kernel bug first and try with a much lower version. -- Nicolas Sebrecht
[gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?
The 01/10/13, Stefan G. Weichinger wrote: I used split and tar to split the image-file into 100 MB parts and rsync them over right now. Maybe I have something wrong in my kernel ... the server shows a load of around 3 ... while only the rsync is running and my mosh-session ... This is a 24-core-system ... it shouldn't even blink ... If you are sure the load don't come from userland (htop?), I would think about reporting a kernel bug. This might be an issue with the NIC driver. -- Nicolas Sebrecht
[gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?
The 27/09/13, Stefan G. Weichinger wrote: I am back from my visit at a customer where I installed a new and shiny gentoo server for running VMs (KVM). Currently I don't have access as my VPN only works from my static IP at home (my router seems to be offline right now ... and I am still away from office for the weekend) so I can't check details now ... basically: I tried to copy/rsync some file with ~8GB over a gigabit connection ... from old to new server. Checked ethtool for gigabit, looked ok. I always saw the behavior that the transfer started rather fast and slowed down within minutes. Let's say ~50 MB/s in the start and then down to maybe 2 or so. That is way from the expected throughput with such new hardware. You should give details of the tests. It looks like a hard disk write speed bottleneck. -- Nicolas Sebrecht
[gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?
The 27/09/13, Stefan G. Weichinger wrote: Am 27.09.2013 15:02, schrieb Nicolas Sebrecht: You should give details of the tests. It looks like a hard disk write speed bottleneck. I will get access again on monday. That's a hardware RAID-10 on 6 SAS disks ... that should be fast enough ... Try avoiding to write on disks. Use devices /dev/null and /dev/zero with both protocol and command lines not optimizing zeros for network tests. You could also use dedicated network performance tools if you have install rights. -- Nicolas Sebrecht
Re: Integrated ZFS for Gentoo - WAS Re:[gentoo-user] Optional /usr merge in Gentoo
The 04/09/13, Joerg Schilling wrote: Linux does not contain code to boot AFAIK Sure, it does. You can boot on the kernel directly without a boot manager. -- Nicolas Sebrecht
[gentoo-user] Re: where did lvm installation guide go?
On Fri, Aug 30, 2013 at 10:37:19AM -0400, Tanstaafl wrote: Just fyi... the *only* problem that I have with this is that I have an *existing* system that has a separate /usr, and it only has that separate /usr because when I followed the original gentoo installation handbook back in 2003 or so, it actually had a separate /usr in the example directory structure layout, so I thought it was the official gentoo *recommendation* to do it that way. Following the Gentoo original handbook at that time was the good thing to do. But things change over time. What was true in 2003 might not still be true today or tomorrow. Things did change to the point that nowadays using an initramfs to keep a seperate /usr filesystem is the way to go. It's surprising you to have taken the handbook from Gentoo as best practice guide to get a proper system and not beeing fine with the recommendations of today. If I wasn't in this predicament, I'd just make a mental note to never install /usr to a separate partition and be done with it. Honestly, I used to have create a dedicated /usr filesystem for a long long time. It really was a big plus in the past. Except of some corner cases, I don't think it worth the trouble anymore. -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo is so AWESOME
On Fri, Aug 02, 2013 at 08:34:11PM +0100, Steven J. Long wrote: Again you're wilfully misinterpreting what I've said, and answering a completely different point. You didn't know the basics of how to go about approaching Gentoo. Stuff that practically every user knows, or can find out *very* easily: much more easily than the documentation they end up searching to do an install and maintain their machine/s. Again, if you cba to do that basic groundwork, wtf do you expect? Oh yes, us all to fall over ourselves and fete you with discussion about how wonderful you are, and how lucky we'd be if you only deigned to contribute some of your wisdom to us mere mortals. So much so that we ignore all the usual metrics, and take your email as gospel truth, that overrides whether you are actually a good fit for Gentoo, or even whether you can lookup docs on a website, let alone have actually contributed as part of the community. Good luck with that approach, and your current projects. While I (and others BTW) was trying to provide an external POV with points to make outside contributions and rectruitement more efficient, you guys @gentoo.org turned this thread into plain bullshits. Starting with a statement like Please note I'm not discussing any technical ability you may or may not have. does not allow you to make the exact opposite and being insulting or border-line in the rest of your mails. I don't remember I ever faced to such direct and personal judgments in the open source world. Oh, I know you pretend it's not. So, I'm on my way, dear, in order to: - learn how to approach a community (stuff that practically every user knows); - learn where to find the doc and read it; - learn all the basics; - not magnify myself. Thank you for all the smart feedbacks. Obvisously, it was all about me. F**k I want to believe you don't embody the dominant POV of the Gentoo maintainers about the original topic. / I'm going serioulsy tired of this thread. -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo is so AWESOME
On Sat, Aug 03, 2013 at 03:20:27PM +0200, pk wrote: On 2013-08-03 14:28, Nicolas Sebrecht wrote: On Fri, Aug 02, 2013 at 08:34:11PM +0100, Steven J. Long wrote: While I (and others BTW) was trying to provide an external POV with points to make outside contributions and rectruitement more efficient, you guys @gentoo.org turned this thread into plain bullshits. Please note that the one you replied to (Steven J. Long) does not have a @gentoo.org email address... Ah, right. Sorry for that. -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo is so AWESOME
The 01/08/13, hasufell wrote: Let's not make this yet another git migration discussion. Sufficient to say, that it is not trivial to implement in Gentoo since we have to migrate history, tools (not just end-user tools, this is also about infra) and a lot of other stuff without breaking everything. Yes, the more objectives are high, the more it is hard to get it running. Even Linus said that once the kernel repository will be too much big he will archive the current repository to keep logs and start with a new one. Also: A lot of gentoo projects have an overlay on github or similar where they accept pull requests already. Including sunrise. ... There is a lot of room for improvement in the political aspects of gentoo. In order to change it, you have to get more involved. I think I wans't clear enough. I proposed myself when the first discussions for CVS to Git migration started. I guess it is something like 2 to 3 years ago. Today, I don't want to contribute anymore. I think the dev ML is not the right place to ask for a mentor, you actually have to _find_ one. Discuss on IRC, help out on bugzie, send pull requests to official gentoo overlays and then you might already know a few devs who work in that area you are intested in. If you are unable to find one, the recruiters will help you with that, just contact them. This is exactly the topic. The feeling I have when I read this thread is that I've not been alone to not get more involved in Gentoo _because_ of this recruitement process. I'm pointing out that it is really too much and I think that Gentoo could benefit of more open ways to contribute. It's true that with more git-based projects it's easier today than in the past to get involved. But there are still ways of improvement in this area, IMHO. I just try to give my external POV to others so they are aware of my experience and perspective. What you do with this owns to you. ,-) Also: we approach people ourselves who force us to commit for them every single time. It is annoying, so we want them to become devs ;) Obsiously. :-) Regards, -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo is so AWESOME
The 02/08/13, Steven J. Long wrote: Again, I proposed myself to the dev list two times in the past. Nobody cared and I had no answers. Because that has never been the process: anyone can post to the mailing-list, it doesn't mean anything. While I agree it would have been good if recruiters had followed it up with you, if you're so new to Gentoo that you think the ML is how to start, then I can see why people might feel you needed to learn more, perhaps by reviewing the documentation. And if that's too much to ask, then perhaps you're not cut out to be a Gentoo developer: ime you need to be more of a self-starter just to use the distro. Please don't get me wrong: I think the recruitment process could be improved, in particular by having more developers working on it. And that does take a cultural shift, in terms of seeing recruitment as important, and a desirable thing to work on, as well as in terms of being more proactive and welcoming to newcomers, and to external perspectives. Neither of those change the fact that you don't join a team just by sending them an email. Like it or not, there are social factors involved, or it wouldn't be a team of people, however loosely associated. If social factours is important, it is not just that FMPOV. Anyway, you seems to think the way Gentoo shares code and knowledge is good enough as-is to have contributors and new developers. Fine. I don't think so and the other contributions to this thread confort me in my opinion. Please, take the critism the constructive way. The topic is not about me. And if you cba to review the basics, stuff most users know, or can find out easily, what makes you think you're cut out to be a developer? Please note I'm not discussing any technical ability you may or may not have with bash, ebuilds or upstream sources. Just your ability to find out the basics, which is much less difficult than installing Gentoo in the first place. If you want/ed to be a developer, my advice would always be: show you're useful, not that you need hand-holding and ego-stroking from the get-go. I've been an occasionnal contributor to Git, the active maintainer of OfflineIMAP for more than a year and I'm maintainer and developer at $DAY_JOB since years. I turned the OfflineIMAP worflow from one maintainer into a team of official maintainers. This is merely one example of my contributions to the open source world and when it comes to recruitement, workflow and decision processes I think I know what I'm talking about. Pointing out my hand-holding, ego-stroking or whatever looks pointless. I know the basics. Thanks, -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo is so AWESOME
On Fri, Aug 02, 2013 at 01:58:35PM +0200, hasufell wrote: So we are pretty open to new contributors. Nice conclusion! -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo is so AWESOME
The 01/08/13, Hans de Graaff wrote: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2 documents this from the new developer perspective. Note how it says to contact the recruiters if you don't already have found a mentor yourself. There is also http://www.gentoo.org/proj/en/devrel/recruiters/ which documents this from the inside, but when I wanted to become a developer I found that more useful documentation :-) So it is explicitly documented. Perhaps not well enough? In that case, let us know what you miss. I've proposed myself some years ago. Things might have changed since then but at that time the mail I sent to the dev list got no response. Process recruitement is incredibely busy and over-complicated compared to all other projects I've been involved into. I think this stands like that because most developers are afraid to give wirte acces to the whole portage CVS tree to others. In all other projects, it's almost a question of subscribing to a mailing list and send git patches. With time, you get direct write access. With Gentoo, you have to find a mentor, officially call for being a member, success the online tests, keep mentored some time. Not very light and efficient... Now, I'm away from Gentoo and it's fine. :-) -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo is so AWESOME
The 01/08/13, Alon Bar-Lev wrote: I don't see the major difference between that and opening a bug and attaching the patch. Only that bugzilla allow to manage the process, not have leftovers, and future people can resume past discussions. The bugzilla thing is what makes the difference, IMHO. git-push and git-send-email are one shoot simple commands to get things done. Having to open the web browser, connect to bugzilla, attach the patch and comment online is too much busy. With Gentoo, you have to find a mentor, officially call for being a member, success the online tests, keep mentored some time. Not very light and efficient... Can you please suggest a different method to ensure quality? Yes, having a few maintainers team with write access to the whole portage tree and contributors sending patches to them or to official package maintainers making the first review before they do the merge and submit to the main maintainers. Something like the kernel with the main maintainers, the lieutenants and open contributors. -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo is so AWESOME
The 01/08/13, hasufell wrote: You can use the command line too. www-client/pybugz I know this tool. I did try it. At that time it was buggy and did not work for me. Though, this would still be a busy process as this is just another interface og the bugzilla thing. Git workflow has been on the todo list for a long time, as well as review systems such as gerrit. It is non trivial to implement Other than the git repository size requiring a huge initial clone, it's very easy to do. And yes, I've read all the headaches on the Gentoo mailing lists about the git migration. Also, Gentoo organization has two heads making ambitious dicisions hard to take. And AFAIKS, to decision process in Gentoo is not helping at all. We are far from how it worked at the genesis/beginning of Gentoo. It is non trivial to implement and none of it is an excuse for not contributing IMO ;) Those are enhancements and we are already working on it. Get your hands dirty. Oh, yes. Pass the recruitement process to enhance the recruitement process, workflow and decision process (not possible to change, IMO). Funny! :-) Again, I proposed myself to the dev list two times in the past. Nobody cared and I had no answers. -- Nicolas Sebrecht
[gentoo-user] Re: Kernel Questions
On Thu, Jan 24, 2013 at 02:21:22PM +0100, Silvio Siefke wrote: Hello, On Wed, 23 Jan 2013 09:30:02 +0100 Nicolas Sebrecht nsebre...@piing.fr wrote: Did you check if the system is swapping when that happen? Im sorry, you mean Swap? How can check them best? % free -m The htop tool is good, too. -- Nicolas Sebrecht
[gentoo-user] Re: Kernel Questions
The 23/01/13, Silvio Siefke wrote: I use the good old Pentium 4 on the desktop and an atom on the laptop. But I have often the problem when the computer has much to do, that the system freeze. That's on the atom often so. The opera is my favorite Browser, but often the call on a website and the result end in freeze. What is really strange, when i run emerge --sync ; emerge -avuDN @world, the Pentium 4 is faster as the Atom. Is that normal? Did you check if the system is swapping when that happen? -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 07/09/12, Dale wrote: The thing is tho, whether it is using the memory as cache or using it as tmpfs, it is the same memory. There is no difference. That's the whole point. Feel free to take your own assumptions as undeniable truth. The way the kernel work with memory is the key, of course. Now, as long as you blind yourself with statements like that, I'm not going to respond anymore. I guess you need to make some basic research. -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 06/09/12, Dale wrote: But whether it is on tmpfs or just regular memory doesn't matter. Once emerge starts, everything is in ram including portages work directory which would be on tmpfs here. That's why it doesn't matter if portage is on tmpfs or not. Once emerge loads up the files, it's the same thing. That's why using tmpfs doesn't matter. I knew that the whole time. The amount of ram on a system doesn't matter either. If you have a system that doesn't have a lot of ram, then you can't really use tmpfs anyway. That is not something I would recommend to anyone. But you're wrong with this assumption. I guess you never tried to upgrade a Gentoo system running as server (a working one, with users and workload). The amount of memory is only /one/ helper parameter to not see a difference. Like I've already said, the issue is all about the persistence strategy used by the VM to mark memory as pinned, reclaimable or swappable. Where tmpfs do change the matter is that a file stored in it is not going be dropped from RAM until there is a unlink(2) call on it or that other running processes are running out of memory and some page needs to be swapped (so there is _already_ no more available RAM in the kernel cache). If not using tmpfs and because memory cache is the first place where the kernel will free up memory, you don't have to wait for the processes to run out of available memory to hit a situation where you'll have to wait for the disk to retrieve files. So, this will affect times. -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 06/09/12, Dale wrote: But this is what you guys are missing too. If you want to use tmpfs, you have to have enough ram to begin with. Whether you use tmpfs or not, you have to have enough ram to do the compile otherwise you start using swap or it just crashes. Having ram is a prerequisite to using tmpfs. This is too minimal overview to get the point. Memory is not a static place. This is not a cake beeing shared once. Memory is living. See my other mail. There is another flaw in your assumption above. I already had the tarballs downloaded BEFORE even the first emerge. This is not a flaw in assumption. This is negligible. What the people wanted to test is if putting portages work directory on tmpfs would make emerge times faster. Come'on. We all understood your goal from the beginning. Do we all admit that having portage on tmpfs does not make emerge times faster yet? No. It depends on factors and underlying processes you claim they don't matter, which is wrong. They *might* be not relevant in some cases. -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 07/09/12, Nicolas Sebrecht wrote: There is another flaw in your assumption above. I already had the tarballs downloaded BEFORE even the first emerge. This is not a flaw in assumption. This is negligible. Fixing myself: s/negligible/out of the scope/ -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 05/09/12, Dale wrote: Michael Mol wrote: On Wed, Sep 5, 2012 at 11:17 AM, Neil Bothwick n...@digimed.co.uk wrote: On Wed, 05 Sep 2012 07:52:45 -0500, Dale wrote: I might also add, I see no speed improvements in putting portages work directory on tmpfs. I have tested this a few times and the difference in compile times is just not there. Probably because with 16GB everything stays cached anyway. I cleared the cache between the compiles. This is the command I use: echo 3 /proc/sys/vm/drop_caches But you are still using the RAM as disk cache during the emerge, the data doesn't stay around long enough to need to get written to disk with so much RAM for cache. Indeed. Try setting the mount to write-through to see the difference. When I run that command, it clears all the cache. It is the same as if I rebooted. Certainly you are not thinking that cache survives a reboot? You missed the point. One of the first thing emerge will do is to uncompress the package. At this time, all the files are cached in RAM. Hence, everything needed for the build/compilation will come from the cache like it would do with tmpfs. -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 06/09/12, Dale wrote: Then explain to me why it was at times slower while on tmpfs? Trust me, I ran this test many times and in different orders and it did NOT make much if any difference. As explained, this is expected if you have enough RAM. I didn't check but I would expect that files stored in tmpfs are NOT duplicated in the the kernel cache in order to save RAM. So, the different times could come from the fact that the kernel will first look up in the kernel cache and /then/ look up in the tmpfs. In the scenario without tmpfs and lot of RAM, every unpacked file is stored in the _kernel cache_ with really fast access much before hitting the disk or even the disk cache (RAM speed and very few processor calculation required). While retrieving, the file is found on first look up from the kernel cache. In the other scenario with tmpfs and lot of RAM, every unpacked file is stored in the tmpfs allowing very fast access (due to RAM speed) but with the price of a first negative result from the kernel cache (and perhaps additional time needed by the kernel for accessing the file through the driver of the tmpfs filesystem). Using tmpfs will still be better as it prevents from writes to the disk in the spare times, avoiding unnecessary mecanic movements and saving disk life time. I might add, the cache on the drive I was using is nowhere near large enough to cache the tarball for the package. Heck, the cache on my current system drive is only 8Mbs according to hdparm. That is not much since I tested using much larger packages. You can't cache files larger than the cache. The disk cache is out of the scope. Do I need to run a test, reboot, run the test again to show this is not making much if any difference? I mean, really? o_O It won't make any difference from the drop cache configuration but it is still not the point! -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 06/09/12, Dale wrote: The point was whether having portages work directory on tmpfs resulted in speed increases. If you have portages work directory on tmpfs, of course it uses ram. That's what tmpfs is. It's taking what might normally be put on the disk and putting it in ram because ram is faster. Please, understand that whithout tmpfs and a lot of RAM, the kernel _won't_ work with the files from the disk but with the files stored in the _kernel cache_ which IS RAM, too. This explains why you get this result: The point is, cache or not, having portages work directory on tmpfs doesn't result in speed improvements as one would expect. Taking back your last sentence with precise sementic: The point is, /tmpfs cache (RAM)/ or /kernel cache (RAM)/, having portages work on tmpfs doesn't result in speed improvements. -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 06/09/12, Dale wrote: The point you are missing is this. Between those tests, I CLEARED that cache. The thing you and Neil claim that makes a difference does not exist after you clear the cache. I CLEARED that cache between EACH and every test that was ran whether using tmpfs or not. I did this instead of rebooting my system after each test. We clearly understand that you cleared the cache between the tests. We pretend that it is not much relevant for your tests because of another process. So, in theory I would say that using tmpfs would result in faster compile times. After testing, theory left the building and reality showed that it did not make much if any difference. Yes, because you did the tests on a system with lot of RAM. If the kernel needs to retrieve a file, there is basically the following workflow: 1. retrieve file from kernel cache; 2. if not found, retrieve file from tmpfs cache; 3. if not found, retrieve file from swap cache; 4. if not found, retrieve file from disk cache; 5. if not found, retrieve file from disk. This is simplified workflow but you get the idea. Now, what we are saying is that *when you have lot of RAM*, the kernel never hit 2, 3, 4 and 5. The problem with the kernel cache is that files stored in this cache are dropped from it very fast. tmpfs allows to have better files persistence in RAM. But if you have lot of RAM, the files stored in the kernel cache are /not/ dropped from it which allows the kernel to work with files in RAM only. Clearing the kernel cache between the tests does not change much since files are stored in RAM again, at the unpack process time. What makes compilation very slow from the disk are all the _next reads and writes_ required by the compilation. Well, why say that caching makes a difference then say it doesn't matter when those caches are cleared? Either caches matter or it doesn't. It does make a difference if you don't have enough RAM for the kernel cache to store all the files involved in the whole emerge process and every other process run by the kernel during the emerge. -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 06/09/12, Neil Bothwick wrote: The only real benefit of using tmpfs is the one you mentioned elsewhere, that the disks don't get bothered at all. Benefits also depends of what the system does during the emerge. If another process is intensively using the kernel cache and the kernel cache can't keep all the cached files for all the processes because it is missing of RAM, then underlying disk rapidity (tmpfs vs bare metal HDD) will sightly change the results. -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 06/09/12, Dale wrote: I do get it. I CLEARED #1 and #2, there is no usage of #3 and #4 is not large enough here to matter. So, it is left with #5. See the point? The test was a NORMAL emerge with portages work directory on tmpfs and a NORMAL emerge with portages work directory on disk and compare the results. The test resulted in little if any difference. If I ran the test and did not clear the cache, then I would expect skewed results because after the first emerge, some files would be cached in ram and the drive would not be used. If you clear the cache, then it has to take the same steps regardless of whether it was run first, second or third time. What you want to measure is the difference of times required by emerge whether you use a real disk or tmpfs as backend. What you would expect is a difference because a disk is much slower than RAM. What you see is no difference. You won't conclude that disk is as fast as RAM, right? Can you explain why you don't see much difference? No. Here is the explanation: if you have enough RAM, the emerge rapidity will NOT rely on the disk rapidity whatever storage backend you use. It will only rely on the RAM rapidity because of the kernel cache. Now, pretending that whatever backend you use (real disk or tmpfs) never changes the emerge time is WRONG because of the persistence strategy used by the kernel for the kernel cache. When having lot of RAM like you have, the persistence strategy of the kernel cache is NEVER raised in the process. This is exactly what your tests demonstrate demonstrate: if you have enough RAM, the persistence strategy of kernel cache is not raised, so everything happens in RAM, so the emerge times do not differ. -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 06/09/12, Dale wrote: Not quite. The theory is that if you put portages work directory on tmpfs, then all the writes and such are done in ram which is faster. No! This is too much simplistic view to explain what you see. In practice, _all_ the writes always happen in RAM whatever backend storage you use. The difference you could see is if there is not enough RAM for the kernel cache, it will have to wait for the backend storage. -- Nicolas Sebrecht
[gentoo-user] Re: aligning SSD partitions
The 06/09/12, Dale wrote: Then take a look at it this way. If I emerge seamonkey with portage's work directory on disk and it takes 12 minutes, the first time. Then I clear the caches and emerge seamonkey again while portage's work directory is on tmpfs and it is 12 minutes. Then repeat that process a few times more. If the outcome of all those emerges is 12 minutes, regardless of the order, then putting portages work directory on tmpfs makes no difference at all in that case. We fully agree with you, here. The emerge times are exactly the same regardless of emerge using cache or not or portage's work directory being on tmpfs or not. I don't care if emerge uses cache DURING the emerge process because it is always enabled in both tests. But you *should* care. If you don't have enough memory, the kernel will reclaim memory from the pagecache, so the whole process rapidity won't only rely on RAM rapidity anymore. The point is whether portage's work directory is on tmpfs or not makes emerges faster. The thing about what you are saying is that I ran those tests with the files in memory. What I am saying is this, that is not the case. I am clearing that memory with the drop_cache command between each test. You claim that cache is affecting the timing but I am clearing the very same cache the same as a reboot would. The emerge times whether portage's We do agree with you that you droped the cache between the tests with almost the same effect of a reboot. The emerge times whether portage's work directory is on tmpfs or not didn't change enough to make a difference. Yes, we agree. You droped the cache which is expected to get correct tests. What we are saying is that you droped the cache but did NOT DISABLED the VM caches (kernel cache). You say that you don't care of that one because it was involved in all the tests. We say that you might not care in some contexts, not for all the contexts. You reach the context where it does not matter much, fine. -- Nicolas Sebrecht
[gentoo-user] Re: {OT} hire a programmer or company?
The 30/05/12, Grant wrote: So if I see a way that their coding could be improved (faster execution, greater legibility, etc) I just keep quiet about it? Improvements is only one aspect of where to focus the efforts. How often should I read their code? I was planning on reading it a lot. In small teams, these tasks (including making releases) are usually done by the software maintainer. To know what to do, you should be clear about who will be in charge of releasing the software. A SVC is *required* and the tool choice should be a team choice. Once done and roles assigned, it will be really easy for you to know what you can/should do or not. Anybody can act/interact as different role as long as the role is well defined (e.g. while reviewing code, you do reviewing code /only/ and might discuss the design choices but the final technical decision must stay in the hands of the software maintainer). FMPOV the key role is the maintainer. The job requires both good technical knowlegde and a large project view. -- Nicolas Sebrecht
[gentoo-user] Re: InitRAMFS - boot expert sought
The 29/03/12, 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? I think there is a better thing to do. Use an initramfs. This is not hell! ;-) -- Nicolas Sebrecht
[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
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
The 13/03/12, Bruce Hill, Jr. wrote: So, what qualifies for the moment a fringe program reaches critical mass to become maistream, the probability of it needing udev (directly or indirectly) will increase. Again, quoting _your_ definition. I gave you examples of programs which have reached critical mass, which don't require udev. And, I'm not attaching your character, for I know you not ... just attacking your FUD! This is not FUD. And more importantly, what Canek says is certainly true. In the past, the kernel was handling devices alone. Since udev, the possibility for userland programs to hook themselves in this process became very easy. Some of them have use this feature very early but we can reasonably think the work is not totally achieved. Also, developers write code given the context at the time it is written. But the changing context doesn't necessarily imply other programs to be rewritten at the same time. Once the context changed, we can reasonably think that currently working code not going to be hacked soon will be rewritten in the longer run to take advantage of this udev facility. Pointing to this fact is not FUD. I'd say it is nice analysis which could even help the current udev - mdev effort by providing a different picture of the landscape. -- Nicolas Sebrecht
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
The 05/01/12, Pandu Poluan wrote: And mdev might be a 'toy' to you, but embedded Linux developers will vehemently disagree with you. And based on the responses in this thread, server guys will also disagree with you. On the embedded side, we need udev much more than you think to support bluetooth, tablet and so. Android uses udev. This is even more true when we know that users will expect to have any plugged-in devices at whatever boot time or runing system be working out of the box. BTW, this is not a major problem since embedded devices already often use initramfs. On servers, I wouldn't be surprised that hypervisor tools will expect /dev/cdrom instead of /dev/sr0. AFAIK, mdev doesn't provide persistent device names and changing a ethernet card might result in a highly broken system where udev will let all interfaces working but the changed one. Worse, I think mdev might change of device names upon reboot so that all ethernet devices can be mixed up in ways like eth0 - eth1, eth1 - eth3 and eth2 - eth0. These are only few examples and this is whole mdev hack (requirements and consequences) that makes mdev alternative look like a toy. People thinking that mdev could replace udev even on embedded devices and servers are wrong for both current or longer term. You might like it or not but udev is a core system tool, nowadays. As admin, I will expect to have a initramfs and udev on linux systems whatever they are desktop, embedded or servers. Actually, I already rely on initramfs for all of these kind of systems for years with success. -- Nicolas Sebrecht
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Thu, Jan 05, 2012 at 02:20:21PM -0500, Michael Mol wrote: FWIW, I had a /dev/cdrom symlink long before *devfs* even existed, let alone udev. We are not looking for device paths that existed berfore udev. Actually, most of them exist since much more time than udev. It's not relevant at all. Also, ethN numberings are generally stable until and unless you do some strange BIOS tweaking or hardware changes, and should be able to be stabilized in the event the instability comes from some racy module loading mechanism. This is not true. I've had computers in hands where network cards could change of names without any BIOS tunning. BIOS is a executed program and the way each is implemented can guarantee *or not* to have the conditions for persistent NIC names on Linux. udev's attempts at stabilizing network interfaces have made things worse more often than I've heard of it making them better. Hit any search engine for eth0 missing 70-persistent-net.rules. It's fully expected and required. Persistent naming can work if you have a configuration for that somewhere. I see nothing worse here. But I see an improvement to let me tune the NIC names if I need to. I have routers with *lot of* NIC cards where this feature is very usefull (expressive names are much better than ethX). (Apologies for anyone who sees this message in such a result; just delete /etc/udev/rules.d/70-persistent-net.rules, and you should get eth0 back.) still quoting to help beginners -- Nicolas Sebrecht
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
The 03/01/12, Pandu Poluan wrote: (Come to think of it, has *any* distro ever attempted this... 'unconventional of going udev-free?) mdev is not an udev replacement. It's a very minimalist udev designed for embedded systems and initramfs. These days, a full-featured system require a dynamic /dev and AFAIK the only existing and up-to-date tool for this job is udev. I don't think any other distro attempted to get free of udev as it means coming back to 10 years ago, at least. -- Nicolas Sebrecht
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
The 03/01/12, Pandu Poluan wrote: But I can see a use case for mdev completely replacing udev: servers and virtual machines. Servers, especially production ones, have a hardware change only once in every two blue moons. They don't need all the bells and whistles of udev. Even more so when you've gone the virtualized route. Since servers are arguably where Linux shines the most, mdev should be seriously considered as a udev replacement. But servers have enough ressources to run udev and any required initramfs to mount /usr. So, the question is where engineering should go: - mdev and manually manage /dev devices if nedded or - rely on initramfs to mount /usr. As initramfs is a prooven working solution, all distributions I know use it either by default or if needed. Also, I think the coming problem you will be face with in the mdev way is the move of binaries from /bin to /usr/bin and so. -- Nicolas Sebrecht
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
The 03/01/12, Alan McKinnon wrote: If you go back through the list archives you will find the enormous thread that caused Walter to start down this road in the first place. His efforts are an attempt to deal with the gigantic bloat-fest that the udev devs seem to revel in. If you go back through the list archives you will find that I'm envolved in this thread. ,-p Walter is doing fine work, he should be supported in this. It's free software so everybody can feel free to support him, of course. I think it's time consummed in the wrong road. I'm a bit curious how long this alternative can survive. :-) -- Nicolas Sebrecht
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
The 03/01/12, Pandu Poluan wrote: On Tue, Jan 3, 2012 at 20:13, Nicolas Sebrecht nsebre...@piing.fr wrote: But servers have enough ressources to run udev and any required initramfs to mount /usr. No, no, no, you got it the wrong way around. It's not udev *per se* that I -- as a server admin -- want to get rid of. It's the initramfs. And I also want to put /usr in a separate partition. The problem is that, judging from where udev is going in upstream, we will be forced to use initramfs, or put /usr in / I know. It's the I want to get the rid of initramfs thing that looks crazy to me. As initramfs is a prooven working solution, all distributions I know use it either by default or if needed. Then again, using initramfs is yet-another-component waiting to break. Knowing Murphy's Law, it will one day fuck up everything. And the mdev alternative won't follow this law? -- Nicolas Sebrecht
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
The 03/01/12, Volker Armin Hemmann wrote: Am Dienstag, 3. Januar 2012, 14:36:08 schrieb Nicolas Sebrecht: It's free software so everybody can feel free to support him, of course. I think it's time consummed in the wrong road. I'm a bit curious how long this alternative can survive. :-) since Walter does it to ease an itch he is feeling and since Walter is doing this for fun 'time consumed in the wrong road' is not an argument. Of course, it's not an argument. It's my feeling. I'm not against people hacking on crazy ideas. I do it myself when I think it worth. -- Nicolas Sebrecht
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
The 03/01/12, Walter Dnes wrote: On Tue, Jan 03, 2012 at 05:22:09PM +0700, Pandu Poluan wrote (Come to think of it, has *any* distro ever attempted this... 'unconventional of going udev-free?) Alpine linux has done it http://alpinelinux.org/ Unfortunately, they're so minimalistic and server-oriented that they use uclibc instead of glibc. Hugh? http://alpinelinux.org/apk/main/x86/udev -- Nicolas Sebrecht
[gentoo-user] Re: A helping hand with virtual machines, please.
The 22/11/11, Alan McKinnon wrote: I use virtualbox and it's the one I recommend. The kernel modules are no better and no worse than any other out-of-tree modules. You're wrong. Using the virtualbox module means you turn the kernel to tained crap because of the number of problems it causes, including random memory curruption. -- Nicolas Sebrecht
[gentoo-user] Re: A helping hand with virtual machines, please.
The 23/11/11, Alan McKinnon wrote: On Wed, 23 Nov 2011 10:17:07 +0100 Nicolas Sebrecht nsebre...@piing.fr wrote: You're wrong. Using the virtualbox module means you turn the kernel to tained crap because of the number of problems it causes, including random memory curruption. Care to back that up with something resembling evidence? EVERY out-of-tree module will taint the kernel. But not all virtualization solutions use out-of-tree module and from those coming out-of-tree, few are taint as crap. As to whether it deserves the crap moniker is a matter of opinion ...I'd rather say a matter of facts. :-) Every one is free to support virtualbox but forgetting to talk about this taint level is not very fair, FMPOV. -- Nicolas Sebrecht
[gentoo-user] Re: A helping hand with virtual machines, please.
The 23/11/11, Joseph Davis wrote: I agree a list of issues, just broad ones, would be helpful. I am interested in VMs, so knowing which ones have what problems, and my own needs, would be help me make a good choice. Please, disparage with details! ;-) I've already said random memory curruption. random is the key word explaining why not much details can be given. :) -- Nicolas Sebrecht
[gentoo-user] Re: A helping hand with virtual machines, please.
The 23/11/11, J. Roeleveld wrote: I also got random memory corruption when compiling large packages with simple kernel configurations and no out-of-tree modules present on the system. Do you have any evidence to proof that this randomness is actually caused by VB modules and not something else? This is a question you should ask to the kernel developers. You're free to not trust them, of course. I'll still think they are at a much better place than yours to tell which driver are crap and which are not. -- Nicolas Sebrecht
[gentoo-user] Re: sed/awk question
The 22/11/11, Joerg Schilling wrote: You seem to miss the fact that you are using gsed instead of sed. using -r makes scripts non-portable. You seem to miss the fact that the OP didn't asked for a portable script and didn't even talked about any system specification. So, it's _welcome_ to suppose he's using the most available implementation of sed on Linux distribution which is GNU sed. -- Nicolas Sebrecht
[gentoo-user] Re: udev + /usr
The 17/09/11, pk wrote: dbus is installed in my system, but only because I run Xfce4 (I am thinking of installing something else due to it's becoming bloated just like gnome). And I have -dbus in my global make.conf. PS. I am quite astonished at the fact that I have a computer that is _way_ faster than the first machine I installed GNU/Linux (an Amiga 4000 with a 68040 cpu at 40Mhz) on but the experience is still the same; it takes about the same time to boot, the same time (or even slower) to load a program. It seems the faster the computer the more I have to wait for it to finish some task. Contradictory, no? Wonder why that is... (bloat?). Believe it or not but I bet you're not doing the same tasks with your modern machine and could just not run the user-end software you use today on a Amiga 4000 with a 68040 cpu at 40Mhz because they learn new feature since then. Bloat? -- Nicolas Sebrecht
[gentoo-user] Re: /dev/sda* missing at boot
The 09/09/11, Michael Schreckenbauer wrote: The question arose, when Canek mentioned bluetoothd, that udev seems to need in some cases. This is wrong. udev on its own does not require extra tools from /usr. Though, the rules used by udev do use software in /usr. It's NOT a udev fault _at all_. This is how developers wrote software and because they wanted to hook themselves early at boot time, using udev facility. They are PulseAudio, NetworkManager, libatasmart, ALSA, D-Bus, CUPS, VirtualBox, usbmuxd, bluetoothd and a LOT of other tools. It's even worse when you know that some scripts are written in python. Everybody can write its own rules without even think about direct (or hidden) /usr dependency. Again, udev is NOT to blame. If bluetoothd doesn't quite fit to /bin or /sbin (I tend to agree here), but is needed before /usr is mounted, then it has to be put *somewhere*. I don't say, that this is the way to go. Only searching for alternatives to a forced initramfs. So, what's the good way to fix all that mess? Certainly not moving most of software to /. Fortunately, we can expect /usr to be mounted before udev starts via the initramfs. It does NOT mean everybody will require a initramfs. It means people WANTING a seperate /usr will need a initramfs. The good thing is that a lot of tools now in / will be granted back to /usr. Let's clean up /. Also, it's a _good_ news for admins expecting to maintain systems with a shared /usr (e.g. over the network). -- Nicolas Sebrecht
[gentoo-user] Re: /dev/sda* missing at boot
The 09/09/11, Michael Schreckenbauer wrote: Am Donnerstag, 8. September 2011, 23:44:41 schrieb Alan McKinnon: On Thu, 8 Sep 2011 21:29:40 + Alan Mackenzie a...@muc.de wrote: Would it not be possible to have a minimal /usr tree in the root partition for udev's use at boot time, and to later mount a more robust /usr partition over this? What am I missing here? A big problem will be that the package manager cannot easily maintain that phase 1 code as it's under another mount point. Doing so would require the package manager to bind-mount / somewhere and copy updated binaries of essential packages there as well as into the real /usr. Not an insurmountable problem, it just requires changes to all affected packages, and well within the capabilities of distros. Couldn't whatever mounts /usr bind-mount this hidden /usr somewhere (where, I think, could be a good question here) before mounting the real one? Then it would be visible even after the real /usr is mounted. So, you're asking if it's smart to use yet another path (hidden once finished to properly boot) to store what is currently stored in /bin and /sbin... Remember: the only reason why /bin and /sbin exist is to have tools available during boot time to mount /usr. -- Nicolas Sebrecht
[gentoo-user] Re: Replace root with aufs-united sda squashfs
On Sat, Jul 23, 2011 at 11:01:43AM +0700, Pandu Poluan wrote: AFAIK, there are files that *must* still exist for this strategy to succeed. However, this post from f.g.o [2] said that those files aren't necessary. So, I should do the following sequence in /etc/fstab : 1. Mount /dev/xvda3 as / 2. Mount /.root.sqfs as / 3. Mount aufs, uniting /dev/xvda3 and /.root.sqfs as / 4. Mount everything else AFAIK, it should be more something like: mount -t aufs /dev/xvda3(rw) and /root/sqfs(ro) /new_root And then chroot to /new_root. -- Nicolas Sebrecht
[gentoo-user] Re: root fs moved, but no init
On Sun, Jul 24, 2011 at 09:49:21AM +1000, Adam Carter wrote: Summary; Copied / from sda3 to sdb3 Updated the fstab in the new disk (/dev/sdb3 / btrfs noatime,compress=lzo0 0) Updated the kernel line's root=/dev/sda3 to /dev/sdb3 in grub.conf, but left the root (hd0,0) as it is. So, kernel is loaded from sda but init should run from sdb. When booting the kernel successfully mounts /dev/sdb3 as root fs Then the system halts at one of the freeing memory messages, but I assume the problem is that init isn't executed from /dev/sdb3 Since root is mounted, i know i have all the drivers I need in the kernel. Any ideas why booting stops? Unix rights on files? How did you copy the system? -- Nicolas Sebrecht
[gentoo-user] Re: Kernel panics and more info
The 21/07/11, Neil Bothwick wrote: On Thu, 21 Jul 2011 14:14:11 -0500, Dale wrote: It's the standard video driver, x11-drivers/xf86-video-vesa And I change nvidia to vesa or do I need to unmerge nvidia first? If you keep xorg.conf, change it to use vesa. Or move it to /root. Also, are these done as modules like nvidia is? Hmmm, if I remove xorg.conf, how does it know which driver to use? Hardware detection. If you don't use third party drivers, you can usually do without an xorg.conf. Or just read /var/log/Xorg.0.log after started X. -- Nicolas Sebrecht
[gentoo-user] Re: Kernel panics and more info
The 21/07/11, Nicolas Sebrecht wrote: The 21/07/11, Dale wrote: I have not been able to get the nv drivers to work. It has been so long since I had to use them, it appears I have forgot how to use them. I'm not sure I have ever used them since I been using Gentoo. Try VESA. I would suspect the NIC driver, too. I've seen a lot of people touched by a r8169 bug freezing the kernel on large downloads, recently. -- Nicolas Sebrecht
[gentoo-user] Re: Anyone have any trouble with rc_parallel=YES ?
On Tue, Jul 19, 2011 at 10:39:49AM +0700, Pandu Poluan wrote: Spelunking in /etc/rc.conf, I found the rc_parallel setting, accompanied with a quite significant WARNING. Have anyone experienced any trouble setting rc_parallel to YES? I did. I have a net configuration with some VLAN. Each VLAN has its own bridge to attach guest virtual NICs. One of the bridge doesn't add the assigned VLAN. Setting rc_parallel to NO resolved this issue. -- Nicolas Sebrecht
[gentoo-user] Re: Kernel panics and more info
On Fri, Jul 22, 2011 at 10:54:09AM -0500, Dale wrote: Just picking a post to reply here and it may have a good point. I was browsing around to see what software I had for my UPS. I thought I would download the thing, untar it and just check out the README file to see what would be involved in installing it on my rig. It was a tarball so nothing video related or flash related either. It also didn't use the little download helper tool I been using either. I clicked on the link to download and the window popped up to ask me whether to open it or save it. I selected to save it as I have done countless times before. As soon as I clicked that, the window popped up asking where to save it to then kernel panic. This was in Seamonkey. Could this be a network card/driver issue? I have had no problems so far with emerge downloading anything from the command line. I'm going to test this by deleting the tarballs for OOo and then fetching them again. If it doesn't crash, then maybe it is something related to HOW Seamonkey and Firefox access the net. If it does crash, then maybe I need a new network card. I can't believe any userland tool like a navigator could make the whole system crash. It's much deeper than that in the system. Again, it's likely to be a driver issue. You could test your network card by doing a lot of traffic on it (on the LAN to give you better chance to catch any issue), X stopped. Next, you could test X (even mouse and keyboard) by playing some games or whatever you don't do usual. But at *FIRST* as it looks like you didn't do it yet, you have to _check your logs_. -- Nicolas Sebrecht
[gentoo-user] Re: Kernel panics and more info
The 21/07/11, Dale wrote: I have not been able to get the nv drivers to work. It has been so long since I had to use them, it appears I have forgot how to use them. I'm not sure I have ever used them since I been using Gentoo. Try VESA. As for Firefox-bin, I'm not sure that would help Seamonkey. I could try it but not sure how that would help. Seamonkey would still crash. Now that I have the same tool I was using in Firefox, I'll most likely get rid of Firefox. The download helper was the only reason I was using Firefox. A book writer would say: when my system crash, I'm always using my text editor; so my editor makes the system crash. I'm not telling the root cause you suspect is not the real cause but that it is NOT likely to be the real cause in the first place. -- Nicolas Sebrecht
[gentoo-user] Re: Managing multiple Gentoo systems
The 06/07/11, Grant wrote: After a frustrating experience with a Linksys WRT54GL, I've decided to stick with Gentoo routers. This increases the number of Gentoo systems I'm responsible for and they're nearing double-digits. What can be done to make the management of multiple Gentoo systems easier? I think identical hardware in each system would help a lot but I'm not sure that's practical. I need to put together a bunch of new workstations and I'm thinking some sort of server/client arrangement with the only Gentoo install being on the server could be appropriate. I maintain multiple Gentoo we mostly use as KVM hosts systems (and coming embedded routers). As KVM hosts, some of them are very sensible. Due to the contracts to our customers, I have to do with various update strategies on top of various hardware. Thanks to everyone for some very juicy tidbits. I'm rearranging my thinking on all of this. I think the key for me may be to combine systems with separate functions in the same physical location into a single system. Does the KVM thing work well? KVM itself works very well here, even with advanced features such as KSM pages sharing. The difficulties come with Microsoft products for both good integration and perfomance (I would recommend RAW format, iSCSI or plain physical partition instead of qcow2, for example). That beeing said, I finally have all working well for XP, NT2003 and 2008 servers. I use libvirt on top of KVM which is in the way to become very good AFA you don't rely on libvirt's API which tend to move a lot. Running a bunch of workstations as nothing more than wireless KVM setups on the same system? I should be able to cut my Gentoo systems down to just a few. Basically one at each physical location. I would be much sceptical for both workstations and wireless guests than for servers: 1) For workstations, things are currently changing with the very recent and not much usable with Gentoo, yet spice software. I expect a lot of improvments in the coming months for this use case. I would say it's not ready for production, yet. 2) About wireless virtualization it's highly depending on what you aim to do, especially if you intend to use the PCI passthrough feature to give your wireless card to a guest. For this to work, you MUST have your hardware (CPU, motherboard and PCI card) VT-d compatible which is currently NOT a piece of cake, today. It relies on industry and manufacturers moving not as fast as software. I would expect more widely VT-d cards in the coming _years_. Now, if you intend to use the wireless card from you hosts and share networks using bridge utilities it _MAY_ be OK: Linux bridging does not always work with all wireless cards (see http://tinyurl.com/ylcutwv for more information). In a more general approach, when I hear routers and wireless I'm more thinking _embedded_. KVM/qemu would only help you to build your target systems. For embedded (or tiny, at least) systems, I would not use LXC. The drawback with Gentoo is that the current official uclibc stage3 for embedded/tiny systems is obsolete and marked as experimental. In facts, it's very _hard_ if not impossible to use it these days. Making your own cross-compilation environment is not a piece of cake (too), even with dedicated tools such as crossdev. This topic would ask its own book. So, if you want to try Gentoo embedded save your time by working on unofficial stage3. -- Nicolas Sebrecht
[gentoo-user] Re: Managing multiple Gentoo systems
On Sat, Jul 02, 2011 at 03:14:38PM -0700, Grant wrote: After a frustrating experience with a Linksys WRT54GL, I've decided to stick with Gentoo routers. This increases the number of Gentoo systems I'm responsible for and they're nearing double-digits. What can be done to make the management of multiple Gentoo systems easier? I think identical hardware in each system would help a lot but I'm not sure that's practical. I need to put together a bunch of new workstations and I'm thinking some sort of server/client arrangement with the only Gentoo install being on the server could be appropriate. I maintain multiple Gentoo we mostly use as KVM hosts systems (and coming embedded routers). As KVM hosts, some of them are very sensible. Due to the contracts to our customers, I have to do with various update strategies on top of various hardware. I've set up a private Gentoo mirror in order to follow updates nicely (all customers want to update slowly). Well, it's not a true mirror. To be able to upgrade old systems, I do private releases of Gentoo approximately once a month. A full mirror of all releases would be too much data. So, I only fetch portage tree and packages from a list I maintain manually (emerge sucks at that game, by the way). Data is stored on a nilfs filesystem to improve snapshots size on disk. -- Nicolas Sebrecht
[gentoo-user] Re: you are stopping a boot service
On Sat, May 14, 2011 at 07:39:03AM +0200, Hartmut Figge wrote: Greetings, i am always booting to a console and switch later to X using startx. Now i have noticed a message appearing after typing the password: i5 login: Password: Last login: Sat May 14 06:58:55 CEST 2011 on tty1 * WARNING: you are stopping a boot service Same thing happens after switching from X to a console with e.g. ctrl-altl-F2. Hm? :) You may have a service in the wrong runlevel called boot. What do you have in it? ( 'ls /etc/runlevels/boot' ) -- Nicolas Sebrecht
[gentoo-user] Re: kvm and libvirt
The 29/03/11, Coert Waagmeester wrote: At the moment I have a running install of kvm. I do all the virtual networking manually with help of tap adaptors and bridges. And I use LVM for the VMs disks. It is working very well, but to add a VM or to migrate it to another host is laborious. Now I have started playing with libvirt, and I would like to know if anyone else here uses the combination of kvm and libvirt? I do. Managing VM from libvrit works well for basic features. That beeing said, I had to manage snapshots outside of the provided features due to internal dependencies between qcow2 snapshots. I still have to test migration as it requires virtual disks shared over the network. What is the most dynamic way of automatically setting up virtual networks per VM? Should I use qemu-ifup? I think the best alternative is to use a dedicated virtual bridging tool but virt-manager (so, libvirt I guess) already provide a network system (based on tun/tap AFAIR). -- Nicolas Sebrecht
[gentoo-user] Re: the best filesystem for server: XFS or JFS (or?)
The 22/03/11, Dale wrote: This is usually the case, more confusion. Every file system has its strengths and its weaknesses. Here is some info BTRFS: https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Current_Status There is no problem here. If you want RAID, you can just use the usual raid driver of the kernel. This issue is a noop. -- Nicolas Sebrecht
[gentoo-user] OT: governors (was: Is cpufrequtils needed these days?)
On Sun, Feb 28, 2010 at 07:52:02PM +0100, Volker Armin Hemmann wrote: On Sonntag 28 Februar 2010, Mick wrote: or is the kernel itself clever enough to manage the hardware directly these days? yes, it is. Just use the ondemand governor. I've noticed what looks like some work overloads using the ondemand governor. I'm pretty sure it is normal but I can see (user feeling) when the system loads the processor by intermittence. It is visible on some compilations tasks and when playing flash videos and compared to the performance governor. I'm still runing a 2.6.26 kernel. Just a user back report. -- Nicolas Sebrecht
