Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users
On Fri, May 22, 2015 at 11:29:40PM +0100, Mick wrote > On Friday 22 May 2015 23:13:06 Neil Bothwick wrote: > > > > make install does it exactly the way you are doing it, but faster and > > less prone to error. > > Hmm ... I may have used it the wrong way quite a few years ago, but > it would only keep two kernels at a time or something like that. > That made me carry on copying kernel files into boot manually. > In this way at least I know where I put them and what options I pass > on to them. I've automated that process. I have 2 kernels, "experimental" and "production". I use 2 scripts "makeover" and "promote". When I first build a new kernel, I run the the "makeover" script, which does make and overwrites the previous experimental kernel. Note that this script *MUST* be executed from the /usr/src/linux/ directory. #!/bin/bash make && \ make modules_install && \ cp arch/x86_64/boot/bzImage /boot/kernel.experimental && \ cp System.map /boot/System.map.experimental && \ cp .config /boot/config.experimental && \ lilo When the "experimental" kernel has been running OK for a couple of weeks, I promote it to "production" with the "promote" script... #!/bin/bash cp /boot/System.map.experimental /boot/System.map.production cp /boot/config.experimental /boot/config.production cp /boot/kernel.experimental /boot/kernel.production lilo This hooks into my /etc/lilo.conf menu, shown here with comment lines removed... ### lba32 boot = /dev/sda map = /boot/.map install = /boot/boot-menu.b menu-scheme=Wb prompt timeout=150 delay = 50 image = /boot/kernel.production root = /dev/sda5 label = Production read-only # read-only for checking append = "noexec=on net.ifnames=0" image = /boot/kernel.experimental root = /dev/sda5 label = Experimental read-only # read-only for checking append = "noexec=on net.ifnames=0" ### This has saved me on occasion, allowing me to fall back to a working "production" kernel when things go badly with "experimental". I then run my "demote" script. #!/bin/bash cp /boot/System.map.production /boot/System.map.experimental cp /boot/config.production /boot/config.experimental cp /boot/kernel.production /boot/kernel.experimental lilo I also have my kernels set up so that I can... zcat /proc/config.gz > /usr/src/linux/.config ...to retrieve a known working .config file from the currently running kernel. This puts me back to square 1 with the experimental kernel. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users
Neil Bothwick wrote: > On Fri, 22 May 2015 17:04:49 -0500, Dale wrote: > >> I also save the config with the same version part as the kernel, that >> way I know which config goes with which kernel. Everyone has their own >> way of doing what works for them. I just prefer to copy my own manually >> with a name that makes sense to me. I don't think make install will do >> this the way I do it. > make install does it exactly the way you are doing it, but faster and > less prone to error. > > Funny, I've yet to screw up copying and naming a kernel. Also, I get to name it the way I want to name it not the way someone else wants to name it. I sort of doubt that make install will repeat the same naming scheme I use. Of course, I haven't tried it in a long time either. It wouldn't do what I wanted the last time I read about it so I never used it. I haven't seen any need to since I don't update my kernels that often. I'm going on two months since my last reboot. Dale :-) :-)
Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users
On Fri, May 22, 2015 at 6:58 PM, Neil Bothwick wrote: > On Fri, 22 May 2015 23:29:40 +0100, Mick wrote: >>> >>> make install does it exactly the way you are doing it, but faster and >>> less prone to error. >> >> Hmm ... I may have used it the wrong way quite a few years ago, but it >> would only keep two kernels at a time or something like that. That >> made me carry on copying kernel files into boot manually. In this way >> at least I know where I put them and what options I pass on to them. > > make install installs the kernel it just made. It doesn't, and can't, > touch other kernels. The only change it makes to /boot beyond copying > three files there is to adjust the symlinks if they are already present. > > I've never understood the approach of trusting the makefile to configure > your kernel, compile it, compile any number of modules and install all > those modules, but when it comes to copying one file to /boot, that has > to be done manually because the makefile can't be trusted to get things > right. "/sbin/installkernel" renames the already-installed vmlinuz and System.map if it's installing the same version of the kernel.
Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users
On Fri, May 22, 2015 at 6:29 PM, Mick wrote: > On Friday 22 May 2015 23:13:06 Neil Bothwick wrote: >> On Fri, 22 May 2015 17:04:49 -0500, Dale wrote: >>> >>> I also save the config with the same version part as the kernel, that >>> way I know which config goes with which kernel. Everyone has their own >>> way of doing what works for them. I just prefer to copy my own manually >>> with a name that makes sense to me. I don't think make install will do >>> this the way I do it. >> >> make install does it exactly the way you are doing it, but faster and >> less prone to error. > > Hmm ... I may have used it the wrong way quite a few years ago, but it would > only keep two kernels at a time or something like that. That made me carry on > copying kernel files into boot manually. In this way at least I know where I > put them and what options I pass on to them. Two same-version kernels at a time? That's true because of "/sbin/installkernel".
Re: [gentoo-user] Re: [~and64] Headsup for google-chrome users
On Fri, May 22, 2015 at 6:19 PM, walt wrote: > On 05/22/2015 02:38 PM, Tom H wrote: >> On Fri, May 22, 2015 at 5:13 PM, walt wrote: >>> On 05/22/2015 06:32 AM, Mick wrote: Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel? >>> >>> When I use the search function in "make menuconfig" I don't see any mention >>> of MEMCG, so I suspect that particular config item must be enabled by some >>> other config option that I didn't enable (though I don't remember making >>> that decision one way or the other). >>> >>> I'm running gentoo-sources-3.14.42. >> >> You must've mistype your search: >> >> $ grep MEMCG init/Kconfig >> config MEMCG >> config MEMCG_SWAP >> depends on MEMCG && SWAP >> config MEMCG_SWAP_ENABLED >> depends on MEMCG_SWAP >> config MEMCG_KMEM >> depends on MEMCG >> recommended that the MEMCG and MEMCG_KMEM options also be >> >> The above was from 4.1.0-rc4 but AFAIK it's existed for 2 or 3 years >> so you should have it in 3.14. > > Yes, I agree that MEMCG has been in the kernel source code for years. > > I want to emphasize (for any future googlers) that the selection (or > de-selection) of kernel config options can change what you can find > or can't find when configuring kernel options in "make menuconfig". But no matter what you've selected, "/MEMCG" within "make menuconfig" will find configs that contain "MEMCG".
Re: [gentoo-user] Re: [~and64] Headsup for google-chrome users
On Fri, 22 May 2015 15:19:56 -0700, walt wrote: > I want to emphasize (for any future googlers) that the selection (or > de-selection) of kernel config options can change what you can find > or can't find when configuring kernel options in "make menuconfig". But it doesn't change what can be found with the menuconfig search function. That will show options that cannot be enabled, and tell you which options you need to set before you can enable it. -- Neil Bothwick A Microsoft joke (is that a tautology?) pgp24Waa_GrMo.pgp Description: OpenPGP digital signature
Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users
On Fri, 22 May 2015 23:29:40 +0100, Mick wrote: > > make install does it exactly the way you are doing it, but faster and > > less prone to error. > > Hmm ... I may have used it the wrong way quite a few years ago, but it > would only keep two kernels at a time or something like that. That > made me carry on copying kernel files into boot manually. In this way > at least I know where I put them and what options I pass on to them. make install installs the kernel it just made. It doesn't, and can't, touch other kernels. The only change it makes to /boot beyond copying three files there is to adjust the symlinks if they are already present. I've never understood the approach of trusting the makefile to configure your kernel, compile it, compile any number of modules and install all those modules, but when it comes to copying one file to /boot, that has to be done manually because the makefile can't be trusted to get things right. -- Neil Bothwick Microbiology: staph only. pgpxFQRpHwpm_.pgp Description: OpenPGP digital signature
Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users
On Friday 22 May 2015 23:13:06 Neil Bothwick wrote: > On Fri, 22 May 2015 17:04:49 -0500, Dale wrote: > > I also save the config with the same version part as the kernel, that > > way I know which config goes with which kernel. Everyone has their own > > way of doing what works for them. I just prefer to copy my own manually > > with a name that makes sense to me. I don't think make install will do > > this the way I do it. > > make install does it exactly the way you are doing it, but faster and > less prone to error. Hmm ... I may have used it the wrong way quite a few years ago, but it would only keep two kernels at a time or something like that. That made me carry on copying kernel files into boot manually. In this way at least I know where I put them and what options I pass on to them. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: [~and64] Headsup for google-chrome users
On Friday 22 May 2015 22:38:52 Tom H wrote: > On Fri, May 22, 2015 at 5:13 PM, walt wrote: > > On 05/22/2015 06:32 AM, Mick wrote: > >> Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel? > > > > When I use the search function in "make menuconfig" I don't see any > > mention of MEMCG, so I suspect that particular config item must be > > enabled by some other config option that I didn't enable (though I don't > > remember making that decision one way or the other). > > > > I'm running gentoo-sources-3.14.42. > > You must've mistype your search: > > $ grep MEMCG init/Kconfig > config MEMCG > config MEMCG_SWAP > depends on MEMCG && SWAP > config MEMCG_SWAP_ENABLED > depends on MEMCG_SWAP > config MEMCG_KMEM > depends on MEMCG > recommended that the MEMCG and MEMCG_KMEM options also be > > The above was from 4.1.0-rc4 but AFAIK it's existed for 2 or 3 years > so you should have it in 3.14. I'm on gentoo-sources-3.18.12 and the help page on module USER_NS mentioned considering enabling MEMCG and MEMCG_KMEM. I don't know if chromium needs these or not. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: [~and64] Headsup for google-chrome users
On 05/22/2015 02:38 PM, Tom H wrote: > On Fri, May 22, 2015 at 5:13 PM, walt wrote: >> On 05/22/2015 06:32 AM, Mick wrote: >>> >>> Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel? >> >> When I use the search function in "make menuconfig" I don't see any mention >> of MEMCG, so I suspect that particular config item must be enabled by some >> other config option that I didn't enable (though I don't remember making >> that decision one way or the other). >> >> I'm running gentoo-sources-3.14.42. > > You must've mistype your search: > > $ grep MEMCG init/Kconfig > config MEMCG > config MEMCG_SWAP > depends on MEMCG && SWAP > config MEMCG_SWAP_ENABLED > depends on MEMCG_SWAP > config MEMCG_KMEM > depends on MEMCG > recommended that the MEMCG and MEMCG_KMEM options also be > > The above was from 4.1.0-rc4 but AFAIK it's existed for 2 or 3 years > so you should have it in 3.14. Yes, I agree that MEMCG has been in the kernel source code for years. I want to emphasize (for any future googlers) that the selection (or de-selection) of kernel config options can change what you can find or can't find when configuring kernel options in "make menuconfig". This is important, and I want to drill this concept home in your (collective) brains. Configuring the linux kernel is *not* simple. The kernel devs have been struggling with this idea for years, and I am certainly no smarter than they are. Please, just understand that the kernel config scripts are fallible, just like the people who write them.
Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users
On Fri, 22 May 2015 17:04:49 -0500, Dale wrote: > I also save the config with the same version part as the kernel, that > way I know which config goes with which kernel. Everyone has their own > way of doing what works for them. I just prefer to copy my own manually > with a name that makes sense to me. I don't think make install will do > this the way I do it. make install does it exactly the way you are doing it, but faster and less prone to error. -- Neil Bothwick "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin pgp0lvsAcW6Lb.pgp Description: OpenPGP digital signature
Re: [gentoo-user] [~and64] Headsup for google-chrome users
Daniel Frey wrote: > On 05/22/2015 10:21 AM, Dale wrote: >> I have always copied mine over manually too. I keep quite a few spares >> laying around, just in case. I had one that got corrupted a long time >> ago. After I booted another kernel and looked at the one I was trying >> to boot, it was only a few kilo bytes worth. No clue what happened >> there. I just copied it over again and the size was right. Then it >> booted fine. Weird. > I've manually copied the kernel .config over and had that happen. I > remember thinking why is it so small, then I opened it with vim and went > "O." ;-) > > Dan > > . > Well, I think something went goofy at some point since it wasn't the config. I did try to open it and got the usual garbage stuff not a text file. If I recall correctly, that was on a drive that later died. It very well could be that it just went corrupt. Also, that kernel had been used before, it just didn't work that time. It's been a while back and was on another machine. So far, the last time I had a kernel fail on first boot was waaay back when I was first creating my own kernels and was learning what options were a must have. That would be back around 2003 or so. Dang, I'm getting to be a old Linux fart. ROFL :-( Dale :-) :-)
Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users
Neil Bothwick wrote: > On Fri, 22 May 2015 12:21:15 -0500, Dale wrote: > >>> I didn't even know about make install until I read this thread, I >>> always manually copied kernels over. > >> I have always copied mine over manually too. I keep quite a few spares >> laying around, just in case. > > Make install only copies the new kernel, it doesn't touch your existing > ones. However, if you use symlinks in /boot, it links the new > kernel to vmlinuz and the previous one to vmlinuz.old, which removes the > need to alter your grub config. > > I'm sure that works but I've been doing the way I do it because that works for me. This is what I end up with: -rw-r--r-- 1 root root 5148896 Dec 6 2013 /boot/kernel-3.11.6-1 -rw-r--r-- 1 root root 5269728 Mar 23 2014 /boot/kernel-3.13.6-1 -rw-r--r-- 1 root root 5309456 Apr 6 2014 /boot/kernel-3.14.0-1 -rw-r--r-- 1 root root 5370192 Aug 10 2014 /boot/kernel-3.16.0-1 -rw-r--r-- 1 root root 5371280 Oct 6 2014 /boot/kernel-3.16.3-1 -rw-r--r-- 1 root root 5316576 Oct 25 2014 /boot/kernel-3.16.3-2 -rw-r--r-- 1 root root 5388960 May 1 00:53 /boot/kernel-3.18.12-1 -rw-r--r-- 1 root root 5387488 Feb 8 13:10 /boot/kernel-3.18.5-1 -rw-r--r-- 1 root root 5387680 Feb 27 18:03 /boot/kernel-3.18.7-1 -rw-r--r-- 1 root root 5387584 Mar 14 16:56 /boot/kernel-3.18.9-1 I also save the config with the same version part as the kernel, that way I know which config goes with which kernel. Everyone has their own way of doing what works for them. I just prefer to copy my own manually with a name that makes sense to me. I don't think make install will do this the way I do it. To each his own. Dale :-) :-)
Re: [gentoo-user] Re: [~and64] Headsup for google-chrome users
On Fri, May 22, 2015 at 5:13 PM, walt wrote: > On 05/22/2015 06:32 AM, Mick wrote: >> >> Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel? > > When I use the search function in "make menuconfig" I don't see any mention > of MEMCG, so I suspect that particular config item must be enabled by some > other config option that I didn't enable (though I don't remember making > that decision one way or the other). > > I'm running gentoo-sources-3.14.42. You must've mistype your search: $ grep MEMCG init/Kconfig config MEMCG config MEMCG_SWAP depends on MEMCG && SWAP config MEMCG_SWAP_ENABLED depends on MEMCG_SWAP config MEMCG_KMEM depends on MEMCG recommended that the MEMCG and MEMCG_KMEM options also be The above was from 4.1.0-rc4 but AFAIK it's existed for 2 or 3 years so you should have it in 3.14.
[gentoo-user] Re: [~and64] Headsup for google-chrome users
On 05/22/2015 06:32 AM, Mick wrote: > On Friday 22 May 2015 13:47:28 walt wrote: >> On 05/21/2015 04:49 PM, Dale wrote: > >>> Then so have I. I have changed one thing a lot of times over the years, >>> run make and it work fine. Most of the time, it is when emerge spits >>> out that a option is needed for a package to work. Honestly, this is >>> the first time I recall hearing this should even be done. >> >> The first n times I discovered than "make clean" prevents (some) problems >> (sometimes) is when I was running the daily unstable kernels directly from >> Linus's git repo. >> >> As you would expect, I had to git-bisect a lot of kernel bugs over the >> years, and along the way I discovered that doing the exact-same bisect on >> the exact- same source code could produce different results -- results >> that were just plain wrong sometimes. >> >> That problem disappeared when I started doing "make clean" after every >> bisect, painful though it seemed at the time. >> >> I'm now much too old and grouchy to debug unstable kernels every day, >> though. > > Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel? When I use the search function in "make menuconfig" I don't see any mention of MEMCG, so I suspect that particular config item must be enabled by some other config option that I didn't enable (though I don't remember making that decision one way or the other). I'm running gentoo-sources-3.14.42, so you can see I've become almost as grumpy as Volker in my dotage ;)
Re: [gentoo-user] [~and64] Headsup for google-chrome users
On 05/22/2015 10:21 AM, Dale wrote: > > I have always copied mine over manually too. I keep quite a few spares > laying around, just in case. I had one that got corrupted a long time > ago. After I booted another kernel and looked at the one I was trying > to boot, it was only a few kilo bytes worth. No clue what happened > there. I just copied it over again and the size was right. Then it > booted fine. Weird. I've manually copied the kernel .config over and had that happen. I remember thinking why is it so small, then I opened it with vim and went "O." ;-) Dan
Re: [gentoo-user] [~and64] Headsup for googled the previous one to vmlinu-chrome users
On Fri, 22 May 2015 12:21:15 -0500, Dale wrote: > > I didn't even know about make install until I read this thread, I > > always manually copied kernels over. > I have always copied mine over manually too. I keep quite a few spares > laying around, just in case. Make install only copies the new kernel, it doesn't touch your existing ones. However, if you use symlinks in /boot, it links the new kernel to vmlinuz and the previous one to vmlinuz.old, which removes the need to alter your grub config. -- Neil Bothwick Ifyoucanreadthis,youspendtoomuchtimefiguringouttaglines. pgpalAChjPAg8.pgp Description: OpenPGP digital signature
Re: [gentoo-user] [~and64] Headsup for google-chrome users
Daniel Frey wrote: > On 05/22/2015 02:19 AM, Alan McKinnon wrote: >> On 22/05/2015 10:38, Neil Bothwick wrote: >>> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote: >>> > So I'm the 3rd one in row to state that I haven't had any deleterious > effects that I noticed. >>> Make that 4. >> >> >> /raises hand: >> >> 5 >> > /raises hand too > > Make that 6. > > I've been compiling kernels since 2003 and never used make clean or make > mrproper. I use make oldconfig all the time. > > I didn't even know about make install until I read this thread, I always > manually copied kernels over. > > Dan > > > . I have always copied mine over manually too. I keep quite a few spares laying around, just in case. I had one that got corrupted a long time ago. After I booted another kernel and looked at the one I was trying to boot, it was only a few kilo bytes worth. No clue what happened there. I just copied it over again and the size was right. Then it booted fine. Weird. Dale :-) :-)
Re: [gentoo-user] [~and64] Headsup for google-chrome users
On Thursday, May 21, 2015 05:55:52 AM walt wrote: Thanks. I also saw that message, but after checking the kernel, ignored it! > I just wasted some time figuring out this mess: > > I just updated google-chrome, which printed this confusing warning message: > > "CONFIG_USED_NS not seen when it should be" > > First, there's a typo: it should read "CONFIG_USER_NS" > ^ > > Then, after I figured out that CONFIG_USER_NS is a kernel config item, > requiring reinstallation of my kernel, I wasted more time figuring out > (for the n'th time) that you shouldn't just change a single kernel config > item and do "make" because that shortcut can break important things. > > No, you should do "make clean" first, and then do "make" etc. > > Then, after finishing that mess, you then need to re-install ati-drivers > (if you use them) because CONFIG_USER_NS breaks the ati-drivers too. > > So, re-install ati-drivers, reboot, etc, all of which will make you late > for work, like I am now :p
Re: [gentoo-user] [~and64] Headsup for google-chrome users
On 05/22/2015 02:19 AM, Alan McKinnon wrote: > On 22/05/2015 10:38, Neil Bothwick wrote: >> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote: >> So I'm the 3rd one in row to state that I haven't had any deleterious effects that I noticed. >> >> Make that 4. > > > > /raises hand: > > 5 > /raises hand too Make that 6. I've been compiling kernels since 2003 and never used make clean or make mrproper. I use make oldconfig all the time. I didn't even know about make install until I read this thread, I always manually copied kernels over. Dan
Re: [gentoo-user] Re: [~and64] Headsup for google-chrome users
On Friday 22 May 2015 13:47:28 walt wrote: > On 05/21/2015 04:49 PM, Dale wrote: > > Then so have I. I have changed one thing a lot of times over the years, > > run make and it work fine. Most of the time, it is when emerge spits > > out that a option is needed for a package to work. Honestly, this is > > the first time I recall hearing this should even be done. > > The first n times I discovered than "make clean" prevents (some) problems > (sometimes) is when I was running the daily unstable kernels directly from > Linus's git repo. > > As you would expect, I had to git-bisect a lot of kernel bugs over the > years, and along the way I discovered that doing the exact-same bisect on > the exact- same source code could produce different results -- results > that were just plain wrong sometimes. > > That problem disappeared when I started doing "make clean" after every > bisect, painful though it seemed at the time. > > I'm now much too old and grouchy to debug unstable kernels every day, > though. Did you also enable CONFIG_MEMCG & MEMCG_KMEM in your kernel? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: [~and64] Headsup for google-chrome users
On 05/22/2015 03:15 AM, Quanyang Liu wrote: > On Thu, May 21 2015 at 20:55:52 +0800, walt wrote: >> I just wasted some time figuring out this mess: >> >> .. >> >> So, re-install ati-drivers, reboot, etc, all of which will make you late >> for work, like I am now :p > > Hi all, but I just found another problem. > > I now use xmonad, and always shift chrome to 7th workspace. And for the > new version chrome, it has no focus after being shifted. I can type in > the start page (if I set it to some website, > i.e. https://www.google.com ), but can't type in the address bar (if > there is no start page). And the title bar is always gray until I click > the browser. I'd suggest posting this question in a new thread because you are describing a different problem from the one I had. More people will see your question that way.
Re: [gentoo-user] [~and64] Headsup for google-chrome users
On Fri, May 22 2015, Alan McKinnon wrote: > On 22/05/2015 10:38, Neil Bothwick wrote: >> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote: >> So I'm the 3rd one in row to state that I haven't had any deleterious effects that I noticed. >> >> Make that 4. > > /raises hand: > 5 ++1 allan
[gentoo-user] Re: [~and64] Headsup for google-chrome users
On 05/21/2015 04:49 PM, Dale wrote: > Mike Gilbert wrote: >> On Thu, May 21, 2015 at 3:44 PM, wrote: >>> walt wrote: >>> >>> [...] Then, after I figured out that CONFIG_USER_NS is a kernel config item, requiring reinstallation of my kernel, I wasted more time figuring out (for the n'th time) that you shouldn't just change a single kernel config item and do "make" because that shortcut can break important things. No, you should do "make clean" first, and then do "make" etc. >>> [...] >>> >>> I haven't done a "make clean" for years when I compiled a kernel and I >>> never had any problems. >> Then you have not made any critical config changes, or you have been very >> lucky. >> >> > > Then so have I. I have changed one thing a lot of times over the years, > run make and it work fine. Most of the time, it is when emerge spits > out that a option is needed for a package to work. Honestly, this is > the first time I recall hearing this should even be done. The first n times I discovered than "make clean" prevents (some) problems (sometimes) is when I was running the daily unstable kernels directly from Linus's git repo. As you would expect, I had to git-bisect a lot of kernel bugs over the years, and along the way I discovered that doing the exact-same bisect on the exact- same source code could produce different results -- results that were just plain wrong sometimes. That problem disappeared when I started doing "make clean" after every bisect, painful though it seemed at the time. I'm now much too old and grouchy to debug unstable kernels every day, though.
Re: [gentoo-user] [~and64] Headsup for google-chrome users
On Friday 22 May 2015 12:09:34 Alan McKinnon wrote: > On 22/05/2015 12:44, Mick wrote: > > On Friday 22 May 2015 09:38:46 Neil Bothwick wrote: > >> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote: > So I'm the 3rd one in row to state that I haven't had any deleterious > effects that I noticed. > >> > >> Make that 4. > >> > >>> When I first emerge a new kernel, I run make mrproper to get a good > >>> clean start. > >> > >> There's no point in that. When you have just emerged the sources, there > >> is nothing for mrproper to remove. > > > > So, coming back to the OP, is it advisable to ignore this message: > No. It's in the ebuild and we assume the ebuild writer had a reason for > putting it there. The usual reason is that upstream has said their code > requires an option to be set. > > Where would you have gotten the idea that ignoring it is good advice? Because the emerge did not stop to warn me about it, or require me to acknowledge before proceeding. Furthermore it tells me that bad things may happen, but doesn't explain what kind of bad things, referring to a URL if space does not allow. At this stage I am guessing that chromium's sandboxing mechanism is changed and it now requires a different memory allocation mechanism than what I had previously configured in my kernel. Having to configure my kernel to get a browser working sounds quite intrusive so I am worried some more. Looking at the changelog and then at bugs referred to there, I eventually arrived at CVE-2015-1252 [1] where the problem is explained: In any case, I think that something like this should invite user input at the start of the ebuild, rather than at the end? I haven't figured out yet if I will need to reinstall chromium after I have reconfigured my kernel ... in which case the warning should definitely come at the start of the ebuild. [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1252 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [~and64] Headsup for google-chrome users
On 22/05/2015 12:44, Mick wrote: > On Friday 22 May 2015 09:38:46 Neil Bothwick wrote: >> On Fri, 22 May 2015 02:53:17 -0500, Dale wrote: So I'm the 3rd one in row to state that I haven't had any deleterious effects that I noticed. >> >> Make that 4. >> >>> When I first emerge a new kernel, I run make mrproper to get a good >>> clean start. >> >> There's no point in that. When you have just emerged the sources, there is >> nothing for mrproper to remove. > > > So, coming back to the OP, is it advisable to ignore this message: No. It's in the ebuild and we assume the ebuild writer had a reason for putting it there. The usual reason is that upstream has said their code requires an option to be set. Where would you have gotten the idea that ignoring it is good advice? > > * Messages for package www-client/chromium-43.0.2357.65: > [27/1984] > > * USER_NS is required for sandbox to work > * Please check to make sure these options are set correctly. > * Failure to do so may cause unexpected problems. > > which doesn't even advise where to find USER_NS, or will chromium no longer > work as it did in the past? > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] [~and64] Headsup for google-chrome users
On Friday 22 May 2015 09:38:46 Neil Bothwick wrote: > On Fri, 22 May 2015 02:53:17 -0500, Dale wrote: > > > So I'm the 3rd one in row to state that I haven't had any deleterious > > > effects that I noticed. > > Make that 4. > > > When I first emerge a new kernel, I run make mrproper to get a good > > clean start. > > There's no point in that. When you have just emerged the sources, there is > nothing for mrproper to remove. So, coming back to the OP, is it advisable to ignore this message: * Messages for package www-client/chromium-43.0.2357.65: [27/1984] * USER_NS is required for sandbox to work * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. which doesn't even advise where to find USER_NS, or will chromium no longer work as it did in the past? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: [~and64] Headsup for google-chrome users
On Thu, May 21 2015 at 20:55:52 +0800, walt wrote: > I just wasted some time figuring out this mess: > > .. > > So, re-install ati-drivers, reboot, etc, all of which will make you late > for work, like I am now :p Hi all, but I just found another problem. I now use xmonad, and always shift chrome to 7th workspace. And for the new version chrome, it has no focus after being shifted. I can type in the start page (if I set it to some website, i.e. https://www.google.com ), but can't type in the address bar (if there is no start page). And the title bar is always gray untill I click the browser. Does anyone have the same problem? And how can I solve it? -- Thanks, Quanyang
Re: [gentoo-user] [~and64] Headsup for google-chrome users
On 22/05/2015 10:38, Neil Bothwick wrote: > On Fri, 22 May 2015 02:53:17 -0500, Dale wrote: > >>> So I'm the 3rd one in row to state that I haven't had any deleterious >>> effects that I noticed. > > Make that 4. /raises hand: 5 Seems like there's a lot of cargo-cult advice around about how to configure a kernel > >> When I first emerge a new kernel, I run make mrproper to get a good >> clean start. > > There's no point in that. When you have just emerged the sources, there is > nothing for mrproper to remove. > > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] [~and64] Headsup for google-chrome users
Neil Bothwick wrote: > On Fri, 22 May 2015 02:53:17 -0500, Dale wrote: > >>> So I'm the 3rd one in row to state that I haven't had any deleterious >>> effects that I noticed. > Make that 4. > >> When I first emerge a new kernel, I run make mrproper to get a good >> clean start. > There's no point in that. When you have just emerged the sources, there is > nothing for mrproper to remove. > > Sometimes, it prints that it removed stuff. Usually not but once in a while it says it removed something. No clue what that was tho. Dale :-) :-)
Re: [gentoo-user] [~and64] Headsup for google-chrome users
On Fri, 22 May 2015 02:53:17 -0500, Dale wrote: > > So I'm the 3rd one in row to state that I haven't had any deleterious > > effects that I noticed. Make that 4. > When I first emerge a new kernel, I run make mrproper to get a good > clean start. There's no point in that. When you have just emerged the sources, there is nothing for mrproper to remove. -- Neil Bothwick "B?#$^f," said Pooh, as line noise garbled his transmission. pgpy2uirGsAsf.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Poor mans audio in the world of the great Jack D.
Staring into the dark abyss of the fathomless mysteries, the humble scholar spake: "Shit! I'm out of ideas, dude…" The .asoundrc snippet works out of the box for me, but I use it just for Firefox, to be honest, every other audio software There are more solutions at http://jackaudio.org/faq/routing_alsa.html Failing that, I don't know. Maybe qsstv does not belong to the ALSA tribe but to the OSS one, and uses the ALSA OSS emulation, and this prevents the ALSA jack plugin to work? -- Emanuele Rusconi
Re: [gentoo-user] [~and64] Headsup for google-chrome users
Mick wrote: > On Friday 22 May 2015 00:49:54 Dale wrote: >> Mike Gilbert wrote: >>> On Thu, May 21, 2015 at 3:44 PM, wrote: walt wrote: [...] > Then, after I figured out that CONFIG_USER_NS is a kernel config item, > requiring reinstallation of my kernel, I wasted more time figuring out > (for the n'th time) that you shouldn't just change a single kernel > config item and do "make" because that shortcut can break important > things. > > No, you should do "make clean" first, and then do "make" etc. [...] I haven't done a "make clean" for years when I compiled a kernel and I never had any problems. >>> Then you have not made any critical config changes, or you have been very >>> lucky. >> Then so have I. I have changed one thing a lot of times over the years, >> run make and it work fine. Most of the time, it is when emerge spits >> out that a option is needed for a package to work. Honestly, this is >> the first time I recall hearing this should even be done. >> >> Dale >> >> :-) :-) > I knew it should be done, but thought it ought to be done when you want to > start with a clean slate and I didn't know if I needed to do this, or what a > clean slate involved exactly. > > Since I run 'make oldconfig' I always assumed that I don't need a clean > slate, > plus updating minor versions takes seconds. > > So I'm the 3rd one in row to state that I haven't had any deleterious effects > that I noticed. > When I first emerge a new kernel, I run make mrproper to get a good clean start. I then copy my old config over to the new kernel. After that, I don't run clean or mrproper again for that version. If I change something, I run menuconfig, make the change, run make all && make modules_install and then copy it over. I don't even want to try and count the number of times I've changed just one setting because some package needed it before it would update. Sometimes, I may change a kernel several times before I update to a new version. I been doing this the same way ever since about 2003. As some know, if it would cause a problem, I should have found it by now, at least once. ;-) Dale :-) :-)
Re: [gentoo-user] [~and64] Headsup for google-chrome users
On Friday 22 May 2015 00:49:54 Dale wrote: > Mike Gilbert wrote: > > On Thu, May 21, 2015 at 3:44 PM, wrote: > >> walt wrote: > >> > >> [...] > >> > >>> Then, after I figured out that CONFIG_USER_NS is a kernel config item, > >>> requiring reinstallation of my kernel, I wasted more time figuring out > >>> (for the n'th time) that you shouldn't just change a single kernel > >>> config item and do "make" because that shortcut can break important > >>> things. > >>> > >>> No, you should do "make clean" first, and then do "make" etc. > >> > >> [...] > >> > >> I haven't done a "make clean" for years when I compiled a kernel and I > >> never had any problems. > > > > Then you have not made any critical config changes, or you have been very > > lucky. > > Then so have I. I have changed one thing a lot of times over the years, > run make and it work fine. Most of the time, it is when emerge spits > out that a option is needed for a package to work. Honestly, this is > the first time I recall hearing this should even be done. > > Dale > > :-) :-) I knew it should be done, but thought it ought to be done when you want to start with a clean slate and I didn't know if I needed to do this, or what a clean slate involved exactly. Since I run 'make oldconfig' I always assumed that I don't need a clean slate, plus updating minor versions takes seconds. So I'm the 3rd one in row to state that I haven't had any deleterious effects that I noticed. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
