SystemRescueCd is my favorite Linux live CD’s for system recovery and related tasks. It is based on Gentoo and comes with all the right toys to make me happy. 🙂
Tag: Gentoo (Page 1 of 2)
I don’t believe in system passwords if they’re not backup by some type of disk encryption. It’s simply too easy to circumvent by changing a few boot parameters or by inserting a good boot disk. For performance reasons, I’ve decided against using full-disk encryption for my laptop and even against encryption for my home folder. This makes typing in a password to login a mere annoyance. Admittedly, my laptop features a fingerprint reader, but at the time I couldn’t get it to work and it still requires me to type in my username, which I find just as superfluous. Also, fingerprints aren’t that secure either.
For ages now, I’ve just wanted to be automatically logged in and greeted by an X session when I boot, especially since my xdm died after some upgrade about a year ago or so ago. For how much time I spend with this machine, I’m amazed how long it takes me before deciding that logging in in the console and typing startx might be not such a good idea.
(It probably has everything to do with “conditionality”. I tell myself, for example, that before ditching xdm (which is one of the few X login managers which doesn’t support auto login), I first need to get it to work again to make a screenshot of my “cute” configuration. Can’t kill my darlings; never could.)
So fuck all that. I’m too lazy to resurrect my darling, no matter how cute, so I took a look at this and added to following to /etc/conf.d/local.start:
# Start X as user if tty7 is free ! fuser /dev/tty7 >& /dev/null; su - bigsmoke -l -c 'exec startx -- vt7 >& ~/.xsession-errors' &
Done. Maybe I’ll also decide to make all my console sessions auto-login, if I can be arsed, that is.
I’m playing with g-cpan to try to install WordPress::Post in Gentoo without causing the usual mess.
When I went from X.org < 7.3 to X.org > 7.3, I had to make some changes to my X input configuration.
First of all, I had to replace x11-drivers/synaptics (http://web.telia.com/~u89404340/touchpad/) with the newer x11-drivers/xf86-input-synaptics, which is automatically installed if you set INPUT_DEVICES="${INPUT_DEVICES} synaptics" or if you add “x11-base/xorg-server input_devices_synaptics” to /etc/portage/package.use.
Starting with X.org 7.3, you’re supposed to use HAL for all the X input configuration. All the "InputDevice" sections have to be removed from xorg.conf (and of course the references in "ServerLayout"). If you don’t want this, you can add the following options:
Section "ServerFlags" Option "AllowEmptyInput" "off" Option "AutoEnableDevices" "off" EndSection
I chose HAL. I wanted to replicate the following settings using HAL.
Section "InputDevice" Identifier "Keyboard1" Driver "kbd" Option "AutoRepeat" "500 30" Option "XkbRules" "xorg" Option "XkbModel" "thinkpadintl" Option "XkbLayout" "us" Option "XkbOptions" "ctrl:nocaps,altwin:menu,compose:ralt,eurosign:e" EndSection Section "InputDevice" Identifier "Synaptics Touchpad" Driver "synaptics" Option "SendCoreEvents" "true" Option "Device" "/etc/psaux" Option "Protocol" "auto-dev" # Auto detect # Option "TouchpadOff" "1" #Uncomment if you just want to disable the touchpad and use only the trackpoint # Option "HorizScrollDelta" "0" #Why is this in here by default. By Gods, it kill horizontal scrolling! Option "RightEdge" "5500" #This is a little bigger than the default narrowing the scroll region Option "BottomEdge" "4500" #This is a little bigger than the default narrowing the scroll region Option "RTCornerButton" "0" #disable Right Top corner "button" Option "RBCornerButton" "0" #disable Right Top corner "button" Option "SHMConfig" "on" #this allows configuration of the touchpad using qsynaptics, synclient, or what have you EndSection
The keyboard part was easy. I copied /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi to /etc/hal/fdi/policy/99-keymap.fdi and made a few adjustments:
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- --> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.keymap"> <append key="info.callouts.add" type="strlist">hal-setup-keymap</append> </match> <match key="info.capabilities" contains="input.keys"> <merge key="input.xkb.rules" type="string">xorg</merge> <!-- If we're using Linux, we use evdev by default (falling back to keyboard otherwise). --> <merge key="input.xkb.model" type="string">thinkpadintl</merge> <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux"> <merge key="input.xkb.model" type="string">evdev</merge> </match> <merge key="input.xkb.layout" type="string">us</merge> <merge key="input.xkb.variant" type="string" /> <merge key="input.xkb.autoRepeat" type="string">500 30</merge> <merge key="input.xkb.options" type="string">ctrl:nocaps,altwin:menu,compose:ralt,eurosign:e</merge> </match> </device> </deviceinfo>
The Touchpad configuration was a little more involving, because I added a few options which, before, I didn’t know the thing supported. 99-x11-synaptics.fdi:
<?xml version="1.0" encoding="ISO-8859-1"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.touchpad"> <merge key="input.x11_driver" type="string">synaptics</merge> <!-- Arbitrary options can be passed to the driver using the input.x11_options property since xorg-server-1.5. --> <!-- Switch on shared memory, enables the driver to be configured at runtime --> <!-- This allows configuration of the touchpad using qsynaptics, synclient, or what have you --> <merge key="input.x11_options.SHMConfig" type="string">on</merge> <!-- Enable vertical scrolling by dragging your finger along the right edge --> <merge key="input.x11_options.VertEdgeScroll" type="string">1</merge> <!-- Enable horizontal scrolling by dragging your finger along the left edge --> <merge key="input.x11_options.HorizEdgeScroll" type="string">1</merge> <!-- This is a little bigger than the default narrowing the scroll region --> <merge key="input.x11_options.RightEdge" type="string">5500</merge> <!-- This is a little bigger than the default narrowing the scroll region --> <merge key="input.x11_options.BottomEdge" type="string">4500</merge> <!-- disable Right Top corner "button" --> <merge key="input.x11_options.RTCornerButton" type="string">0</merge> <!-- disable Right Bottom corner "button" --> <merge key="input.x11_options.RBCornerButton" type="string">0</merge> <!-- Enable vertical scrolling when dragging with two fingers anywhere on the touchpad --> <merge key="input.x11_options.VertTwoFingerScroll" type="string">1</merge> <!-- Enable horizontal scrolling when dragging with two fingers anywhere on the touchpad --> <merge key="input.x11_options.HorizTwoFingerScroll" type="string">1</merge> <!-- Enable tapping to emulate mouse buttons --> <merge key="input.x11_options.TapButton1" type="string">1</merge> <merge key="input.x11_options.TapButton2" type="string">2</merge> <merge key="input.x11_options.TapButton3" type="string">3</merge> <!-- Maximum movement of the finger for detecting a tap --> <merge key="input.x11_options.MaxTapMove" type="string">221</merge> <!-- For other possible options, check CONFIGURATION DETAILS in synaptics man page --> </match> </device> </deviceinfo>
I’m still not completely satisfied with the Touchpad configuration (actually less so than before I started messing with HAL), so I wrote a little tool to be able to mess around with my configuration a little bit easier.
Introducing synclient-sync
With SHMConfig on, you can use the synclient program to make changes to the touchpad configuration without having to restart X. I decided that it would be handy if I could utilize this to test out changes I made to the HAL config file without having to reload it, so I wrote a little script which detects the differences between the current (live) configuration and the configuration in the HAL .fdi file. The running configuration is then updated to reflect the changes in this file. (Newer versions of the script can be found on GitHub)
#!/bin/bash HAL_FILE=/etc/hal/fdi/policy/99-x11-synaptics.fdi VERBOSITY_LEVEL=2 usage() { cat <<EOF Usage: $0 options OPTIONS: --verbosity [level] Control the level of output processed by the script. Level 0: No output at all Level 1: Only output changed options Level 2: Only output options the configuration file Level 3: Output all options --verbose Shortcut verbosity level 3 - Show this EOF 1 } options_from_hal_file() { HAL_SED_FILTER='s%^\s*<merge\s*key="input\.x11_options\.\(.*\?\)"\s*type="string">\(.*\)</merge>%\1=\2%' cat $HAL_FILE \ | grep '<merge key="input.x11_options.' \ | grep -v 'SHMConfig' \ | sed -e $HAL_SED_FILTER } from() { synclient -l \ | grep '=' \ | sed -e 's/\s//g' \ | option; key= $option|cut -f 1 -d '='` old_val= $option|cut -f 2 -d '='` new_val=`options_from_hal_file|grep $key|cut -f 2 -d '='` [ -z $new_val ]; [ $VERBOSITY_LEVEL == 3 ] && -e "\e[1;30m$key = $old_val\e[0m" [ $old_val != $new_val ]; [ $VERBOSITY_LEVEL -ge 1 ] && -e "\e[1m$key = \e[1;31m$old_val \e[1;4;32m$new_val\e[0m" synclient "$key=$new_val" # The HAL file and the life configuration are in sync [ $VERBOSITY_LEVEL -ge 2 ] && -e "\e[1m$key = \e[4m$new_val\e[0m" } do_from=0 [ $# -gt 0 ]; do "$1" --from-hal) do_from=1 ;; --verbose) VERBOSITY_LEVEL=3 ;; --verbosity) VERBOSITY_LEVEL=$2 ;; -) usage ;; [ $do_from == 1 ]; from usage # vim: set shiftwidth=4 tabstop=4 expandtab:
References
When I installed this laptop last year, I was pleasantly surprised by the performance of vanilla Wine (and Gentoo’s default Wine configuration). At that time, my only memory of Wine was that getting anything useful to work took work and that your best bet to get anything working was to install CrossOver Office. Things change and in the meantime Wine has even come to version 1.0.
I want to write down what I had to do to be able to execute Windows executables as if they are Linux native. This can be done thanks to Linux’ support for misc. binaries.
First, you have to enable CONFIG_BINFMT_MISC in your kernel configuration. If it was configured as a module, run /sbin/modprobe binfmt_misc
.
Then you have to register the appropriate binary formats:
':windows:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register
That’s it. Of course, the .exe files need to have their executable bit set:
chmod u+x program.exe
Done.
I’m trying to upgrade my qt 4.3 to 4.5. Version 4.5 seems to be split up in several ebuils, one of which is qt-dbus. When trying to install qt-dbus, it says that the files conflict with qt-4.3. This is only normal, because in version 4.3, the files did belong to qt.
The thing is, some time ago, collision protection was disabled by default, which I thought made sense because when I tried enabling it, I’d get errors like these all the time. I disabled it for now (by putting “-collision-protect -protect-owned” in the FEATURES variable in make.conf), to be able to install Qt, but because it is enabled by default, I’d rather not keep it disabled.
(Text was copied from the post I made on the Gentoo forum about it.)
I always thought I had portage’s compile cache enabled, but upon recent inspection, it appears that I didn’t. What was missing, was the package dev-util/ccache. I also increased the cache size to 2 GB, as per the Gentoo documentation.
I noticed this because recently, portage started saying this:
!!! Directory does not exist: '/usr/lib/ccache/bin' !!! Disabled FEATURES='ccache'
This Gentoo box needs upgrading badly. I started this in February, so perhaps it’s time to continue.
Trying to update the world profile causes a few too many problems, so I start with updating everything in the system profile:
# emerge --update --deep --newuse system
sys-apps/man-pages
The first blockage of the day is “sys-apps/man-pages-3” that is blocking “sys-apps/man-pages-posix-2003a“. The latter is pulled in by “sys-apps/man-pages-posix“, which in turn is required by “sys-apps/man-pages-3.20“.
Somehow, unmerging “sys-apps/man-pages” resolved this blockage:
# emerge --unmerge sys-apps/man-pages
I just had to ignore a few warnings about the package being part of my system profile and I could reissue the system update command. The unmerged package is neatly remerged.
# emerge --update --deep --newuse system
This command started merging 99 packages. The only interruption left in this process was caused by the savedconfig use flag which made the busybox ebuild fail.
During the first gentoo update session for this machine, I didn’t get very far. I already mentioned the problem I had with e2fsprogs, but this was not the first or the last problem that I had.
Until a few moments ago, I actually thought I made a bit of a fuck-up. I was meaning to make regular snapshots of /etc/portage files for a while now, because I was always just an echo something >> /etc/portage/package.keywords
with one >
-symbol too few away from destroying my configuration. Despite this fear, I thought I had already started deleting entries from /etc/portage/package.keywords and /etc/portage/package.unmask without backing up first.
Luckily, it turns out that I did make a dated copy of /etc/portage/package.keywords before starting on my modifications. I didn’t do so for /etc/portage/package.unmask, but I recovered a recent enough version from a recent full system rsync backup. So, everything is good. Still, I’m glad that I now use Git to track all changes in /etc/. All this goes to show that my methods are sometimes a bit more organized than my mind, which, I suppose, is a good thing. 😕
The point of this post—yes, there is a point—the point is that once you start mixing stable and unstable stuff, your system becomes, ehm, unstable. I have this huge amount of crap already in /etc/portage to cater to my wish to run stuff that I know to be quite stable but that isn’t yet marked as such in the Gentoo porttree. Now, after many months, I want to remove everything from package.keywords and package.unmask that is no longer necessary.
I was going to write about all the complicated upgrades, downgrades and conflicts suggested by Portage (mostly related to me removing KDE 4 stuff from package.keywords and package.unmask), because I was confused about what changes I had made. With the relevant backups readily available for comparison, I am no longer in a hurry to untangle my thoughts and I’ve moved the preliminary notes to a new draft for when I’ll actually update KDE 4.
Actual justification for this post
I’m trying to get into a blogging style were I post a lot more rubbish like this that can’t possibly be of any use to anybody except myself. I have plenty of reasons/excuses for this (about which I’ll likely post in the future), but I shouldn’t actually need any. That Ryan wanker who thinks I publish this blog for him should really shut the fuck up. Sure enough, he isn’t talking about this blog but I still think he’s a big-time asshole. Fuck you, Ryan!
During my recent Gentoo update session, I was once again confronted with the inconvenience of not having my /etc/ directory under version management. This time, I thought I had the ideal SCM for this job: Git.
I found a blog post of a chap who has done the same. It includes a few notes I might not have thought about on my own and also a few very cool Debian tricks.
One of the steps that I might have overlooked myself is that it’s essential to make the .git directory group/world inaccessible with chmod go-rwx
. If I would have forgotten this, a smart attacker might use my Git repo to access forbidden file contents.
The author also describes a cool Post-Invoke for Debian’s dpkg that will automatically stage and commit configuration changes made by apt/dpkg (although, later, he mentions that Debian has gotten a package could etckeeper that does this automatically.
Now I would like to learn how I can let Gentoo’s etc-update do as much. In its /etc/dispatch-conf.conf I can only find the option to use (of all things) RCS to track replaced configuration files in a special directory (/etc/config-archive/ by default). Hopefully, there is some drop-in replacement for etc-update which does this and which can rid me of etc-update’s awkward interface at once.
Recent Comments