Category Archives: ubuntu

boot issues, encryption, linux, ubuntu

Boot Disk Encryption, Cryptsetup and Initramfs

Setting up Cinnamon so that the boot disk is encrypted has been a source of frustration for 3 releases now.

Most recently I installed Saucy. As with Roaring it doesn’t seem to be possible to install onto an encrypted root successfully with the desktop installer. Everything seemed to work until it was time to install the boot loader. That seems to have failed and I wasn’t able to get it to work.

Ultimately, I went back to installing the server version, and then doing an apt-get install ubuntu-desktop. Although this seemed to work out of the chute, I had a few issues.

The configuration files for lightdm changed structure, and my “after the reinstall script” which endeavours to restore all the tweaks I have in config files, put a file named /etc/lightdm/lightdm.conf out there, which seemed to croak lightdm. When I moved the file into the new lightdm.conf.d scheme that problem was solved. All that was about getting synergy client running as soon as the display manager comes up.
Continue reading Boot Disk Encryption, Cryptsetup and Initramfs →

fedora, linux, ubuntu

Vino, Vinagre, VNC

Another bit of lore that I don’t use often, manage to forget, and end up having to figure out again from time to time:

Vinagre is obsolete. This was the name of the previous built in remote viewing client in gnome (and therefore, for my purposes, in both Ubuntu and Fedora). It will operate as a VNC client (i.e. enable opening windows to VNC servers), but also an RDP client and will even pop up a terminal window for an SSH session. .

Remmina is the new remote viewing client, replacing Vinagre.

Vino is the name of the built in VNC server. This is launched when you invoke the “desktop sharing” preference and enable “allow other users to view your desktop”. Your gnome instance sprouts a vino server listening on 5900, giving (possibly password protected) access to the existing desktop to any vnc client that can reach port 5900. A remote user attached in this way is sharing the desktop with the user seated at the “console”. When either moves the mouse, both will see the cursor move on the the display.

Realvnc, Tightvnc, Tigervnc, Ultravnc are all different forks of the original VNC. Realvnc was the first, from the original devlopers. Tightvnc developed improvements in the encoding (tight encoding) if both ends are tightvnc. Tigervnc seems to be a Fedora fork of tightvnc. All will work with other, but some improvements only kick in if both ends share the improvement.

Xvnc in linux (as installed with the tigervnc package) is a little different animal. It is really a two-headed server, with an X server on one side and a vnc server on the other. The X server is an entirely separate virtual display than the console. There is no physical monitor anywhere, but applications can be started which open that X server and display upon it. On the other side, VNC clients are able to view and control the applications which are displaying on the X server. When the X server is launched, any X applications wanted can also be launched — including an entire gnome desktop environment (entirely independent of the gnome environment which might be running on the “console”, if there is one). Multiple users can have different desktop environments open, albeit using different network ports for each. VNC ports normally start at 5900, which vino attempts to use if it is enabled. So different remote users can use 5901, 5902, 5903…  Continue reading Vino, Vinagre, VNC →

fedora, linux, ubuntu

Starting Services

There is no great insight in this post, it is only to help me remember how to start services in Fedora and Ubuntu as I have both.  I used Fedora long enough to get used to the old chkconfig stuff, but now thats gone. Ubuntu never did that anyway. They are different, and I get confused about which new syntax to use on which system.

If somebody other than me ever reads this, be careful to check dates and versions before you believe anything I write. It will probably change. This is as of Fedora 16 and Ubuntu 12.04. Continue reading Starting Services →

linux, ubuntu, xbmc

XBMC Dvdplayer on Ubuntu 12.04

Since installing Ubuntu 12.04 shortly after it was released, XBMC has been unable to play .iso files. This has been the case for me, and for my friend who has a similar setup. I’ve found a way to overcome this.

By way of background, we both have a central shared MySQL database on an Ubuntu 12.04 instance, shared with multiple other XBMC instances running on different platforms. The XBMC instance I mostly watch happens to be Mac OS/X, and that has continued to work. In his case, the “living room” instance that he watches is the same Ubuntu box which houses the database. That XBMC instance is unable to play .iso files. My Ubuntu instance is also unable to play .iso files, though since I rarely watch on that instance it was not a big issue for me. He on the other hand was having to watch movies in another room on a Windows XBMC instance in order to be able to play the .iso files. We are both set up to share the files from the central repository with NFS. Over time we’ve experimented with different protocols, but mostly NFS and SMB, and at the moment we are set up with NFS. Continue reading XBMC Dvdplayer on Ubuntu 12.04 →

boot issues, encryption, linux, ubuntu

Ubuntu 12.04 and luks encrypted root drive

I had trouble booting the last few kernels that came out in 11.10 (3.0.0-16 and 17), and alas the same trouble with booting 12.04 which I installed today.

My root filesystem is encrypted, and I expect during the boot process to get a prompt for the encryption password. This doesn’t happen, and instead the boot drops into busybox. I was able to just keep using 3.0.0-15 under 11.10 but now that 12.04 is installed I can’t do that anymore. Actually have to try to track this down. .

After a lot of digging around, I haven’t completely got it figured out, but I did find some hints in this tread: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/874774 which gave me a start, and at least enabled me to boot. The thread describes a mixup in matching device names from udev to names in /etc/crypttab. If a match isn’t found, you don’t get a prompt for a password, the device doesn’t get luksOpened, and the boot fails waiting for it. So, the trick is to ensure the matching logic finds a match between the udev devname and the entry in /etc/crypttab. I actually didn’t even have an entry in /etc/crypttab for the root device. Silly me. I had entries for a couple of other encrypted devices. I would love to report that all I had to do was put in an entry in /etc/crypttab and it all worked. I alas not – I haven’t yet managed to get the problem solved. But I now know where to look, and more importantly reading the thread mentioned did make clear the short term workaround, which may be clear to everyone but me: it didn’t occur to me that once I dropped into busybox, I could just do cryptsetup luksOpen /dev/sde3 sde3_crypt, type in the correct password, and then exit busybox. The boot process resumes and is successful.

Update: In the normal course of Ubuntu updates I got 3.2.24 and the problem spontaneously healied itself. Now upon boot, I get an early prompt for the root password. Bob’s your uncle.