[gentoo-user] Re: Having Trouble with Wireless Interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/21/2014 01:56 PM, Alexander Kapshuk wrote: > Thanks for the explanation. > > Just to double check I understood it correctly, there's no need to put > the list of kernel modules into /etc/conf.d/modules any longer, because > udev is aware of the modules that have been built and will load them by > consulting /lib/modules/$(uname -r)/modules.alias. Is that correct? > > Thanks. > > You only need to list the modules in /etc/conf.d/modules (for OpenRC) or /etc/modules-load.d/*.conf (for systemd) if they would not otherwise be loaded. Just about any module that provides a driver for hardware that can be autodetected (that is, PCI, USB, etc.) will be auto-loaded by udev. Modules used to provide filters, etc. for iptables are autoloaded by iptables itself as needed. Some modules do not have anything that would cause them to be autoloaded (such as the vbox-* modules from VirtualBox), in which case you *would* need to explicitly load them. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTfXBLAAoJELHSF2kinlg4TQ0QAKGDJ3ZFZOeK8Y4hEE6xGMXV f2vjjAUhyrR2J67vwA5eJ377ZxF5ieMvY8N4sTk68hlLDWZrAGmfLs5u+d9gbqaO 3dF6ekvnebdH9apQ2xdCpaWD/AlfeZ8JR1Mav3kYkjaurGeMkNN3cqZAzkaip8gZ jJ1TWRy74+jJFv2F904/pjShKKEl+BEssLcSSFr91Jx70fNKiby+1oJfhZIcm4Kj 8KMLz/sh7BB6ia0KnEnNM2P11zRct+4ParXIAhCxT2P/x5DvOHGbgMie27k8VY1J 8v8LjbqCAZS43In6Vr07IfMwy0wNQAkob6GkGytyiIcijSdVDINkwSomcSS1Madb xWTWX1gEqogHtQoe3GkaW2H+nksZejtJwt5FzQsUmEDytNA5kqef7UiW1rV6rXE5 Uz94OZiopQTyrXYtnZHsCnY0JGu4DnCvm+JLSh5ee1VDRs8aPX22pWjCEtat1q9c +QKTVW62D32zC8cgLH04Hgbc6zN3/J3akTJftZRSISqMCA1xQwe0wyZet2RKVJUo anyC/lOh2mIp9zCTUvTt81oUpElTPKN4l7UjDuPoLK7n4oOK2Ao9frPeEoDxJGam 0fhlOwAg5PpV4qSyWQGneg96UlirB9O9mai/wEzzOZPxaY9gu/scqXrPUZWGwQbp BpEgVnDCGLTpZE6cqfu1 =SJpi -END PGP SIGNATURE-
Re: [gentoo-user] Use Flags and Updating
On Wed, May 21, 2014 at 10:10 PM, wrote:
> I run a script that syncs portage, updates @world, depcleans, revdep-rebuild
> and finally runs dispatch-conf -- about once weekly. Keeps my system in fine
> trim. :)
This one is a gem - I forget where I saw it (likely planet, but maybe
it was on a list). Stick it in your crontab. I will warn you that
sometimes it chokes on its own output and obviously it can't build
binpkgs for anything more than one step down the dependency tree.
However, when my weekly chromium build runs at 2AM and I can just
install it (with -k) the next morning it is a nice thing indeed. You
still get full control over USE flags/etc, but most of the convenience
of a binary distro.
#!/bin/sh
LIST=$(mktemp);
emerge -puD --changed-use --color=n --columns --quiet=y --with-bdeps=y
world | awk '{print $2}' > ${LIST};
for PACKAGE in $(cat ${LIST});
do
printf "Building binary package for ${PACKAGE}... "
emerge -uN --quiet-build --quiet=y --buildpkgonly ${PACKAGE};
if [[ $? -eq 0 ]];
then
echo "ok";
else
echo "failed";
fi
done
Re: [gentoo-user] Only 4 of 8 GB usable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/14 09:20, wraeth wrote: > Just a quick suggestion to help rule it out: try booting a LiveCD or other > "one-size-fits-most" medium and seeing if your full memory is registering > there. If it is, then it's not a hardware malfunction; if it doesn't, then > either you've got bad hardware or a configuration issue in your BIOS. Just had another thought, too: you could check what the BIOS reports either by entering the BIOS configuration and going to the system information area, or by inspecting your machines POST output (the diagnostic information that is displayed during boot, sometimes hidden by a splash screen with "Press [something] to show details". cheers wraeth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlN9ZGAACgkQXcRKerLZ91mfFgD/RljFu05+0ymLJrOs8BRUvTji bk1s4RhOGroibx8GaMkA/2xZjYptJrj7PM+7ebw+2FN0juGKFZQyQ5VrL81yYn0z =eRY0 -END PGP SIGNATURE-
Re: [gentoo-user] Use Flags and Updating
On Wed, May 21, 2014 at 04:49:57PM +0300, Alexander Kapshuk wrote:
> On 05/20/2014 10:13 PM, Matti Nykyri wrote:
> > On May 20, 2014, at 14:49, Alexander Kapshuk
> > mailto:alexander.kaps...@gmail.com>> wrote:
> >
> >> On 05/20/2014 02:40 PM, Hunter Jozwiak wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> *From:*Alexander Kapshuk [mailto:alexander.kaps...@gmail.com]
> >>> *Sent:* Tuesday, May 20, 2014 7:44 AM
> >>> *To:* gentoo-user@lists.gentoo.org
> >>> *Subject:* Re: [gentoo-user] Use Flags and Updating
> >>>
> >>>
> >>>
> >>> On 05/20/2014 02:37 PM, Hunter Jozwiak wrote:
> >>>
> >>> Hi all. How do I get Portage to update all software to use my
> >>> new USE flags? I made some modifications to the variable, and I
> >>> want to make sure that all packages can use the flags.
> >>>
> >>> emerge(1)
> >>> -N -- --newuse
> >>>
> >>> Thank you.
> >>>
> >> No worries.
> >>
> >> Here's what I usually run when updating the world.
> >> Long version: emerge --ask --update --deep --with-bdeps=y --newuse @world
> >> With '--with-bdeps=y' set in the file shown below:
> >> grep bdeps /etc/portage/make.conf
> >> EMERGE_DEFAULT_OPTS="--with-bdeps=y"
> >>
> >> Short version: emerge -avuND @world
> >> -a [--ask]
> >> -v [--verbose]
> >> -u [--update]
> >> -N [--newuse]
> >> -D [--deep]
> >
> > And how to remember this... Make it a name:
> >
> > emerge -DuvaN @world
> >
> > Human mind is a complex organ ;)
> >
> > --
> > -Matti
>
> I just put this into a shell function.
>
> sed -n '/chkupd/,/}/p' .bash_profile
> chkupd(){
> emerge --sync && emerge -avuND @world
> }
>
I run a script that syncs portage, updates @world, depcleans, revdep-rebuild
and finally runs dispatch-conf -- about once weekly. Keeps my system in fine
trim. :)
signature.asc
Description: Digital signature
Re: [gentoo-user] Only 4 of 8 GB usable
wraeth wrote: > > > On 22/05/14 07:37, Alex Schuster wrote: > > Does this ring any bells? I'm out of ideas. Except than pulling out the 4 > > GB, or trying another mainboard. > > Just a quick suggestion to help rule it out: try booting a LiveCD or other > "one-size-fits-most" medium and seeing if your full memory is registering > there. If it is, then it's not a hardware malfunction; if it doesn't, then > either you've got bad hardware or a configuration issue in your BIOS. > > cheers > wraeth Isn't there a kernel setting that cuts off after 4GBs or something? I seem to recall having to turn that on at some point. I would think this would be on by default but . . . . Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] May GMN Tips and Tricks
Alan McKinnon wrote: > On 22/05/2014 00:41, David Abbott wrote: >> Hi Everyone, >> We are putting together this months GMN [1] Looking for some content >> to add to the "Tip of the month" section. >> Regards >> David >> >> [1] http://blogs.gentoo.org/news >> > > This month has been a treasure trove of such things here on gentoo-user. > > If you have the time, trawl the systemd and grub2 threads for some > amazing tips. > > The "Fonts and bad eyes" thread would also make a good insert - it > covered a very interesting area of less than general scope (but that's > what makes it so especially interesting - if you need to edit a console > font, the answer is in there) > I had no idea there was as many folks with bad eyes when I started that thread. It's will take me a while to try all the things recommended. Some days my eyes are somewhat OK but some days, they just plain suck. Text is really hard to read but even pics have some challenge to them. I thought the newsletter died. When did it come back? One thing I used to like about them was warning of issues that were coming. That helps a lot. Upgrade xyz, make sure to update configs BEFORE rebooting else you get pieces. That sort of thing was very helpful. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
[gentoo-user] maintenance
Last year there was an enormous thread on how to maintain gentoo system (portage tools etc) - was this ever summarised anywhere? BillK
Re: [gentoo-user] Only 4 of 8 GB usable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/14 07:37, Alex Schuster wrote: > Does this ring any bells? I'm out of ideas. Except than pulling out the 4 > GB, or trying another mainboard. Just a quick suggestion to help rule it out: try booting a LiveCD or other "one-size-fits-most" medium and seeing if your full memory is registering there. If it is, then it's not a hardware malfunction; if it doesn't, then either you've got bad hardware or a configuration issue in your BIOS. cheers wraeth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlN9NLMACgkQXcRKerLZ91knaQD/VGNVPzB+voalyCX4GiU9e3Zy oz82/X8k+BlDFqhUulMA/AqNcFqqAIXOBUym1DSJfJWd5eu5gBpia+G3cTjGLkt6 =My0D -END PGP SIGNATURE-
Re: [gentoo-user] grub2 boots only older kernel
On 05/21/14 08:00, Todd Goodman wrote: * wirel...@tampabay.rr.com [140519 21:25]: [SNIP] It never tries to boot. Grub just sits there withe phrase (did not copy it down) where it says what version it will boot on the screen and it does nothing (locked up?) I have to or push a manual reset. It never tries to load the kernel. Does not matter if I try a 3.13.7 or 3.14.x, I've rebuilt them quite a few times and did all the grub2 steps, but none of the newer kernels will boot. Nothing was done to the bios. The only change was to get rid of ATI Frame buffer support as suggested upon a recent update: * Checking for suitable kernel configuration options... * CONFIG_FB_RADEON:should not be set. But it is. * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. James I've had problems like this with grub2 when it was trying to retain the graphics mode (sorry, I don't remember the line in grub.cfg since I've since removed it.) yep, this is what I suspect. I may need to reinstall grub2, for some unknown reason. My research so far has yielded lots of anomolies with grub2 I usually find grub problems by entering the grub command line and typing the commands in the menuentry from /boot/grub/grub.cfg that doesn't work one at a time. Good idea, I'll try this. Todd James
Re: [gentoo-user] May GMN Tips and Tricks
On 22/05/2014 00:41, David Abbott wrote: > Hi Everyone, > We are putting together this months GMN [1] Looking for some content > to add to the "Tip of the month" section. > Regards > David > > [1] http://blogs.gentoo.org/news > This month has been a treasure trove of such things here on gentoo-user. If you have the time, trawl the systemd and grub2 threads for some amazing tips. The "Fonts and bad eyes" thread would also make a good insert - it covered a very interesting area of less than general scope (but that's what makes it so especially interesting - if you need to edit a console font, the answer is in there) -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] May GMN Tips and Tricks
Hi Everyone, We are putting together this months GMN [1] Looking for some content to add to the "Tip of the month" section. Regards David [1] http://blogs.gentoo.org/news -- David Abbott (dabbott) Gentoo Foundation Secretary http://dev.gentoo.org/~dabbott/
[gentoo-user] Only 4 of 8 GB usable
Hi there! So I installed another 4 GiB RAM into a Gentoo amd64 system that had 4 GiB already. But it still sees only 4 GiB, not 8 GiB: leela ~ # uname -a Linux leela 3.6.11-gentoo #3 SMP Mon Feb 4 15:37:48 CET 2013 x86_64 AMD A6-3500 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux leela ~ # free -m total used free sharedbuffers cached Mem: 3688 3269419 0108 1050 -/+ buffers/cache: 2110 1577 Swap: 2047 54 1993 Huh? Any idea why this is? The BIOS shows the full 8GiB, and lshw finds it. dmidecode shows that 8G should work: leela ~ # dmidecode -t 16 # dmidecode 2.11 SMBIOS 2.7 present. Handle 0x0008, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: None Maximum Capacity: 8 GB Error Information Handle: Not Provided Number Of Devices: 2 In case this helps, I uploaded the outputs of dmesg [1], lshw -c memory [2] and full dmidecode output [3]. The dmesg output is somewhat weird though, it has several 'vmalloc: allocation failure: 0 bytes' entries. I suspected those were causing the problem, but I found that I needed to activate CONFIG_KALLSYMS=y, and they are gone. But still only 4 GiB RAM. The system is using an old kernel right now, so I cannot get the current dmesg, sorry for this. Probably related: Since I inserted this 2nd RAM module, wakeup from hibernate-ram does no longer work. Does this ring any bells? I'm out of ideas. Except than pulling out the 4 GB, or trying another mainboard. [1] http://www.wonkology.org/tmp/lshw.txt [2] http://www.wonkology.org/tmp/dmesg.txt [3] http://www.wonkology.org/tmp/dmidecode.txt Wonko
Re: [gentoo-user] fstab cleanup
Am 21.05.2014 21:44, schrieb Tom H: > The answer is "no" unless you want to apply different perms to "/dev/shm". I don't have an idea why I should want to do that so I removed the line for now. Thanks. Stefan
Re: [gentoo-user] Confusing Portage Outcomes
On Wed, 21 May 2014 14:33:30 -0400 Hunter Jozwiak wrote: > I commented that out for the purposes of having it in the email as a > sort of example. It isn't actually commented I was in the file. So > having the x86 and the ~x86 in the same variable would make a safe > portage solution? Yes; it allows ~x86 versions, while not disallowing x86 versions. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-user] fstab cleanup
On Wednesday 21 May 2014 20:44:04 Tom H wrote:
> On Wed, May 21, 2014 at 1:53 PM, Stefan G. Weichinger
wrote:
> > Am 21.05.2014 15:31, schrieb Tom H:
> >> On Wed, May 21, 2014 at 6:32 AM, Stefan G. Weichinger
wrote:
> >>> Do I still need these lines .. especially with a modern
> >>> systemd/gnome3-environment?
> >>>
> >>> # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
> >>> # POSIX shared memory (shm_open, shm_unlink).
> >>> # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
> >>> # use almost no memory if not populated with files)
> >>> tmpfs /dev/shmtmpfs
> >>> nodev,nosuid,noexec 0 0
> >>>
> >>>
> >>> /dev/cdrw /media/cdrecorder auto
> >>> user,exec,noauto,managed 0 0
> >>
> >> From "src/core/mount-setup.c":
> >>
> >> { "tmpfs", "/dev/shm", "tmpfs",
> >> "mode=1777", MS_NOSUID|MS_NODEV|MS_STRICTATIME, NULL,
> >> MNT_FATAL|MNT_IN_CONTAINER },
> >
> > So the answer is "no" ?
>
> The answer is "no" unless you want to apply different perms to "/dev/shm".
I went through a new installation recently and seem to recall that the fstab
was rather empty from its usual entries. Will older installations eventually
get an enotice to this effect with baselayout updates?
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] fstab cleanup
On Wed, May 21, 2014 at 1:53 PM, Stefan G. Weichinger wrote:
> Am 21.05.2014 15:31, schrieb Tom H:
>> On Wed, May 21, 2014 at 6:32 AM, Stefan G. Weichinger wrote:
>>>
>>> Do I still need these lines .. especially with a modern
>>> systemd/gnome3-environment?
>>>
>>> # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
>>> # POSIX shared memory (shm_open, shm_unlink).
>>> # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
>>> # use almost no memory if not populated with files)
>>> tmpfs /dev/shmtmpfs
>>> nodev,nosuid,noexec 0 0
>>>
>>>
>>> /dev/cdrw /media/cdrecorder auto
>>> user,exec,noauto,managed 0 0
>>
>> From "src/core/mount-setup.c":
>>
>> { "tmpfs", "/dev/shm", "tmpfs",
>> "mode=1777", MS_NOSUID|MS_NODEV|MS_STRICTATIME, NULL,
>> MNT_FATAL|MNT_IN_CONTAINER },
>
> So the answer is "no" ?
The answer is "no" unless you want to apply different perms to "/dev/shm".
Re: [gentoo-user] Re: Having Trouble with Wireless Interface
On Wednesday 21 May 2014 18:56:49 Alexander Kapshuk wrote:
> On 05/18/2014 04:05 AM, Jonathan Callen wrote:
> > On 05/15/2014 03:50 PM, Mick wrote:
> > > On Thursday 15 May 2014 14:24:57 Alexander Kapshuk wrote:
> > >> On 05/15/2014 11:39 AM, Stroller wrote:
> > >>> On Wed, 14 May 2014, at 12:36 pm, Alexander Kapshuk
> > >
> > > wrote:
> > >> ?
> > >> If you like to check if RTL8192CE is enabled in your kernel's
> >
> > .config
> >
> > >> file. If it isn't, you probably want to compile it as a module,
> > >> and then add rtl8192ce to /etc/conf.d/modules as well.
> > >
> > > Am pretty sure there's no need to add this one to
> >
> > /etc/conf.d/modules -
> >
> > > IME it'll just be found and loaded automagically by the kernel.
> >
> > Thanks for pointing that out. I wasn't aware of that. As I
> >
> > mentioned in
> >
> > my previous post, I do not use genkernel myself.
> > >>>
> > >>> Neither do I - for this reason I found it a little frustrating
> >
> > trying to
> >
> > >>> help in a recent thread, myself.
> > >>>
> > >>> However, I'm pretty sure that loadable kernel modules behave the same
> > >>> whether your kernel is built "by hand" or by genkernel - if you have
> > >>> modules listed in /etc/conf.d/modules then I have to wonder if you
> > >>> really need them there.
> > >>>
> > >>> I haven't used that file for years, and I prefer to compile
> >
> > everything as
> >
> > >>> a module, too.
> > >>>
> > >>> Stroller.
> > >>
> > >> That's interesting. I wasn't aware of that either.
> > >>
> > >> So far, I've just been following the instructions given in the
> >
> > handbook,
> >
> > >> section 7.d, which do recommend explicitly specifying the kernel
> >
> > modules
> >
> > >> to be loaded at boot time in /etc/conf.d/modules.
> > >>
> > >> How does the kernel know then what modules to load at boot time, if it
> > >> doesn't rely on /etc/conf.d/modules to supply the list of modules to
> > >> be loaded?
> > >>
> > >> Does it use udev, or some other mechanism for that?
> > >>
> > >> Thanks.
> > >
> > > I understand it is udev magic which probes the hardware and it
> >
> > fetches the
> >
> > > corresponding module from the kernel, as long as it has been compiled.
> > > Incidentally, I noticed that I now have this running on my system:
> > >
> > > /lib/systemd/systemd-udevd --daemon
> >
> > The actual udev magic in question is this line from
> > /lib/udev/rules.d/80-drivers.rules:
> >
> > ENV{MODALIAS}=="?*", RUN{builtin}+="kmod load $env{MODALIAS}"
> >
> > When a new device is seen by the kernel (which includes cold-plug on
> > boot), udev calls the equivalent of `modprobe ${MODALIAS}` (in reality,
> > the actual command is now just a call to libkmod, which is linked into
> > udev itself), where ${MODALIAS} is the contents of the file "modalias"
> > under the /sys directory describing that device. This file may look
> > something like this (actual example from my machine):
> >
> > pci:v8086d0416sv1558sd7104bc03sc00i00
> >
> > This information (following the the initial "pci:", indicating that this
> > is a PCI device), can be split into multiple identifier/number pairs,
> > like so:
> >
> > v 8086
> > d 0416
> > sv 1558
> > sd 7104
> > bc 03
> > sc 00
> > i 00
> >
> > In this case I have vendor "8086" (Intel Corporation), device
> > "0416" (4th Gen Core Processor Integrated Graphics Controller),
> > subsystem vendor "1558" (CLEVO/KAPOK Computer), subsystem device
> > "7104" (not listed in pci.ids, sorry), base class "03" (Display
> > controller), sub class "00" (VGA compatible controller), and programming
> > interface "00" (VGA controller).
> >
> > This information is then used to look up the module in
> > /lib/modules/$(uname -r)/modules.alias (actually, modules.alias.bin is
> > used if present to speed up the lookup). This lookup finds the line:
> >
> > alias pci:v8086d0416sv*sd*bc03sc*i* i915
> >
> > As my card matches the glob in the second field in that line, the module
> > listed in the third field is loaded to handle the card. The actual
> > modules.alias file is generated by depmod when the module is installed
> > by reading the information from the module itself.
>
> Thanks for the explanation.
>
> Just to double check I understood it correctly, there's no need to put
> the list of kernel modules into /etc/conf.d/modules any longer, because
> udev is aware of the modules that have been built and will load them by
> consulting /lib/modules/$(uname -r)/modules.alias. Is that correct?
>
> Thanks.
No, it is incorrect, or I better say incomplete. There are some modules
(netfilter, virtualbox, et al.) which will not be autoloaded. You will need
to add those in your /etc/conf.d/modules and make sure the syntax is correct
for the kernel version that you intend to boot with.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message
Re: [gentoo-user] Confusing Portage Outcomes
> On May 21, 2014, at 13:33, Tom Wijsman wrote: > > On Wed, 21 May 2014 13:02:46 -0400 > Hunter Jozwiak wrote: > >> Hi all. I made the following in /etc/portage/make.conf >> #ACCEPT_LICENS="*" >> ACCEPT_KEYWORDS="~x86" >> Save and exit. >> To double check, I ran: >> #emerge --info | grep -i accept >> ACCEPT_LICENSES="* -@EULA" >> ACCEPT_KEYWORDS="x86 ~x86" >> The way it looks, the file just appended what I want to the Portage >> default. As far as the keywords variable is concerned, that will cause >> issues. Do I need to negate the defaults with the -? > > ACCEPT_LICENSES is commented out; so, yes, it'll use the default. > > ACCEPT_KEYWORDS I think that ~x86 includes, similar to how maintainers > specify KEYWORDS="x86" and not KEYWORDS="x86 ~x86" in their ebuilds; > I'm not entirely sure, but I think that would be the case. > > You can check with something like ACCEPT_KEYWORDS="~amd64 ~ppc ~x86" > which might result in something that lists all the stable ones as well. > > Negating x86 with - could be a possible solution; however, I wonder if > that's what you want as some packages have only stable versions. > > -- > With kind regards, > > Tom Wijsman (TomWij) > Gentoo Developer > > E-mail address : tom...@gentoo.org > GPG Public Key : 6D34E57D > GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D I commented that out for the purposes of having it in the email as a sort of example. It isn't actually commented I was in the file. So having the x86 and the ~x86 in the same variable would make a safe portage solution?
Re: [gentoo-user] Re: Having Trouble with Wireless Interface
On 05/18/2014 04:05 AM, Jonathan Callen wrote:
> On 05/15/2014 03:50 PM, Mick wrote:
> > On Thursday 15 May 2014 14:24:57 Alexander Kapshuk wrote:
> >> On 05/15/2014 11:39 AM, Stroller wrote:
> >>> On Wed, 14 May 2014, at 12:36 pm, Alexander Kapshuk
> > wrote:
> >> ?
> >> If you like to check if RTL8192CE is enabled in your kernel's
> .config
> >> file. If it isn't, you probably want to compile it as a module, and
> >> then add rtl8192ce to /etc/conf.d/modules as well.
> >
> > Am pretty sure there's no need to add this one to
> /etc/conf.d/modules -
> > IME it'll just be found and loaded automagically by the kernel.
>
> Thanks for pointing that out. I wasn't aware of that. As I
> mentioned in
> my previous post, I do not use genkernel myself.
> >>>
> >>> Neither do I - for this reason I found it a little frustrating
> trying to
> >>> help in a recent thread, myself.
> >>>
> >>> However, I'm pretty sure that loadable kernel modules behave the same
> >>> whether your kernel is built "by hand" or by genkernel - if you have
> >>> modules listed in /etc/conf.d/modules then I have to wonder if you
> >>> really need them there.
> >>>
> >>> I haven't used that file for years, and I prefer to compile
> everything as
> >>> a module, too.
> >>>
> >>> Stroller.
> >>
> >> That's interesting. I wasn't aware of that either.
> >>
> >> So far, I've just been following the instructions given in the
> handbook,
> >> section 7.d, which do recommend explicitly specifying the kernel
> modules
> >> to be loaded at boot time in /etc/conf.d/modules.
> >>
> >> How does the kernel know then what modules to load at boot time, if it
> >> doesn't rely on /etc/conf.d/modules to supply the list of modules to be
> >> loaded?
> >>
> >> Does it use udev, or some other mechanism for that?
> >>
> >> Thanks.
>
> > I understand it is udev magic which probes the hardware and it
> fetches the
> > corresponding module from the kernel, as long as it has been compiled.
> > Incidentally, I noticed that I now have this running on my system:
>
> > /lib/systemd/systemd-udevd --daemon
>
>
> The actual udev magic in question is this line from
> /lib/udev/rules.d/80-drivers.rules:
>
> ENV{MODALIAS}=="?*", RUN{builtin}+="kmod load $env{MODALIAS}"
>
> When a new device is seen by the kernel (which includes cold-plug on
> boot), udev calls the equivalent of `modprobe ${MODALIAS}` (in reality,
> the actual command is now just a call to libkmod, which is linked into
> udev itself), where ${MODALIAS} is the contents of the file "modalias"
> under the /sys directory describing that device. This file may look
> something like this (actual example from my machine):
>
> pci:v8086d0416sv1558sd7104bc03sc00i00
>
> This information (following the the initial "pci:", indicating that this
> is a PCI device), can be split into multiple identifier/number pairs,
> like so:
>
> v 8086
> d 0416
> sv 1558
> sd 7104
> bc 03
> sc 00
> i 00
>
> In this case I have vendor "8086" (Intel Corporation), device
> "0416" (4th Gen Core Processor Integrated Graphics Controller),
> subsystem vendor "1558" (CLEVO/KAPOK Computer), subsystem device
> "7104" (not listed in pci.ids, sorry), base class "03" (Display
> controller), sub class "00" (VGA compatible controller), and programming
> interface "00" (VGA controller).
>
> This information is then used to look up the module in
> /lib/modules/$(uname -r)/modules.alias (actually, modules.alias.bin is
> used if present to speed up the lookup). This lookup finds the line:
>
> alias pci:v8086d0416sv*sd*bc03sc*i* i915
>
> As my card matches the glob in the second field in that line, the module
> listed in the third field is loaded to handle the card. The actual
> modules.alias file is generated by depmod when the module is installed
> by reading the information from the module itself.
>
>
Thanks for the explanation.
Just to double check I understood it correctly, there's no need to put
the list of kernel modules into /etc/conf.d/modules any longer, because
udev is aware of the modules that have been built and will load them by
consulting /lib/modules/$(uname -r)/modules.alias. Is that correct?
Thanks.
Re: [gentoo-user] fstab cleanup
Am 21.05.2014 15:31, schrieb Tom H:
> On Wed, May 21, 2014 at 6:32 AM, Stefan G. Weichinger wrote:
>>
>> Do I still need these lines .. especially with a modern
>> systemd/gnome3-environment?
>>
>> # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
>> # POSIX shared memory (shm_open, shm_unlink).
>> # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
>> # use almost no memory if not populated with files)
>> tmpfs /dev/shmtmpfs
>> nodev,nosuid,noexec 0 0
>>
>>
>> /dev/cdrw /media/cdrecorder auto
>> user,exec,noauto,managed 0 0
>
> From "src/core/mount-setup.c":
>
> { "tmpfs", "/dev/shm", "tmpfs",
> "mode=1777", MS_NOSUID|MS_NODEV|MS_STRICTATIME, NULL,
> MNT_FATAL|MNT_IN_CONTAINER },
So the answer is "no" ?
Re: [gentoo-user] Confusing Portage Outcomes
On Wed, 21 May 2014 13:02:46 -0400 Hunter Jozwiak wrote: > Hi all. I made the following in /etc/portage/make.conf > #ACCEPT_LICENS="*" > ACCEPT_KEYWORDS="~x86" > Save and exit. > To double check, I ran: > #emerge --info | grep -i accept > ACCEPT_LICENSES="* -@EULA" > ACCEPT_KEYWORDS="x86 ~x86" > The way it looks, the file just appended what I want to the Portage > default. As far as the keywords variable is concerned, that will cause > issues. Do I need to negate the defaults with the -? ACCEPT_LICENSES is commented out; so, yes, it'll use the default. ACCEPT_KEYWORDS I think that ~x86 includes, similar to how maintainers specify KEYWORDS="x86" and not KEYWORDS="x86 ~x86" in their ebuilds; I'm not entirely sure, but I think that would be the case. You can check with something like ACCEPT_KEYWORDS="~amd64 ~ppc ~x86" which might result in something that lists all the stable ones as well. Negating x86 with - could be a possible solution; however, I wonder if that's what you want as some packages have only stable versions. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-user] Confusing Portage Outcomes
Hi all. I made the following in /etc/portage/make.conf #ACCEPT_LICENS="*" ACCEPT_KEYWORDS="~x86" Save and exit. To double check, I ran: #emerge --info | grep -i accept ACCEPT_LICENSES="* -@EULA" ACCEPT_KEYWORDS="x86 ~x86" The way it looks, the file just appended what I want to the Portage default. As far as the keywords variable is concerned, that will cause issues. Do I need to negate the defaults with the -?
Re: [gentoo-user] Use Flags and Updating
> What would you recommend? Thanks. I always use emerge -uDNav @world --with-bdeps=y --keep-going=y, as I want to update *all* packages on my system. What's the point in keeping on the system some packages that are deliberately not updated?
[gentoo-user] Digital Ocean Rigs and Distcc
Hi all. Is it possible to deploy a Digital Ocean rig and have it do distcc compiling? If so, is there documentation on it, and where?
Re: [gentoo-user] Fonts and bad eyes
On Wednesday 21 May 2014 10:28:58 I wrote: > Still hoping to find a font editor though, to replace that zero. Found one: http://sourceforge.net/projects/nafe/postdownload?source=dlp I've used it to remove the oblique stroke from the zero character and slope its shoulders. The result's not very polished, but it'll do pro tem. -- Regards Peter
Re: [gentoo-user] Use Flags and Updating
On 05/20/2014 11:56 PM, yac wrote: > On Tue, 20 May 2014 14:49:17 +0300 > Alexander Kapshuk wrote: > >> Here's what I usually run when updating the world. >> Long version: emerge --ask --update --deep --with-bdeps=y --newuse >> @world With '--with-bdeps=y' set in the file shown below: >> grep bdeps /etc/portage/make.conf >> EMERGE_DEFAULT_OPTS="--with-bdeps=y" >> >> Short version: emerge -avuND @world >> -a [--ask] >> -v [--verbose] >> -u [--update] >> -N [--newuse] >> -D [--deep] >> >> > It's also good to use -t --unordered-display to see what pulls what and > resolve potential issues. > > Then --keep-going so the whole thing doesn't fail just because one > package fails. > > Then -k to use already built binary packages where applicable > (Actually, I'm not sure why this sometimes gets activated but I see it > from time to time) > > Why do you run the the --width-bdeps=y ? > > --- > Jan Mate(jka| Developer > https://gentoo.org | Gentoo Linux > GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B After reading about the flag in the handbook, I thought I'd use it as well. http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 Code Listing 3.11: Updating your system with dependencies # emerge --update --deep @world Still, this doesn't mean all packages: some packages on your system are needed during the compile and build process of packages, but once that package is installed, these dependencies are no longer required. Portage calls those build dependencies. To include those in an update cycle, add --with-bdeps=y: Code Listing 3.12: Updating your entire system # emerge --update --deep --with-bdeps=y @world Since security updates also happen in packages you have not explicitly installed on your system (but that are pulled in as dependencies of other programs), it is recommended to run this command once in a while. What would you recommend? Thanks.
Re: [gentoo-user] Use Flags and Updating
On 05/20/2014 10:13 PM, Matti Nykyri wrote:
> On May 20, 2014, at 14:49, Alexander Kapshuk
> mailto:alexander.kaps...@gmail.com>> wrote:
>
>> On 05/20/2014 02:40 PM, Hunter Jozwiak wrote:
>>>
>>>
>>>
>>>
>>>
>>> *From:*Alexander Kapshuk [mailto:alexander.kaps...@gmail.com]
>>> *Sent:* Tuesday, May 20, 2014 7:44 AM
>>> *To:* gentoo-user@lists.gentoo.org
>>> *Subject:* Re: [gentoo-user] Use Flags and Updating
>>>
>>>
>>>
>>> On 05/20/2014 02:37 PM, Hunter Jozwiak wrote:
>>>
>>> Hi all. How do I get Portage to update all software to use my
>>> new USE flags? I made some modifications to the variable, and I
>>> want to make sure that all packages can use the flags.
>>>
>>> emerge(1)
>>> -N -- --newuse
>>>
>>> Thank you.
>>>
>> No worries.
>>
>> Here's what I usually run when updating the world.
>> Long version: emerge --ask --update --deep --with-bdeps=y --newuse @world
>> With '--with-bdeps=y' set in the file shown below:
>> grep bdeps /etc/portage/make.conf
>> EMERGE_DEFAULT_OPTS="--with-bdeps=y"
>>
>> Short version: emerge -avuND @world
>> -a [--ask]
>> -v [--verbose]
>> -u [--update]
>> -N [--newuse]
>> -D [--deep]
>
> And how to remember this... Make it a name:
>
> emerge -DuvaN @world
>
> Human mind is a complex organ ;)
>
> --
> -Matti
I just put this into a shell function.
sed -n '/chkupd/,/}/p' .bash_profile
chkupd(){
emerge --sync && emerge -avuND @world
}
Re: [gentoo-user] fstab cleanup
On Wed, May 21, 2014 at 6:32 AM, Stefan G. Weichinger wrote:
>
> Do I still need these lines .. especially with a modern
> systemd/gnome3-environment?
>
> # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
> # POSIX shared memory (shm_open, shm_unlink).
> # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
> # use almost no memory if not populated with files)
> tmpfs /dev/shmtmpfs
> nodev,nosuid,noexec 0 0
>
>
> /dev/cdrw /media/cdrecorder auto
> user,exec,noauto,managed 0 0
>From "src/core/mount-setup.c":
{ "tmpfs", "/dev/shm", "tmpfs",
"mode=1777", MS_NOSUID|MS_NODEV|MS_STRICTATIME, NULL,
MNT_FATAL|MNT_IN_CONTAINER },
Re: [gentoo-user] grub2 boots only older kernel
* wirel...@tampabay.rr.com [140519 21:25]: [SNIP] > It never tries to boot. Grub just sits there withe phrase (did not copy > it down) where it says what version it will boot on the screen > and it does nothing (locked up?) I have to or push > a manual reset. It never tries to load the kernel. Does not matter if > I try a 3.13.7 or 3.14.x, I've rebuilt them quite a few times and did > all the grub2 steps, but none of the newer kernels will boot. > > Nothing was done to the bios. The only change was to get rid of ATI > Frame buffer support as suggested upon a recent update: > > * Checking for suitable kernel configuration options... > * CONFIG_FB_RADEON:should not be set. But it is. > * Please check to make sure these options are set correctly. > * Failure to do so may cause unexpected problems. > > > > > James I've had problems like this with grub2 when it was trying to retain the graphics mode (sorry, I don't remember the line in grub.cfg since I've since removed it.) I usually find grub problems by entering the grub command line and typing the commands in the menuentry from /boot/grub/grub.cfg that doesn't work one at a time. Todd
[gentoo-user] fstab cleanup
Do I still need these lines .. especially with a modern systemd/gnome3-environment? -> # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory (shm_open, shm_unlink). # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will # use almost no memory if not populated with files) tmpfs /dev/shmtmpfs nodev,nosuid,noexec 0 0 /dev/cdrw /media/cdrecorder auto user,exec,noauto,managed 0 0 ?
Re: [gentoo-user] Fonts and bad eyes
On Sat, 17 May 2014 02:17:17 -0500, Dale wrote: > I'm just curious. Just reply and let me know what you use. I think I > need to change mine to something better. For monospace, Source Code Pro [1] (media-fonts/source-pro). For proportional, I prefer Helvetica (non-free) but among free options Liberation Sans (media-fonts/liberation-fonts). [1] http://blog.typekit.com/2012/09/24/source-code-pro/ -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: PGP signature
Re: [gentoo-user] Fonts and bad eyes
On Wednesday 21 May 2014 02:22:21 Walter Dnes wrote: > On Mon, May 19, 2014 at 12:23:53PM +0200, David Haller wrote > > > emerge terminus-font > > > > might help. E.g.: setfont ter-132n. But that seems to need a > > framebuffer, but you seem to have that ;) > > I like default8x16 better though. At least at vga=normal which gives > > me a nice 80x25 terminal ;) > > I now have 80x25 consolemode on the notebook. Thanks for that info. > My next goal is 80x40 etc. My screen is 27" and 1920 x 1080, so I can't imagine what vga=normal would look like :-) Too big, anyway. I've set consolefont="ter-124n" to give me a lovely VT screen. It does have a diagonal bar through the zero, though, as without it the zero and capital-O would be identical. At least at 12 x 24 I don't confuse 0 and 8. Still hoping to find a font editor though, to replace that zero. -- Regards Peter
