Monday, February 16, 2015

xorg odds and ends, xorg.conf

xterm settings

In Arch it's become slightly difficult to implement xterm settings. The way Xorg initializes has changed -- it no longer directly loads .Xdefaults or .Xresources. Instead, they are called by .xinitrc. Sometimes, this extra step fails and your xterm will look vanilla.

Troubleshoot: save either .Xresources or .Xdefaults. I kept .Xresources and therefore deleted .Xdefaults, but I could have switched this. Add your xterm customizations to whichever of the two is kept. Check these customizations by loading the file directly...
$ xrdb .Xresources
...then open a new xterm to see if it looks configured.

If xterm still looks vanilla, .Xresources needs additional work. However if xterm looks proper, then .xinitrc needs work, since it's not calling .Xresources. Correct .xinitrc, logout, restart X, then open an xterm to see if it's been remedied.

xorg install order

  1. # pacman xf86-video-ati There are several drivers to pick from; you'll need the correct one for your chip. I found my chip this way:
    $ lspci |grep vga
    VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780MC [Mobility Radeon HD 3100]
    So I had the Radeon HD 3100 RS780MC chip, which corresponded with the xf86-video-ati driver. Since it's radeon, I also proceeded with the next step; others may not need it
  2. # nano /etc/mkinitcpio.conf
    # mkinitcpio -p linux
    # reboot
  3. # pacman xorg-xinit xorg-server xorg-server-utils xorg-apps (80Mb)
  4. # pacman icewm icewm-themes (20Mb) just get some WM in there to test all the settings
  5. # pacman dillo a light browser for looking stuff up about the install
  6. get the skeletons for /etc/X11/xinit/xinitrc, /usr/share/icewm (the entire directory, then chown it and change it to ".icewm"), and /etc/dillo/dillorc
  7. modify ~/.xinitrc to add "exec icewm"
  8. I like to reboot here, before starting X, but some might just logout and log back in. Either way, "startx", and then tweak and add apps


x configuration is a persisting mystery. The following may help in Arch.
  1. the files to configure 90% of your X session are in /etc/X11/xorg.conf.d/ directory
  2. create /etc/X11/xorg.conf.d/10-extras.conf for your custom stuff, like screen blanking, Blender mouse remapping, and so on -- all in one file
  3. the config files can have multiple "ServerLayout", "InputDevice", etc. sections
  4. comments in configuration files in the directory are with pound sign "#"
  5. .xinitrc and .Xresources play about a 10% role
  6. /etc/profile.d/ is important for "locales", which affect font encoding. You want all of these to be "C"

Sunday, February 15, 2015

[solved] distributed install (Tex Live info also)

Typically, the details I need to operate within Linux are difficult to find on the Net, yet what I don't need seems written again and again nearly everywhere on the Net. I often must acknowledge to myself later that, what I couldn't find at the time was too simple for anyone to even bother typing.

Recent example. For years, I've wanted to backup my data directory quickly, so I could have a cron backup script to automate it. "Quickly" to me also meant "dd" (data destroyer, lol) instead of "rsync" or "cp". In turn, "dd" meant "unmounted" --- I don't want "live acquisition" for a directory as important as "/home". But I could not grasp how a separate, unmountable, partition for "/home" would work exactly.

The allocations for each partition seemed easy: I used...
$ du -ch
... to determine usage, and formulated a plan for splitting-up the drive: 10G swap, 30G install, the rest to /home. But I couldn't figure out how to do it. How would applications find the partition containing the data files? Dual booters run into that problem, for example.

fstab - the key

One day, I was struggling with the problem and I finally recalled a Linux basic: everything is a network, everything is a file. For example, how does a worker in Building A access his home directory on a server in Building B? Of course! fstab would simply mount it. Fstab was the solution and it was so simple it's little wonder no one had bothered to explain this in their distributed install instructions.

new Arch install

Solution in hand, the new install had 3 pieces: "/home", "/", and "swap" (some add a separate boot partition also). Using cfdisk, I sized each partition as noted above. Then...
# mkswap /dev/sda3
# swapon /dev/sda3
# mount -rw -t ext3 /dev/sda1 /mnt
# mkdir /mnt/home
# mount -rw -t ext3 /dev/sda2 /mnt/home
# genfstab -p /mnt >> /mnt/etc/fstab
...and all was good. The rest of the install was normal. Knowing the mounting commands and their order were the key. The root directory had to be mounted first, then other directories, such as /home.

I also put the TexLive distro (4.5G) into /home, since it's so large. I don't use the Arch repo version, since the full install is more complete. To install, create a directory called, eg., "/home/foo/latex" and, using command "D" during the install, supply the directory information. TL will create the necessary environment within your userspace, no root required. You will just have to update your PATH variables subsequently (see below).
$ cd /home/foo/latex/install-tl-20150525/
$ ./install-tl
command: D

After install, TexLive provides a reminder about paths.
Add /home/foo/latex/texlive/2015/texmf-dist/doc/info to INFOPATH.
Add /home/foo/latex/texlive/2015/texmf-dist/doc/man to MANPATH
(if not dynamically found).

Most importantly, add /home/foo/latex/texlive/2015/bin/x86_64-linux
to your PATH for current and future sessions.

Welcome to TeX Live!
You can test the PATH by attempting to compile,say,a small test TEX file with $ pdflatex test.tex". If the command isn't found, then bash needs the PATHs. You could 1) make a small executable to add paths in /etc/profile.d./ or, 2) add:
$ nano .bashrc
export PATH=/home/foo/latex/texlive/2015/bin/x86_64-linux:$PATH
export INFOPATH=/home/foo/latex/texlive/2013/texmf-dist/doc/info:$INFOPATH
export MANPATH=/home/foo/latex/texlive/2015/texmf-dist/doc/man:$MANPATH
Exit the X session and logout of the user (eg, "foo"), then log back in. The bash paths should be updated and TexLive normally available from non-X terminal, xterm, geany, etc.


Simple now.The format of "dd":
dd if=[source] of=[target] bs=[byte size]
Essentially, "dd" goes from a device to a file. The easiest large file is probably an ISO. One other thing, "dd" copies the entire device, including the empty areas -- it's a copy -- so the target device has to be as large as the source, unless one compresses.
Steps: assume here that home directory /dev/sda2 is to be backed up to a usb drive, /dev/sdb1.
  • boot-up into CLI
  • determine the block/byte size of /dev/sda2 (typically 4k these days), by writing an extremely small file, far below the size of a full block (for example a file only containing the number "1"), and then checking its disk usage (du):
    $ echo 1 > test
    $ du -h test
      4.0 Kb   test
  • Verify the file system format, eg Reiser, ext3, etc. You can use "lsblk -fs /dev/sda2" or "file -sL /dev/sd*".
  • # umount /dev/sda2 (no writing to the partition; we want a clean backup)
  • attach the usb drive (/dev/sdb)
  • dd if=[source] of=[target] bs=[byte size]
  • # dd if=/dev/sda2 of=/dev/sdb1/20150210.iso bs=4k conv=sync,noerror
  • profit.
Profit unless you inverted your source and target drive names ("i" and "o" are next to each other on the keyboard) -- in which case dd wrote from the back-up drive to your HDD, destroying your HDD data.

Sunday, February 8, 2015

[solved] clipboard note - clipit

A very useful note was found in this gentleman's post. I was receiving confounding GLIBC errors when loading clipit. They didn't make sense. Appears sometimes the configuration can become corrupted. Simply delete it.
$ cd .local/share/
$ rm -r clipit/
Clipit loaded normally again.


On a friend's HP system with all that proprietary HP keyboard and so on, there is an error which is not relieved by removing clipit's history. This was so intransigent that I emailed the developer. It's in line 1018 of the C code.