+ 3 - 2 | § ¶Test Entry For Tags.
Just a test entry.
Keywords: bar,beryl,debian,foo
+ 3 - 0 | § ¶KDE4 with KDE3
While the Debian KDE Team has done a great job of packaging KDE4 in time, with quality, it is not always possible to fulfill the request of every odd user.
Unfortunately, I fell into the Odd user category because I still want to have KDE4 and KDE3 installed together. For many reasons.
So here's one way to do it.
- Install KDE 3 Packages from Debian Repositories
- Install KDE 4 from SVN
- Create a X session file like this.
rrs@learner:~$ cat /usr/share/xsessions/kde4-svn.desktop
[Desktop Entry]
Encoding=UTF-8
Type=XSession
Exec=/opt/kde4-svn/kde/bin/startkde
TryExec=/opt/kde4-svn/kde/bin/startkde
- Add the following to your .bashrc file
if [ $DESKTOP_SESSION == "kde4-svn" ]; then
# KDE
export KDE4DIR=/opt/kde4-devel
export KDEDIR=$KDE4DIR/kde
export KDEHOME=$HOME/.kde4-devel
export KDETMP=/tmp/$USER-kde4
mkdir -p $KDETMP
export KDEVARTMP=/var/tmp/$USER-kde4
export KDEDIRS=$KDEDIR
export PKG_CONFIG_PATH=$KDEDIR/lib/pkgconfig:$PKG_CONFIG_PATH
export PATH=$KDEDIR/bin:/usr/local/bin:$PATH
export LD_LIBRARY_PATH=$KDEDIR/lib:$LD_LIBRARY_PATH
unset XDG_DATA_DIRS # to avoid seeing kde3 files from /usr
unset XDG_CONFIG_DIRS
# This will make the debug output prettier
export KDE_COLOR_DEBUG=1
export QTEST_COLORED=1# Make
# Tell many scripts how to switch from source dir to build dir:
export OBJ_REPLACEMENT="s#$KDE_SRC#$KDE_BUILD#"
# Use makeobj instead of make, to automatically switch to the build dir.
# If you don't have makeobj, install the package named kdesdk-scripts or
# kdesdk, or check out kdesdk/scripts from svn, or just don't set the alias
# yet.
alias make=makeobj
fi
- And then restart KDM and select KDE4-SVN from the listi of available Window Managers.
This will ensure that your KDE3 Data and Settings are safe and intact while you can still play with all of KDE4 and help the KDE team with bug reports. 
Keywords: kde4___kde3,kde4___kde3_on_debian
+ 3 - 1 | § ¶KDE4
Keywords: kde4_kde_debian
+ 2 - 2 | § ¶Linux SCSI Persistent Device Detection
Many of us might be aware of the block level encryption features (LUKS for example) provided in Linux.
Most of the articles that I referred to over the internet mention the usage of the traditional scsi block device when creating it as an ecrypted device. Eg. sudo cryptsetup luksFormat /dev/sdb1
This actually poses a problem. The problem is with the way Linux detects SCSI devices. While many distributions have shifted to using ID/LABEL based access to devices, users still use the old traditional way of using a device. This turns out to be a problem in cases like suspend/resume where devices are rediscovered. Technically there is no guarantee that the device you see currently as sda will be named sda again on reboot/resume. While we don't see issues like this with attached disks, the issue can be easily reproduced in a SAN Enviornment or in cases where users use external hard drives using USB.
I faced the same issue with my external USB Hard Drive which I use for backups. This has an encrypted device to which I backup using a software like keep. To rectify the proble, all I had to do to recreate the encrypted device was to refer the SCSI device by its device ID.
sudo cryptsetup luksFormat /dev/disk/by-id/usb-WDC_WD12_00BEVE-11UYT0_ST_Killer-0:0-part2
This would now work across reboots/resumes because the device ID for the device will not change and will remain persistent.
Here's how the devices look in /dev:
rrs@learner:~$ ls -l /dev/disk/by-id/
total 0
lrwxrwxrwx 1 root root 9 2008-01-08 13:37 ata-Hitachi_HTS72106-MPCC14Y3GUX6LE -> ../../sda
lrwxrwxrwx 1 root root 10 2008-01-08 13:37 ata-Hitachi_HTS72106-MPCC14Y3GUX6LE-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2008-01-08 13:37 ata-Hitachi_HTS72106-MPCC14Y3GUX6LE-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2008-01-08 13:37 ata-Hitachi_HTS72106-MPCC14Y3GUX6LE-part3 -> ../../sda3
lrwxrwxrwx 1 root root 9 2008-01-08 13:37 scsi-S_MPCC14Y3GUX6LE -> ../../sda
lrwxrwxrwx 1 root root 10 2008-01-08 13:37 scsi-S_MPCC14Y3GUX6LE-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2008-01-08 13:37 scsi-S_MPCC14Y3GUX6LE-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2008-01-08 13:37 scsi-S_MPCC14Y3GUX6LE-part3 -> ../../sda3
lrwxrwxrwx 1 root root 9 2008-01-09 00:05 usb-WDC_WD12_00BEVE-11UYT0_ST_Killer-0:0 -> ../../sdc
lrwxrwxrwx 1 root root 10 2008-01-09 00:05 usb-WDC_WD12_00BEVE-11UYT0_ST_Killer-0:0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 2008-01-09 00:05 usb-WDC_WD12_00BEVE-11UYT0_ST_Killer-0:0-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 2008-01-09 00:05 usb-WDC_WD12_00BEVE-11UYT0_ST_Killer-0:0-part3 -> ../../sdc3
lrwxrwxrwx 1 root root 10 2008-01-09 00:05 usb-WDC_WD12_00BEVE-11UYT0_ST_Killer-0:0-part4 -> ../../sdc4
lrwxrwxrwx 1 root root 10 2008-01-09 00:05 usb-WDC_WD12_00BEVE-11UYT0_ST_Killer-0:0-part5 -> ../../sdc5
lrwxrwxrwx 1 root root 10 2008-01-09 00:05 usb-WDC_WD12_00BEVE-11UYT0_ST_Killer-0:0-part6 -> ../../sdc6
As you can notice, currently my usb disk is pointing to sdc where as on a reboot it will return back to the proper order and would be listed as sdb.
Keywords: scsi_id_cryptsetup_luks_encrypted_disk