Um am Login Bildschirm von Fedora nur jene Konten anzuzeigen, die sich in letzter Zeit eingeloggt haben, muss man nur eine kleine Änderung an der /etc/gdm/custom.conf Datei vornehmen:
--- old/custom.conf 2011-07-07 09:35:01.462829111 +0200 +++ new/custom.conf 2011-07-07 09:30:27.146258540 +0200 @@ -7,6 +7,7 @@ [xdmcp] [greeter] +IncludeAll=false [chooser]
Damit werden nicht oder zB nur per scp genutzte Benutzernamen ausgeblendet.
In an earlier post, I already wrote about how to install the proprietary video driver on Fedora. In a brief update I suggested to change the acpi_sleep kernel option to accomplish proper display wake-up from standby. Unfortunately, that solution doesn’t work reliably in my experience. Today I found a solution that seems to successfully work around the problem of the black screen by waking up the screen “manually”.
Gernot Walzl wrote a “nasty workaround” (quoting himself) in the form of the following script:
#!/bin/sh # nvidia_dpms_fix.sh # 2011-06-12 # by Gernot WALZL # nasty workaround for nvidia drivers to resume from dpms off/suspend export DISPLAY=:0 getXauthority () { export XAUTHORITY=$(ps -C X -f | grep "$DISPLAY" \ | sed -n 's/.* -auth \([^ ]*\).*/\1/p') } handle_line () { if echo "$1" | grep -e "(EE) NVIDIA.* DisplayPort link training failed" \ > /dev/null; then getXauthority xset dpms force on fi } tail --follow=name /var/log/Xorg.0.log --retry --lines=1 2> /dev/null \ | while read line; do handle_line "$line" done
To actually make this do its job, I copied it into /usr/local/bin, made it executable and created an autostart entry for GNOME 3 by saving the following lines under ~/.config/autostart/nvidia_dpms_fix.sh.desktop
[Desktop Entry] Type=Application Exec=/usr/local/bin/nvidia_dpms_fix.sh Hidden=false X-GNOME-Autostart-enabled=true Name=NVidia DPMS fix Comment=Wakes up the display properly
I believe the problem that is being worked around is indicated by a line in the Xorg.0.log:
(WW) NVIDIA(GPU-0): AUO (DFP-3): Failed to set DisplayPort power state
Although I could only test this on my machine (HP EliteBook 8440p), with some luck this works for all cases where a similar log message is found.
Ever since I upgraded my notebook with a SSD, I was looking for a way to minimise or avoid unnecessary write accesses. The tools of choice (on Linux at least) are iostat for a rough summary and pidstat for the details. With the help of those two one can easily figure out which processes are responsible for write accesses.
Once a writing process is identified, lsof can tell you which files are actually written. Depending on what you want to achieve, you can then continue to relocate that file to a different disk (e.g. if you have two disks and want one of them to sleep most of the time) or to memory (using tmpfs). The latter obviously means that the written data will be lost at the next reboot, but sometimes this is perfectly fine e.g. for the files inside /tmp. Therefore, it is generally a good idea to move that directory into volatile memory following the instructions on the openSUSE Wiki.
All good and well if you actually manage to relocate or move a file. Often file locations are a matter of configuration and otherwise you can help yourself with dynamic links. But there was one very special file on my openSUSE 11.4 installation that withstood all my assaults for quiet some time. I’m speaking of a beast called .xsession-errors residing in your $HOME directory. Created by KDM, one would expect to be able to configure the location of that file. Indeed, there is a configuration option called ClientLogFile specifically for that purpose. Unfortunately this is only the first and easier of two necessary steps:
root open your /usr/share/kde4/config/kdm/kdmrc, go to a section labelled [X-:0-Core] (there may be multiple of those, but don’t worry and just pick the last one) and add the following line:
ClientLogFile=../../tmp/xsession-errors-%u
This will move the file into the /tmp directory. Mind the path relative to $HOME.
root open your /etc/X11/xdm/Xsession and make the following changes (I deliberately use the patch syntax here i.e. remove lines with a minus sign and add those with a plus sign):
--- Xsession.old 2011-05-01 19:46:40.000000000 +0200 +++ Xsession 2011-05-02 22:18:39.000000000 +0200 @@ -123,8 +123,8 @@ # GDM seems to handle this its self test -z "$GDMSESSION" || break - # Once if KDM does handle this its self - #test -z "$KDMSESSION" || break + # KDM handles this itself + test -z "$KDE_SESSION_VERSION" || break # Avoid bad symbolic links case "$errfile" in
Done; logout, restart KDM, re-login and check if the xsession-errors* exists at the new location. If so, remove your old one and cheer to a long living SSD. Only, of course, if the new location is not on your SSD, but e.g. in memory. It doesn’t hurt to re-check with pidstat.
As already mentioned in my last post, my laptop won’t boot from a USB stick prepared using a binary copy of an ISO (by means of dd). Here is the method I use to boot the Fedora Live images off my USB stick using GNU GRUB2. The device node of the USB driver is denoted /dev/sdX in the following and must be replaced with the actual device node (e.g. /dev/sdc).
fdisk -l /dev/sdX is your friend)mount -o loop /path/to/iso /mnt/loopgrub-install --no-floppy --root-directory=/mnt/usb /dev/sdX/mnt/usb/boot/grub/grub.cfg with the following content
menuentry "Fedora Live" {
linux /isolinux/vmlinuz0 root=live:LABEL=XYZ rootfstype=auto ro liveimg quiet rhgb rd_NO_LUKS rd_NO_MD rd_NO_DM
initrd /isolinux/initrd0.img
}
menuentry "Fedora Live (Basic Video)" {
linux /isolinux/vmlinuz0 root=live:LABEL=XYZ rootfstype=auto ro liveimg quiet rhgb rd_NO_LUKS rd_NO_MD rd_NO_DM xdriver=vesa nomodeset
initrd /isolinux/initrd0.img
}where XYZ must be replaced by the actual partition name of your USB partition.
Often, the simple answers are those you don’t find on the web. Here is one of them with hopefully enough keywords to make it findable:
To activate the Ambient Light Sensor on my new HP EliteBook 8440p (article and pictures will follow later) running Fedora 13, the following command (issued by root obviously) did the trick:
echo 1 > /sys/devices/platform/hp-wmi/als
Also don’t forget to check if the ALS is enabled in the BIOS if this doesn’t work. It seems to be enabled by default though.