Re: [gentoo-user] [SOLVED] KDE 4.9.5 VERY slow to respond
Am 02.02.2013 11:19, schrieb Dale: > Volker Armin Hemmann wrote: >> you can ignore all that. there is something broken - have a look at >> htop while clicking, check with xev that your clicks are actually >> delivered on time. Check Xorg.0.log hat X is behaving the way it should. > I posted it earlier but it turned out to be dbus needing a update. It > appears dbus had a issue but the one with the fix was keyworded. > Anyway, it is back to normal now. Well, normal for me anyway. lol > > Thanks. > > Dale > > :-) :-) > yeah, we probably should have a look at your 'Dale being Dale' problem in the near future ;)
Re: [gentoo-user] [SOLVED] KDE 4.9.5 VERY slow to respond
Am 02.02.2013 22:18, schrieb Dale: > Volker Armin Hemmann wrote: >> Am 02.02.2013 11:19, schrieb Dale: >>> Volker Armin Hemmann wrote: >>>> you can ignore all that. there is something broken - have a look at >>>> htop while clicking, check with xev that your clicks are actually >>>> delivered on time. Check Xorg.0.log hat X is behaving the way it should. >>> I posted it earlier but it turned out to be dbus needing a update. It >>> appears dbus had a issue but the one with the fix was keyworded. >>> Anyway, it is back to normal now. Well, normal for me anyway. lol >>> >>> Thanks. >>> >>> Dale >>> >>> :-) :-) >>> >> yeah, we probably should have a look at your 'Dale being Dale' problem >> in the near future >> >> ;) >> > Well, I do run into problems from time to time. I got a thread on here > about gtkam that is a real head scratcher. I don't know tho, maybe I > don't have any more problems than anyone else. I don't start to many > threads with problems so maybe it just feels like Murphy picks on me a > lot. :/ > > I wasn't the only one with this problem either. So this time, it was > not just me. lol I just had the nerve to post about it. O-o > > Dale > > :-) :-) > don't worry to much about it. Some people are just lucky and run into problems a lot. Not even their fault.
Re: [gentoo-user] Selecting a Linux compatible mobo for FX8350
Any am3+ board should work. know of no feauture intetferemce. Am 12.02.2013 10:09 schrieb "Nilesh Govindrajan" : > Hi, > > I'm searching for a mobo which is fully compatible with Linux and > supports AMD FX 8350. > Preferably, I'm looking for one with onboard GFX, since I don't have > any need for a big GFX for now. > > Any pointers? > > -- > Nilesh Govindrajan > http://nileshgr.com > >
Re: [gentoo-user] Re: Acroread
Am 17.02.2013 13:05, schrieb (Nuno Silva): > On 2013-02-17, Nilesh Govindrajan wrote: >> On Feb 17, 2013 3:04 PM, "Yohan Pereira" wrote: >> >>> On 17/02/13 at 02:44pm, Nilesh Govindrajan wrote: That's what I did. But I tend to switch browsers too often (chromium and Firefox). Firefox has a pdf.js addon, doesn't work reliably many times. >>> If you use KDE try this. You can then use okular(among other things) >>> in your browsers. >>> >>> www-plugins/kpartsplugin >>> http://www.unix-ag.uni-kl.de/~fischer/kpartsplugin/ >>> Description: Plugin using KDE's KParts technology to embed file >>> viewers into non-KDE browsers >> That sounds interesting. Will try it out. Thanks. >> >> But nobody replied if Adobe still supports acroread? > AFAIK there was no annoucement regarding end of life for acroread, so I > don't see any reason to expect otherwise. > > Flash is a separate thing. > > But keep in mind that Adobe Acrobat Reader is one of the worst, most > bloated and most heavy PDF viewers out there. The only thing it may be > worthy for is some kind of bleeding edge PDF feature libpoppler and the > like don't have yet. > > Also, I actually had to try running it recently. I was trying to print a > document with annotations -- spoiler: it didn't work, not even with > acroread, closest I got was generating a postscript file using acroread > in the commandline after manually hacking the acroread settings to > enable annotation printing, and even then part of the annotations don't > show up or are covered, and there's no mapping between annotations and > their icons. But the interface was *really* slow, almost unusable. I > wonder why. I possibly overlooked something. > biddings need digitally signed pdfs. Easy to create with acroread. Not so easy with anything else. And that 'feature' is not arcane nor seldomly used.
Re: [gentoo-user] No space left on device ?
Am 23.02.2013 07:05, schrieb Joseph: > On 02/23/13 11:08, Nilesh Govindrajan wrote: >> On Saturday 23 February 2013 10:30:04 AM IST, Joseph wrote: >>> I'm trying to update one of my system and running: >>> emerge -uDNavq world >>> I get a very strange message: No space left on device' >>> >>> I have plenty of room left on the HD >>> df -h >>> Filesystem Size Used Avail Use% Mounted on >>> rootfs 50G 13G 35G 27% / >>> /dev/root50G 13G 35G 27% / >>> tmpfs 3.7G 668K 3.7G 1% /run >>> udev 10M 4.6M 5.5M 46% /dev >>> shm 3.7G 0 3.7G 0% /dev/shm >>> cgroup_root 10M 0 10M 0% /sys/fs/cgroup >>> /dev/sda4 530G 119G 385G 24% /home >>> tmpfs10M 4.6M 5.5M 46% /var/tmp/portage >>> >>> df -i >>> Filesystem Inodes IUsedIFree IUse% Mounted on >>> rootfs 3278576 829078 2449498 26% / >>> /dev/root 3278576 829078 2449498 26% / >>> tmpfs957692535 9571571% /run >>> udev 949264990 9482741% /dev >>> shm 957692 1 9576911% /dev/shm >>> cgroup_root 957692 6 9576861% /sys/fs/cgroup >>> /dev/sda4 35266560 33051 352335091% /home >>> tmpfs949264990 9482741% /var/tmp/portage >>> >>> So, why I'm getting this message? >>> >> >> Your /var/tmp/portage is 10 MB! Increase that. >> >> -- >> Nilesh Govindarajan >> http://nileshgr.com > > How do I increase it? > I deleted all the file in /var/tmp/portage but after reboot the system > populate it again. > In fstab I have two entries: > ... > shm/dev/shmdevtmpfsnodev,nosuid,noexec0 0 > tmpfs /var/tmp/portage devtmpfsdefaults 0 0 > > should I just comment them out? > no, you should change it to this: tmpfs /var/tmp/portage tmpfs rw,size=8G 0 0 play around with size. Usually 2GB is more than enough. Except for libreoffice. Then umount /var/tmp/portage and mount it again.
Re: [gentoo-user] No space left on device ?
Am 23.02.2013 09:52, schrieb Neil Bothwick: > On Fri, 22 Feb 2013 23:21:02 -0700, Joseph wrote: > >> Got it. I change it to: >> tmpfs/var/tmp/portagedevtmpfs >> size=1512M,nr_inodes=1M 0 0 > Why are you using devtmpfs? You should be using tmpfs for this, which > defaults to half your available RAM. devtmpfs is a special option > for early-boot /dev only. > > which is why he got 10mb size... good catch.
Re: [gentoo-user] help
Am 23.02.2013 10:28, schrieb Dan Hunter: > > no
Re: [gentoo-user] help
Am 23.02.2013 14:27, schrieb Dan Hunter: > On 02/23/13 17:07, Dale wrote: >> Volker Armin Hemmann wrote: >>> Am 23.02.2013 10:28, schrieb Dan Hunter: >>> no >>> >>> >> Double no. Next he will try the "unsubscribe" in the subject line angle >> with little success there either. Then someone will post the nice long >> reply about the unsubscribe kit and all its options. I find that one >> funny tho so I usually read it. o_O >> >> Dale >> >> :-) :-) >> > sorry expected robot reply > just want to knowurl ofthis lists. Is available http-version of gentoo lists? > look into the header of the mails your received. List-help for example. There are many email-archives carrying this list. google is your friend.
Re: [gentoo-user] No space left on device ?
Am 23.02.2013 15:16, schrieb Joseph: > On 02/23/13 08:52, Neil Bothwick wrote: >> On Fri, 22 Feb 2013 23:21:02 -0700, Joseph wrote: >> >>> Got it. I change it to: >>> tmpfs /var/tmp/portage devtmpfs >>> size=1512M,nr_inodes=1M 0 0 >> >> Why are you using devtmpfs? You should be using tmpfs for this, which >> defaults to half your available RAM. devtmpfs is a special option >> for early-boot /dev only. >> >> >> -- >> Neil Bothwick > > I was following the instruction from recent "udev" upgrade: Upgrading > udev from 171 (or older) to 197 > > copy > - The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the > fstype for > possible /dev line in /etc/fstab is devtmpfs (and not, for example, > tmpfs) > ---end coopy > > So I change both lines in fstab: > shm /dev/shm devtmpfsnodev,nosuid,noexec 0 0 > tmpfs /var/tmp/portage devtmpfs > size=2048M,nr_inodes=1M 0 0 > and the part quoted talked about DEV nothing else.
Re: [gentoo-user] No space left on device ?
Am 23.02.2013 16:44, schrieb Alan McKinnon: > On 23/02/2013 16:24, Volker Armin Hemmann wrote: >> Am 23.02.2013 15:16, schrieb Joseph: >>> On 02/23/13 08:52, Neil Bothwick wrote: >>>> On Fri, 22 Feb 2013 23:21:02 -0700, Joseph wrote: >>>> >>>>> Got it. I change it to: >>>>> tmpfs /var/tmp/portage devtmpfs >>>>> size=1512M,nr_inodes=1M 0 0 >>>> Why are you using devtmpfs? You should be using tmpfs for this, which >>>> defaults to half your available RAM. devtmpfs is a special option >>>> for early-boot /dev only. >>>> >>>> >>>> -- >>>> Neil Bothwick >>> I was following the instruction from recent "udev" upgrade: Upgrading >>> udev from 171 (or older) to 197 >>> >>> copy >>> - The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the >>> fstype for >>> possible /dev line in /etc/fstab is devtmpfs (and not, for example, >>> tmpfs) >>> ---end coopy >>> >>> So I change both lines in fstab: >>> shm /dev/shm devtmpfsnodev,nosuid,noexec 0 0 >>> tmpfs /var/tmp/portage devtmpfs >>> size=2048M,nr_inodes=1M 0 0 >>> >> and the part quoted talked about DEV nothing else. >> > > I have to say this: > > The number of people who completely and totally misread the simple > instructions about upgrading udev is spectacular. > > The guides say clearly and unambiguously to modify the mount options for > /dev > > And what did so many users at once go and do? Changed every line in > fstab that had the three characters d-e-v in them as well. > > I dunno, sometimes I want to give up. > > > > I am so tired. Really, I am.
Re: [gentoo-user] KDE 4.10.0 Freezed once click on something
.xsession-errors
Re: [gentoo-user] OT: wrong ram?
Am 05.03.2013 18:22, schrieb James: > Hello, > > I purchased this ram from New Egg: > > http://www.newegg.com/Product/Product.aspx?Item=N82E16820231529 > > G.SKILL Ripjaws Z Series 32GB (4 x 8GB) 240-Pin DDR3 SDRAM DDR3 1866 (PC3 > 14900) > Desktop Memory Model F3-14900CL10Q-32GBZL > > I've since found out it is for "Intel". > > > I have an FX8350 processor with this mobo: > GIGABYTE GA-990FXA-UD3 AM3+ AMD 990FX SATA 6Gb/s USB 3.0 ATX AMD Motherboard > > > So will it damage the board, ram or processor? > > I've nevered RMA anything to NewEgg. It's been > over 90 days since purchase, but less than 120. > > Thoughts, scolding and recommendations are most warranted... > > I have since found this ram: > G.SKILL Trident X Series 16GB (2 x 8GB) 240-Pin DDR3 SDRAM DDR3 2400 (PC3 > 19200) > Desktop Memory Model F3-2400C10D-16GTX > > That looks perfect for (overclocked?) FX8350 based system? > > > TIA, > James > > > > > intel introduced an extension for spd information. The ram should work just fine. Intel motherboards might or might not make use of the additional information. so might or might not amd boards. And no, there won't be any risk. DDR3 is DDR3.
Re: [gentoo-user] IO latency issues
Am 09.03.2013 19:15, schrieb Florian Philipp: > Hi list! > > Whenever I do sequential IO for a long stretch of time (e.g. md5summing > 40 GB), I'm experiencing high load (ca. 6 on a 4 CPU system) and > temporary freezes of most applications. For example, switching between > tabs in konsole sometimes takes more than 2 seconds. > > When doing this on an ext4 filesystem, the load seems to result from > khugepaged and kswapd0 as well as some kworkers. > > I think I've had similar issues with NFS over wifi but I cannot test > this now. > > Today I copied 60GB from my hard disk to an USB disk formatted with > NTFS, issuing the copy command from KDE's dolphin. The freezes became so > long it was impossible to work and then X11 locked up and had to be killed. > > I tried using a preemptive kernel but that didn't seem to help. blkio > and cpu cgroups didn't help either. Ionice seems to be the only solution > but while I'm okay with that, my dad won't be. Can anyone tell me what > is causing this behavior? > > Throughput is good, by the way. That's why I don't suspect a driver issue. > > Thanks in advance! > Florian Philipp > congratulation. You hit 'the bug'. Been around for ages, but for magical reasons kernel dev are unable to see or unable to do something about it. If you are using a vanilla kernel, posting on lkml might be the right thing to do.
Re: [gentoo-user] A question concerning graphics...
Am 10.03.2013 09:54, schrieb Chris Walters: > Hello Everyone, > > I have a couple of questions concerning what graphic drivers you use. > Does anyone use the proprietary ATI drivers, or have used them? Would > you recommend them? I just recently started using the ati-drivers > package, but I don't really notice a difference - yes it does say the > frame rate is much higher, but I am not sure it is worth losing my > framebuffer over them. > > Technically, I lost my frame buffer because I am using an initramfs > (initrd) because I have an encrypted root file system, and a separate > non-encrypted usr partition. I still have not been able to figure out > how to get either uvesafb or vesafb working through the initramfs. > They will both load fine, before my initrd starts, then they seem to > disappear. > > In case you're wondering, before I changed to the proprietary ati > drivers, I was using the kernel framebuffer for my video card(s). Two > Radeon HD 5000 series cards. I did have to insert the proper ucode > into my kernel, but it worked. > > Chris > > . > yes, it is worth using them. Because of proper power management alone. You might not care about framerates, but the open source drivers use a lot more energy - for nothing.
Re: [gentoo-user] kernel 3.8 and external drivers
Am 10.03.2013 19:28, schrieb Daniel Wagener: > Hello, > > I ran into some trouble about an hour ago… > > My workstation has an onboard Realtek Ethernet which only works with the > r8168 driver. > Unfortunately, this driver is not in the kernel, but available to be compiled > as a kernel module. (I guess because of som patents) > That worked for quite some time, until i thought "hey, you got an hour of > time, your workstation is still on 3.7.4, why don't you just upgrade it to > 3.8.2?" > So I did, only to find out that Linus and his friends changed the way drivers > are initialized… (__devinit got unsupported for example) > > Of course, the guys who wrote that r8169 have not changed their code yet. > > tl;dr: > My network is broken since 3.8.0. > > So for an immediate fix I am emerging 3.7.10 (since emerge --depclean deleted > the Kernel source when it found the source fo 3.7.8 which got removed as soon > as 3.8.2 was emerged…) to get it working again. > For the long run im thinking of buying a PCI(e) card with Kernel support. > Or maybe, if I find some time I will fix the driver myself. > > My question now is: > Who should I talk to so something like this does not happen again? > A certain gentoo dev, who could issue warnings on emerging kernels, something > like excerpts from the changelog? > Myself, because I missed what I described above? > The devs of the r8169? > Linus & co for breaking things? > Myself bcause I forgot something else? > Realtek? > Or someone completely different? > so, you are using a superfluous external driver. Despite the fact that external drivers are prone to breaking you insist on using the latest kernel, instead using the latest kernel of one of the stable kernel series like 3.4. To add insult to injury you remove kernels after installing instead of after testing. And then you try to blame others for all the stupid stuff you did. A simple grep would have told you that your NIC has been supported for ages. A little bit of common sense would have prevented the rest.
Re: [gentoo-user] kernel 3.8 and external drivers
Am 11.03.2013 14:00, schrieb Yuri K. Shatroff: > On 11.03.2013 03:05, Daniel Wagener wrote: >> On Sun, 10 Mar 2013 21:53:42 +0100 >> Volker Armin Hemmann wrote: >> >>> Am 10.03.2013 19:28, schrieb Daniel Wagener: >>>> Hello, >>>> >>>> I ran into some trouble about an hour ago… >>>> >>>> My workstation has an onboard Realtek Ethernet which only works >>>> with the r8168 driver. Unfortunately, this driver is not in the >>>> kernel, but available to be compiled as a kernel module. (I guess >>>> because of som patents) That worked for quite some time, until i >>>> thought "hey, you got an hour of time, your workstation is still on >>>> 3.7.4, why don't you just upgrade it to 3.8.2?" So I did, only to >>>> find out that Linus and his friends changed the way drivers are >>>> initialized… (__devinit got unsupported for example) >>>> >>>> Of course, the guys who wrote that r8169 have not changed their >>>> code yet. >>>> >>>> tl;dr: >>>> My network is broken since 3.8.0. >>>> >>>> So for an immediate fix I am emerging 3.7.10 (since emerge >>>> --depclean deleted the Kernel source when it found the source fo >>>> 3.7.8 which got removed as soon as 3.8.2 was emerged…) to get it >>>> working again. For the long run im thinking of buying a PCI(e) card >>>> with Kernel support. Or maybe, if I find some time I will fix the >>>> driver myself. >>>> >>>> My question now is: >>>> Who should I talk to so something like this does not happen again? >>>> A certain gentoo dev, who could issue warnings on emerging kernels, >>>> something like excerpts from the changelog? Myself, because I >>>> missed what I described above? The devs of the r8169? >>>> Linus & co for breaking things? >>>> Myself bcause I forgot something else? >>>> Realtek? >>>> Or someone completely different? >>>> >>> so, you are using a superfluous external driver. Despite the fact that >>> external drivers are prone to breaking you insist on using the latest >>> kernel, instead using the latest kernel of one of the stable kernel >>> series like 3.4. To add insult to injury you remove kernels after >>> installing instead of after testing. >> >> well… I guess that sums it up… :( >> > > sorry for breaking in, but... > (to Volker Armin Hemmann) > > 1. If this driver is superfluous as you say, then why does it ever > exist in portage? because it exists? gnome is there too. Or systemd AND openrc. mrxvt, rxvt AND urxvt. > > > 2. Since it does exist, then probably it would be much nicer to user > to show him a notice when he (user) tries to compile it on a kernel > which has native support for the device, or moreover an unsupported > kernel installed, than blame user for that? no, this is gentoo. You are supposed to do your homework. No training wheels. > > 3. Why does the ebuild *not* check for supported kernel version or > breaking APIs/ABIs? why should it? See above. You can't know if in the future something might change. > > 4. How and why would you expect to force all users to grep thru kernel > src in search for a driver they might need, especially when the > portage explicitly lists this driver? Also sometimes kernel drivers' > description is not quite consistent and it is not easy to figure out > whether it supports exactly yours card/chip/device, or moreover find > it by grep. All kernel source? grep? Nope. Just reading a bit of help text. Maybe using google. Doing it once. Then you have a working setup you can use for the rest of eternity (or the next couple of years...) > 5. After all, linux and gentoo in particular are *not* > developer-only-oriented systems, and it is up to maintainers or > whomever to make them more user-friendly. Yes, it is not fair of a > user to blame someone for breaking APIs etc. but neither it is fair to > blame the user for not knowing everything as I bet nobody knows > everything about linux kernel. oh, so gentoo is for ubuntu users? Well, why not use ubuntu in the first place? But I feel generous right now. You might have a point there. That does not invalidate the 'remove kernels before testing' criticism from the list nor does it solve the 'insisting to use the latest kernel release instead of stable series' problem.
Re: [gentoo-user] kernel 3.8 and external drivers
Am 11.03.2013 00:05, schrieb Daniel Wagener: > On Sun, 10 Mar 2013 21:53:42 +0100 > Volker Armin Hemmann wrote: > >> Am 10.03.2013 19:28, schrieb Daniel Wagener: >>> Hello, >>> >>> I ran into some trouble about an hour ago… >>> >>> My workstation has an onboard Realtek Ethernet which only works >>> with the r8168 driver. Unfortunately, this driver is not in the >>> kernel, but available to be compiled as a kernel module. (I guess >>> because of som patents) That worked for quite some time, until i >>> thought "hey, you got an hour of time, your workstation is still on >>> 3.7.4, why don't you just upgrade it to 3.8.2?" So I did, only to >>> find out that Linus and his friends changed the way drivers are >>> initialized… (__devinit got unsupported for example) >>> >>> Of course, the guys who wrote that r8169 have not changed their >>> code yet. >>> >>> tl;dr: >>> My network is broken since 3.8.0. >>> >>> So for an immediate fix I am emerging 3.7.10 (since emerge >>> --depclean deleted the Kernel source when it found the source fo >>> 3.7.8 which got removed as soon as 3.8.2 was emerged…) to get it >>> working again. For the long run im thinking of buying a PCI(e) card >>> with Kernel support. Or maybe, if I find some time I will fix the >>> driver myself. >>> >>> My question now is: >>> Who should I talk to so something like this does not happen again? >>> A certain gentoo dev, who could issue warnings on emerging kernels, >>> something like excerpts from the changelog? Myself, because I >>> missed what I described above? The devs of the r8169? >>> Linus & co for breaking things? >>> Myself bcause I forgot something else? >>> Realtek? >>> Or someone completely different? >>> >> so, you are using a superfluous external driver. Despite the fact that >> external drivers are prone to breaking you insist on using the latest >> kernel, instead using the latest kernel of one of the stable kernel >> series like 3.4. To add insult to injury you remove kernels after >> installing instead of after testing. > well… I guess that sums it up… :( > I hope so. But not all is lost. You learnt a lesson, next time someone does something like that you can act like the resident asshole and I get a couple of minutes off. Everybody wins. Especially me.
Re: [gentoo-user] kernel 3.8 and external drivers
Am 12.03.2013 12:51, schrieb Yuri K. Shatroff: > On 12.03.2013 14:44, Neil Bothwick wrote: >> On Tue, 12 Mar 2013 12:30:57 +0200, Alan McKinnon wrote: >> not "has to be easy", but definitely, with such purpose. Do you disagree? Perhaps you reckon that the whole purpose of computing is to make life harder? :) >>> >>> You know, this general topic rears it's head about every six months. >>> The >>> answer never changes: >>> >>> Gentoo is what it is, it works a certain way for a reason. Maybe you >>> like it, maybe you don't. Either way that is not going to change >>> anytime >>> soon. What you could do is pitch in and do all the same heavy lifting >>> that our long-term devs have done, and be the change you want to see in >>> the world. >>> >>> That might involve dealing with the protestations of the existing devs >>> though and they will likely quote the "Gentoo is what it is" line. >> >> On the other hand, if you file bug report with a patch to the ebuild >> that checks the running kernel version and outputs an elog message of >> "you might want to try the in-kernel drivers". They may simply say >> "thank >> you". > > The starting point has to be someone identifying the problem. > When you come e.g. to a car service and say, 'my engine is not working > properly e.g. ignition fails or sort of', do you expect the mechanic > to answer, 'hell why are you coming to me? you know the problem, c'mon > fix it yourself'? no, because I am going to pay a shitload of money. See the difference? Nobody is paying me to hang around on this list. A list that is full with threads about problems that are: occuring every odd month, so a little search would have answered the question obvious user errors caused by stupid behaviour or easily fixable with a little bit of thinking and/or using google. Bonus points: people being pissy if pointed out. At some point you have three choices dealing with this: go away, because the shit isn't worth it anymore swallow it, show your nicest smile and go on in the hope that someday somebody might grow up become an asshole. I have chosen option number three. I admit it freely. There are very few people on this list whose opinion I really care about. Those people earned my respect. So why staying and act like this? Because sometimes people are ok. Sometimes there are good threads. Because some people do see the pattern. Others realize that a bit of own research means a lot of time saved. Their own time. Learning something. Stuff like that. Btw, Daniel? cool reaction. I liked that. > Or even more of it, 'your car is what it is, you wanna drive -- buy a > limousine for a couple hundred grands'? you are proposing that. 'Oh, this car needs manual intervention and some thinking. Mod your car to turn it into Carbuntu! It will do everything for you! Even driving! And breaking!* *except in icy conditions or raining. There will be no warning. > Yes, you can expect that a gentoo user is more familiar with the > things but you can't expect everyone capable of everything. > And clearly, there are people who'd do it better than an average > gentoo user. > >> This is not a unique situation, there are other out of tree drivers that >> give such a message, and plenty more that don't. All it needs is for >> someone to take the time to fix it - rather than demanding that someone >> else fixes it for them. > > Yes, that's it -- if you can't do it yourself, just inform someone who > has the time and ability to fix it. And no profound discussions about > what gentoo is and what it is not. Because (it's my humble opinion of > course) he who discusses the most does the least. > have a look at the checks in ati or nvidia drivers, create a suitable patch for every other driver. Not that hard. If you want to do it. I don't. Seriously.
Re: [gentoo-user] Emerge problems
Am 17.03.2013 05:50, schrieb meino.cra...@gmx.de:
> Hi,
>
> while updateing this morning I got this ouput:
>
>
> Calculating dependencies... done!
> [nomerge ] app-text/texlive-core-2012-r1 USE="X tk -cjk -doc -source
> -xetex"
> [ebuild N ] dev-tex/luatex-0.70.1-r1 USE="-doc" 0 kB
> [ebuild U ] app-emulation/emul-linux-x86-gtklibs-20130224 [20121202]
> USE="development" 6,030 kB
> [ebuild U ~] sys-fs/ecryptfs-utils-103 [101] USE="gtk pam -doc -gpg
> -openssl -pkcs11 -python -suid -tpm" 610 kB
> [ebuild U ] app-emulation/emul-linux-x86-sdl-20130224 [20121202]
> USE="development" 637 kB
> [ebuild U ] app-emulation/emul-linux-x86-soundlibs-20130224 [20121202]
> USE="alsa development" 6,903 kB
> [ebuild U ] app-emulation/emul-linux-x86-medialibs-20130224 [20121202]
> USE="development" 10,173 kB
> [ebuild U ]app-emulation/emul-linux-x86-xlibs-20130224 [20121202]
> USE="development opengl" 2,415 kB
> [ebuild U ] app-emulation/emul-linux-x86-opengl-20130224
> [20121202-r1] USE="development" 61,283 kB
> [ebuild UD ] app-text/poppler-0.20.5:0/0 [0.22.2:0/35] USE="cairo cxx
> introspection jpeg jpeg2k lcms png qt4 tiff utils -cjk -curl -debug -doc" 0 kB
> [ebuild R] sys-process/procps-3.3.4 USE="ncurses nls%* unicode
> -static-libs" 0 kB
> [ebuild U ] app-emulation/emul-linux-x86-db-20130224 [20121202]
> USE="development" 1,395 kB
> [ebuild U ] app-emulation/emul-linux-x86-baselibs-20130224 [20121202]
> USE="development" 40,865 kB
>
> Total: 12 packages (9 upgrades, 1 downgrade, 1 new, 1 reinstall), Size of
> downloads: 130,308 kB
>
> WARNING: One or more updates have been skipped due to a dependency conflict:
>
> app-text/poppler:0
>
> (app-text/poppler-0.22.2::gentoo, ebuild scheduled for merge) conflicts with
> (dev-tex/luatex-0.70.1-r1::gentoo, ebuild scheduled for merge)
>
>
> After doing an
>
> eix app-text/poppler
>
> I got his:
>
> [I] app-text/poppler
> Available versions:
> (0) 0.20.5^t
> (0/35) (~)0.22.2^t
> {{cairo cjk curl cxx debug doc +introspection (+)jpeg jpeg2k +lcms png
> qt4 tiff +utils}}
> Installed versions: 0.22.2(0/35)^t(05:14:11 03/17/13)(cairo cxx
> introspection jpeg jpeg2k lcms png qt4 tiff utils -cjk -curl -debug -doc)
> Homepage:http://poppler.freedesktop.org/
> Description: PDF rendering library based on the xpdf-3.0 code
> base
>
> and there is no "xpdf-headers" USE flag. XPdf was removed at all
> if my brain serves me right... ;)
> So no chance to resolve the conflict?
>
> How can I prevent this problem?
>
> Thank you very much in advance for any help!
> Best regards,
> mcc
>
>
>
>
>
>
>
wait a couple of hours and sync again. You probably synced in the middle
of some changes.
Re: [gentoo-user] Can I chroot to a folder?
Am 18.03.2013 19:43, schrieb João Matos: > Do I need to create a partition just for this? > no
Re: [gentoo-user] System freezes during compiles
Am 20.03.2013 05:42, schrieb Carlos Hendson: > Hello, > > For last few weeks or so, I've been getting intermittent hard lock-ups > during the emerge of various packages. It appears the more compile > intensive the package, the more likely the lock-up. These lock-ups have > occurred under kernels 3.4.9 and 3.7.10 with gcc 4.5.4 and 4.6.3. > > Once the machine is in a frozen state, the only thing that responds is > the soft power reset button. Some times the machine lock-ups again > after the button is pressed (this is because the compile resumes once > the system comes out of it's frozen state). > > If the system subsequently lock-ups because I wasn't able to cancel the > compile fast enough only a only option left is a hard power reset (10sec > + hold power button). If I cancel the compile, the system is perfectly > responsive and functions normally. > > There are kernel stack traces in /var/log/messages which I'm unable to > decipher and diagnose as to what caused the lock-up. > > If I had to guess, I'd blame an incorrect setting in the .config, but > since I'm stuck in the diagnostic of what part of the kernel might be > experiencing the problem, I need a bit of help to pin point the issue. > > I believe it to be a kernel configuration issue because when I booted > the machine using a system rescue Live CD, I was able to chroot into the > system and emerge packages like gcc without the lock-up problem > occurring. > > That's by no means conclusive, however, I've also run a complete pass of > memcheck for over an hour without any issues reported. > > I'd like to completely rule out hardware failure, what diagnostic tools > tools are recommend to try identify potential hardware issue of this > type? > > The various kernel stack traces are attached in case someone wants to > take a look. I can provide more information should it be needed. > > Any help or advice would be appreciated. > > Regards, > Carlos you might just hit a thrashing situation. Linux is very bad when it comes to abusing swap in case of an emergency. But it also sounds like overheating or a power problem. Power problems might be caused by the PSU - but it could also be the power circuitry of your mobo.
Re: [gentoo-user] OT: parental control software
Am 20.03.2013 12:04, schrieb Neil Bothwick: > I'm looking for software that can be used to control a child's usage of > the computer (not Internet filtering). At the very least it should be > able to control length of login sessions and when the child is able to > login. Ideally it would also be able to control access to programs, for > example education programs can be used for a couple of hours but games > for only 30 mins at a time (net control software can be used to deal with > online versions). There are other situations where this sort of thing is > useful, so it need not necessarily be a package aimed specifically at > parental controls. > > Timekpr looks the ideal candidate, except it hasn't had a release in > over three years. > > Any suggestions? > > limits.conf groups (just add the kid to all the groups it needs - and nothing else) parental supervision. Really. You are ok with your offspring to use a machine connected to the mains - do you let it play with the stove in the kitchen, wall sockets and needles or power tools too? No? Why?
Re: [gentoo-user] System freezes during compiles
You got your answer. 8gig and no swap is NOT ENOUGHT. Am 20.03.2013 22:51 schrieb "Carlos Hendson" : > On Wed, 2013-03-20 at 20:57 +0100, Volker Armin Hemmann wrote: > > you might just hit a thrashing situation. Linux is very bad when it > > comes to abusing swap in case of an emergency. > > > > But it also sounds like overheating or a power problem. Power problems > > might be caused by the PSU - but it could also be the power circuitry > > of > > your mobo. > > It's not a thrashing issue as I don't have any swap. The 8GB of ram has > been sufficient memory for all tasks thus far. I have no objection to > allocating some swap space if it could resolve the issue. > > Actually, Grant and you both suggested possible heat issues which has > just made me think that I should check for dust build up in the CPU heat > sink. There so much dust where I live that I have to vacuum dust build > up from the case. > > The sensors tool reports 51C, it doesn't appear to be running too hot, > but I don't have a baseline to compare it to. I see I need to implement > monitoring for this machine once it's stable again. > > k10temp-pci-00c3 > Adapter: PCI adapter > temp1:+51.0°C (high = +70.0°C) >(crit = +71.0°C, hyst = +66.0°C) > > > I'll give the inside a clean this weekend and see if there's any > improvement. > > Thanks for the suggestions. > > Regards, > Carlos > > >
Re: [gentoo-user] System freezes during compiles
Oom Killer is Not instant, can take a long time or get stuck or kills something vital. ... Am 21.03.2013 07:52 schrieb "Carlos Hendson" : > On Thu, 2013-03-21 at 06:45 +0100, Volker Armin Hemmann wrote: > > You got your answer. 8gig and no swap is NOT ENOUGHT. > > It's a strong indicator, which is going to be corrected. > > I am slightly confused by the resulting behaviour however. I was of the > impression oomkiller would start to kill processes when unallocated > memory is getting scarce? > > How would no free memory cause CPU stalls? > > Regards, > Carlos > > >
Re: [gentoo-user] Re: System freezes during compiles
Am 26.03.2013 15:13, schrieb J. Roeleveld: > On Thu, March 21, 2013 21:03, Grant Edwards wrote: >> On 2013-03-20, Carlos Hendson wrote: >> >>> Could this be the cause of the stalls during compiles? If it is the >>> cause, is it possible for the kernel to detect such failures and report >>> them? >> I think that as long as the errors are "recovered" they shouldn't >> cause problems. The $64 question is whether those errors are >> indicating that you're headed for unrecoverable errors (which will >> cause problems). If they seem to be increasing in frequency, I'd >> probably be a little worried. > Consumer harddrives, which I am assuming you are using, will stall > indefinitely untill they have fixed the error they are encountering. no, they don't. PATa drives take 30secs. SATA not even a tenth. That is why dmesg can fill up with hdd errors and you don't realize it until a reboot and the drive not spinning up anymore. > > RAID-drives (With TLER = Time Limited Error Recovery) will return sooner > with an error-code which can then be handled by the controller and/or > driver. > > In other words, yes, these can explain the stalls during compiles. they would - if it wasn't already established that it was overheating.
Re: [gentoo-user] How to prevent a dns amplification attack
Turn off this unnecessary crap? Am 28.03.2013 09:52 schrieb "Norman Rieß" : > Hello, > > i am using pdns recursor to provide a dns server which should be usable > for everybody.The problem is, that the server seems to be used in dns > amplification attacks. > I googled around on how to prevent this but did not really find > something usefull. > > Does anyone got an idea about this? > > Regards, > Norman > >
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
Am 01.04.2013 01:12, schrieb walt: > Any of you admin types out there have any grumpy thoughts about this > article? :) Is it really just marketing BS from cloudflare, or is it > solid stuff? > > http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet > > > and since pretty much every technological site PLUS a lot of mainstream news sites reported that attack days ago, it is really great to see ANOTHER thread spawned by this non-news.
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
Am 31.03.2013 21:55, schrieb Neil Bothwick: > On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote: > >>> instead of pushing a completely >>> different (and possibly less reliable) naming scheme by default. >> Whilst I wouldn't want them changing on me (though if your physically >> changing the pci slot then you should be able to handle the number >> change). > What about USB network adaptors? A user may not even realise they plugged > it into a different USB slot from last time, yet the device name changes. > > congratulation, you just found another reason why today's udev sucks.
Re: [gentoo-user] Unable to compile chromium 26
Am 01.04.2013 18:59, schrieb Nilesh Govindrajan: > On Mon, Apr 1, 2013 at 9:09 PM, Michael Mair-Keimberger > wrote: >> Look at bug 463550 [1].. >> >> >> >> Either you downgrade to app-accessibility/speech-dispatcher-0.7.1-r2 or use >> the patch which is pointed out at the bug. >> >> >> >> mike >> >> >> >> >> >> 1) https://bugs.gentoo.org/show_bug.cgi?id=463550 >> >> >> >> >> >> On Monday 01 April 2013 20:57:43 Nilesh Govindrajan wrote: >> >>> I'm unable to compile chromium. >>> It somewhere exits with not able to find libspeechd.h, but it exists >>> in /usr/include/speech-dispatcher. >>> I have attached build log. Can anybody tell what's going wrong? > Thanks a lot. > It's a bit weird that I couldn't find it when I searched for "chromium" on > bgo. > > ALL chromium search in bugzillas really really sucks.
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
Am 01.04.2013 01:12, schrieb walt: > Any of you admin types out there have any grumpy thoughts about this > article? :) Is it really just marketing BS from cloudflare, or is it > solid stuff? > > http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet > > > well, it was bad for spamhaus and London's inet traffic was higher than normal - and that was it. No danger, no slowdowns (apart from LINX) but the media made a huge fuss about it. If it helps to take down spammer friendly hosters, it was worth it.
Re: [gentoo-user] Re: [way OT but interesting] Massive recent DDOS attack
Am 03.04.2013 02:35, schrieb walt: > On 03/31/2013 06:00 PM, Volker Armin Hemmann wrote: >> Am 01.04.2013 01:12, schrieb walt: >>> Any of you admin types out there have any grumpy thoughts about this >>> article? :) Is it really just marketing BS from cloudflare, or is it >>> solid stuff? >>> >>> http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet >>> >>> >>> >> and since pretty much every technological site PLUS a lot of mainstream >> news sites reported that attack days ago, it is really great to see >> ANOTHER thread spawned by this non-news. > Thanks Volker. You haven't yelled at me for ages and I was beginning to > worry about you ;p > it's my guinea pigs. They make me non-grumpy.
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
Am 01.04.2013 05:37, schrieb luis jure: > > i'm glad for all the people who weren't affected. but whatever it was, i've > been suffering the consequences. so i'm more than irritated by the > assholes minimizing the problem, or treating this as "non-news". > if you meant me - it is none-news. Or, it became none-news. Because: everybody already reported it. Spamhaus was hit hard. But at no point was 'the internet in danger'. London exchange had a bit surplus traffic which resulted in some irregularities - for a whole hour. Frankfurt didn't measure anything outside of the usual statistical noise. http://www.de-cix.net/about/statistics/ But somebody had to blow it up. And even more people jumped on it. Boohoo. So the next time you start insulting people, base your findings on more than a blog written by those guys who have an economical interest to blow the whole mess out of proportion. 300gbit/s sounds like a lot. London exchange does 1tbit/s on a normal day. Frankfurt 1.5tbit/s on average. And they have reserves. Of course, those responsible - all those guys with unpatched boxes whose little zombies took part in this attack, need a good kicking. But that is no excuse for spamming mailing lists with something the media already abused to no end.
Re: [gentoo-user] Re: [way OT but interesting] Massive recent DDOS attack
Am 03.04.2013 13:16, schrieb J. Roeleveld: > On Wed, April 3, 2013 11:09, Neil Bothwick wrote: >> On Wed, 03 Apr 2013 05:46:07 +0200, J. Roeleveld wrote: >> Do guinea pigs work better or worse than tribbles at calming you? >>> Tribbles don't keep people calm indefinitely. At some point they all >>> die from starvation and humans would follow soon after :) >> AFAIR guinea pigs don't last forever either... > True, but they don't eat ALL the food first ;) > > -- > Joost > > > indeed. They never showed any interest for my pizzas.
Re: [gentoo-user] Problem compiling dev-lang/v8
Am 05.04.2013 22:58, schrieb Peter Humphrey: > > Hello list, > > > > Today's update wanted to move v8 up from 3.15.11.15 to 3.16.14.9-r1 > but the emerge failed. Here are the last few lines of console output > (well, the first of these is very long - sorry; it ends with > "--end-group"): > > > > x86_64-pc-linux-gnu-g++ -pthread -Wl,-O1 -Wl,--as-needed -o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/cctest > -Wl,--start-group > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/gen/resources.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/cctest.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/gay-fixed.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/gay-precision.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/gay-shortest.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-accessors.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-alloc.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-api.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-ast.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-bignum.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-bignum-dtoa.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-circular-queue.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-compiler.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-conversions.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-cpu-profiler.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-dataflow.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-date.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-debug.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-decls.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-deoptimization.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-dictionary.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-diy-fp.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-double.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-dtoa.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-fast-dtoa.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-fixed-dtoa.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-flags.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-func-name-inference.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-global-object.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-hashing.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-hashmap.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-heap.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-heap-profiler.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-list.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-liveedit.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-lock.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-lockers.o > /tmp/portage/dev-lang/v8-3.16.14.9-r1/work/v8-3.16.14.9/out/x64.release/obj.target/cctest/test/cctest/test-log.o > /tmp/p
Re: [gentoo-user] Eth0 interface not found - udev that little slut!!!!!
Am 06.04.2013 17:57, schrieb Alan Mackenzie:
> Hi, Nick.
>
> On Sat, Apr 06, 2013 at 10:51:42AM -0400, Nick Khamis wrote:
>> After updating our systems we lost network connectivity to the
>> servers. When trying to start net.eth0 we got the following message:
>> /ib64/rc/net/wpa_supplicant.sh: line 68: _is wireless command not found
>> /etc/init.d/net.eth0: line 548: _exists command not found
>> Errror: Interface eth0 does not exist
>> Ensure that you have loaded the correct kernel modules for your hardware
>> # lsmod
>> module used by
>> tg3 0
>> lbphytg3
>> eth0
>> flags=4098 mtu 1500
>>
>> interrupt=16
>
>> lo
>> flags=73 mtu 16436
>> inet 127.0.0.1 BROADCAST 255.255.255.0
>> inet6 ::1 prefixlen 128 scopeid 0x10
>
>> Please excuse me, I am running back and forth from the servers and
>> typing the error message here. Did our configuration get switched to
>> IP6? These are our DB servers and why me!!! Why ME!
> No, it's not just you, it's happened to pretty much everybody. udev-200
> now renames eth0, eth1, to something else, dependent upon
> complicated rules. In my case eth0 has become p6p1, though many people
> seem to have got longer names.
>
> Have a look in /sys/class/net and see if your new name is there. If so,
> edit all your config files containing eth0, switching to the new name.
>
> Once you got that done and things work again, take a deep breath and have
> a look at the most recent Gentoo news item ($ eselect news read) which
> explains it all, more or less. Then decide whether the above is a long
> term solution, and if not start reading docs about writing udev rules.
>
> Yes, it's a pain in the backside. But at least with Gentoo, you've a
> good chance of fixing things like this quickly.
>
>> Your help is greatly appreciated,
>> Nick
in my case it is still eth0:
ifconfig
eth0: flags=4163 mtu 1500
inet 192.168.178.21 netmask 255.255.255.0 broadcast
192.168.178.255
inet6 fe80::1e6f:65ff:fe87:6f6a prefixlen 64 scopeid 0x20
ether 1c:6f:65:87:6f:6a txqueuelen 1000 (Ethernet)
RX packets 4647305 bytes 6693078055 (6.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2943816 bytes 226871998 (216.3 MiB)
TX errors 0 dropped 1 overruns 0 carrier 0 collisions 0
sys-fs/udev
Available versions: (~)168-r2[1] [M]171-r10 197-r8^t{tbz2}
(~)198-r6^t{tbz2} (~)199-r1^t{tbz2} 200^t{tbz2} **^t {acl
action_modeswitch build debug doc edd extras +firmware-loader floppy
gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux
static-libs test}
Installed versions: 200^t{tbz2}(18:30:31
29.03.2013)(firmware-loader gudev hwdb keymap kmod openrc -acl -doc
-introspection -selinux -static-libs)
I did keep net.eth0
Re: [gentoo-user] Eth0 interface not found - udev that little slut!!!!!
Am 06.04.2013 21:33, schrieb Mick:
> On Saturday 06 Apr 2013 20:03:15 Volker Armin Hemmann wrote:
>> Am 06.04.2013 17:57, schrieb Alan Mackenzie:
>>> Hi, Nick.
>>>
>>> On Sat, Apr 06, 2013 at 10:51:42AM -0400, Nick Khamis wrote:
>>>> After updating our systems we lost network connectivity to the
>>>> servers. When trying to start net.eth0 we got the following message:
>>>> /ib64/rc/net/wpa_supplicant.sh: line 68: _is wireless command not found
>>>> /etc/init.d/net.eth0: line 548: _exists command not found
>>>> Errror: Interface eth0 does not exist
>>>> Ensure that you have loaded the correct kernel modules for your hardware
>>>> # lsmod
>>>> module used by
>>>> tg3 0
>>>> lbphytg3
>>>> eth0
>>>> flags=4098 mtu 1500
>>>>
>>>> interrupt=16
>>>>
>>>> lo
>>>> flags=73 mtu 16436
>>>> inet 127.0.0.1 BROADCAST 255.255.255.0
>>>> inet6 ::1 prefixlen 128 scopeid 0x10
>>>>
>>>> Please excuse me, I am running back and forth from the servers and
>>>> typing the error message here. Did our configuration get switched to
>>>> IP6? These are our DB servers and why me!!! Why ME!
>>> No, it's not just you, it's happened to pretty much everybody. udev-200
>>> now renames eth0, eth1, to something else, dependent upon
>>> complicated rules. In my case eth0 has become p6p1, though many people
>>> seem to have got longer names.
>>>
>>> Have a look in /sys/class/net and see if your new name is there. If so,
>>> edit all your config files containing eth0, switching to the new name.
>>>
>>> Once you got that done and things work again, take a deep breath and have
>>> a look at the most recent Gentoo news item ($ eselect news read) which
>>> explains it all, more or less. Then decide whether the above is a long
>>> term solution, and if not start reading docs about writing udev rules.
>>>
>>> Yes, it's a pain in the backside. But at least with Gentoo, you've a
>>> good chance of fixing things like this quickly.
>>>
>>>> Your help is greatly appreciated,
>>>> Nick
>> in my case it is still eth0:
>> ifconfig
>> eth0: flags=4163 mtu 1500
>> inet 192.168.178.21 netmask 255.255.255.0 broadcast
>> 192.168.178.255
>> inet6 fe80::1e6f:65ff:fe87:6f6a prefixlen 64 scopeid 0x20
>> ether 1c:6f:65:87:6f:6a txqueuelen 1000 (Ethernet)
>> RX packets 4647305 bytes 6693078055 (6.2 GiB)
>> RX errors 0 dropped 0 overruns 0 frame 0
>> TX packets 2943816 bytes 226871998 (216.3 MiB)
>> TX errors 0 dropped 1 overruns 0 carrier 0 collisions 0
>>
>> sys-fs/udev
>> Available versions: (~)168-r2[1] [M]171-r10 197-r8^t{tbz2}
>> (~)198-r6^t{tbz2} (~)199-r1^t{tbz2} 200^t{tbz2} **^t {acl
>> action_modeswitch build debug doc edd extras +firmware-loader floppy
>> gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux
>> static-libs test}
>> Installed versions: 200^t{tbz2}(18:30:31
>> 29.03.2013)(firmware-loader gudev hwdb keymap kmod openrc -acl -doc
>> -introspection -selinux -static-libs)
>>
>> I did keep net.eth0
> Is your eth0 NIC a module (modprobed), or built in the kernel?
r8169 41918 0
module
Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!
Am 06.04.2013 23:19, schrieb Nick Khamis: > Our net card was also build as a module Volker, did you include > your net driver for example in /etc/conf.d/modules? no I removed the 70-something rules, and did pretty much nothing else. /etc/udev/rules.d/80-net-name-slot.rules just exists and is full of text. And nothing changed.
Re: [gentoo-user] Portage screwup
Am 18.04.2013 17:50, schrieb Joseph: > On 04/18/13 15:31, Neil Bothwick wrote: >> All ebuilds stay on the Gentoo CVS server, ones that are removed from >> the >> tree in the "attic". If you want a previous version, download it from >> the attic and put it in your local overlay. >> >> >> -- >> Neil Bothwick >> >> If there is light at the end of the tunnel...order more tunnel. > > Do you have any link how to set it up? > http://lmgtfy.com/?q=portage+attic+local+overlay
Re: [gentoo-user] Removing pulseaudio
Am 18.04.2013 21:48, schrieb Michael Mol: > On 04/18/2013 03:32 PM, Alan Mackenzie wrote: > > [snip] > >> So, I grasped the nettle, put in a negative pulseaudio use flag, unmerged >> pa and alsa-plugins, then rebuilt the 14 packages which needed it. >> >> Surprisingly, everything still works. I now get those last seconds from >> my news streams. :-) >> >> So, yes, I can recomment the removal of pulseaudio, unless anybody's got >> some particular need for it. > IME, there is one application that all but forces the use of PulseAudio: > Flash. Once Flash grabs onto an ALSA device, it doesn't let go, so you > *must* route it through PA if you would like to reliably use it with > anything else. > > My particular discovery was that if I launched WoW under WINE, and then > launched a browser, audio in WoW worked fine. If I launched the browser > first (which resulted in a flash applet being loaded in GMail for the > purpose of audio notifications for google talk), Flash grabbed the ALSA > device and no WINE application could get at it. Routing both through > PulseAudio solved the problem. /I can have as many flash instances as I want and still listen to stuff being played in vlc. Without pulseaudio crap. Maybe wine just sucks?/
Re: [gentoo-user] Removing pulseaudio
Am 18.04.2013 22:13, schrieb Michael Mol: > On 04/18/2013 04:02 PM, Volker Armin Hemmann wrote: >> Am 18.04.2013 21:48, schrieb Michael Mol: >>> On 04/18/2013 03:32 PM, Alan Mackenzie wrote: >>> >>> [snip] >>> >>>> So, I grasped the nettle, put in a negative pulseaudio use flag, unmerged >>>> pa and alsa-plugins, then rebuilt the 14 packages which needed it. >>>> >>>> Surprisingly, everything still works. I now get those last seconds from >>>> my news streams. :-) >>>> >>>> So, yes, I can recomment the removal of pulseaudio, unless anybody's got >>>> some particular need for it. >>> IME, there is one application that all but forces the use of PulseAudio: >>> Flash. Once Flash grabs onto an ALSA device, it doesn't let go, so you >>> *must* route it through PA if you would like to reliably use it with >>> anything else. >>> >>> My particular discovery was that if I launched WoW under WINE, and then >>> launched a browser, audio in WoW worked fine. If I launched the browser >>> first (which resulted in a flash applet being loaded in GMail for the >>> purpose of audio notifications for google talk), Flash grabbed the ALSA >>> device and no WINE application could get at it. Routing both through >>> PulseAudio solved the problem. >> /I can have as many flash instances as I want and still listen to stuff >> being played in vlc. Without pulseaudio crap. >> >> Maybe wine just sucks?/ >> > Easy on the invective. Did you pay attention to the specific sequence of > events I described? Or are you simply reporting that Flash works fine as > an ALSA client along other concurrently reporting tasks, with no > reference to the explicit order of the launch of things? > > Incidentally, WoW+WINE worked absolutely fine with other ALSA clients. > It was only when Flash got added to the mix--and was launched > first--that I had a problem. Further, if Flash was launched before PA > (and ALSA apps weren't configured to route through PA's alsa wrapper), > PA itself could not latch on to the sound card. > > Also, it's possible Adobe has since fixed the bug. This was a couple > years ago, even before they added direct PulseAudio support to flash. the order is completely irrelavant. I start flash, xine, amarok, vlc, alsaplayer, whatever - and it just works. Without pulseaudio, jackd, esd, artsd etc pp. I don't use wine. For a lot of good reasons.
Re: [gentoo-user] Removing pulseaudio
Am 18.04.2013 22:02, schrieb Stroller: > On 18 April 2013, at 20:32, Alan Mackenzie wrote: >> ... >> (i) It's a "sound server", a description I don't understand. What does >> it _do_? Why do I want it? It seems to be an unnecessary layer of fat >> between sound applications and the kernel. > If you don't understand the term "sound server" you probably shouldn't be > using Gentoo. > > When I'm watching a YouTube video I still want to hear my email client go > bing or my chat program alert me of my buddy coming online. > > That's not possible if my web-browser has a hard-wired path into my soundcard > and ain't letting go. > > Stroller. > > > beeep. Wrong.
Re: [gentoo-user] Removing pulseaudio
Am 18.04.2013 23:10, schrieb Michael Mol: > On 04/18/2013 04:43 PM, Volker Armin Hemmann wrote: >> Am 18.04.2013 22:13, schrieb Michael Mol: >>> On 04/18/2013 04:02 PM, Volker Armin Hemmann wrote: >>>> Am 18.04.2013 21:48, schrieb Michael Mol: > [snip] > >>>>> My particular discovery was that if I launched WoW under WINE, and then >>>>> launched a browser, audio in WoW worked fine. If I launched the browser >>>>> first (which resulted in a flash applet being loaded in GMail for the >>>>> purpose of audio notifications for google talk), Flash grabbed the ALSA >>>>> device and no WINE application could get at it. Routing both through >>>>> PulseAudio solved the problem. >>>> /I can have as many flash instances as I want and still listen to stuff >>>> being played in vlc. Without pulseaudio crap. >>>> >>>> Maybe wine just sucks?/ >>>> >>> Easy on the invective. Did you pay attention to the specific sequence of >>> events I described? Or are you simply reporting that Flash works fine as >>> an ALSA client along other concurrently reporting tasks, with no >>> reference to the explicit order of the launch of things? >>> >>> Incidentally, WoW+WINE worked absolutely fine with other ALSA clients. >>> It was only when Flash got added to the mix--and was launched >>> first--that I had a problem. Further, if Flash was launched before PA >>> (and ALSA apps weren't configured to route through PA's alsa wrapper), >>> PA itself could not latch on to the sound card. >>> >>> Also, it's possible Adobe has since fixed the bug. This was a couple >>> years ago, even before they added direct PulseAudio support to flash. >> the order is completely irrelavant. I start flash, xine, amarok, vlc, >> alsaplayer, whatever - and it just works. Without pulseaudio, jackd, >> esd, artsd etc pp. > Do you say that because you've tested the various orders and know that > one application will not conflict with another if started before that, > or do you say that because you've never noticed a problem, despite not > knowing the order you've started things? because I am using linux since Suse 6.2. And in that time I have listened to a lot of music, watched a lot of movies and did a lot of things in parallel. Just yesterday I watched a music video on youtube, while hunting for something sounding almost identical on my harddisk - using vlc. So firefox&flash and vlc were working fine. > >> I don't use wine. For a lot of good reasons. >> > Name one. > fat, slow and buggy. Do you need more? If I really had an application that I must use and is windows only - I would install windows. That is a lot quicker and less painful than that wine crapfest shitting all over the place.
Re: [gentoo-user] Removing pulseaudio
Am 19.04.2013 00:02, schrieb Michael Mol: > On 04/18/2013 05:46 PM, Volker Armin Hemmann wrote: >> Am 18.04.2013 23:10, schrieb Michael Mol: > [snip] > >>> Do you say that because you've tested the various orders and know >>> that one application will not conflict with another if started >>> before that, or do you say that because you've never noticed a >>> problem, despite not knowing the order you've started things? >> because I am using linux since Suse 6.2. And in that time I have >> listened to a lot of music, watched a lot of movies and did a lot of >> things in parallel. Just yesterday I watched a music video on >> youtube, while hunting for something sounding almost identical on my >> harddisk - using vlc. So firefox&flash and vlc were working fine. > I know you're smarter than this. You actively ignored my explicit > description of a testable sequence of steps. Which Hartmut specifically > tried, and in doing so that the problem I encountered is not currently > present. > > By ignoring the sequence of steps, you're left with, well, nothing > testable or verifiable. I have answered your none-question. I am using a wide range of applications (firefox&flash, chromium, vlc, mplayer, alsaplayer etc pp) a lot of them at the same time, starting in different orders AND I NEVER HAD A PROBLEM. It does not matter if flash starts first, then vlc then alsaplayer then mplayer or chromium first, then xine then firefox. IT JUST WORKS. The only thing missing is wine. Hmm... maybe it IS wine? But why using a broken-by-design sounddaemon to paper over wine bugs, if there are a couple of easy ways to solve the problem once and for all? Without introducing lag and additional bugs. ie - fix wine. Or don't use it in the first place. >>>> I don't use wine. For a lot of good reasons. >>>> >>> Name one. >>> >> fat, slow and buggy. Do you need more? > Not from you, I suspect. At this point, I'm confident you have > absolutely no idea what you're talking about. > > By "fat", I suppose you're referring to the number of additional > binaries that land on your system. If you're going to implement the > entire API of an operating system, even as a wrapper around native > libraries, you're going to have a lot of code. That's just the way it is. No, by fat I mean its absolute humongous size. The crap its vomits into my $HOME adds just insult to injury. > > As for "slow"...it's been documented from time to time that some > applications run *faster* via WINE than on Windows. On one occasion, > this was the result of the Linux drivers being faster than the Windows ones. well, from time to time I try wine with this and that app. Speed? Abysmal - if the app works at all. Btw, who is doing that 'documentation'? Phoronix? > > As for "buggy"...Sure, not all of the APIs are implemented. Not all of > them need to be. Bugfixes and such are prioritized by interest in the > applications which need the buggy APIs, which is why many applications > work fine. Heck, I have an application installed which *depends* on > WINE, and this is part of that application's "Linux" version. I use it > every day as part of my job, and so I can do my job from this laptop > running Gentoo instead of a machine running Windows. great for you. AT WORK I just use the XP box to do windows jobs. At the end it is so much easier. > >> If I really had an application that I must use and is windows only - >> I would install windows. That is a lot quicker and less painful than >> that wine crapfest shitting all over the place. > ...The worst I've had has been WINE apps getting registered to handle > some files. Unless you're referring to the idea that WINE was what was > breaking my sound (itself clearly erroneous if you had read through the > description of either my or Hartmut's steps), I really don't know what > you're talking about, and I fear I'm just feeding a troll. And I am afraid that you are just talking because you like the sound of your voice. What was your point again?
Re: [gentoo-user] Error building tar
Am 28.04.2013 19:58, schrieb staticsafe: > Updating a Gentoo VM today when I encountered an issue with building > tar. Attaching relevant logs. yeah, thanks to some automake update someone did not think about testing first before unmasking, a whole bunch of packages are suddenly failing with that error. Nothing to see, but versionitis once again hitting a couple of innocents. Just go to bugzilla and see the bugs for the last 24h. It is a massacre.
Re: [gentoo-user] Recover on SSD
Am 05.05.2013 16:44, schrieb Randolph Maaßen: > Hi, > > I have a SSD in my laptop and I am running Win7 and Gentoo in > Parralel. for some purpose I needed several Partitions so my base > system was lying on sda10, on an LVM-PV. Today my Windows refused to > start and during recovery its diskpart must have deleted the > information about the 10th partition on the disk, containing my main > Gentoo system. Recovery failed, but sysrescuecd still works :) > > Now I'm concerned about the rescueing of the partition on the SSD, is > it the same way as on HDDs and are the same memory-parts of the SSD > used? Or is the partiton gone forever? And when I recreate a > partition, will the PV with the data still be there and readable? > > -- > Mit freundlichen Grüßen / Best regards > > Randolph Maaßen > http://www.google.de/search?q=ssd+partition+recovery&client=safari&rls=x86_64&oe=UTF-8&oq=ssd+partition+recovery&gs_l=heirloom-serp.3..0j0i30j0i8i30l8.4222.5907.0.6812.8.7.1.0.0.0.80.476.7.7.0...0.0...1ac.1.12.heirloom-serp.XThCXzx_Xuk good luck. Next time: backup first, fiddle around with partition tools second.
Re: [gentoo-user] Using date/time variables in cronjobs?
Am 06.05.2013 01:21, schrieb Tanstaafl: > Last question... > > In order to keep only a certain number of backups, what would be the > easiest and SAFEST way to delete the older ones? > > For example, I want to keep 17 hourlies, and 30 nightlies, so I have > two cron jobs set up, the hourly, and the nightly. Each backs up to a > separate dir. > > I'm thinking the easiest way would be to find and delete the oldest > file in the backup target directory before executing the backup command. > > For the hourlies dir, I'd just find the files that are older than one > day - so maybe: > > find $BACKUP_DIR/hourly* -type f -mtime +1 -delete > > Would that do it? > > So, in my script, I could add this in like: > > #!/bin/bash > BACKUP_DIR="/home/user/mypg_backups/hourly" > PGUSER="superuser" > PGyy=`date '+%Y'` > PGmm=`date '+%m'` > PGdd=`date '+%d_'` > PGtt=`date '+%H:%M'` > find $BACKUP_DIR* -type f -mtime +1 -delete > /usr/bin/pg_dumpall -U $PGUSER -o -f > $BACKUP_DIR/mypg-$PGyy-$PGmm-$PGdd$PGtt.gz > > and for the nightly backup script, since I want to keep 30 days worth: > > #!/bin/bash > BACKUP_DIR="/home/user/mypg_backups/nightly" > PGUSER="superuser" > PGyy=`date '+%Y'` > PGmm=`date '+%m'` > PGdd=`date '+%d_'` > PGtt=`date '+%H:%M'` > find $BACKUP_DIR* -type f -mtime +30 -delete > /usr/bin/pg_dumpall -U $PGUSER -o -f > $BACKUP_DIR/mypg-$PGyy-$PGmm-$PGdd$PGtt.gz > > Am I asking for trouble doing it this way? > > On 2013-05-05 5:56 PM, Tanstaafl wrote: >> So, my final script looks like this: >> >> #!/bin/bash >> BACKUP_DIR="/home/user/mypg_backups" >> PGUSER="superuser" >> PGyy=`date '+%Y'` >> PGmm=`date '+%m'` >> PGdd=`date '+%d_'` >> PGtt=`date '+%H:%M'` >> /usr/bin/pg_dumpall -U $PGUSER -o -f >> $BACKUP_DIR/mypg-$PGyy-$PGmm-$PGdd$PGtt.gz >> >> For some reason, if I put the underscore in the filename itself, ie: >> >> $BACKUP_DIR/mypg-$PGyy-$PGmm-$PGdd_$PGtt.gz >> >> It omitted the $PGdd variable entirely. >> >> I had to add the underscore into the variable to get the output like I >> wanted. Weird... >> >> Anyway, this is working perfectly, thanks guys. >> > > > and then your backup scripts fails without you noticing and you just removed all your backups. oops.
Re: [gentoo-user] Recover on SSD
Am 06.05.2013 13:00, schrieb Hinnerk van Bruinehsen: > On Mon, May 06, 2013 at 07:50:52AM +0100, Stroller wrote: >> On 5 May 2013, at 17:16, Hinnerk van Bruinehsen wrote: >>> ... The data on a SSD is not >>> necessarily stored linar so it's not said that a new partition is using >>> the same memory cells as the old one. >>> … >>> For a HDD I'd advise to create a copy >>> using dd but from my understanding of SSD technology it's not >>> guaranteed to copy the right (now unused marked) blocks. >> Is anyone able to elaborate on this, please? >> >> I think I've had a eureka! moment of understanding whilst preparing to >> compose this reply, but I've always been sceptical of these kinds of >> statements in the past. >> >> Surely flash memory devices must present themselves to the o/s as block >> devices, because that's how all storage devices work, right? >> >> If I'm now understanding correctly, SSDs present themselves to the o/s as >> block devices more or less as convenient or necessary. They can be treated >> as such as long as all the data required is listed in the file allocation >> table. I'm left wondering how the SSD knows that a file has been deleted, >> and whether this works for all conceivable file-systems. > The problem is that you can't delete on a flash cell. The process is > simplified: read cell - delete to be deleted stuff in memory - write > memory contents back. > > Since flash cells can only be written to a fixed amount of times > (afterwards they become unreliable) there is a concept called wear > leveling. This means essentially that your 128 GB flash drive in reality > hasn't just 128 GB of storage but e.g. 256GB. To spread out the writes > it reads one cell, does the memory operation and write the contents back > to another cell while marking the old cell as unused. emm - no. Wear leveling does not need any spare blocks. A lot of drives do have spare blocks, but those are never the same size of the original size (at least not on drives you can buy for a sensible amount of money). More like 120+8 or 160+16 or 256+16. The spare blocks are used like on a hdd: some block goes bad, another one is mapped in. Since the sdd firmware does not know if something was deleted or not* - it does know shit about filesystems**, you can of course dd an image, if you want to. Just like on a hdd. *there are drives that do garbage collection without TRIM for fat and or ntfs.. so they seem to know a bit about filesystems. ** and this is why TRIM exists in the first place. To tell the drive: yes, this data is gone. You don't need to care about it anymore.
Re: [gentoo-user] Annoying structure of /var/db/pkg// database
Am 10.05.2013 04:59, schrieb Thomas Mueller: > Having package data in /var/db/pkg// carries the > nuisance factor that finding a package involves a fishing expedition through > many possible categories. > > I am spoiled by having /var/db/pkg/ in NetBSD pkgsrc and > FreeBSD ports, though FreeBSD is wsitching to a different structure nkwon as > pkgng. > > Is there any way to configure so as to avoid this annoyance in Gentoo? Like > maybe making /var/db/pkg/? > > One can do > ls /var/db/pkg/*/ but this is still an annoyance. > > I have some limited experience with Gentoo Linux on my older computer. > Compiling the kernel took 130 minutes, and then the kernel failed to boot. > > Tom > > > . > and how do you deal with the problem of several packages having the same name? Or.. you don't look at that stuff, besides some cases of severe damage control, you never have to go there?
Re: [gentoo-user] Nvidia drivers and KDE problem
Am 26.05.2013 11:12, schrieb Dale: > Howdy, > > I been letting portage upgrade nvidia drivers as usual. Thing is, the > last two or three drivers seems to cause a issue. First, versions that > cause the issue: > > =x11-drivers/nvidia-drivers-319.12 > =x11-drivers/nvidia-drivers-319.17 > =x11-drivers/nvidia-drivers-319.23 > > I'm currently using this one which works fine: > > x11-drivers/nvidia-drivers-313.30 > > This is KDE info: > > [IP-] [ ] kde-base/kdelibs-4.10.3-r2 > > Video card info: > > 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce GT > 220] (rev a2) (prog-if 00 [VGA controller]) > Subsystem: NVIDIA Corporation Device 069a > Flags: bus master, fast devsel, latency 0, IRQ 18 > Memory at fb00 (32-bit, non-prefetchable) [size=16M] > Memory at c000 (64-bit, prefetchable) [size=256M] > Memory at de00 (64-bit, prefetchable) [size=32M] > I/O ports at ef00 [size=128] > [virtual] Expansion ROM at d000 [disabled] [size=512K] > Capabilities: [60] Power Management version 3 > Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ > Capabilities: [78] Express Endpoint, MSI 00 > Capabilities: [b4] Vendor Specific Information: Len=14 > Capabilities: [100] Virtual Channel > Capabilities: [128] Power Budgeting > Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 > Len=024 > Kernel driver in use: nvidia > Kernel modules: nvidia > > > The problem. After I am logged into KDE for a good while, like several > hours to maybe a day or so, the kicker thingy at the bottom locks up > tight. I can't switch desktops, clock stops working, can't click the K > menu thingy either. Everything in the kicker thingy is dead as a door > nail. I can switch desktops with the keyboard and everything else works > in KDE just fine. I can also switch to a console too. Killing X and > restarting it fixes it, xdm restart in my case. I don't have to reload > drivers or restart the system. I do go back and downgrade the drivers > after testing it. > > So, is this a nvidia bug, KDE bug or is it something else? Since it > works when I go back a version of nvidia, it looks like nvidia. Think > is, it only affects KDE and nothing else. Is it possible that my card > is not supposed to use the 319.* series of drivers? The versions that > don't work are all 319.* series. > > Thoughts? > > Dale > > :-) :-) > next time as root do: killall -9 krunner killall -9 plasma-desktop
Re: [gentoo-user] Re: Poor sound quality
Am 03.06.2013 22:51, schrieb Chris Stankevitz: > On Mon, Jun 3, 2013 at 10:28 AM, James wrote: >> Good luck, Good Hunting! > > James, > > Thank you for your tips. I tried to reproduce the problem on the same > hardware using a different OS (xubuntu 12.04). The problem did not > occur on the different OS. Therefore I rule out hardware problems. > Do you have any gentoo-specific suggestions as to the source that I > can try? > > Thank you, > > Chris > > less /var/log/emerge.log have fun.
Re: [gentoo-user] Linux viruses
Am 12.07.2013 18:36, schrieb Timur Aydin: > On 7/5/2013 11:12 PM, Dale wrote: >> I since did some googling and it seems I am right and he just thought I >> was some know nothing guy he could sell some service too. Anyway, has >> anything changed to make Linux more prone to viruses than it used to >> be? I read a percentage somewhere that said like 99% of viruses are >> windoze only. Is there a indisputable source of information on this? > > Linux is inherently more secure than Windows, but it isn't so much > more secure that only 1% of all viruses can attack it. Virus > developers don't have a financial incentive to develop Linux viruses > (not enough Linux users, most Linux users knowledgeable about > computers, and moral reasons). > moral reasons... you just made my day
[gentoo-user] ZFS is slow? readahead and zfs
Hello, I am using zfs for a while now. I am not using it for / but for /var and my media collection. PORTDIR is /var/portage so portage files are on zfs too. This resulted in portage being incredible slow. eix-sync took ages, emerge - auv world gave you enought time to prepare a meal. And eat it. Until I turned off readahead. Dear Gents, if you are trying out zfs, make sure you turn off readahead for your zfs disks. On a related note: increase readahead for your none-zfs SSDs. And make sure the no-op io-scheduler is used for them all. -- #163933
Re: [gentoo-user] more on SSD: swap
Am Sonntag, 21. Juli 2013, 11:31:41 schrieb luis jure: > OK, now i have my system successfully installed and running on my new SSD. > now i have to decide what to do with the rest of the disk (it's a 256MB > samsung). > > the first big question is: what about swap? i found some web pages > (perhaps old) stating that it's not wise to put swap on the SSD because of > all the read/writes. but apparently from what i read on the recent > thread on this list, that shouldn't be much of a concern now. > > i also read somewhere that if you have swap on the SSD and want to avoid > unnecessary read/writes, you can reduce swappiness. i have 12GB RAM and i > think normally i don't really need swap space on disk, so i thought that > could be a good idea. > > so what i'm planning to do now is: > > - put swap on the SSD don't make a swap partition, use a swapfile. > - reduce swappiness only swapon if you really need it. > - put /var/tmp/portage on tmpfs good, but also put /tmp on tmpfs. And maybe /var on a harddisk. > -- #163933
Re: [gentoo-user] more on SSD: swap
should - not must have to survive. And nothing in /var/tmp/portage is important enough. So just let it get lost. I would not put PORTAGE_TMPDIR to /tmp because if it accidentally fills up, you have a big problem. While a seperate tmpfs /var/tmp/portage... well nobody cares if it is full. Yeah, emerge fails but that's it. 2013/7/21 Neil Bothwick > On Sun, 21 Jul 2013 21:39:29 +0200, Volker Armin Hemmann wrote: > > > > - put /var/tmp/portage on tmpfs > > > > good, but also put /tmp on tmpfs. > > Doesn't the FHS spec say that /var/tmp should survive a reboot? So the > correct approach is to put /tmp on a tmpfs and set PORTAGE_TMPDIR > to /tmp. > > > -- > Neil Bothwick > > Mosquito - designed to make houseflies look better. >
Re: [gentoo-user] more on SSD: swap
Am Montag, 22. Juli 2013, 06:19:09 schrieb William Kenworthy: > experience with compiling in tempfs is that it works, but has a much > higher failure rate than on disk - i.e., things like OO/Lo, KDE, gcc and > glibc have large space requirements that you must make sure tmpfs can > satisfy before you start. em, no. KDE does not have large space requirements. LO does. The rest is happy with 2gb of tmpfs diskspace. -- #163933
Re: [gentoo-user] systemd - are we forced to switch?
Am Montag, 22. Juli 2013, 09:03:46 schrieb Helmut Jarausch: > Hi, > > gnome-base/gnome-settings-daemon-3.8.4 requires systemd > > sys-auth/consolekit-0.4.6cannot coexist with systemd > > but many packages depend on sys-auth/consolekit : > > emerge -vpc sys-auth/consolekit gives > >sys-auth/consolekit-0.4.5_p20120320-r2 pulled in by: > gnome-base/gnome-session-3.8.2.1-r1 requires sys-auth/consolekit > gnome-base/gnome-shell-3.8.3-r1 requires sys-auth/consolekit > kde-base/kdm-4.10.5 requires sys-auth/consolekit > net-misc/networkmanager-0.9.8.2-r2 requires sys-auth/consolekit > net-wireless/bluez-4.101-r5 requires sys-auth/consolekit > sys-apps/accountsservice-0.6.34 requires sys-auth/consolekit > sys-auth/pambase-20120417-r2 > requires >=sys-auth/consolekit-0.4.5_p2012[pam] > sys-auth/polkit-0.111 requires sys-auth/consolekit[policykit] > x11-apps/xdm-1.1.11-r3 requires sys-auth/consolekit > x11-misc/slim-1.3.5-r2 requires sys-auth/consolekit > > > So, what to do? Obviously, I don't want an unbootable system. > > How did you resolve this conflict? > > Many thanks for a hint, > Helmut not using gnome. Gnome decided to force systemd. -- #163933
Re: [gentoo-user] systemd - are we forced to switch?
yeah, because it is so great to have that monster systemd on your box. Because xml configs are awesome and binary logs even more and I always wanted an init with builtin webbrowser. Security? bah, not needed. So when do I have to install mysql to use it? How long until some crap ala windows-registry is forced down my throat? 2013/7/22 Canek Peláez Valdés > ConsoleKit is for all practical purposes unmaintained, and all of the > packages you mentioned it support systemd just fine. Emerge systemd, > and purge CK from your system; I did that almost a year ago. > > Regards. > > On Mon, Jul 22, 2013 at 2:03 AM, Helmut Jarausch > wrote: > > Hi, > > > > gnome-base/gnome-settings-daemon-3.8.4 requires systemd > > > > sys-auth/consolekit-0.4.6cannot coexist with systemd > > > > but many packages depend on sys-auth/consolekit : > > > > emerge -vpc sys-auth/consolekit gives > > > > sys-auth/consolekit-0.4.5_p20120320-r2 pulled in by: > > gnome-base/gnome-session-3.8.2.1-r1 requires sys-auth/consolekit > > gnome-base/gnome-shell-3.8.3-r1 requires sys-auth/consolekit > > kde-base/kdm-4.10.5 requires sys-auth/consolekit > > net-misc/networkmanager-0.9.8.2-r2 requires sys-auth/consolekit > > net-wireless/bluez-4.101-r5 requires sys-auth/consolekit > > sys-apps/accountsservice-0.6.34 requires sys-auth/consolekit > > sys-auth/pambase-20120417-r2 requires > >>=sys-auth/consolekit-0.4.5_p2012[pam] > > sys-auth/polkit-0.111 requires sys-auth/consolekit[policykit] > > x11-apps/xdm-1.1.11-r3 requires sys-auth/consolekit > > x11-misc/slim-1.3.5-r2 requires sys-auth/consolekit > > > > > > So, what to do? Obviously, I don't want an unbootable system. > > > > How did you resolve this conflict? > > > > Many thanks for a hint, > > Helmut > > > > -- > Canek Peláez Valdés > Posgrado en Ciencia e Ingeniería de la Computación > Universidad Nacional Autónoma de México > >
Re: [gentoo-user] systemd - are we forced to switch?
maybe you should not just believe everything posted. Especially from a systemd fanboi. 2013/7/22 Michael Hampicke > Am 22.07.2013 17:02, schrieb Canek Peláez Valdés: > > ConsoleKit is for all practical purposes unmaintained, and all of the > > packages you mentioned it support systemd just fine. Emerge systemd, > > and purge CK from your system; I did that almost a year ago. > > > > Thanks, just purged consolekit from my system after setting > USE="-consolekit" and remerged the affected packages. > >
Re: [gentoo-user] Upgrade only to bigger Version
ok, first make an overlay and copy the ebuild of the version you want to pin there. Than mask everything else. You can find the ebuild in /var/db if it was removed from the tree already. And yes, this ebuild removing sucks - because nobody needs every single LO update... 2013/7/26 Silvio Siefke > Hello, > > i have installed Libreoffice 4.1.0.2 and now is update to Version 4.1.0.4 > available. > > Is there a way to stop these updates? i has try with portage.mask, but then > come a downgrade to Version 4.0.4.2. Its enough when update to bigger > Updates > for example 4.2. Each update is not required for such a package. > > Hope understand what i mean. :) > > > Thank you for help and good weekend. > > > Silvio > >
Re: [gentoo-user] Creating binary packages before updating them
or you can make yourself a wrapper script that, depending on an option calls quickpkg before emerge or not. Even better, not calling emerge, but ebuild - with the different steps, and before merging into filesystem, call quickpkg. 2013/7/29 Alan McKinnon > On 29/07/2013 21:46, Neil Bothwick wrote: > > On Mon, 29 Jul 2013 15:21:59 +0100, Peter Humphrey wrote: > > > >>> Add FEATURES="buildpkg" to make.conf... > >> > >> That way you'll gradually build up a /usr/portage/packages directory > >> with a package for everything installed. Or if you don't want to wait > >> months for that: > >> > >> # emerge -eB world > > > > It isn't necessary to recompile everything just to build packages of > > them, quickpkg will do that. > > > > > > > Just make sure that quickpkg does what you want with config files... > > been there, done that, made the mistakes :-) > > -- > Alan McKinnon > alan.mckin...@gmail.com > > >
Re: [gentoo-user] ata6: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
Am 01.08.2013 09:37, schrieb Thanasis:
> on 08/01/2013 12:59 AM Paul Hartman wrote the following:
>
>> If no disks are attached, I wonder if something is probing it?
>>
>> I checked my dmesg and every time I plug in my eSATA enclosure, I see
>> this very similar message:
>>
>> [156541.724580] ata7: exception Emask 0x10 SAct 0x0 SErr 0x404
>> action 0xe frozen
>> [156541.724587] ata7: irq_stat 0x0040, connection status changed
>> [156541.724593] ata7: SError: { CommWake DevExch }
>> [156541.724604] ata7: hard resetting link
>> [156551.725559] ata7: softreset failed (device not ready)
>> [156551.725567] ata7: hard resetting link
>>
>> (and then a bunch of lines initializing all of the disks in the enclosure).
>>
> Me too. That's exactly how I use this Sata port, so it must be related
> to the way the kernel handles/probes it.
>
> BTW, I use a cable which is sata <-> eSata, i.e. sata for the
> motherboard side and eSata for the external disk side, and I keep the
> cable connected to the motherboard and the disk connected to the cable.
> I just power on the eSata external disk enclosure whenever I need to use
> the disk, and before switching the power off, I just unmount the disk.
> Is that a correct procedure?
>
> .
>
that is not an error. That is the linux kernel initializing the sata
connection.
stuff like that always happens if you hotplug a (e)sata device.
Re: [gentoo-user] Freeze after suspend-to-ram with kernel 3.10
Am 02.08.2013 12:47, schrieb Frank Steinmetzger: > Hey list > > My netbook doesn't freeze so often during operation any more. But now it’s > started to not properly wake up from suspend-to-ram. It’s like with my big > laptop: when that one runs on nouveau instead of nvidia-drivers, it behaves > the very same way, i.e. I switch it on and the screen stays blank. Not even > sysrq are working then, only hard power-down. > > I tried to confirm my oberservation by deliberately hibernating it multiple > times yesterday -- it always woke up with 3.9. Now I booted it with 3.10 and > it didn't come up on the first try. > Do you have any suggestion how I might debug this? I can’t simply report to > kernel blokes “3.10 is crap on my netbook, you put in a regression somewhere”. > > I don’t really have the time right now to go after hunches, such as the new > tikless system, as building a kernel takes up to 45 minutes on that thing. well, take your 3.9 config and don't change it.
Re: [gentoo-user] All KDE-related programs don't play music anymore
Am 16.09.2013 13:37, schrieb Alexander Puchmayr: > Hi there, > > I've got a somewhat strange problem, which occurs on both my laptop and my > desktop-pc, both running gentoo. From one day to the other, all KDE-based > music/media player don't start playing music anymore. > I've tried Amarok, Kaffeine and Juk, and all of them seem to hang when > starting > any kind of music file (mp3/flac/wma). But, strangly, kaffeine plays videos > with > sound without a problem. Also, other programs (non-kde), for example audacity > and xine, play mp3 files properly. > In kde's system settings, the phonon configuration dialog play its test > sounds > properly. > > Any ideas? Any idea why it affects two different systems pretty much at the > same > time? Any idea why it worked yesterday morning and started to have troubles > yesterday evening, without having changed anything in the system? > > BTW: dmesg shows a lot of lines that might be relevant: > [21219.855176] traps: alsa-sink[12956] general protection ip:7f08486569f2 > sp:7f083fff6b70 error:0 in libasound.so.2.0.0[7f084860+ea000] > one per attempt to play anything in amarok. > > Best regards > Alex > > > . > revdep-rebuilt may help you. And even if it doesn't, rebuild phonon.
Re: [gentoo-user] ZFS
Am 17.09.2013 09:20, schrieb Grant: > I'm convinced I need 3-disk RAID1 so I can lose 2 drives and keep > running. I'd also like to stripe for performance, resulting in > RAID10. It sounds like most hardware controllers do not support > 6-disk RAID10 so ZFS looks very interesting. > > Can I operate ZFS RAID without a hardware RAID controller? > > >From a RAID perspective only, is ZFS a better choice than conventional > software RAID? > > ZFS seems to have many excellent features and I'd like to ease into > them slowly (like an old man into a nice warm bath). Does ZFS allow > you to set up additional features later (e.g. snapshots, encryption, > deduplication, compression) or is some forethought required when first > making the filesystem? > > It looks like there are comprehensive ZFS Gentoo docs > (http://wiki.gentoo.org/wiki/ZFS) but can anyone tell me from the real > world about how much extra difficulty/complexity is added to > installation and ongoing administration when choosing ZFS over ext4? > > Performance doesn't seem to be one of ZFS's strong points. Is it > considered suitable for a high-performance server? > > http://www.phoronix.com/scan.php?page=news_item&px=MTM1NTA > > Besides performance, are there any drawbacks to ZFS compared to ext4? > do yourself three favours: use ECC ram. Lots of it. 16GB DDR3 1600 ECC ram cost you less than 170€. And it is worth it. ZFS showed me just how many silent corruptions can happen on a 'stable' system. Errors never seen neither detected thanks to using 'standard' ram. turn off readahead. ZFS' own readahead and the kernel's clash - badly. Turn off kernel's readahead for a visible performance boon. use noop as io-scheduler.
Re: [gentoo-user] ZFS
Am 17.09.2013 20:11, schrieb cov...@ccs.covici.com: > Volker Armin Hemmann wrote: > >> Am 17.09.2013 09:20, schrieb Grant: >>> I'm convinced I need 3-disk RAID1 so I can lose 2 drives and keep >>> running. I'd also like to stripe for performance, resulting in >>> RAID10. It sounds like most hardware controllers do not support >>> 6-disk RAID10 so ZFS looks very interesting. >>> >>> Can I operate ZFS RAID without a hardware RAID controller? >>> >>> >From a RAID perspective only, is ZFS a better choice than conventional >>> software RAID? >>> >>> ZFS seems to have many excellent features and I'd like to ease into >>> them slowly (like an old man into a nice warm bath). Does ZFS allow >>> you to set up additional features later (e.g. snapshots, encryption, >>> deduplication, compression) or is some forethought required when first >>> making the filesystem? >>> >>> It looks like there are comprehensive ZFS Gentoo docs >>> (http://wiki.gentoo.org/wiki/ZFS) but can anyone tell me from the real >>> world about how much extra difficulty/complexity is added to >>> installation and ongoing administration when choosing ZFS over ext4? >>> >>> Performance doesn't seem to be one of ZFS's strong points. Is it >>> considered suitable for a high-performance server? >>> >>> http://www.phoronix.com/scan.php?page=news_item&px=MTM1NTA >>> >>> Besides performance, are there any drawbacks to ZFS compared to ext4? >>> >> do yourself three favours: >> >> use ECC ram. Lots of it. 16GB DDR3 1600 ECC ram cost you less than 170€. >> And it is worth it. ZFS showed me just how many silent corruptions can >> happen on a 'stable' system. Errors never seen neither detected thanks >> to using 'standard' ram. >> >> turn off readahead. ZFS' own readahead and the kernel's clash - badly. >> Turn off kernel's readahead for a visible performance boon. >> >> use noop as io-scheduler. > How do you turnoff read ahead? > set it with blockdev to 8 (for example). Doesn't turn it off. Just makes it none-obstrusive.
Re: [gentoo-user] ZFS
Am 17.09.2013 20:11, schrieb Tanstaafl: > On 2013-09-17 2:00 PM, Volker Armin Hemmann > wrote: >> use ECC ram. Lots of it. 16GB DDR3 1600 ECC ram cost you less than 170€. >> And it is worth it. ZFS showed me just how many silent corruptions can >> happen on a 'stable' system. Errors never seen neither detected thanks >> to using 'standard' ram. >> >> turn off readahead. ZFS' own readahead and the kernel's clash - badly. >> Turn off kernel's readahead for a visible performance boon. >> >> use noop as io-scheduler. > > Is there a good place to read about these kinds of tuning parameters? > > zfsonlinux? google?
Re: [gentoo-user] ZFS
Am 18.09.2013 11:56, schrieb Joerg Schilling: > Volker Armin Hemmann wrote: > >> turn off readahead. ZFS' own readahead and the kernel's clash - badly. >> Turn off kernel's readahead for a visible performance boon. > You are probably not talking about ZFS readahead but about the ARC. > > Jörg > which does prefetching. So yes.
Re: [gentoo-user] ZFS
Am 19.09.2013 06:47, schrieb Grant: turn off readahead. ZFS' own readahead and the kernel's clash - badly. Turn off kernel's readahead for a visible performance boon. >>> You are probably not talking about ZFS readahead but about the ARC. >> which does prefetching. So yes. > I'm taking notes on this so I want to clarify, when using ZFS, > readahead in the kernel should be disabled by using blockdev to set it > to 8? > > - Grant > > . > you can't turn it off (afaik) but 8 is a good value - because it is just a 4k block.
Re: [gentoo-user] [Hardware Error]: MC1 Error: Copyback Parity/Victim error.
Am 23.09.2013 20:59, schrieb Paul Hartman: > On Mon, Sep 23, 2013 at 1:45 PM, Grant wrote: >> Can anyone tell me how to decipher this which has appeared in dmesg? >> Google wasn't very helpful. >> >> [Hardware Error]: MC1 Error: Copyback Parity/Victim error. >> [Hardware Error]: Error Status: Corrected error, no action required. >> [Hardware Error]: CPU:3 (10:2:3) MC1_STATUS[-|CE|-|-|-]: 0x9171 >> [Hardware Error]: cache level: L1, tx: INSN, mem-tx: EV > Looks like machine check error, it detected an error in the L1 cache > on your CPU. > > Since it says "Corrected error, no action required" I would not worry > about it. If that makes you feel any better. :) > > since those errors are rare, I would worry about it.
Re: [gentoo-user] [Hardware Error]: MC1 Error: Copyback Parity/Victim error.
Completely unrelated. He got a Cache ecc error. Not tlb Bug. Also those were fixed quickly. In hardware and software. No Problem There. I hate Auto correction. Am 24.09.2013 12:37 schrieb "Ralf Ramsauer" < ralf+gen...@ramses-pyramidenbau.de>: A friend of mine told me, that AMD also had some trouble concerning TLB on that architecture (translation lookaside buffer). Unfortunatelly I have no references for that issue. I would keep a eye on that error, and if your system must be highly-available, i would even change hardware. Regards, -- Ralf On 09/24/13 10:01, Grant wrote: >> I had a deeper look into the kernel sources: >> >> Your error me...
Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?
Am 27.09.2013 12:33, schrieb Stefan G. Weichinger: > 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. > > The NICs in the new server are BCM-something, Broadcom, using the tg3 > Tigon module (exact model not available right now as mentioned above). > > In "dmesg" I see lines like > > hpet1: lost 1 rtc interrupts > > which makes me wonder if that leads to the lousy performance (btw, I > fear slow virtualization performance as well). > > Dealing with HPET I checked for kernel support and also added kernel > options to GRUB: > > hpet=force clocksource=hpet > > which lead to > > # cat /sys/devices/system/clocksource/clocksource0/current_clocksource > hpet > > I am unsure if I should further investigate things around this HPET-issue? > > My thinkpad here shows "tsc" as clocksource ... good/better ? faster, if it works. Completely broken, if it doesn't. > What direction to go? force or disable HPET? > > neither
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
Am 28.09.2013 16:04, schrieb Alan McKinnon: > On 28/09/2013 13:32, Tanstaafl wrote: >> On 2013-09-27 7:10 PM, Alan McKinnon wrote: >>> No really,*why exactly*? >> Because that was the RECOMMENDED WAY IN THE GENTOO HANDBOOK when I first >> set this system up many years ago. > This was something almost all of us recommended way back then. Lord only > knows why we recommeded that. I never knew. Something about 'saver as..' or something stupid. > Maybe it was small drives (which didn't > have), maybe it was different mount options (which I never did and never > saw anyone else do either), or maybe it was for thin clients (which I > only ever saw in use once - Shuttleworth labs in University of Cape Town). > > So why did we all (and I included myself) recommend this so much? Dude, > I have no idea, but I *think* we were cargo-culting more than any other > single factor. > > >> I have no philosophical reason reason to stick with it, only a (maybe >> irrational) fear of breaking things if I attempt to merge it back into /. >> >> This, combined with an intense (also maybe irrational) desire to avoid >> like the plague using an initramfs, is why this decision to FORCE me >> into a position of possibly having to break my system (either by a filed >> attempt at merging /usr into /, or a failed attampt at using an initramfs). > No-one is forcing you to do anything, the news item did not say that. > > It says that if you do it, the devs will not support you and you are on > your own. It also says that in the dev's opinion, the day when you can > no longer support it either is probably not too far away > >> I too sincerely hope eudev bypasses this issue. > This has nothing to do with eudev, not with udev > >> The main thing about this that pisses me off is the lack of enough >> warning... one month? Really? One month to compleyelt rebuild a seerver >> that has been running flawlessly for many years, just because someone >> doesn't like something that has been done for many years? > > First, it is not one month, it is much longer. We've all been whinging > about the issue for most of this year. Two, why do you think you need to > rebuild the entire machine? You don't need to do that just to merge two > filesystems. > > To merge two filesystems, you just merge two filesystems. You don't > rebuild anything. You might have some downtime though one reboot. You cp everything into /newuser. On shutdown you unmount /usr, mv newuser usr, sync, unmount, reboot. if you want to do it 'old fashioned', you cp everything to /newuser, reboot with systemrescuecd, mount / on /mnt/gentoo, my newuser to usr and reboot. Oh, and change fstab. Simple and boring.
Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
Am 29.09.2013 00:36, schrieb Alan McKinnon: > On 28/09/2013 22:58, Alon Bar-Lev wrote: >> As far as I read, the problem is with bluetooth keyboards? and some >> other devices and locales, which are minor for this decision of >> removing supportability. Especially for servers and for most of >> workstations. Most sane configuration can be supported with separate >> /. >> >> And of course there is the hidden systemd agenda, which is what I >> suspect had more impact. > No, the problem is not bluetooth keyboards per se. That just happens to > be a convenient example of the kind of problem anticipated. There is a > tendency to use it as the only example, which reinforces the idea that > BT keyboards are problem to be solved. > > The actual problem is better stated something like this: > > In the early stages of user-land setup (around the time when udev is > getting it's act together), arbitrary code can run and that code can be > in any arbitrary place, but there is no guarantee that that code is even > accessible at the point when it is needed. The actual cause of this mess > is the lack of standards on where to put stuff on Linux systems, and it > forms a classic bootstrap problem. > > There has only ever been one way around that problem - define an exact > entry point that is guaranteed to be in a specific state. For current > userland this effectively means that everything that has traditionally > been in bin, sbin and lib in / and /usr must be available as step 1. > Technically, you could include /var/lib/ and maybe even /opt in there. > but we can safely exclude those at this time as only a brain-dead moron > would ever put init-critical code there. > > It's a fact of history that Linux packager and package devs have never > managed to make up their minds where to put stuff. Just have a look at > coreutils binaries - why are 60% of them in /usr? It's coreutils! And > core isn't in the name because of a whim. > > So you have two choices: enforce a decent separation so that the problem > doesn't happen, or enforce that all binaries are in one place where we > can call it "the system". Every major OS out there does the latter, it's > only Linux that tolerates this free for all wild wild west approach of > stick anything anywhere and still expect it to work. Hint: it doesn't > work. Duct-tape and bubblegum don't actually hold stuff together, no > matter how much we try convince ourselves it does. > > This should actually have been done when MAKEDEV was phased out in > favour of the now-defunct devfs, but it's never too late to fix design > flaws that date back 30 years or more. > > So this brings us back to the essential technical problem that still > needs to be solved on your machines: > > /usr needs to be available (and not only for BT keyboards) at the > earliest possible opportunity - this is a technical constraint. To > guarantee that, you need to either merge /usr with /, or use an > initramfs to guarantee that /usr is available before anything else > happens in userland. > > It *really* is that simple. If you have a better solution than my last > two choices, then I am all ears. > > the correct and simple solution would be to deprecate /usr and move everything into / .
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
Am 29.09.2013 10:28, schrieb Alan McKinnon: > On 29/09/2013 10:25, Mick wrote: >> On Sunday 29 Sep 2013 06:29:37 Walter Dnes wrote: >>> On Sat, Sep 28, 2013 at 06:09:40PM -0500, Dale wrote >>> Most likely, I'll install Kubuntu to start. Then I may roam around and test other distros until I find one I like. Thing is, I already have a starting point. >>> I'm already looking. http://forums.funtoo.org/viewtopic.php?id=2265 >>> and they also dislike systemd. I think I could get to like it. See >>> also http://bugs.funtoo.org/browse/FL-34 >> Very interesting! This looks as a logical way to put udev back in its >> userspace box and stop it breaking the OS, or did I understand it >> incorrectly? >> > Exherbo might be worth a look too[1]. > > It's a sort-of Gentoo fork using the portage tree and PMS; plus Ciaran > strikes me as the kind of guy who *would* expend massive effort to find > a way round current udev and systemd. > > > [1] I didn't look myself. I have no idea what Exherbo's stance is on > this matter. > > > why do you bring up udev and systemd AT ALL? They are not the problem or the reason why seperate /usr is prone to break.
Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
Am 29.09.2013 02:08, schrieb Alan McKinnon: > On 29/09/2013 01:23, Volker Armin Hemmann wrote: >>> It *really* is that simple. If you have a better solution than my last >>>> two choices, then I am all ears. >>>> >>>> >> the correct and simple solution would be to deprecate /usr and move >> everything into / . >> >> > I did consider that, but gave up on the idea as not workable. Sure, it > would work great and did work very well for Android and MacOS, both > controlled environments. > > But doing it gains you nothing really apart from a crap load of stuff > cluttering up /, thinks like local, games and share. > > But hey, maybe we can go right back to the originsl and put /home where > it started: /usr/people > and a cluttered / is worse than a non-existant / and a cluttered /usr? Because we are just moving in that direction.
Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
Am 29.09.2013 01:31, schrieb pk: > On 2013-09-29 01:23, Volker Armin Hemmann wrote: > >> the correct and simple solution would be to deprecate /usr and move >> everything into / . > Install Windows and be done with it, I say. > > Best regards > > Peter K > > > . > look at history, think and retry.
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
Am 29.09.2013 13:03, schrieb Greg Woodbury: > On 09/29/2013 06:55 AM, Volker Armin Hemmann wrote: > >> why do you bring up udev and systemd AT ALL? >> >> They are not the problem or the reason why seperate /usr is prone to >> break. >> > Except that systemd *is* why a seperate /usr is broken now. > Parts of the libraries that systemd depend on we *deliberately* placed > in /usr despite the fact that they are needed to bbring the system to > an operational state. For *years* things required to boot the system > were defined to be in the root file system, and items not required > until after mounting had been accomplished were to be placed in /usr. > > BTW: There is a standard (The File System Hierarch Standard - FSS) > that existed and described this behaviour. It was killed off by > deliberate vendor refusals to support or adhere to it. In > frustration, the folks involved simply gave up. > things were broken way before that. As much as I hate systemd, it is not the root cause of the problem. The problems were caused by people saying that seperate /usr was a good idea, so / would not fill up and similar idiocies. The problems were caused by people saying that lvm is a good idea - for desktops. Those people who are fighting against the kernel auto assembling raids are to blame too. Systemd is just another point in a very long list.
[gentoo-user] Re: Flexibility and robustness in the Linux organisim
Am 29.09.2013 17:12, schrieb Greg Woodbury: > On 09/29/2013 07:58 AM, Volker Armin Hemmann wrote: > >> things were broken way before that. As much as I hate systemd, it is not >> the root cause of the problem. >> >> The problems were caused by people saying that seperate /usr was a good >> idea, so / would not fill up and similar idiocies. The problems were >> caused by people saying that lvm is a good idea - for desktops. Those >> people who are fighting against the kernel auto assembling raids are to >> blame too. >> >> Systemd is just another point in a very long list. >> > The usr filesystem was separate from root from the very early days of > UNIX. Disks were *tiny* (compared to today) and spreading certain > things across separate spindles provided major benefits. Certainly, > the original need to require a separate usr went away fairly quickly, > but other benefits continued to encourage a seperation between root > and usr. > in the very early days /usr did not exist in the first space and was only created because someone added a harddisk. Not really a good reason to keep it around. > The var filesystem was for variable system data, and was never > terribly big and its inclusion on the root volume happened. The home > filesystem became traditionally separate because data expands to fill > all availab;e space, and users collect *things* and a seperate /home does not create any problems. /var is much more prone to accidentally fill up then /usr ever was. > Networking made it possible to have home entirely off system, and > diskless worstations ruled for a while as well. > > By the time Linux came along, it had become common for boot volumes to > not be mounted during normal system operation, but the three > filesystem layout was common and workable. As Linux continued to be > like Topsy (she jest growed!) fragmentation started to occur as > "distributions" arose. The "balkanization" of Linux distributions > became a real concern to some and standardization offorts were > encouraged. > > The "File System Standard" (FSS) was renamed to the Filesystem > Hierarch Standard (FHS) and it was strongly based on the UNIX System V > definitions (which called for seperation of usr and root.) POSIX added > more layers and attempted to bring in the various BSD flavors. > > THe LSB (Linux Standards Base) effort was conceived as supersceeding > all the other efforts, and FHS was folded into the LSB definition. Yet > even then a separate root and usr distinction survived. Then things > started falling apart again - POSIX rose like a phoenix and even the > Windows/wintel environment could claim POSIX compliant behavior. The > fall of the LSB effort really became evident when the FHS was gutted > and certain major players decided to ignore the LSB recommendations. too bad POSIX is much older than LSB or FHS. > > As a result, the GNOME Alliance has shattered. The main GNOME army > marches on its unfathomable path, and various large chunks have broke > off in their own directions (e.g. Cinnamon and Mate) seeking to remain > flexible and not incompatible with the KDE and other lesser DE folks. > > It is truly layable at the feet of the GNOME folks, the breakage of > the root and usr filesystem separability is all derived from the GNOME > camp. > These changes may not, in fact, be deliberate or intended to "defeat" > Microsoft, but Ockham's Razor cuts and intentionality is the simpler > explanation. that gnome is very hostile when it comes to KDE or choice is not news. And their dependency on systemd is just the usual madness. But they are not to blame for seperate /usr and the breakage it causes. > > > To come back to the thesis: robustness and flexibility are required > for good "health" and we are witnessing a dangerous challenge. > what? that you need an initrd? That is so bad? Are you kidding me? > > [PS} If anybody cares, I was trained in both Computer Science and > Biological Science. and I can expand on the parallels if so desired. > no thank you. But if I might add one: you are making an elephant out of a gnat.
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
Am 29.09.2013 14:07, schrieb Alan Mackenzie: there was no conspiracy and there will never be one to break seperate /usr. In fact seperate /usr works just fine. You just need an initrd/initramfs. Other distros are using those for ages. So for them putting something 'essential' into /usr was no problem. It was not their fault that gentoo users hate this things so much. From REDHATs or SuSEs perspective seperate /usr is not a problem. Putting lvm/bluetooth/mdraid/whateverthefuckyoumightneed there was and is not a problem too. Thanks to initrds&co. They are using them for AGES and it works fine. See? No conspiracy needed. It just happened that YOUR use case of seperate /usr + no initrd has become so arcane and rare that pretty much nobody needs or wants to worry about fringe cases. Would you be fine with a 40% decrease in performance just to optimally support some 3 machines worldwide architecture? Certainly not. And that is not a conspiracy either. I dislike them, because they are another step to be taken on updates. But if I was so dumb to create a seperate /usr - well I wouldn't complain about the initrd and just go with the rest.
Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
Am 29.09.2013 17:24, schrieb pk: > On 2013-09-29 12:59, Volker Armin Hemmann wrote: > >> look at history, think and retry. > That's just what I did. Read and retry. > > Best regards > > Peter K > > > . > I did, your mail did not make any more sense at all.
Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim
Am 29.09.2013 18:41, schrieb Francisco Blas Izquierdo Riera (klondike): > El 29/09/13 18:03, Volker Armin Hemmann escribió: >> Am 29.09.2013 17:12, schrieb Greg Woodbury: >>> On 09/29/2013 07:58 AM, Volker Armin Hemmann wrote: >>> >>>> things were broken way before that. As much as I hate systemd, it is not >>>> the root cause of the problem. >>>> >>>> The problems were caused by people saying that seperate /usr was a good >>>> idea, so / would not fill up and similar idiocies. The problems were >>>> caused by people saying that lvm is a good idea - for desktops. Those >>>> people who are fighting against the kernel auto assembling raids are to >>>> blame too. >>>> >>>> Systemd is just another point in a very long list. >>>> >>> The usr filesystem was separate from root from the very early days of >>> UNIX. Disks were *tiny* (compared to today) and spreading certain >>> things across separate spindles provided major benefits. Certainly, >>> the original need to require a separate usr went away fairly quickly, >>> but other benefits continued to encourage a seperation between root >>> and usr. >>> >> in the very early days /usr did not exist in the first space and was >> only created because someone added a harddisk. >> >> Not really a good reason to keep it around. > I'm going to show the lack of sense of this argument: > in the very early days linux did not exist in the first space and was > only created because someone got a 386. > > Not really a good reason to keep it around. wrong analogy and it goes down from here. Really. > > in the very early days GNU did not exist in the first space and was > only created because someone jammed a printer. > > Not really a good reason to keep it around. > > in the very early days Gentoo did not exist in the first space and was > only created because someone added a processor. > > Not really a good reason to keep it around. > > in the very early days hardening did not exist in the first space and was > only created because someone added security. > > Not really a good reason to keep it around. > > in the very early days Gnome did not exist in the first space and was > only created because someone got a graphics card. > > Not really a good reason to keep it around. > > I'm sure you'll be able to figure out the pattern there. > > Ohh and BTW, /usr was not just added because someone added a harddrive, > in most cases it was used to allow machines contain a very small system > on / which was enough to just boot and mount a networked system (/usr) > containing most of the software. This allowed for cheaper deployment of > machines since the hard drive could be smaller as it wouldn't need to > have all the data locally. Yeah, if this sounds familiar is because this > was later moved to initramfs. no, network'ed file systems came a lot later. Initially /usr was added because one harddisk was full. Really, that is the whole reason for its (broken) existance. > >>> The var filesystem was for variable system data, and was never >>> terribly big and its inclusion on the root volume happened. The home >>> filesystem became traditionally separate because data expands to fill >>> all availab;e space, and users collect *things* >> and a seperate /home does not create any problems. >> /var is much more prone to accidentally fill up then /usr ever was. > You are jst getting it wrong, /var was kept locally as the data there > was supposed to change from machine to machine. no, you just don't understand what I wrote. People told other people to keep /usr seperate so / may not fill up by accident. That advise always was murky at best. Outright stupid is a good description too. /usr is not prone to much changes. So if your / fits the contents of /usr just fine, there is pretty much no risk. /var on the other hand tends to explode - but a lot of people never got told to put /var on a seperate disk. If you ever realized that a tens of gigabyte logfile just made your box unbootable, you learnt a lot that day. >>> Networking made it possible to have home entirely off system, and >>> diskless worstations ruled for a while as well. >>> >>> By the time Linux came along, it had become common for boot volumes to >>> not be mounted during normal system operation, but the three >>> filesystem layout was common and workable. As Linux continued to be >>> like Topsy (she jest growed!) fragmentation started to occur as >>> "distributions" arose. The "balkanization"
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
Am 30.09.2013 00:06, schrieb Walter Dnes: > On Sun, Sep 29, 2013 at 06:10:46PM +0200, Volker Armin Hemmann wrote > >> From REDHATs or SuSEs perspective seperate /usr is not a problem. >> Putting lvm/bluetooth/mdraid/whateverthefuckyoumightneed there was >> and is not a problem too. Thanks to initrds&co. > And if I wanted to run bleeping Redhat Fedora, I'd run bleeping Redhat > Fedora. I want GNU/Linu-x, not GNOME/Lenna-x. luckily nobody forces you to install gnome, systemd or pulseaudio. You don't have to do anything unless you: have /usr on a seperate partition no initrd. If you have no initrd: genkernel it will create one for you. Very easy to use. > >> They are using them for AGES and it works fine. > * Loading firmware into the kernel worked fine for AGES, until Kay > Seivers broke udev... https://lkml.org/lkml/2012/10/2/303 different story. > * Everybody's single-NIC machine came up with eth0 for AGES, until Kay > Seivers broke udev. And calling the new setup "predictable" is > George Orwell 1984 doublespeak. Let's see you walk up to an unknown > machine and "predict" what the NIC is going to come up as. and you could predict with the old setup? If think these new names are as stupid as it gets, but I had enough pain in the past with multi-nic boxes shuffling eth0, eth1, ethn+1... randomly on reboots. That was fun. > > * Separate /usr worked fine for AGES, until... Do you see a pattern > developing here? > seperate /usr has stopped working fine AGES AGO. Just some setups were lucky enough not to stumble over the wreckage and fall into the shards. Only worse than breakage is silent breakage that seems to be ok. Until the day where some minor and arcane change fucks you up. I have to admit: I don't use init'thingies' - because I don't have to. But back when I played around with different RAID setups I was prepared to use one - because I am not stupid. If I want something to work that needs an 'initthingie', I don't complain and bitch, I read up on 'initthingies'. Besides, AFAIR Dale is the only one who had ever problems with 'initthingies' on this list. And Dale has a lot of problems with stuff that works for everybody else.
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
Am 29.09.2013 19:58, schrieb Tanstaafl: > On 2013-09-28 4:17 PM, Neil Bothwick wrote: >> On Sat, 28 Sep 2013 19:04:41 +, Alan Mackenzie wrote: >> I suppose that what I am about to say isn't really relevant, but it is unfortunate over the past year that people blamed udev specifically for this. It is true that it does things that don't work if /usr isn't mounted, but eudev does as well, since it is basically the same code. >>> >>> Who else is there to blame? We are continually being told that a >>> separate /usr is "broken", as though this were some unfortunate act of >>> , much like an earthquake. This gets >>> patronising really quickly. (Please note, I'm NOT blaming you here. I >>> appreciate that you're as much victim as Dale or me or anyone else >>> round here.) >> >> It's evolution. Linux has for years been moving in this direction, >> now it >> has reached the point where the Gentoo devs can no longer devote the >> increasing time needed to support what has now become an dge case. > > So the solution is to give users one MONTH to prepare? Why not 6 > months, or better, a year? What for gods sake is the rush??? one month to run genkernel is more than enough. And that this point was approaching was clear - what, 2 years ago? At least? > > Where are the links/pointers to the INTERNAL discussions of this > decision? I seriously want to know. If gentoo devs are not willing to > provide a 'paper trail' for how this decision was arrived at, and let > others judge their decisions based on the merits of their arguments, > then what does that say about their true motivations/intentions? marc.info --> gentoo-dev > > Again, I don't have a problem necessarily with what is being decided > (no separate /usr without an initramfs), my problem is with the > implementation - giving us one MONTH before we can expect possible > breakage with each and every update. No, you already can expect possible breakage with each and every update. In 4 weeks they will stop listening to your complains. > > The other HUGE thing that worries me, and has me seriously considering > switching to FreeBSD NOW, is, maybe there really is a secret, > underlying ulterior motive to force both systemd AND an initramfs for > everyone in ALL use cases. If that is the case, then say so now, and > give those of us who do not want this advanced notice, and I'll just > plan on setting my gentoo box to never update on Nov 1, and start > working on learning FreeBSD and if necessary, pay someone to help me > migrate services to it. so do it. You will be a lot happier there. I am sure. With forcing llvm etc
Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
Am 30.09.2013 00:53, schrieb Tanstaafl: > On 2013-09-29 5:15 PM, Alan McKinnon wrote: >> Those numbers are not likely to change much with time, with one >> exception: >> >> /usr/src >> >> That can get real big real quick if you don't clean up kernel sources >> often. Ideally, you'd make that a suitably sized LV and mount it >> seperately. > > Yeah, I always keep 2 or 3 known good kernels, and clean out the old > stuff, so no worries there. > >> The other space consumer is /usr/share with it's many documentation >> files. But those too tend to be stable once you have everything >> installed. 5G free out of 19G is ~75% space in use which is perfectly >> acceptable for this case. >> >> Regular monitoring of the state of your machines will tell you if space >> usage increases so you can investigate and deal with it timeously. >> >> I assume you long since moved portage and it's storage directories out >> of /usr into /var? > > Hmmm... No, I never did that myself... > > Wow... > > moria : Sun Sep 29, 18:19:01 : ~ > # du -sh /usr/* > 85M /usr/bin > 131M/usr/include > 0 /usr/lib > 11M /usr/lib32 > 530M/usr/lib64 > 51M /usr/libexec > 15M /usr/local > 7.8G/usr/portage > 21M /usr/sbin > 509M/usr/share > 3.9G/usr/src > 0 /usr/tmp > 7.0M/usr/x86_64-pc-linux-gnu > moria : Sun Sep 29, 18:26:30 : ~ > # > > Is this the official gentoo way now? Will a new/fresh virgin install > have /var/portage instead of /usr/portage? > > I can eliminate almost 8GB by moving portage and its storage > directories... > > I don't recall seeing a news item about that... > > But... is /usr/portage the default/recommended location? If so, then I > don't think I want to move it - I generally never change defaults > unless there is a very good reason to do so. > > But, is there some official gentoo docs online explaining how to do this? > > Something more to think about... > > Also - is there any kind of maintenance I shoudl be doing on > /usr/portage to clean old cruft out? Or does portage maintain it already. > > :) > > df -h DateisystemGröße Benutzt Verf. Verw% Eingehängt auf /dev/root59G 33G 24G 58% / devtmpfs7,8G 0 7,8G0% /dev tmpfs 1,6G712K 1,6G1% /run shm 7,8G1,1M 7,8G1% /dev/shm cgroup_root 10M 0 10M0% /sys/fs/cgroup /dev/sda1 197M 17M 181M9% /boot/efi /dev/sde1 110G 82G 23G 79% /home/energyman tmpfs 1,0G3,4M 1021M1% /tmp zfstank/data3,6T1,9T 1,8T 52% /mnt/data zfstank/var 100G 16G 85G 16% /var zfstank 1,8T256K 1,8T1% /zfstank and I put PORTDIR into /var ages ago. I hate 'moving targets' like PORTDIR in a static place like /usr. 7,8G/var/portage 6,5G/var/packages but seriously, if seperate /usr is so important for you - running genkernel really IS easy...
Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?
Am 30.09.2013 11:54, schrieb Stefan G. Weichinger: > Am 29.09.2013 16:37, schrieb Stefan G. Weichinger: >> Am 27.09.2013 17:55, schrieb Volker Armin Hemmann: >> >>>> What direction to go? force or disable HPET? >>>> >>>> >>> neither >> And what to do to avoid those lost interrupts? > Is there no good suggestion for this? > > > > > let the kernel figure out the best clocksource for you? if you have a real problem with lost interrupts, go to lkml.
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
Am 30.09.2013 01:27, schrieb Dale: > Tanstaafl wrote: >> On 2013-09-29 5:35 PM, Dale wrote: >>> Tanstaafl wrote: Ok, but... everything I've read and personal experience over the years shows that space required for /usr should not change much, especially constantly grow over time (like requirements for /home can and will)- it may fluctuate (increase, decrease) *a little* over time, but it definitely should not grow substantially, so, if you had to resize it, most likely it is because you simply didn't allocate enough room to start with. >>> So my experience doesn't matter any then? >> Dale, that is NOT what I said, and nothing I am saying is intended to >> be offensive. >> >>> My /usr does vary and sometimes varies quite a bit. >> The question you should be asking yourself then, is WHY? > To me, it doesn't matter why it varies, it just does. After each > update, I check to see what the partitions look like. The biggest > change was going from KDE3 to KDE4. That seemed to make things grow a > good bit. Other things I install/uninstall seem to change things too. > >>> That is why I had to resize the thing. Saying that I didn't make it >>> large enough to begin with isn't the point. >> It is precisely the point... >> >> The fact is, there is nothing in there that *should* vary much (once >> your system is fully installed) - unless you are using it in some >> non-standard way, and/or not occasionally cleaning out /usr/src (as >> Alan pointed out)... and if either of those is the case, then as I >> said, it is your own fault that you needed to resize it. >> >> Don't you see how contradictory it is to say that you will change from >> gentoo to distro-x because gentoo has made a change that requires you >> to either merge /usr into / or use an 'init thingy', when distro-x, >> that you say you will change to, USES AN INIT THINGY? Doesn't that >> sound irrational to you? > No, it doesn't. On Gentoo, I HAVE to make the thing but don't know how > to fix it if it breaks. On other distros, I don't have to make the > thing. If it fails, at worst, I can reinstall in much less time than I > would spend trying to fix the silly thing. Since I don't know how to > fix one and can't boot to get help, then the computer may as well be a > screen door on a submarine. As I posted before, if something breaks and > I can't fix it, I replace it with something else that works. That could > be why /usr varies so much too. > >> What would be logical and rational would be to either: >> >> a) learn how to use an init thingy (which from some more reading I've >> been doing, doesn't look quite as bad as it seemed initially), or >> >> b) determine what is a sane size for /usr, make / an appropriate size >> to subsume it, and merge it into /. >> >> Now, if you don't have enough room in / to merge it, then obviously it >> will be more painful, but once it is done, you never have to worry >> about it again - and no init thingy. > Actually, history proves that wrong too. I started using LVM because I > got tired of having to rearrange my partitions and resize things. That > was the whole reason I switched to LVM when I did. Ask anyone on this > list that has been here long ehough. I have had to move things around > LOTS of times because things grow including /usr and /var. /home is a > different and unrelated thing. Funny thing is, I did it several times > and never even posted about it. > >>> When people use LVM, the reason they use it is so that we can resize >>> things when needed. >> Yes, and I use LVM - but again, this is only important for dirs/mnt >> points that have the potential to consume more and more disk space... >> that potential is simply not there for (a properly configured and >> maintained) /usr... > See above. > >>> And what is rational for you, is not rational to me. Since you can >>> dismiss mine, I can dismiss yours too. Funny how that works huh? >> Yep... and you can also dismiss my claim that jumping off that 1,000' >> cliff won't result in you going splat, but it doesn't change the fact >> that if you jump off of it, you WILL go splat. I just wouldn't get the >> chance to say I told you so. >> >> > And what you are saying is not changing anything either. I don't want > to mess with the init thingy. If I do, first time it fails and a > solution isn't obvious, time to move on to something else. I like my 16 > year old washing machine and I have repaired things on it a few times. > If it breaks and I can't fix it, time for a new washing machine. Most > likely, a different brand and model too. > > Dale > > :-) :-) > 500gb harddisks are extremely cheap. 150gb for / with usr and you will be fine for ages. Why are you acting like this is a problem?
Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
Am 30.09.2013 11:00, schrieb Alan McKinnon: > On 30/09/2013 00:53, Tanstaafl wrote: >> On 2013-09-29 5:15 PM, Alan McKinnon wrote: >>> Those numbers are not likely to change much with time, with one >>> exception: >>> >>> /usr/src >>> >>> That can get real big real quick if you don't clean up kernel sources >>> often. Ideally, you'd make that a suitably sized LV and mount it >>> seperately. >> Yeah, I always keep 2 or 3 known good kernels, and clean out the old >> stuff, so no worries there. >> >>> The other space consumer is /usr/share with it's many documentation >>> files. But those too tend to be stable once you have everything >>> installed. 5G free out of 19G is ~75% space in use which is perfectly >>> acceptable for this case. >>> >>> Regular monitoring of the state of your machines will tell you if space >>> usage increases so you can investigate and deal with it timeously. >>> >>> I assume you long since moved portage and it's storage directories out >>> of /usr into /var? >> Hmmm... No, I never did that myself... >> >> Wow... >> >> moria : Sun Sep 29, 18:19:01 : ~ >> # du -sh /usr/* >> 85M /usr/bin >> 131M/usr/include >> 0 /usr/lib >> 11M /usr/lib32 >> 530M/usr/lib64 >> 51M /usr/libexec >> 15M /usr/local >> 7.8G/usr/portage >> 21M /usr/sbin >> 509M/usr/share >> 3.9G/usr/src >> 0 /usr/tmp >> 7.0M/usr/x86_64-pc-linux-gnu >> moria : Sun Sep 29, 18:26:30 : ~ >> # > Apart from portage and src that all looks totally normal and unlikely to > vary much over time. > > > >> Is this the official gentoo way now? Will a new/fresh virgin install >> have /var/portage instead of /usr/portage? > The new instaled default is to put all of portage on /var, whilst still > supporting old installs on /usr. This is no big deal in code, as it's > really just a string containing a base path > > >> I can eliminate almost 8GB by moving portage and its storage directories... > Or move them onto a dedictaed LV. This is a case where a different mount > point makes a lot of sense - we're all aware just how unique the tree is > in terms of fs performance - thousands of small files mostly smaller > than 2k in hundreds of directories. It's quite different to everything > else on /usr or even /var. > > Same with distfiles, that too can move anywhere you want it to be, just > adjust one setting in make.conf > >> I don't recall seeing a news item about that... > IIRC it wasn't a news item as such. Perhaps it was an elog from portage > itself. > > >> But... is /usr/portage the default/recommended location? If so, then I >> don't think I want to move it - I generally never change defaults unless >> there is a very good reason to do so. > It's /var/portage for new installs. If you want it to be somewhere else, > just move it and adjust make.conf > > really? so when I moved PORTDIR to /var/portage I was ahead of the rest? Wow...
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
Am 30.09.2013 19:25, schrieb Tanstaafl: > On 2013-09-30 1:10 PM, Volker Armin Hemmann > wrote: >> 150gb for / with usr and you will be fine for ages. > > I'm curious what a common/average size is for desktops... > > My /usr, without portage files, is @ 5GB. > > My current / is only 83M, so even after I merge /usr into it, it will > still be only @ 5GB... > > But, this is a server, so... > > For an average desktop, loaded with software (say, KDE, Libreoffice, > etc), how much will /usr grow to? Or more specifically, what is a > *reasonable* maximum one could expect? > > my whole / with KDE, libreoffice, ut2004 in /opt and /usr/src having several linux versions in it but without PORTDIR is: /dev/root59G 33G 24G 58% / 10G are /opt 18G are /usr 5.4G are /usr/src
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
Am 30.09.2013 22:48, schrieb Dale: > Volker Armin Hemmann wrote: >> 500gb harddisks are extremely cheap. 150gb for / with usr and you will >> be fine for ages. Why are you acting like this is a problem? > Maybe cheap for you but not so for me. I'm on a fixed income, > disabled. Also, my brother has cancer and I'm taking him to treatments > that are about 75 miles away one way. I'm buying gas since he can't > work much if any right now either. Right now, buying anything computer > related is out of the question. I got much more important things to > deal wtih. I'm certainly not going to be able to do that in the next 30 > days. So, computer, Gentoo as well, is pretty low on the priority > list. I suspect I will be bootable for a good while but have a plan B > if needed. > > Dale > > :-) :-) > you are talking to a person whose income is only slightly above social security levels and I am still be able to buy an adequate hdd once in a while.
Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim
Am 01.10.2013 01:21, schrieb Francisco Blas Izquierdo Riera (klondike): > El 30/09/13 00:47, Volker Armin Hemmann escribió: >> Am 29.09.2013 18:41, schrieb Francisco Blas Izquierdo Riera (klondike): >>> El 29/09/13 18:03, Volker Armin Hemmann escribió: >>>> Am 29.09.2013 17:12, schrieb Greg Woodbury: >>>>> On 09/29/2013 07:58 AM, Volker Armin Hemmann wrote: >>>>> >>>>>> things were broken way before that. As much as I hate systemd, it is not >>>>>> the root cause of the problem. >>>>>> >>>>>> The problems were caused by people saying that seperate /usr was a good >>>>>> idea, so / would not fill up and similar idiocies. The problems were >>>>>> caused by people saying that lvm is a good idea - for desktops. Those >>>>>> people who are fighting against the kernel auto assembling raids are to >>>>>> blame too. >>>>>> >>>>>> Systemd is just another point in a very long list. >>>>>> >>>>> The usr filesystem was separate from root from the very early days of >>>>> UNIX. Disks were *tiny* (compared to today) and spreading certain >>>>> things across separate spindles provided major benefits. Certainly, >>>>> the original need to require a separate usr went away fairly quickly, >>>>> but other benefits continued to encourage a seperation between root >>>>> and usr. >>>>> >>>> in the very early days /usr did not exist in the first space and was >>>> only created because someone added a harddisk. >>>> >>>> Not really a good reason to keep it around. >>> I'm going to show the lack of sense of this argument: >>> in the very early days linux did not exist in the first space and was >>> only created because someone got a 386. >>> >>> Not really a good reason to keep it around. >> wrong analogy and it goes down from here. Really. > Ohh, but they are inspired on YOUR analogy, so guess how wrong yours was. your trolling is weak. And since I never saw anything worth reading posted by you, you are very close to plonk territory right now. >>> in the very early days GNU did not exist in the first space and was >>> only created because someone jammed a printer. >>> >>> Not really a good reason to keep it around. >>> >>> in the very early days Gentoo did not exist in the first space and was >>> only created because someone added a processor. >>> >>> Not really a good reason to keep it around. >>> >>> in the very early days hardening did not exist in the first space and was >>> only created because someone added security. >>> >>> Not really a good reason to keep it around. >>> >>> in the very early days Gnome did not exist in the first space and was >>> only created because someone got a graphics card. >>> >>> Not really a good reason to keep it around. >>> >>> I'm sure you'll be able to figure out the pattern there. >>> >>> Ohh and BTW, /usr was not just added because someone added a harddrive, >>> in most cases it was used to allow machines contain a very small system >>> on / which was enough to just boot and mount a networked system (/usr) >>> containing most of the software. This allowed for cheaper deployment of >>> machines since the hard drive could be smaller as it wouldn't need to >>> have all the data locally. Yeah, if this sounds familiar is because this >>> was later moved to initramfs. >> no, network'ed file systems came a lot later. >> Initially /usr was added because one harddisk was full. Really, that is >> the whole reason for its (broken) existance. > Please provide some reference about "Initially /usr was added because > one harddisk was full." without it your statement is moot to me. see Mark David Dumlao's mails. But it is interesting, that you are attacking others with your superior knowledge - and then show that you lack exactly that. You are talking about stuff you have no clue at all about. > > The setup of a separate /usr on a networked system was used in amongst > other places a few swedish universities. seperate /usr on network has been used in a lot of places. So what? Does that prove anything? Nope, it doesn't. >>>>> The var filesystem was for variable system data, and was never >>>>> terribly big and its inclusion on the root volume happened. The home >>>&
Re: [gentoo-user] ati-drivers:legacy fail to build with kernel 3.12
Am 01.10.2013 10:00, schrieb Helmut Jarausch: > Hi, > > in "good" tradition the new 3.12 Linux kernel breaks ati-drivers > again (as always in the past). > Does anybody know about a patch to make > x11-drivers/ati-drivers:legacy > compile with linux-3.12-rc3 ? > > Trying to emerge ati-drivers-13.1_pre897 (currently the only legacy > driver) > with 3.12-rc3 gives > > MODPOST 1 modules > FATAL: modpost: GPL-incompatible module fglrx.ko uses GPL-only symbol > 'acpi_bus_get_device' > > Many thanks for a hint, > Helmut > so you are using a driver meant for stable (old) systems, with a pre release kernel - and you don't even know what do do with that message? Does that do no seem a bit silly? hm? acpi_bus_get_device is gpl only. You can undo that. If you want. But seriously, what is wrong with using stable releases like 3.10.x? If you use ati-drivers, you don't need the amd driver improvements in 3.11 or 3.12.
Re: [gentoo-user] which filesystem is more suitable for /var/tmp/portage?
Am 03.10.2013 11:55, schrieb Kerin Millar: > On 18/09/2013 16:09, Alan McKinnon wrote: >> On 18/09/2013 16:05, Peter Humphrey wrote: >>> On Wednesday 18 Sep 2013 14:52:30 Ralf Ramsauer wrote: >>> In my opinion, reiser is a bit outdated ... >>> >>> What is the significance of its date? I use reiserfs on my Atom box >>> for /var, >>> /var/cache/squid and /usr/portage, and on my workstation for >>> /usr/portage and >>> /home/prh/.VirtualBox. It's never given me any trouble at all. >> >> >> Sooner or later, reiser is going to bitrot. The ReiserFS code itself >> will not change, but everything around it and what it plugs into will >> change. When that happens (not if - when), there is no-one to fix the >> bug and you will find yourself up the creek sans paddle >> >> An FS is not like a widget set, you can't really live with and >> workaround any defects that develop. When an FS needs patching, it needs >> patching, no ifs and buts. Reiser may nominally have a maintainer but in >> real terms there is effectively no-one >> >> Circumstances have caused ReiserFS to become a high-risk scenario and >> even though it might perform faultlessly right now, continued use should >> be evaluated in terms of that very real risk. > > Another problem with ReiserFS is its intrinsic dependency on the BKL > (big kernel lock). Aside from hampering scalability, it necessitated > compromise when the time came to eliminate the BKL: and that one was solved when - 4-5 years ago? > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8ebc423 > > > Note the performance loss introduced by the patch; whether that was > addressed I do not know. > > In my view, ReiserFS is only useful for saving space through tail > packing. Unfortunately, tail packing makes it slower still (an issue > that was supposed to be resolved for good in Reiser4). > why don't you mention that reiserfs used barriers by default - and ext3 did not. Just to look good at 'using defaults benchmarks' (like phoronix)? I mean, if we are digging around in history and btrfs is still broken in my regards... tmpfs is the filesystem of choice for /tmp or /var/tmp/portage.
Re: PORTDIR default - changing PORTDIR variable - WAS Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
Am 03.10.2013 11:00, schrieb Yuri K. Shatroff: > I apologize but I always thought that it's Linux that derives from > AT&T SysV (1983), while FreeBSD derives from ... BSD (1978). How come > then Linux uses SysV init and BSD does not? ;) no, no and no.
Re: [gentoo-user] which filesystem is more suitable for /var/tmp/portage?
Am 03.10.2013 18:32, schrieb Kerin Millar: > On 03/10/2013 13:08, Volker Armin Hemmann wrote: >> Am 03.10.2013 11:55, schrieb Kerin Millar: >>> On 18/09/2013 16:09, Alan McKinnon wrote: >>>> On 18/09/2013 16:05, Peter Humphrey wrote: >>>>> On Wednesday 18 Sep 2013 14:52:30 Ralf Ramsauer wrote: >>>>> >>>>>> In my opinion, reiser is a bit outdated ... >>>>> >>>>> What is the significance of its date? I use reiserfs on my Atom box >>>>> for /var, >>>>> /var/cache/squid and /usr/portage, and on my workstation for >>>>> /usr/portage and >>>>> /home/prh/.VirtualBox. It's never given me any trouble at all. >>>> >>>> >>>> Sooner or later, reiser is going to bitrot. The ReiserFS code itself >>>> will not change, but everything around it and what it plugs into will >>>> change. When that happens (not if - when), there is no-one to fix the >>>> bug and you will find yourself up the creek sans paddle >>>> >>>> An FS is not like a widget set, you can't really live with and >>>> workaround any defects that develop. When an FS needs patching, it >>>> needs >>>> patching, no ifs and buts. Reiser may nominally have a maintainer >>>> but in >>>> real terms there is effectively no-one >>>> >>>> Circumstances have caused ReiserFS to become a high-risk scenario and >>>> even though it might perform faultlessly right now, continued use >>>> should >>>> be evaluated in terms of that very real risk. >>> >>> Another problem with ReiserFS is its intrinsic dependency on the BKL >>> (big kernel lock). Aside from hampering scalability, it necessitated >>> compromise when the time came to eliminate the BKL: >> >> and that one was solved when - 4-5 years ago? > > Consider the manner in which the hard requirement on the BKL was > removed, then objectively argue that its "deep use of the specific > properties of the BKL" did not necessitate what would quite reasonably > be described as a compromise. > >> >>> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8ebc423 >>> >>> >>> >>> Note the performance loss introduced by the patch; whether that was >>> addressed I do not know. >>> >>> In my view, ReiserFS is only useful for saving space through tail >>> packing. Unfortunately, tail packing makes it slower still (an issue >>> that was supposed to be resolved for good in Reiser4). >>> >> >> why don't you mention that reiserfs used barriers by default - and ext3 >> did not. Just to look good at 'using defaults benchmarks' (like >> phoronix)? I mean, if we are digging around in history and btrfs is >> still broken in my regards... > > Because none of this passive aggressive rhetoric would have had any > meaningful context within the content of my previous post. while your message had no meaningful context within this thread at all. Oh look, there was a data eating bug in XFS X years ago. Or oh look, some very heavy patching was done in ext4 over the time are just as meaning- and helpful as your message: not at all.
Re: [gentoo-user] s6 et al
Am 04.10.2013 00:32, schrieb Walter Dnes: > On Wed, Oct 02, 2013 at 12:04:24AM -0500, Bruce Hill wrote >> Just stumbled across some very interesting software/ideas: >> >> http://skarnet.org/poweredby.html > Out of sheer curiousity, what common software would break under > uclibc? My first gues would be stuff like Schlockwave/Trash and Nvidia > binary blobs... i.e. any binary file that has been complied against > glibc, which we do not have the sources to re-compile. Other than that, > it might be fun to build a "Gentoo lite" based on uclibc and busybox. > https://wiki.gentoo.org/wiki/Project:Hardened_uClibc https://wiki.gentoo.org/wiki/Project:Hardened_uClibc/Lilblue
Re: [gentoo-user] Mantle Open source GPU engine
Am 04.10.2013 22:53, schrieb Bruce Hill: > On Fri, Oct 04, 2013 at 09:20:43PM +0200, Alan McKinnon wrote: >>> computer gaming (yawn)... >> >> Think again. >> >> What is the driving force behind all the super-duper performance >> hardware you have right now? >> >> Gaming. >> >> What is the GPU capable of achieving when parallelized? Well, graphics >> rendering is highly parallelizable and nowadays you see it in render >> farms and Top500 supercomputers. But those didn;t fund it, so what did? >> >> Graphics cards sold to gamers. >> >> Graphics cards for gamers are probably the only thing left really >> keeping the pc market as such going. Yes, there are still millions of >> them on corporate desktops but that is a cut-throat market and at >> what-tiny-number-of-bucks a pop? Bread and butter money, it keeps things >> ticking over and pays the rent. But gamers pay for the bling. >> >> Almost ever awesome performance gain in the last 10 years at least that >> you see in commercial products were driven in whole or in part by the >> primary high performance market - gamers. >> >> Personally, I don't like games much and don't play them much. OK, I >> don't play them at all. But the market they make up - that's different. >> Those egg-heads are very important > See previous reply in thread to James. This one was not threaded, but rather, > a reply to the OP, so it makes it look as if you haven't read the thread. > > I played one computer game one day in 1990. Lost that entire day to that > stupid game, and never played again. Except...one time for a few hours with a > new friend the second year living in China. He wanted me to play NFS. After > playing a few races with him, I explained that we do this with _real_cars_ on > _real_roads_ in _real_life_ "back in America". It developed from the days of > moonshining, and your car (and you as a driver) weren't anything if you > couldn't outrun the local cops. ;) what, with your stupid 55mph speed limit?
Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
Am 08.10.2013 02:03, schrieb walt: > On 09/29/2013 04:58 AM, Volker Armin Hemmann wrote: > >> As much as I hate systemd > My Alzheimer's prevents me from remembering your reasons for hating systemd. > Would you *very* briefly refresh my memory, please? > > > simple: one tool to do one job. text output to pipe into other tools. Small is better. systemd violates all of them. Also: dishonesty.
Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?
Am 09.10.2013 21:17, schrieb Stefan G. Weichinger: > Am 09.10.2013 20:20, schrieb Nicolas Sebrecht: > >> I would think about a kernel bug first and try with a much lower >> version. > Yep. A bit scary with a server which is hundreds of kilometers away. > > Got to get that HP IlO-thingy going in my browser(s) ... > > S > > > go with that dmesg, lspci, kernel config etc pp to lkml. Seriously.
Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
Am 10.10.2013 16:46, schrieb William Hubbs: > On Wed, Oct 09, 2013 at 05:24:39PM -0700, walt wrote: >> On 10/08/2013 09:16 PM, William Hubbs wrote: >> >>> to provide service supervision, which is the main >>> feature systemd offers >> By supervision do you mean restarting a service after it crashes, for >> example? > Right. This is one of the more significant features that OpenRC doesn't > have yet. > > William why? 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. The rest is so visible (or audible - like fancontrol) that you know that there is a problem.
Re: [gentoo-user] OT: PowerColor HD 7850 SCS3 silent
Am 10.10.2013 21:10, schrieb James: > Hello, > > Well, I'm trying to reseach a 7850 slilent the silent > video card on an Gentoo based GA-99FXA-UD3 mobo. > > I've had Asus Radeons HD 7750 in these mobo, and it > is an outstanding bargain workstation. > > The PowerColor HD 7850 SCS3 seems to be getting really good > reviews, for the cost. I think it now comes in a 2 GB > of memory. This card says it is PCI-3.0 compliant. > I cannot find if the mobo I have (GA-99FXA-UD3) has > PCI 3 (16) ? that does not matter in any way. > > Will the card work anyway? Or should I wait until I get > a PCI 3.0 based mobo? it will work. pcie is compatible between revisions. btw, it is PCIE not PCI. Completely different thing.
