[gentoo-user] Why is depclean trying to remove python-3.4.1?
I have selected python 3.4 set with eselect: eselect python list Available Python interpreters: [1] python2.7 [2] python3.3 [3] python3.4 * This is what I have installed: eix -l dev-lang/python [I] dev-lang/python Available versions: (2.7) 2.7.7 [-berkdb build doc examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk +wide-unicode wininst +xml ELIBC=uclibc] ~2.7.8 [-berkdb build doc examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk +wide-unicode wininst +xml ELIBC=uclibc] (3.2) 3.2.5-r6[build doc examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk +wide-unicode wininst +xml ELIBC=uclibc] (3.3) 3.3.5-r1[build doc examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk wininst +xml ELIBC=uclibc] (3.4) ~3.4.0 [build examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk wininst +xml ELIBC=uclibc] 3.4.1 [build examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk wininst +xml ELIBC=uclibc] ~3.4.2 [build examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk wininst +xml ELIBC=uclibc] Installed versions: 2.7.7(2.7)(08:57:14 08/22/14)(gdbm ipv6 ncurses readline sqlite ssl threads wide-unicode xml -berkdb -build -doc -examples - hardened -tk -wininst ELIBC=-uclibc) 3.3.5-r1(3.3)(09:00:09 08/22/14)(gdbm ipv6 ncurses readline sqlite ssl threads xml -build -doc -examples -hardened -tk -wininst ELIBC=-uclibc) 3.4.1(3.4)(00:44:46 10/14/14)(gdbm ipv6 ncurses readline sqlite ssl threads xml -build -examples -hardened -tk -wininst ELIBC=-uclibc) Homepage:http://www.python.org/ Description: An interpreted, interactive, object-oriented programming language Why does depclean want to remove python-3.4.1? These are the packages that would be unmerged: dev-lang/python selected: 3.4.1 protected: none omitted: 2.7.7 3.3.5-r1 All selected packages: =dev-lang/python-3.4.1 'Selected' packages are slated for removal. 'Protected' and 'omitted' packages will not be removed. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Why is depclean trying to remove python-3.4.1?
On 12/05/2014 04:23 AM, Mick wrote: I have selected python 3.4 set with eselect: eselect python list Available Python interpreters: [1] python2.7 [2] python3.3 [3] python3.4 * afaik eselect means nothing to portage's dependency solver. This is what I have installed: eix -l dev-lang/python [I] dev-lang/python Available versions: (2.7) 2.7.7 [-berkdb build doc examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk +wide-unicode wininst +xml ELIBC=uclibc] ~2.7.8 [-berkdb build doc examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk +wide-unicode wininst +xml ELIBC=uclibc] (3.2) 3.2.5-r6 [build doc examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk +wide-unicode wininst +xml ELIBC=uclibc] (3.3) 3.3.5-r1 [build doc examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk wininst +xml ELIBC=uclibc] (3.4) ~3.4.0 [build examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk wininst +xml ELIBC=uclibc] 3.4.1 [build examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk wininst +xml ELIBC=uclibc] ~3.4.2 [build examples gdbm hardened ipv6 +ncurses +readline sqlite +ssl +threads tk wininst +xml ELIBC=uclibc] Installed versions: 2.7.7(2.7)(08:57:14 08/22/14)(gdbm ipv6 ncurses readline sqlite ssl threads wide-unicode xml -berkdb -build -doc -examples - hardened -tk -wininst ELIBC=-uclibc) 3.3.5-r1(3.3)(09:00:09 08/22/14)(gdbm ipv6 ncurses readline sqlite ssl threads xml -build -doc -examples -hardened -tk -wininst ELIBC=-uclibc) 3.4.1(3.4)(00:44:46 10/14/14)(gdbm ipv6 ncurses readline sqlite ssl threads xml -build -examples -hardened -tk -wininst ELIBC=-uclibc) Homepage:http://www.python.org/ Description: An interpreted, interactive, object-oriented programming language Why does depclean want to remove python-3.4.1? These are the packages that would be unmerged: dev-lang/python selected: 3.4.1 protected: none omitted: 2.7.7 3.3.5-r1 All selected packages: =dev-lang/python-3.4.1 'Selected' packages are slated for removal. 'Protected' and 'omitted' packages will not be removed. A couple things: * Do you have python3_4 in PYTHON_TARGETS? * Do you have dev-lang/python:3.4 in @world? Basically, if you haven't explicitly let portage know you want python 3.4, it will be depcleaned. Alec
Re: [gentoo-user] Why is depclean trying to remove python-3.4.1?
On Friday 05 Dec 2014 09:27:49 Alec Ten Harmsel wrote: On 12/05/2014 04:23 AM, Mick wrote: I have selected python 3.4 set with eselect: eselect python list Available Python interpreters: [1] python2.7 [2] python3.3 [3] python3.4 * afaik eselect means nothing to portage's dependency solver. Oh! I hadn't understood this correctly. A couple things: * Do you have python3_4 in PYTHON_TARGETS? * Do you have dev-lang/python:3.4 in @world? Basically, if you haven't explicitly let portage know you want python 3.4, it will be depcleaned. I don't have python in world, because it is always installed as a dependency. However, I just noticed this in 'emerge --info': PYTHON_SINGLE_TARGET=python2_7 PYTHON_TARGETS=python2_7 python3_3 Hmm ... if I don't have PYTHON_TARGETS in my make.conf, where else is this being set? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Why is depclean trying to remove python-3.4.1?
On 12/05/2014 06:37 AM, Mick wrote: I don't have python in world, because it is always installed as a dependency. However, I just noticed this in 'emerge --info': PYTHON_SINGLE_TARGET=python2_7 PYTHON_TARGETS=python2_7 python3_3 Hmm ... if I don't have PYTHON_TARGETS in my make.conf, where else is this being set? PYTHON_TARGETS is set to python2_7 python3_3 in the system profile (portage being written in python naturally requires a system dependency on Python). Unless you need a specific version of Python, I personally would just leave it to the system profile, as it will be updated automatically when necessary (I think python3_3 - python3_4 will be solid in a few months). Also, 3.4 probably got installed because the python3_3 - python3_4 transition was actually committed for a day or two until loads of issues became apparent and this transition was reverted. iirc the revert was not because porting from python3.3 to python3.4 is difficult, just due to ebuilds not specifying python3_4 as supported, which is why I imagine this will be solid in a few months. Alec
Re: [gentoo-user] Why is depclean trying to remove python-3.4.1?
On Friday 05 Dec 2014 11:48:08 Alec Ten Harmsel wrote: On 12/05/2014 06:37 AM, Mick wrote: I don't have python in world, because it is always installed as a dependency. However, I just noticed this in 'emerge --info': PYTHON_SINGLE_TARGET=python2_7 PYTHON_TARGETS=python2_7 python3_3 Hmm ... if I don't have PYTHON_TARGETS in my make.conf, where else is this being set? PYTHON_TARGETS is set to python2_7 python3_3 in the system profile (portage being written in python naturally requires a system dependency on Python). Unless you need a specific version of Python, I personally would just leave it to the system profile, as it will be updated automatically when necessary (I think python3_3 - python3_4 will be solid in a few months). Also, 3.4 probably got installed because the python3_3 - python3_4 transition was actually committed for a day or two until loads of issues became apparent and this transition was reverted. iirc the revert was not because porting from python3.3 to python3.4 is difficult, just due to ebuilds not specifying python3_4 as supported, which is why I imagine this will be solid in a few months. OK got it, thanks! -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: automated code validation
Alec Ten Harmsel alec at alectenharmsel.com writes: I have time next semester, I'll look into it Repoman false-alarms is another potential issue with this. Repoman can be improved ;) Repoman is already run nightly, I just don't think Gentoo has the manpower to deal with that stuff. Fantastic, GSoc for Alec with Rich mentoring! I bet our friends at RackSpace will provide all the virtual HorsePower you need, should google not provide the hundreds/thousands or cores for you to run on. With the evolving etest tool in hand, I'm sure I can put together a very large pile of ebuilds that need parsing? James
Re: [gentoo-user] Re: automated code validation
On Fri, Dec 5, 2014 at 9:05 AM, James wirel...@tampabay.rr.com wrote: Alec Ten Harmsel alec at alectenharmsel.com writes: I have time next semester, I'll look into it Repoman false-alarms is another potential issue with this. Repoman can be improved ;) Repoman is already run nightly, I just don't think Gentoo has the manpower to deal with that stuff. Fantastic, GSoc for Alec with Rich mentoring! I bet our friends at RackSpace will provide all the virtual HorsePower you need, should google not provide the hundreds/thousands or cores for you to run on. With the evolving etest tool in hand, I'm sure I can put together a very large pile of ebuilds that need parsing? My guess is that the hardware to run all this on is the simplest part of the problem. If somebody writes something good and we build the processes to support it, then I'm sure we can find donors to provide the CPU cycles. ChromeOS could probably steal whatever we put together so there is an obvious synergy there, and I'm sure Amazon/Rackspace/etc are always looking for use cases to show off. From past feedback from Diego and such the biggest issue with any kind of tinderbox is dealing with the output. As has been pointed out there are folks running Repoman regularly already, and there have been past tinderbox efforts. The real issue is to improve the signal/noise ratio. You'll only get so far with that using code - there has to be process change to support it. If we were to do something like this long-term I'd envision that this would run on every commit or something like that, and the commit doesn't go into the rsync tree until it passes. If the tree goes red then people stop doing commits until it is fixed, and somebody gets their wrist slapped. That is my sense of how most mature organizations do CI. The tinderbox is really just doing verification - stuff should already be tested BEFORE it goes in the tree. There also shouldn't be any false positives. There would need to be a mechanism to flag ebuilds with known issues so that the tinderbox can ignore them, and of course we can monitor that to ensure it isn't abused. Basically doing this sort of thing right requires a big change in mindset. You can't just throw stuff at the tree and wait for the bug reports to come in. You can't just make dealing with the tinderbox the problem of the poor guy running the tinderbox. The tinderbox basically has to become the boss and everybody has to make part of their job keeping the boss happy. Then you have to throw in uncooperative upstreams. If you ARE the upstream then you can apply these practices yourself and have a build system that outputs zero warnings and all that. We're dealing with what we get, so we're going to have to set the bar considerably lower if we don't want to exclude anything from the tree which has a lousy build system. In any case, focus first on decent code with proposed procedures that help deal with the output. Don't go spending a lot of money on hardware or worrying about setting up clusters and all that. Of course, if you want to run stuff in parallel that is something you can design in from the start (and there is no reason you can't run it in a few VMs on your laptop - it will be slow but the focus is on ensuring that it works, not that it is fast). In the past I've seen lots of people focus on building empires with dreams of hardware and all that, and they end up with little in the way of donations and if they do buy hardware they end up with nothing to run on it. Write the code first and get it working at small scale. If you write the code, the hardware will probably take care of itself. People care about Gentoo, but they're not going to throw lots of equipment at somebody who has little more than an email chain to show up-front, and I doubt the Foundation is going to want to buy hardware before the code exists. The code will be hard. The culture change will be harder. The hardware will be easy. Bottom line - this sort of thing is a lot harder to pull off than it might first appear. I don't want to discourage anybody, but don't think that you can toss together a few lines in bash to do an emerge -e world and you're done. Of course, if you do want to do a manual run like this and manually submit bugs that have been manually screened for validity, that is always welcome. -- Rich
[gentoo-user] Re: hibernation
Marc Stürmer mail at marc-stuermer.de writes: The sad thing about hibernation is, that it has always kinda been some kind of lackluster in the kernel and quite disappointing. It is a kind of area which does not get much love in the kernel for at least over one decade. So if you want to get this working reliable, good luck. You'll need it. Hibernation depends on a myriad of CPU variants, setting and the matching memory issues. (U)efi is a good place to start your long, arduous journey of research [1] ; see S4. I would research the problem and fix it with winblows as the operating system, if possible; then hope that those setting are not changed by booting linux. Often you can copy the bios setting from the laptop and find tools to at least view the contents legibly. It does depend on the bios. Maybe you need a vendor supplied bios update/downgrade. Maybe Coreboot, has some old work laying around that is relevant to your needs [2]. It is mostly a research journey, that may lead to success or failure. Hard to say, as sometimes the same make and model of a laptop, has diffent internal components (like firmware, bios and chips)... Good hunting! James [1] http://technet.microsoft.com/en-us/library/dn387089.aspx [2] http://www.coreboot.org/Laptop
Re: [gentoo-user] samba and window 7 NTFS
On Dec 4, 2014, at 22:21, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 04 Dec 2014 19:15:07 +, thegeezer wrote: In order to format the USB stick to NTFS I need this option in kernel as well, am I correct? yes You're probably better off not using the in-kernel NTFS and using ntfs-3g instead, which also includes mkfs.ntfs. You can't format a filesystem with just a kernel driver. Same opinoin here. The in-kernel driver is only good for reading files and directories. If anything else is needed use ntfs3g. -- -Matti
[gentoo-user] Re: automated code validation
Rich Freeman rich0 at gentoo.org writes: My guess is that the hardware to run all this on is the simplest part of the problem. If somebody writes something good and we build the processes to support it, then I'm sure we can find donors to provide the CPU cycles. ChromeOS could probably steal whatever we put together so there is an obvious synergy there, and I'm sure Amazon/Rackspace/etc are always looking for use cases to show off. Um, it was a bit of humor ,on a serious topic, which I support. From past feedback from Diego and such the biggest issue with any kind of tinderbox is dealing with the output. As has been pointed out there are folks running Repoman regularly already, and there have been past tinderbox efforts. The real issue is to improve the signal/noise ratio. You'll only get so far with that using code - there has to be process change to support it. Sound like you have the issues well conceptualized? If we were to do something like this long-term I'd envision that this would run on every commit or something like that, and the commit doesn't go into the rsync tree until it passes. If the tree goes red then people stop doing commits until it is fixed, and somebody gets their wrist slapped. That is my sense of how most mature organizations do CI. The tinderbox is really just doing verification - stuff should already be tested BEFORE it goes in the tree. There also shouldn't be any false positives. There would need to be a mechanism to flag ebuilds with known issues so that the tinderbox can ignore them, and of course we can monitor that to ensure it isn't abused. Are we talking about a database of know failures? Over time the database would grow quite large, but be very useful? Basically doing this sort of thing right requires a big change in mindset. You can't just throw stuff at the tree and wait for the bug reports to come in. You can't just make dealing with the tinderbox the problem of the poor guy running the tinderbox. The tinderbox basically has to become the boss and everybody has to make part of their job keeping the boss happy. Ah, yes; leadership is a fleeting quality. It always has been and always will be. fleeting Then you have to throw in uncooperative upstreams. If you ARE the upstream then you can apply these practices yourself and have a build system that outputs zero warnings and all that. We're dealing with what we get, so we're going to have to set the bar considerably lower if we don't want to exclude anything from the tree which has a lousy build system. POINT very well acknowledged. Perhaps if we build something that ordinary coders can use and some folks with resources help those upstream application developers, then a few will participate with us? This is a huge problem for the scientific community. Because just because a large, complicated algorithm runs, does not mean it is correct or robust. They need tools built upon what your are designing for first the admins and the secondly for the upstream code developers. Once something is built for quality code check, and it is reasonable simple to depoly, I think at the very least many users of those codes will run these tools on open source code projects. Yes this is a huge effort, that is sorely needed, imho. We are all in this together. In any case, focus first on decent code with proposed procedures that help deal with the output. Don't go spending a lot of money on hardware or worrying about setting up clusters and all that. Of course, if you want to run stuff in parallel that is something you can design in from the start (and there is no reason you can't run it in a few VMs on your laptop - it will be slow but the focus is on ensuring that it works, not that it is fast). I totally agree. With excellent leadership, you can keep the secondaries like me, in-line. We do need a specification to begin with. Sure it will evolve, but specs help keep focus and priortize what tools get worked on and when, imho. In the past I've seen lots of people focus on building empires with dreams of hardware and all that, and they end up with little in the way of donations and if they do buy hardware they end up with nothing to run on it. Write the code first and get it working at small scale. If you write the code, the hardware will probably take care of itself. People care about Gentoo, but they're not going to throw lots of equipment at somebody who has little more than an email chain to show up-front, and I doubt the Foundation is going to want to buy hardware before the code exists. Easy on the coffee. Now you are jumping to too many conclusions. I agree well need lots of thinking, planning and an overall robust architecture design and lots of code. Hardware never is a problem, us EE's are always way out front of the CS folk, imho.. And yes, let's get coding...Um what's my homework assignment this week? The code will be
[gentoo-user] urxvt on i3wm as wallpaper
Hello everyone. I was wondering that is it possible to have urxvt (or another terminal) on a portion of background? I used the override-redirect option but it didnt work properly. Have anyone tried this? thanks.
[gentoo-user] Openrc-run
I find references to man openrc and man 8 openrc-run. 'man openrc' nor 'man 8 openrc-run' return anything. I have version 0.12.4 on my system. I have neither of these locally installed, and I am not sure why? Does upgrade to openrc-0.13.6 fix this? Is it advisable (how stable/useful is openrc-0.13.6) ? I did find this: https://github.com/OpenRC/openrc/blob/master/man/openrc-run.8 Is there some github thingy-trick I need to read this as a logically formated doc? TIA, James
Re: [gentoo-user] Openrc-run
On 12/05/2014 01:34 PM, James wrote: I find references to man openrc and man 8 openrc-run. 'man openrc' nor 'man 8 openrc-run' return anything. Curiosity piqued: commit 3470eda3f5cea437a6de132b1ead3f27effd3902 Author: William Hubbs w.d.hu...@gmail.com Date: Sat Dec 21 14:51:11 2013 -0600 Rename runscript to openrc-run This was requested by Debian, because the minicom software, which is available on Debian and other distros, has a binary named runscript. We are keeping a backward compatibility symlink for now, but this allows Debian or any other distro to safely remove the symlink. X-Gentoo-Bug: 494220 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=494220 commit 7b5fa011ac7a9544fe68a9abb2f8ef940d9845f7 Author: William Hubbs w.d.hu...@gmail.com Date: Wed Dec 11 17:39:38 2013 -0600 Rename the rc binary to openrc Debian requested this rename due to the rc binary conflicting with the rc binary from the plan 9 shell. We also add a deprecation warning to the binary when it is run as rc to encourage users to switch to openrc instead. X-Gentoo-Bug: 493958 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=493958 So, the reason you can't find their man pages is because they don't exist yet. Try `man 8 rc` or `man 8 runscript` instead. If you ever need to read a man page that isn't installed, you can give the path to it locally. So if you clone that repo, you can do: $ man ./man/openrc-run.8 to read it.
Re: [gentoo-user] samba and window 7 NTFS
On Friday 05 Dec 2014 16:11:26 Matti Nykyri wrote: On Dec 4, 2014, at 22:21, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 04 Dec 2014 19:15:07 +, thegeezer wrote: In order to format the USB stick to NTFS I need this option in kernel as well, am I correct? yes You're probably better off not using the in-kernel NTFS and using ntfs-3g instead, which also includes mkfs.ntfs. You can't format a filesystem with just a kernel driver. Same opinoin here. The in-kernel driver is only good for reading files and directories. If anything else is needed use ntfs3g. This is right, ntfs-3g is a safe way of accessing NTFS from Linux. Just mentioned in passing that the ntfs in-kernel driver is really good for recovering corrupted NTFS partitions. I tried the same with ntfs-3g and it couldn't read it. The kernel driver had no problem doing so. YMMV. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] urxvt on i3wm as wallpaper
behrouz khosravi bz.khosr...@gmail.com writes: Hello everyone. I was wondering that is it possible to have urxvt (or another terminal) on a portion of background? I used the override-redirect option but it didnt work properly. Have anyone tried this? thanks. Omit the window decorations? -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
[gentoo-user] How to find out to what file(...) writes goes on a idle system...
Hi, on different systems I see the write stats (/proc/dikstats) to physical existing disks steadily increasing. Looking at the output of lsof I cannot find any file suspicous for receiving those writes. In the context of preserving the live of flash media by minimizing the count of unessary writes I want to know which application/daemon/etc is continous writing to that media and which entity (file/pipe/fifo...) is receiving those writes... How can I find that information? Thank you very much in advance for any help! Best regards, Meino
Re: [gentoo-user] hibernation
On Thursday, December 04, 2014 07:52:44 PM J. Roeleveld wrote: On 4 December 2014 18:32:16 CET, Michael Vetter michael.vetter@uni- konstanz.de wrote: Am 04/12/14 18:10, schrieb Randolph Maaßen: 2014-12-04 17:58 GMT+01:00 Michael Vetter michael.vet...@uni-konstanz.de: Did you try suspending using the echo command I mentioned earlier? Yes, it seemed to work (just starting up again didn't). You can set the resume partition in the kernel. Might be an option. Okay, so I changed my kernel command string from root=/dev/sdb2 to root=/dev/sdb2,resume=/dev/mapper/g-SWAP. In my menuconfig I have a space separated list, not comma separated. So I guess the boot failure is, that the kernel can't find the root partition /dev/sdb2,resume... Okay, sorry thought this is equivalent to [1]. Anyways, I changed it to space and my system boots now. So I tried the suspend command again, but when rebooting its like a fresh reboot. Any ideas? [1] http://man7.org/linux/man-pages/man7/bootparam.7.html Yes. If using LVM for the swap partition (and subsequently the resume) you need to use an initramfs. I will dig out the script I use on my laptop and post it tomorrow. (It boots faster with a custom script compared to the genkernel or dracut ones) Bit later then planned. The init file is the initramfs init-file. The config is what I configure in the kernel: $ zcat /proc/config.gz | grep initramfs CONFIG_INITRAMFS_SOURCE=/usr/src/initramfs/config There are a few changes you'll need to do: 1) In the init file, change the name of the swap-partition you use 2) In the config file, change the following paths: - init-file 3) In the config file, run the command mentioned at the end of the file and add the result of the command to the end of the config file. I have been using this config succesfully for over a year on my laptop. -- Joost # vim: set ft=initramfs : # init script file /init /usr/src/initramfs/init 0755 0 0 # basic device nodes dir /dev 0755 0 0 nod /dev/console 0600 0 0 c 5 1 # mount point for our real root dir /root 0700 0 0 dir /lib 0755 0 0 dir /etc 755 0 0 # utilities needed to do anything useful dir /bin 0755 0 0 dir /sbin 0755 0 0 dir /usr 755 0 0 dir /usr/lib 755 0 0 dir /usr/sbin 755 0 0 dir /usr/bin 755 0 0 dir /lib64 755 0 0 dir /usr/lib64 755 0 0 file /bin/busybox /bin/busybox 0755 0 0 # some busybox symlinks slink /bin/dd busybox 777 0 0 slink /bin/cp busybox 777 0 0 slink /bin/df busybox 777 0 0 slink /bin/ln busybox 777 0 0 slink /bin/ls busybox 777 0 0 slink /bin/mv busybox 777 0 0 slink /bin/ps busybox 777 0 0 slink /bin/rm busybox 777 0 0 slink /bin/sh busybox 777 0 0 slink /bin/vi busybox 777 0 0 slink /bin/ash busybox 777 0 0 slink /bin/cat busybox 777 0 0 slink /bin/pwd busybox 777 0 0 slink /bin/sed busybox 777 0 0 slink /bin/tar busybox 777 0 0 slink /bin/date busybox 777 0 0 slink /bin/echo busybox 777 0 0 slink /bin/grep busybox 777 0 0 slink /bin/gzip busybox 777 0 0 slink /bin/kill busybox 777 0 0 slink /bin/more busybox 777 0 0 slink /bin/ping busybox 777 0 0 slink /bin/sync busybox 777 0 0 slink /bin/true busybox 777 0 0 slink /bin/zcat busybox 777 0 0 slink /bin/chgrp busybox 777 0 0 slink /bin/chmod busybox 777 0 0 slink /bin/chown busybox 777 0 0 slink /bin/dmesg busybox 777 0 0 slink /bin/egrep busybox 777 0 0 slink /bin/false busybox 777 0 0 slink /bin/fgrep busybox 777 0 0 slink /bin/mkdir busybox 777 0 0 slink /bin/mknod busybox 777 0 0 slink /bin/mount busybox 777 0 0 slink /bin/pidof busybox 777 0 0 slink /bin/rmdir busybox 777 0 0 slink /bin/sleep busybox 777 0 0 slink /bin/touch busybox 777 0 0 slink /bin/uname busybox 777 0 0 slink /bin/gunzip busybox 777 0 0 slink /bin/hostname busybox 777 0 0 slink /bin/mktemp busybox 777 0 0 slink /bin/umount busybox 777 0 0 slink /bin/usleep busybox 777 0 0 slink /usr/bin/[ ../../bin/busybox 777 0 0 slink /usr/bin/du ../../bin/busybox 777 0 0 slink /usr/bin/id ../../bin/busybox 777 0 0 slink /usr/bin/tr ../../bin/busybox 777 0 0 slink /usr/bin/wc ../../bin/busybox 777 0 0 slink /usr/bin/cmp ../../bin/busybox 777 0 0 slink /usr/bin/cut ../../bin/busybox 777 0 0 slink /usr/bin/env ../../bin/busybox 777 0 0 slink /usr/bin/tee ../../bin/busybox 777 0 0 slink /usr/bin/tty ../../bin/busybox 777 0 0 slink /usr/bin/yes ../../bin/busybox 777 0 0 slink /usr/bin/chvt ../../bin/busybox 777 0 0 slink /usr/bin/find ../../bin/busybox 777 0 0 slink /usr/bin/expr ../../bin/busybox 777 0 0 slink /usr/bin/free ../../bin/busybox 777 0 0 slink /usr/bin/head ../../bin/busybox 777 0 0 slink /usr/bin/deallocvt ../../bin/busybox 777 0 0 slink /usr/bin/tail ../../bin/busybox 777 0 0 slink /usr/bin/sort ../../bin/busybox 777 0 0 slink /usr/bin/test ../../bin/busybox 777 0 0 slink /usr/bin/time ../../bin/busybox 777 0 0 slink /usr/bin/uniq ../../bin/busybox 777 0 0 slink /usr/bin/wget ../../bin/busybox 777 0 0 slink /usr/bin/dirname ../../bin/busybox 777 0 0 slink /usr/bin/killall ../../bin/busybox 777 0
Re: [gentoo-user] Re: hibernation
On Friday, December 05, 2014 03:08:25 PM James wrote: Marc Stürmer mail at marc-stuermer.de writes: The sad thing about hibernation is, that it has always kinda been some kind of lackluster in the kernel and quite disappointing. It is a kind of area which does not get much love in the kernel for at least over one decade. So if you want to get this working reliable, good luck. You'll need it. Hibernation depends on a myriad of CPU variants, setting and the matching memory issues. (U)efi is a good place to start your long, arduous journey of research [1] ; see S4. Not my experience, suspend-to-disk works quite well. The biggest issue was with certain drivers not being able to re-initialize certain hardware. (Yes, I am talking about the likes of Nvidia) With current kernels, it does work though. I would research the problem and fix it with winblows as the operating system, if possible; then hope that those setting are not changed by booting linux. Often you can copy the bios setting from the laptop and find tools to at least view the contents legibly. It does depend on the bios. Maybe you need a vendor supplied bios update/downgrade. Maybe Coreboot, has some old work laying around that is relevant to your needs [2]. It is mostly a research journey, that may lead to success or failure. Hard to say, as sometimes the same make and model of a laptop, has diffent internal components (like firmware, bios and chips)... For suspend-to-ram, I agree. Suspend-to-disk can be handled by the OS. -- Joost
