I tried testing my software raid (mdadm) setup by removing one of the disks. When I tried to boot the degraded system, the system hanged displaying a purple screen. If I try booting the system in recovery mode, I get the following error:
![** WARNING: There appears to be one or more degraded RAID devices ** The system my have suffered a hardware fault, such as a disk drive failure. The root device may depend on the RAID devices being online. Do you wish to start the degraded RAID? [y/N]:](https://i0.wp.com/www.guyrutenberg.com/wp-content/uploads/2013/11/degraded_raid.png)
The system my have suffered a hardware fault, such as a disk drive failure. The root device may depend on the RAID devices being online.
Do you wish to start the degraded RAID? [y/N]:
mobi and epub Files in UbuntuYou can do it with Calibre and specifically with the ebook-viewer program that comes with it. However, for some reason the packagers didn’t ship a desktop file to accompany it, so you can’t just double-click on eBooks and have them opened correctly. This can be corrected by placing a ebook-viewer.desktop file in ~/.local/share/applications:
[Desktop Entry]
Version=1.0
Name=Ebook Viewer
Comment=Display .epub files and other e-books formats
Type=Application
Terminal=false
Icon=calibre
Exec=ebook-viewer %f
StartupWMClass=ebook-viewer
MimeType=application/x-mobipocket-ebook;application/epub+zip;
Categories=Graphics;Viewer;
It’s a hassle.
The first step is to grab the 64bit deb package from Citrix website. Next install it using dpkg:
~$ sudo dpkg --install Downloads/icaclient_12.1.0_amd64.debThis results in the following error:
dpkg: error processing icaclient (--install): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: icaclient
Which can be fixed by changing line 2648 in /var/lib/dpkg/info/icaclient.postinst:
echo $Arch|grep "i[0-9]86" >/dev/nullto:
echo $Arch|grep -E "i[0-9]86|x86_64" >/dev/nullAnd then execute
~$ sudo dpkg --configure icaclientCredit for this part goes to Alan Burton-Woods.
Next, when trying to actually use the Citrix Receiver to launch any apps, I’ve encountered the following error:
Contact your help desk with the following information: You have not chosen to trust "AddTrust External CA Root", the issuer of the server's security certificate (SSL error 61)
In my case the missing root certificate was Comodo’s AddTrust External CA Root, depending on the certificate used by the server you’re trying to connect to, you may miss some other root certificate. Now you can either download the certificate from Comodo, or use the one in /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt (they are the same). Either way, you should copy the certificate to the icaclient certificate directory:
$ sudo mv /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt /opt/Citrix/ICAClient/keystore/cacerts/
These steps got Citrix working for me, but your mileage may vary.
nameref Doesn’t Work Properly with Theorem EnvironmentI came across not-so-expected behavior in nameref, the package responsible for creating named references, when used in conjunction with theorem environments such as the one provided by amsthm. For example take a look at the following LaTeX document.
\documentclass{article}
\usepackage{amsmath,hyperref}
\begin{document}
\section{My Section}
\newtheorem{theorem}{Theorem}
\begin{theorem}[My Theorem]
\label{theo:My}0=0
\end{theorem}
This is a named reference: \nameref{theo:My}
\end{document}You would expect the named reference to refer to the theorem’s name. However in reality it refers to the section’s name.
Continue reading nameref Doesn’t Work Properly with Theorem Environment
Usually when one wants to keep track of one’s cron jobs, one tells the cron daemon to email the output of the commands. While this is probably the best solution for servers, on desktop machines is problematic. Many ISPs block outgoing traffic on port 25 (SMTP), and if you want to send the emails via external SMTP server (such as GMail) this requires you to store authentication details in plain text. A better solution for the desktop would be to harness the desktop notifications available in Ubuntu.
There is a useful tool called notify-send which is able to send desktop notifications directly from the command line. However, there are few caveats:
notify-send expects its input on the command line, it can’t read from stdin.The first issue can be worked around by using cat to pick up the input. The second issue is handled by adding a DISPLAY environment variable to the crontab. So your crontab will look something like this:
DISPLAY=:0
10 1 * * sun some_cool_command | notify-send "Backup Documents" "$(cat)"The first argument to notify-send is the title of the notification. The second is the actual text to appear in it, in our case it’s whatever comes in the stdin. If you want to store the output in a log file as well as displaying it in a desktop notification, you can use tee, which basically saves its input to a given file and also pipes it again to stdout.
DISPLAY=:0
10 1 * * sun some_cool_command | tee -a ~/some_log.log | notify-send "Backup Documents" "$(cat)"virtualenv after Upgrading Your Distribution/PythonAfter you upgrade your python/distribution (specifically this happened to me after upgrading from Ubuntu 11.10 to 12.04), your existing virtualenv environments may stop working. This manifests itself by reporting that some modules are missing. For example when I tried to open a Django shell, it complained that urandom was missing from the os module. I guess almost any module will be broken.
Apparently, the solution is dead simple. Just re-create the virtualenv environment:
virtualenv /PATH/TO/EXISTING/ENVIRONMENT
or
virtualenv --system-site-packages /PATH/TO/EXISTING/ENVIRONMENT
(depending on how you created it in the same place). All the modules you’ve already installed should keep working as before (at least it was that way for me).
Say you’ve an existing package like gitg and you want to use the new version of gitg or even apply your own patches. You could directly make install but you will probably regret it as soon as you’ll want to upgrade/uninstall, and you want to create a better package than the one created by checkinstall. Apperantly, creating a deb package for a new version of already packaged deb isn’t complicated.
Start by pulling the sources for the already available package. I’ll by using gitg as an example throughout this tutorial.
$ apt-get source gitg
This will create a folder according to the version of the package, something like gitg-0.2.4. Extract the new version besides it and cd into its directory. The next step is to copy the debian/ directory from the old source package the code you’ve just extracted.
$ cp -R ../gitg-0.2.4/debian/ .
There are some dependencies you’ll need:
$ sudo apt-get install devscripts
$ sudo apt-get install dpkg-dev
You’ll probably want to do:
$ sudo apt-get build-dep gitg
in order to make sure you’ve all the relevant build time dependencies.
debian/ FilesThe next step is to update the files under the debian/ sub-directory.
$ DEBEMAIL="Guy Rutenberg <myemail@domain.com>" debchange --nmu
This will update the debian/changelog and set the new version. --nmu will create a new “non maintainer upload” version, meaning if the current version was 0.2.4-0ubuntu1, it will change it to 0.2.4-0ubuntu1.1. This will make sure that there won’t be any collision between your package and an official one. If you update to a new upstream version. It might be more suitable to use something like this:
$ debchange --newversion 0.2.5+20111211.git.20391c4
If necessary, update the Build-Depends and Depends sections of debian/control.
If your building a package directly from version control and not part of an official release, you may need to run
$ ./autogen
at this point.
Now to the actual building:
$ debuild -us -uc -i -I -b
-us -uc tells the script not to sign the .dsc and .changes files accordingly. -i and -I makes the script ignore common version control files. -b tells debuild to only create binary packages. You can also pass -j followed by the number of simultaneous jobs you wish to allow (e.g. -j3, like in make) which an significantly speed things up.
The package will reside in the parent directory, for example:
../gitg_0.2.5+20111211.git.20391c4_amd64.deb
At this point you’re basically done. If you want to install the package you can use
sudo debi
while you’re still inside the build directory.
If you want to go the extra mile and create source packages, it will make things easier for others to build their own packages based on yours.
You’ll need to create a an “orig” tarball
../gitg_0.2.5+20111211.git.20391c4.orig.tar.bz2
(note the underscore between the package-name and the version). The “orig” tarball should contain the original source-code without the debian specific patches.
Now you can run the debuild command like before but without the -b flag.
This will create the following files:
../gitg_0.2.5+20111211.git.20391c4.debian.tar.gz
../gitg_0.2.5+20111211.git.20391c4.dsc
debuild, dpgk-genchanges, dpgk-buildpackage.My brother asked me to repair his boot loader, after he accidentally erased his MBR. This can be done easily via LiveCD and the command line.
Boot the system using a LiveCD (I’ve used Ubuntu from USB stick) and do the following:
$ sudo mount /dev/sda /mnt
$ sudo mount --bind /usr/sbin /mnt/usr/sbin
$ sudo mount --bind /usr/lib /mnt/usr/lib
$ sudo mount --bind /dev/ /mnt/dev
$ sudo chroot /mnt
# grub-install /dev/sda
I hope it will be useful for others as well, as the Ubuntu community documentations offers a solution based on Boot-Repair, which seems an overkill for me.
In Ubuntu (gnome) there is an easy graphical way to disable tapping on the touchpad. However, KDE lacks such thing. But lacking graphical configuration doesn’t mean this should be difficult. All you need is the gsynaptics package. The package provides a small utility called synclient. Now you can disable tapping by doing
synclient TapButton1=0
To disable the tapping permanently you should use the following to run the command at the start of every KDE session.
echo "synclient TapButton1=0" > ~/.kde/env/disable-tapping.sh
Uncomplicated Firewall (ufw) is one of the greatest frontends to IPTables I’ve encountered. It is very simple to use and I just wish it was also available for Gentoo. Up until recently everything went smoothly for me and ufw, but we hit some rough waters when I’ve tried to block an IP range.
To block an IP or IP range in ufw you should do
sudo ufw deny from 188.162.67.197/21