Re: [gentoo-user] Is the ebuild for dhcpcd wrong
On Tue, Oct 22, 2013 at 9:24 AM, Alan McKinnon wrote: > On 22/10/2013 13:37, Chris Allison wrote: >> Hello, >> >> when emerging dhcpcd it attempts to retrieve the source from >> /distfiles/... >> looking at the mirror the file is actually at >> /gentoo/distfiles/... >> >> Is this the correct place to bring this to your attention? >> >> regards >> >> Chris >> -- >> _ o , , >> / | | |_| / \_/ \_| | >> \__/ \/ \/ |/ \/ \/ \/|/ >> (| > > > > That mirror is set up wrong, contact the admins of the mirror you are > using. Proper mirrors work properly: > It is also possible that he has an incorrect URL in GENTOO_MIRRORS; not every gentoo mirror sticks distfiles in a top-level directory. For example: http://mirrors.rit.edu/gentoo/ This is listed on the gentoo mirrors page.
Re: [gentoo-user] Re: New mobo change
Edward M wrote: > On 10/22/2013 2:04 AM, Dale wrote: >> I started the UPS service that started this whole mess to see if it >> works. This is from messages: >> ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc >> 9 --> status -121 >> Oct 22 02:47:52 localhost kernel: [51257.891409] ohci_hcd >> :00:12.0: urb 8803ea >> Oct 22 02:47:50 localhost kernel: [51255.888492] 43f980 path 2 ep1in >> 9212 cc 9 --> status -121 >> Oct 22 02:47:54 localhost kernel: [51259.902338] ohci_hcd >> :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> >> status -121 >> Oct 22 02:47:56 localhost kernel: [51261.905256] ohci_hcd >> :00:12.0: urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> >> status -121 >> Oct 22 02:47:58 localhost kernel: [51263.916194] ohci_hcd >> :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc > > Hello, > >Those messages appear are coming from the ohci driver;I guess, > possibly a bug in the ohci-q.c file > Did those messages appear after an gentoo-sources upgrade? > Did you try booting into an older linux kernel version to see > if those messages appear? > > I been running 3.9.5 for a while but did try my old 3.5.3 version. That was with my old mobo but same situation. Same error. The biggest problem, I don't know when the error messages started. I sort of been busy and haven't checked the messages file in a while. I also tried a older version of nut just in case. Same thing. Thanks. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: New mobo change
On 10/22/2013 2:04 AM, Dale wrote: I started the UPS service that started this whole mess to see if it works. This is from messages: ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 Oct 22 02:47:52 localhost kernel: [51257.891409] ohci_hcd :00:12.0: urb 8803ea Oct 22 02:47:50 localhost kernel: [51255.888492] 43f980 path 2 ep1in 9212 cc 9 --> status -121 Oct 22 02:47:54 localhost kernel: [51259.902338] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 Oct 22 02:47:56 localhost kernel: [51261.905256] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 Oct 22 02:47:58 localhost kernel: [51263.916194] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc Hello, Those messages appear are coming from the ohci driver;I guess, possibly a bug in the ohci-q.c file Did those messages appear after an gentoo-sources upgrade? Did you try booting into an older linux kernel version to see if those messages appear?
Re: [gentoo-user] there are no ebuilds to satisfy "=x11-libs/gtk+-2.24.19".
Thank Bruce, My problem was that I was missing in make.conf PORTDIR_OVERLAY="/usr/local/portage" This solved my problem. -- Joseph On 10/22/13 11:32, Bruce Hill wrote: On Tue, Oct 22, 2013 at 09:36:46AM -0600, Joseph wrote: I'm tryint to emerge: gtk+-2.24.19 on one of my x86 but I'm getting: there are no ebuilds to satisfy "=x11-libs/gtk+-2.24.19". package.keywords has: =x11-libs/gtk+-2.24.19 ~x86 That version is no longer in portage: mingdao@baruch ~ $ eshowkw x11-libs/gtk+ Keywords for x11-libs/gtk+: | | u | | a a p s | n | | l m h i m m p s p | u s | r | p d a p a 6 i p c 3 a x | s l | e | h 6 r p 6 8 p p 6 9 s r 8 | e o | p | a 4 m a 4 k s c 4 0 h c 6 | d t | o ---+---+-+--- 1.2.10-r12 | + + + + + o ~ + + o + + + | o 1 | gentoo ---+---+-+--- 2.24.16 | o o o o o o o o o + o o o | o 2 | gentoo [I]2.24.17 | + + + + + o ~ + + o + + + | o | gentoo 2.24.22 | ~ ~ ~ ~ ~ o ~ ~ ~ o ~ ~ ~ | o | gentoo ---+---+-+--- [I]3.4.4 | + + + + + o ~ + + + + + + | o 3 | gentoo 3.6.3-r3 | ~ ~ + ~ ~ o ~ ~ ~ o ~ ~ ~ | o | gentoo 3.8.4 | ~ ~ ~ ~ ~ o ~ ~ ~ o ~ ~ ~ | # | gentoo 3.8.6 | ~ ~ ~ ~ ~ o ~ ~ ~ o ~ ~ ~ | o | gentoo By putting =category/package-atom in package.accept_keywords (not package.keywords) you have limited it to that one single version and unstable package. Also, you need not put ~arch in package.accept_keywords because that file will pull whatever the latest version is available for category/package. Try changing your "=x11-libs/gtk+-2.24.19 ~x86" to "x11-libs/gtk+" and emerge again. Or, because you appear to have two separate issues here... I've created manifest in: ebuild /usr/local/portage/x11-libs/gtk+/gtk+-2.24.19.ebuild manifest Appending /usr/local/portage to PORTDIR_OVERLAY... >>> Creating Manifest for /usr/local/portage/x11-libs/gtk+ Now, if you have created your own local overlay and ebuild, you need to also provide the source and needed patches for x11-libs/gtk+-2.24.19 -- Happy Penguin Computers >') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/
Re: [gentoo-user] Re: New mobo change
Bruce Hill wrote: > On Tue, Oct 22, 2013 at 04:04:21AM -0500, Dale wrote: >> Every once in a while, my brain actually comes up with something. ROFL >> >> Want to hear something equally funny? I started the UPS service that >> started this whole mess to see if it works. This is from messages: >> >> Oct 22 02:47:50 localhost kernel: [51255.888492] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 >> Oct 22 02:47:52 localhost kernel: [51257.891409] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 >> Oct 22 02:47:54 localhost kernel: [51259.902338] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 >> Oct 22 02:47:56 localhost kernel: [51261.905256] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 >> Oct 22 02:47:58 localhost kernel: [51263.916194] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 >> Oct 22 02:48:00 localhost kernel: [51265.919112] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 >> Oct 22 02:48:02 localhost kernel: [51267.930020] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 >> Oct 22 02:48:04 localhost kernel: [51269.932920] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 >> Oct 22 02:48:06 localhost kernel: [51271.943841] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 >> Oct 22 02:48:08 localhost kernel: [51273.946758] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 >> Oct 22 02:48:10 localhost kernel: [51275.949676] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 >> Oct 22 02:48:12 localhost kernel: [51277.960606] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 >> Oct 22 02:48:14 localhost kernel: [51279.963523] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 >> Oct 22 02:48:16 localhost kernel: [51281.974454] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 >> Oct 22 02:48:18 localhost kernel: [51283.977370] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 >> Oct 22 02:48:20 localhost kernel: [51285.980286] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 >> Oct 22 02:48:22 localhost kernel: [51287.991218] ohci_hcd :00:12.0: >> urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 >> >> So, new mobo and $120 later, same freakin error. All this, still in the >> same hole. Now ain't that something? < Dale is going to the shop and >> getting his mini sledge > >> >> Dale > I was about to suggest you search http://www.apc.com/support/answers.cfm for a > possible meaning to "status -121" from APC. Assuming it's an APC unit. I can't > search for you cause they demand cookies. Later I read Neil's reply to you. > > You can always bring the UPS to Tupelo on your next visit for your brother; > along with the entire rig if you'd like. > > Cheers, Homie! Mine is a CyberPower UPS. I use nut for it tho. Just uses a different driver. I got it plugged into a 3.0 port now and going to test that. I may run up to my bothers and see what it does there too. Bringing it up your way could work to tho. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] there are no ebuilds to satisfy "=x11-libs/gtk+-2.24.19".
On Tue, Oct 22, 2013 at 09:36:46AM -0600, Joseph wrote: > I'm tryint to emerge: gtk+-2.24.19 on one of my x86 > but I'm getting: > there are no ebuilds to satisfy "=x11-libs/gtk+-2.24.19". > > package.keywords has: > =x11-libs/gtk+-2.24.19 ~x86 That version is no longer in portage: mingdao@baruch ~ $ eshowkw x11-libs/gtk+ Keywords for x11-libs/gtk+: | | u | | a a p s | n | | l m h i m m p s p | u s | r | p d a p a 6 i p c 3 a x | s l | e | h 6 r p 6 8 p p 6 9 s r 8 | e o | p | a 4 m a 4 k s c 4 0 h c 6 | d t | o ---+---+-+--- 1.2.10-r12 | + + + + + o ~ + + o + + + | o 1 | gentoo ---+---+-+--- 2.24.16 | o o o o o o o o o + o o o | o 2 | gentoo [I]2.24.17 | + + + + + o ~ + + o + + + | o | gentoo 2.24.22 | ~ ~ ~ ~ ~ o ~ ~ ~ o ~ ~ ~ | o | gentoo ---+---+-+--- [I]3.4.4 | + + + + + o ~ + + + + + + | o 3 | gentoo 3.6.3-r3 | ~ ~ + ~ ~ o ~ ~ ~ o ~ ~ ~ | o | gentoo 3.8.4 | ~ ~ ~ ~ ~ o ~ ~ ~ o ~ ~ ~ | # | gentoo 3.8.6 | ~ ~ ~ ~ ~ o ~ ~ ~ o ~ ~ ~ | o | gentoo By putting =category/package-atom in package.accept_keywords (not package.keywords) you have limited it to that one single version and unstable package. Also, you need not put ~arch in package.accept_keywords because that file will pull whatever the latest version is available for category/package. Try changing your "=x11-libs/gtk+-2.24.19 ~x86" to "x11-libs/gtk+" and emerge again. Or, because you appear to have two separate issues here... > I've created manifest in: > ebuild /usr/local/portage/x11-libs/gtk+/gtk+-2.24.19.ebuild manifest > Appending /usr/local/portage to PORTDIR_OVERLAY... > >>> Creating Manifest for /usr/local/portage/x11-libs/gtk+ Now, if you have created your own local overlay and ebuild, you need to also provide the source and needed patches for x11-libs/gtk+-2.24.19 -- Happy Penguin Computers >') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] xorg seizes during debugging
Hello, I got no feedback from eclipse, so I thought I would try here: I debug a multithreaded program using Eclipse (which uses gdb underneath). Somtimes (but usually not) xorgs will seizes for 1-3 secconds during a "step" operation. When I say xorg "seizes" what I mean is that the display freezes. My CPU graph which is always updating at 10Hz stops updating. However, the mouse cursor moves. Can someone suggest a "teach a man to fish" approach I can use to figure out what is causing this? Thank you, Chris
[gentoo-user] there are no ebuilds to satisfy "=x11-libs/gtk+-2.24.19".
I'm tryint to emerge: gtk+-2.24.19 on one of my x86 but I'm getting: there are no ebuilds to satisfy "=x11-libs/gtk+-2.24.19". I've created manifest in: ebuild /usr/local/portage/x11-libs/gtk+/gtk+-2.24.19.ebuild manifest Appending /usr/local/portage to PORTDIR_OVERLAY... Creating Manifest for /usr/local/portage/x11-libs/gtk+ package.keywords has: =x11-libs/gtk+-2.24.19 ~x86 -- Joseph
Re: [gentoo-user] Why is iptables-xml (in net-firewall/iptables) in /usr/bin/ rather than /sbin/
I see. Thanks for the explanation! On Tue, Oct 22, 2013 at 10:15 PM, Michael Orlitzky wrote: > On 10/22/2013 10:02 AM, Linlin Yan (颜林林) wrote: >> Hi there, >> >> After net-firewall/iptables-1.4.16.3 (amd64) installed, I occasionally >> found that it put iptables-xml ('s symbolic link) in /usr/bin/, but >> other tools (like iptables-restore and iptables-save) are not. Is >> there any trick about this? >> > > The others are in /sbin because, > > a) They can't be run by anyone other than root > > b) You want them available at boot time > > But as a normal user, suppose I have an old iptables-save dump lying > around. There's no problem with me running iptables-xml on it, since > that will just read a file and write some XML to stdout. No special > privileges necessary. > >
Re: [gentoo-user] Why is iptables-xml (in net-firewall/iptables) in /usr/bin/ rather than /sbin/
On 10/22/2013 10:02 AM, Linlin Yan (颜林林) wrote: > Hi there, > > After net-firewall/iptables-1.4.16.3 (amd64) installed, I occasionally > found that it put iptables-xml ('s symbolic link) in /usr/bin/, but > other tools (like iptables-restore and iptables-save) are not. Is > there any trick about this? > The others are in /sbin because, a) They can't be run by anyone other than root b) You want them available at boot time But as a normal user, suppose I have an old iptables-save dump lying around. There's no problem with me running iptables-xml on it, since that will just read a file and write some XML to stdout. No special privileges necessary.
Re: [gentoo-user] Re: New mobo change
On Tue, Oct 22, 2013 at 04:04:21AM -0500, Dale wrote: > > Every once in a while, my brain actually comes up with something. ROFL > > Want to hear something equally funny? I started the UPS service that > started this whole mess to see if it works. This is from messages: > > Oct 22 02:47:50 localhost kernel: [51255.888492] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 > Oct 22 02:47:52 localhost kernel: [51257.891409] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 > Oct 22 02:47:54 localhost kernel: [51259.902338] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 > Oct 22 02:47:56 localhost kernel: [51261.905256] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 > Oct 22 02:47:58 localhost kernel: [51263.916194] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 > Oct 22 02:48:00 localhost kernel: [51265.919112] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 > Oct 22 02:48:02 localhost kernel: [51267.930020] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 > Oct 22 02:48:04 localhost kernel: [51269.932920] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 > Oct 22 02:48:06 localhost kernel: [51271.943841] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 > Oct 22 02:48:08 localhost kernel: [51273.946758] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 > Oct 22 02:48:10 localhost kernel: [51275.949676] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 > Oct 22 02:48:12 localhost kernel: [51277.960606] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 > Oct 22 02:48:14 localhost kernel: [51279.963523] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 > Oct 22 02:48:16 localhost kernel: [51281.974454] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 > Oct 22 02:48:18 localhost kernel: [51283.977370] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 > Oct 22 02:48:20 localhost kernel: [51285.980286] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 > Oct 22 02:48:22 localhost kernel: [51287.991218] ohci_hcd :00:12.0: > urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 > > So, new mobo and $120 later, same freakin error. All this, still in the > same hole. Now ain't that something? < Dale is going to the shop and > getting his mini sledge > > > Dale I was about to suggest you search http://www.apc.com/support/answers.cfm for a possible meaning to "status -121" from APC. Assuming it's an APC unit. I can't search for you cause they demand cookies. Later I read Neil's reply to you. You can always bring the UPS to Tupelo on your next visit for your brother; along with the entire rig if you'd like. Cheers, Homie! -- Happy Penguin Computers >') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] Why is iptables-xml (in net-firewall/iptables) in /usr/bin/ rather than /sbin/
Hi there, After net-firewall/iptables-1.4.16.3 (amd64) installed, I occasionally found that it put iptables-xml ('s symbolic link) in /usr/bin/, but other tools (like iptables-restore and iptables-save) are not. Is there any trick about this? Best wishes! Linlin
Re: [gentoo-user] Is the ebuild for dhcpcd wrong
On 22/10/2013 13:37, Chris Allison wrote: > Hello, > > when emerging dhcpcd it attempts to retrieve the source from > /distfiles/... > looking at the mirror the file is actually at > /gentoo/distfiles/... > > Is this the correct place to bring this to your attention? > > regards > > Chris > -- > _ o , , > / | | |_| / \_/ \_| | > \__/ \/ \/ |/ \/ \/ \/|/ > (| That mirror is set up wrong, contact the admins of the mirror you are using. Proper mirrors work properly: >>> Fetching (1 of 1) net-misc/dhcpcd-6.1.0 >>> Downloading 'ftp://ftp.is.co.za/mirror/gentoo.org/distfiles/dhcpcd-6.1.0.tar.bz2' --2013-10-22 15:21:46-- ftp://ftp.is.co.za/mirror/gentoo.org/distfiles/dhcpcd-6.1.0.tar.bz2 => ‘/var/distfiles/dhcpcd-6.1.0.tar.bz2’ Resolving ftp.is.co.za... 196.4.160.12 Connecting to ftp.is.co.za|196.4.160.12|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done.==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /mirror/gentoo.org/distfiles ... done. ==> SIZE dhcpcd-6.1.0.tar.bz2 ... 113671 ==> PASV ... done.==> RETR dhcpcd-6.1.0.tar.bz2 ... done. Length: 113671 (111K) (unauthoritative) 100%[>] 113,671 --.-K/s in 0.1s [I know that mirror works properly as I co-maintain it] -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: cflags for atom
Adam Carter gmail.com> writes: > The i686 and -Os ideas are interesting. SMALL is better. I've run numerous embedded and minimized gentoo systems over the years. Here is the make.conf from a i586: CHOST="i486-pc-linux-gnu" CFLAGS="-Os -march=i586 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" PORTAGE_NICENESS="1" MAKEOPTS="-j2" USE="-* -nls mmx hardened ncurses ssl crypt berkdb tcpd pam perl pcre \ python readline zlib bzip2 nptl nptlonly syslog" MINIMIZE your efforts! > Also - try diffing the kernel .configs - maybe you missed something > important on the slow system. I spent days building several kernels; keep at least 2 so when you minimize yourself into oblivion, you can recover with the known, working kernel. Days and Days of minimize-test-reboot (rinse and repeat) before I got a minimized hardened kernel, that worked well. SMALL is superior to OPTIMIZED, ihmo. That said, if you are trying to make it a graphically minimized portable workstation, experiment with only what you need. HTOP is the best app to watch along with IOtop, as you use the system. Published benchmarks will be mostly irrelevant, imho. Here is a busy, i586 Load average: 0.00 0.00 0.00 mem 9/248 MB CPU 2.0% [1] www.gentoo.org/proj/en/base/embedded/handbook/ ymmv, James
[gentoo-user] Is the ebuild for dhcpcd wrong
Hello, when emerging dhcpcd it attempts to retrieve the source from /distfiles/... looking at the mirror the file is actually at /gentoo/distfiles/... Is this the correct place to bring this to your attention? regards Chris -- _ o , , / | | |_| / \_/ \_| | \__/ \/ \/ |/ \/ \/ \/|/ (|
Re: [gentoo-user] Re: New mobo change
Neil Bothwick wrote: > On Tue, 22 Oct 2013 05:52:06 -0500, Dale wrote: > >>> Did you consider the possibility that the fault lies within the UPS? >> Yep. The UPS costs even more than the mobo tho. ;-) Still sucks tho. >> As it was, I don't have anything to test the UPS with. I had to replace >> something. > Take the UPS to a friend's house and connect it to his computer. If it > breaks: > > 1) Get a new UPS > 2) Get a new friend > > Well, I thought of taking it to my bros. Thing is, his puter is already flakey. It reboots at will sometimes, video just goes blank, keyboard stops working etc etc etc. I think the mobo in that thing is just about gone. It's about 10 years old tho. Slow as syrup that just came out of a freezer too. Oh, only 768MBs of ram. O_O That is maxed out. It's all the mobo can take. At least now I have the makings of a new rig tho. I got a mobo and some ram. LOL I hate crawling under my desk tho. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: New mobo change
On Tue, 22 Oct 2013 05:52:06 -0500, Dale wrote: > > Did you consider the possibility that the fault lies within the UPS? > Yep. The UPS costs even more than the mobo tho. ;-) Still sucks tho. > As it was, I don't have anything to test the UPS with. I had to replace > something. Take the UPS to a friend's house and connect it to his computer. If it breaks: 1) Get a new UPS 2) Get a new friend -- Neil Bothwick WinErr 004: Erroneous error - Nothing is wrong signature.asc Description: PGP signature
Re: [gentoo-user] Re: New mobo change
Neil Bothwick wrote: > On Tue, 22 Oct 2013 04:04:21 -0500, Dale wrote: > >> Want to hear something equally funny? I started the UPS service that >> started this whole mess to see if it works. This is from messages: > >> So, new mobo and $120 later, same freakin error. All this, still in the >> same hole. Now ain't that something? < Dale is going to the shop and >> getting his mini sledge > > > Did you consider the possibility that the fault lies within the UPS? > > Yep. The UPS costs even more than the mobo tho. ;-) Still sucks tho. As it was, I don't have anything to test the UPS with. I had to replace something. Oh well. Live and learn. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: New mobo change
On Tue, 22 Oct 2013 04:04:21 -0500, Dale wrote: > Want to hear something equally funny? I started the UPS service that > started this whole mess to see if it works. This is from messages: > So, new mobo and $120 later, same freakin error. All this, still in the > same hole. Now ain't that something? < Dale is going to the shop and > getting his mini sledge > Did you consider the possibility that the fault lies within the UPS? -- Neil Bothwick JPEG (JPG) Joint Photographic Experts Group. The original name of the committee that designed the eponymous standard image compression algorithm. Abbreviated to JPG by PPL WHO CNT TYP or WSE PCS ARE BKN. signature.asc Description: PGP signature
Re: [gentoo-user] Re: New mobo change
Neil Bothwick wrote: > On Mon, 21 Oct 2013 18:57:21 -0500, Dale wrote: > >>> press Tab at the boot menu to edit isolinux options. But use one of >>> the specifically 64 bit menu items, not the generic one that tries to >>> determine your CPU type on the fly. >> >> Thanks. I thought there was a way to edit it but I was going to have to >> just look and see if I could figure it out. This helps. It gives me >> hope that it is doable too. ;-) >> >> I wonder, if I try to boot the 32 bit version if it would work? >> According to some of the things I read, it affects the 64 bit stuff but >> not 32 bit stuff. Hm. Interesting. ^-^ > > That's a good idea. Both use the same userspace so the only difference is > in the kernels, and I doubt there are many differences between them > except for the target architecture, so it old be a good test. You could > also try the two versions of the alt kernel. > > Every once in a while, my brain actually comes up with something. ROFL Want to hear something equally funny? I started the UPS service that started this whole mess to see if it works. This is from messages: Oct 22 02:47:50 localhost kernel: [51255.888492] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 Oct 22 02:47:52 localhost kernel: [51257.891409] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 Oct 22 02:47:54 localhost kernel: [51259.902338] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 Oct 22 02:47:56 localhost kernel: [51261.905256] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 Oct 22 02:47:58 localhost kernel: [51263.916194] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 Oct 22 02:48:00 localhost kernel: [51265.919112] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 Oct 22 02:48:02 localhost kernel: [51267.930020] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 Oct 22 02:48:04 localhost kernel: [51269.932920] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 Oct 22 02:48:06 localhost kernel: [51271.943841] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 Oct 22 02:48:08 localhost kernel: [51273.946758] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 Oct 22 02:48:10 localhost kernel: [51275.949676] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 Oct 22 02:48:12 localhost kernel: [51277.960606] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 Oct 22 02:48:14 localhost kernel: [51279.963523] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 Oct 22 02:48:16 localhost kernel: [51281.974454] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 Oct 22 02:48:18 localhost kernel: [51283.977370] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 Oct 22 02:48:20 localhost kernel: [51285.980286] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9212 cc 9 --> status -121 Oct 22 02:48:22 localhost kernel: [51287.991218] ohci_hcd :00:12.0: urb 8803ea43f980 path 2 ep1in 9312 cc 9 --> status -121 So, new mobo and $120 later, same freakin error. All this, still in the same hole. Now ain't that something? < Dale is going to the shop and getting his mini sledge > Dale :-) :-) P. S. I got a email off list that explained this IOMMU thingy. Water is a little clearer now. lol -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 10/21/2013 03:33 PM, Volker Armin Hemmann wrote: > Am 20.10.2013 13:18, schrieb Daniel Campbell: >> On 10/20/2013 06:02 AM, Volker Armin Hemmann wrote: >>> Am 20.10.2013 12:52, schrieb Daniel Campbell: On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote: > Am 20.10.2013 08:34, schrieb Daniel Campbell: >> hm, Redhat is one of the companies investing the most money into linux >> kernel, userland, graphics... if you 'don't trust them' you are pretty >> much 20 years too late. >> Investing money does not make them any more qualified or deserving of >> making decisions. Red Hat is not the sole user of Linux. They should >> consider themselves lucky that they are even able to profit from >> something that's free. >> >> You're right, though. They've been around for a while, and I've never >> trusted them or any other corporate interest in *nix. There's always a >> catch when dealing with a business. >> > 'have been around for a while' - replace that with 'are financing more > core developers than anybody else'. > That's less reason to trust, not more. That's like citing the popularity of something as proof of its quality, when oftentimes it's the exact opposite that's true. So they spend a lot of money hiring developers. The more important question is what is their agenda? What do they tell those developers to *make*? You don't hire people without a business plan in mind. >>> without Redhat, there would be no linux. gnu software would be massively >>> lacking and X would be without drivers. >>> >>> So calm down. >>> >> Linux was created and released in 1991, built with GNU tools. Red Hat >> didn't come along until 1993. Linux and GNU would both still be here; >> their quality without Red Hat involvement is speculative at best. > > no, it is not. Several of the most important Kernel devs are or were > Redhat developers. > > So you just showed that you have no clue at all. You should stop right > there. I do "have a clue", but there is logically no way to say, for sure, that Linux and GNU would be worse off without Red Hat's existence. Why? Because we only know what happened _with_ their existence. The assertion can't be validated or even tested without somehow going back in time and preventing Red Hat from forming. It's an empty assertion. > >> I maintain that motives matter more than money and that they (motives) >> should continually be audited, especially when receiving contributions >> from a company. They may already be; I don't know. >> >> Re: drivers, do you expect me to believe Red Hat is responsible for >> every X11 driver out there? > no, but they paid a lot of developers working on several drivers. > > For example David Airlie is employed by Redhat. > > Look him up. > The "no" is all I need to see. You said "X would be without drivers". So unless Red Hat employees wrote every line of the X driver code (unlikely) or produced every single X driver available (proven false), the assertion is false. > >> How many of this list?[1] What of radeon and > > radeon? David Airlie again. > >> nouveau? nvidia's own driver? xf86-input-wacom (and linuxwacom)[2]? I'm >> sure Red Hat has contributed plenty to X11, but your statement is >> flat-out false. > > nope. Your statements lack any connection to reality. > > since you like links, think about this one for a while: > > https://www.linux.com/learn/tutorials/560928-counting-contributions-who-wrote-linux-32 > http://www.linuxfoundation.org/news-media/announcements/2012/04/linux-foundation-releases-annual-linux-development-report > > My statements reflect the truth that Red Hat contributed to, but did not single-handedly *build*, the GNU/Linux operating system. Without their existence, there's no proof that the same drivers (X11 or otherwise) wouldn't be written by some other people. Like I said, speculative at best. On both sides. Your links truthfully reflect that Red Hat contributes the most changes of any company. A majority of something does not magically make it perfect or good or whatever other mythical ideal one can conjure. The links prove that Red Hat guides a lot of the changes. Taking a look at the pdf[1] from 2012, Red Hat's contribution percentage, compared to other companies, is rather high (11.9%, p.10). Almost double the next highest contributor (Novell, at 6.4%). Why would a company invest that much effort into something open and free if there was no agenda, no business plan, no grander scheme or vision? I'm sure some of their work is good. Nothing's all bad or all good. But a company should not be trusted simply because they throw money at something or have the most people working on something compared to other companies. That's reason to be *suspicious*. A business does not throw money at something unless they plan on capitalizing on it in some way. [1]: http://go.linuxfoundation.org/who-writes-linux-2012
Re: [gentoo-user] Re: New mobo change
On Mon, 21 Oct 2013 18:57:21 -0500, Dale wrote: > > press Tab at the boot menu to edit isolinux options. But use one of > > the specifically 64 bit menu items, not the generic one that tries to > > determine your CPU type on the fly. > > Thanks. I thought there was a way to edit it but I was going to have to > just look and see if I could figure it out. This helps. It gives me > hope that it is doable too. ;-) > > I wonder, if I try to boot the 32 bit version if it would work? > According to some of the things I read, it affects the 64 bit stuff but > not 32 bit stuff. Hm. Interesting. ^-^ That's a good idea. Both use the same userspace so the only difference is in the kernels, and I doubt there are many differences between them except for the target architecture, so it old be a good test. You could also try the two versions of the alt kernel. -- Neil Bothwick Sometimes too much to drink is not enough. signature.asc Description: PGP signature
[gentoo-user] Re: [O/T] RAID help - now won't boot
The 21/10/13, Mick wrote: > I'm fast gravitating towards this option ... > > Although with metadata 0.90 I was able to progress with the installation > (after I deselected the swap partitions) the grub-install script wanted to > install in /dev/md127p1 but it failed. I had to override the Ubuntu > installer > since I could only install grub in the /dev/md127 block device. Which is the one we expect. /dev/md127p1 is the first partition of /dev/md127. > BTW, I'm > still at a loss as to why for Ubuntu the RAID 1 is seen as /dev/md127 and not > /dev/md0 which I created originally with sysrescuecd. Names of RAID devices are built at boot time. It depends on /etc/mdadm.conf which should be part of the initramfs. Otherwise, consider the name random. > Either way, it won't boot again. Now it stays on a blank screen, no error at > all shown. I don't understand why this blank screen. Or do you mean a black screen? > I'll have another go with sysrescueCD to see if I install grub on > /dev/sda and /dev/sdb and if this does not work either, It should work. Linux software RAID is assembled once the kernel is up and running. Before, the system boot as usual on a single disk. Though, I'm not sure how mdadm will handle the disk change behind his back. Once the installed system is bootable, I suggest you to try to reinstall grub. This will be required at some point in time in the future to update it either way. > I'll stop wasting > time > and follow your suggestion of installing on a single disk first, before I > mirror it thereafter. -- Nicolas Sebrecht