Re-installing to disk (instead of USB)

Re-installing to disk (instead of USB)
This post is not intended to start a flame/holy war or any other kind of religious conflict with regard to Linux desktop environments (DEs). What it is intended to do, is to simply catalogue the multitude of problems I have been encountering while using Debian Jessie and GNOME 3.14. 🙂
Let’s put this one right out there: The GNOME Shell/GNOME 3 UI is, IMHO, the BEST desktop user experience out there for Linux.
“Wait,” you might say, “doesn’t this conflict with the title of this blog post?”
Well yes, it does. But I want you, my learned reader, to understand that I wish that the GNOME DE was as stable and solid as it should be. As it could be. And hopefully as it will be.
You see, this is what Linux and other Unix-like operating systems have been known and reputed for – their stability. I love what the GNOME devs did when they decided to reimagine the desktop for GNOME 3: they used space sensibly, vertically, which to me feels more natural and intuitive. And I love how it’s meant to stay out of the way – another good design motif.
But in terms of stability, sadly, GNOME has been something of a disappointment to me, and I wish this were not the case. Perhaps this is just a consequence of its ambition, and that will always garner my respect. Or maybe my install went terribly wrong, somewhere. But I don’t reckon. So, without further ado…
DISCLAIMER: WRT the issues with Debian Jessie‘s implementation of GNOME Shell/GNOME 3, I shall simply refer to it as GNOME. I apologise to the purists out there. I am only commenting on my experience in Debian Jessie, not anyone else’s, nor of any other GNU/Linux distribution. Finally, I intentionally do not go into detail here and am not providing numerous distro/upstream links to “validate” my own claims. I don’t need to. If you’re interested, just search anything I have put below. I am pretty confident you will find stuff…
Have you had similar experiences to these? Do comment below.
The problems with GNOME start from the very moment you log in: it’s a disk-thrashing, sluggard of a desktop. And yes, I am using a disk, not a SSD. Why? Because badly written software doesn’t deserve a place in my CPU, let alone being so resource-hogging as to require an SSD.
So yes, Tracker is the first problem with GNOME. From logging in, all the way through your session, to shutting down your machine, it’s there – consuming all available CPU, disk I/O and (perhaps due to a memory leak), system memory. Happily gobbling it all up like a sickly child with no manners. 🙂
Perhaps I am being unfair, inferring that Tracker is “bad software”. It’s not a bad idea and its search seems to work well. But it doesn’t reign itself in. And software that doesn’t adhere to users’ choices through its own preferences panel is software that needs attention.
There are too many people/posts on the web with/of similar experiences. But, why not just disable tracking completely, you ask? Like, through the GUI you mean..? Mmm.
Next up is something akin to heresy: crashing and freezing of the whole desktop UI. Seriously, it’s that bad.
You are in the middle of something, as you might be in a productive desktop environment, and BAM! no window response. That’s it. All gone. This single issue is by far the most perplexing and irritating, totally demolishing my productivity recently.
When you start searching on t’interweb about this, you realise that this has haunted GNOME for years, and in multiple versions. The nearest posts I have found on the web which seem related to the problem I have are here:
An alternative way to make GNOME hang on you is to use the live user switching. Just set up another user account, then Switch User via this menu. Then, as your new user, switch back to your original account.
Do this a few times for maximum effect, until you get stuck looking at the frozen greeter, just after it’s accepted your password for logging back in.
Enjoy the view.
It’ll last a while.
In fact, no need to take a photo. This’ll last long enough.
Moving on…
Ahh, GOA. Such a good idea. Implemented in such an average way.
GNOME Online Accounts is meant to centralise internet service (or “cloud”, hwk-ding) accounts through one easy GUI component, and then share the online resources of each account with the appropriate desktop software. Think, Google Calendar being visible in your desktop calendar, which is a separate desktop application than, say, your email reader (where you could read your GMail). But no need to set up each application separately; just set up the GOA and each application gets relevant access. Get the idea?
The account set-up bit of this is, actually, great. I’m all for it too – this whole concept. It just makes so much sense.
One of the problems with it is that things don’t work properly. For example, if you use two-factor authentication in your Google account, and rely on application-specific passwords, then GOA doesn’t like that. You will be constantly prompted for your Google account password, which is never accepted.
To be fair to Jessie, I haven’t seen this happen recently, so it may have finally been plugged. Or I may just be lucky.
Another problem is SMTP/IMAP accounts. Sure, they integrate nicely with Evolution. Until you edit parts of the account in Evolution, which are more application-specific. Then, you return to your account folders list with your GOA mail account being renamed to “Untitled”. A rummage through, and edit of, the relevant ~/.config files is required to correct this error. Not so slick.
I still have hope though. One day this stuff will work great.
Yep, another hangy-crashy thing. Sometimes, for no discernible reason, when you close Evolution is hangs, mid-termination. Forever. You have to send a KILL to it to actually get it to close off completely. Why? Who knows. It appears to be a timeout or spinlock type of problem. Sorry for being vague, but look, just do this Google search and pick a year. It looks like this bug has been around in one incarnation or another for a very long time.
Are you seeing a pattern here? Yep, our faithful friend and file utility, Nautilus, also hangs. Quite often. Why it does this, I have not yet been able to determine. Sigkill to the rescue. (You can do a Google search on this too…)
Now, I admit, this is a silly thing to do when you look at it, because you are clearly asking for trouble if you have a remote filesystem mounted into your own filesystem, and then put your machine to sleep for a while.
You can make the problem worse still, if you have laptop with a docking station. Simply put it to sleep, undock, wake the machine, then reconnect using your wireless instead of ethernet. The outcome varies from a locked desktop (where nothing works), to a frozen nautilus.
Again, a silly thing to do, perhaps, but also an innocent mistake at times. Like, when you’re rushing to attend a meeting, for example.
So, why not be offered a notification, when requesting to “sleep” the machine, saying that remote filesystems are mounted? I think even I might be able to knock up some code for that one (but I’d prefer to leave it to the experts, who I respect fully and who would do it far better than I).
As you may have gathered from previous comments, when it comes to GNOME I am primarily a business user. My business runs and relies on GNU software & Linux. For the experience and knowledge I have gained – not to mention being able to sustain an income and lifestyle I’m happy with, I am indebted to many people for their determined efforts in the free software community.
Unfortunately, little bugs creep in here and there – that’s the rule of life. One minor annoyance with Jessie, that wasn’t present in its predecessor Wheezy, is automatic audio output switching. In Wheezy, after a small tweak to the kernel module loading (via /etc/modprobe.d), the audio output would be directed to my docking station’s analogue jack when the laptop was docked, and then automatically switch to the laptop’s speakers when undocked.
Unfortunately, in Jessie, when my laptop is docked I have to hit the Super (Windows) key and get to the Sound preferences, then switch the output device. After undocking, the same story. This is, apparently, fixed upstream, but regressive and annoying nonetheless.
This is so subjective an issue that I thought it barely worth mentioning, but an issue it is nonetheless. And one that I actually feel is perhaps the worst of all.
When key processes are busy in the GNOME Desktop Environment – say Tracker for sake of argument, the “hit” on the rest of the system is shocking. Right now, as I type this blog entry, any mouse-based GUI interactions are extremely sluggish. This could be the reason why:
top - 16:34:34 up 2:00, 2 users, load average: 16.31, 15.97, 13.93
So what is causing such a load on my machine? It doesn’t take long to figure it out, in top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9187 smd 39 19 2239548 210440 34852 R 83.7 1.3 3:50.74 tracker-extract 9148 smd 20 0 693940 59696 8652 S 7.6 0.4 4:33.53 tracker-store
For reference, my trusty ThinkPad T420 uses a 2nd gen Core i7 processor (dual core w/hyperthreading), 16GB DDR3 memory (dual channel), a 64GB mSATA SSD system drive and 500GB Seagate Momentus 7200.4 drive for my /home. It’s a set-up that’s still powerful enough for getting things done, and I’ve grown quite fond of this chunky, heavy laptop (by 2016 standards). Yes, it’s a bit clunky now, but it’s still got it where it counts, and has only required minimal servicing over the years (since 2011).
Back to the main issue, though. You see, I grew up on Amigas. Fully pre-emptive multitasking spoilt me, and I’ve never looked back, or sideways, since. These days, all modern operating systems provide significantly more advanced multitasking and far, far more powerful hardware, but the user’s needs should always come first in a desktop environment. So, having an unresponsive desktop for hours, because a non-GUI process is taking too much CPU and I/O, is not a productivity boon, to say the least.
I love how well integrated Dejadup is into Nautilus. It’s a neat idea, to be able to just navigate to anywhere on your file-system and then say “hey, you know what? I wonder if that file I was looking for used to live here?“, or “I really must restore the earlier version of this file, or that file…”.. And so on. It even states on its website, that it “hides the complexity of doing backups the Right Way (encrypted, off-site, and regular) and uses duplicity as the backend” [my link].
‘GNOME Backups’ was designed to facilitate exactly this, using the Dejadup/duplicity combo, with two main Nautilus integration actions. Firstly, you can right-click in a folder (on blank space) and select “Restore missing files”. Or, you can right-click on a specific file and select “Revert to previous version”. In either case, a dialog will appear prompting you to select a date, from a range of dates when backups occurred. Great, huh?
Except a backup is only good when you’re able to restore it. I was not able to restore mine. The “Revert” functionality simply failed, every time I tried, with a “File not found in archive”-style error message each time. I also tried restoring the entire backup, which also failed. This issue pretty much covers it.
So, perhaps using duplicity (and not Duplicity) as the backend is exactly what it does. I don’t trust it with my back-ups. For that job, I use BackInTime.
I was originally going to entitle this blog post, Debian’s GNOME is a broken user experience, but shied away from making such a bold, and somewhat unfair, claim. However, it’s hard not to conclude that this might actually be the case.
GNOME 2 used to be amazingly solid. In fact, in my younger years I didn’t use it because I perceived it as being a little boring, instead opting for KDE (v2, then v3) as my go-to desktop for quite a while. I would love to have the stability of GNOME 2 – at least as I experienced it – just in GNOME 3 form.
The biggest problem about GNOME 3 / Gnome Shell, is that I like it so damn much. For me, despite all the wrinkles and annoyances, the occasional memory leaks of “background” indexing processes, the frequent hanging of various applications and the seemingly (at times) untested nature of the software, it’s actually brilliant. It’s fast, feature-full, yet fluid. That’s a rare combination in software.
For me, it’s faster to work in than any other DE, because it combines enough functionality with equally enough transparency. For instance, when I am editing a client’s website files and want to upload them, Nautilus is the hero – allowing me to quickly mount the remote filesystem, upload my files, and then disconnect. No need to launch additional software for that task. We’re just moving data from one filesystem to another, right? That’s what a file manager does and, in the main, Nautilus is exceptional at it.
As an Emacs user, I know I could do a similar thing using Tramp and Dired mode. And I’ll keep that as an option to probably explore someday soon.
I’ve been using Debian for some time now, migrating away from Fedora on my netbook to start with, and then later on my main work laptop. In general it’s an operating system that does so much right, it’s hard when things occasionally don’t work as expected.
I won’t say that Jessie’s innings with GNOME have been the best; fair from it. But hopefully we can look forward to a smoother experience as time goes on.
I recently upgraded my laptop hard drive and decided to move all the virtual disk files of my virtual machines to my home directory.
However, when trying to run the VM, an error notification appeared:
Error starting domain: internal error process exited while connecting to monitor: Warning: option deprecated, use lost_tick_policy property of kvm-pit instead. kvm: -drive file=/home/sd/libvirt/images/WinXPsp3IE8-d3.qcow2,if=none,id=drive-ide0-0-0,format=raw,cache=writeback: could not open disk image /home/sd/libvirt/images/WinXPsp3IE8-d3.qcow2: Permission denied
The Details section of that dialog showed me where the error was occurring:
Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 66, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1114, in startup self._backend.create() File "/usr/lib/python2.7/dist-packages/libvirt.py", line 620, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: internal error process exited while connecting to monitor: Warning: option deprecated, use lost_tick_policy property of kvm-pit instead. kvm: -drive file=/home/sd/libvirt/images/WinXPsp3IE8-d3.qcow2,if=none,id=drive-ide0-0-0,format=raw,cache=writeback: could not open disk image /home/sd/libvirt/images/WinXPsp3IE8-d3.qcow2: Permission denied
… or, at least, that’s what I hoped. Except it didn’t.
For a long time, I played around with permissions on the virtual disk image itself, the directory containing it, and further back/up until reaching ~. None of it helped.
Then I stumbled upon this libvirt bug report. Comment #6 by Cole Robinson was what I needed:
“What virt-manager typically offers to do is use ACLs to allow the ‘qemu’ user search permissions on your home dir, which is all it should need and is fairly safe and restrictive.”
In order to check and set this, you’ll need to use the File Access Control utilities – getfacl and setfacl:
# cd /home
My home is “sd”
# getfacl sd # file: sd # owner: sd # group: sd user::rwx user:root:--x user:www-data:r-x group::r-x group:www-data:r-x mask::r-x other::---
The reason I have www-data with read and execute permissions is that I do web development and testing, and I also keep all my web-dev files in ~ too. This just makes my system more “portable”, safer to upgrade and/or easier to migrate to a different Linux.
To set the required permission for libvirt / qemu, you just issue this one liner:
# setfacl -m u:libvirt-qemu:r-x sd
.. substituting sd for your own ~ directory name.
setfacl (set file access control) takes three main arguments:
After this, my virtual machine runs up perfectly.
This is relevant for Crunchbang and other Debian-related distros. For Fedora/CentOS, I believe the user should be qemu.
When installing Debian, or a derivative OS such as crunchbang, you may have opted to separate out your partitions/logical volumes to manage your disk space more finely.
I opted to do this. My partitions were set up thus:
$ sudo lvs LV VG Attr LSize home t420 -wi-ao-- 438.10g root t420 -wi-ao-- 332.00m swap_1 t420 -wi-ao-- 15.50g <-- way too big! tmp t420 -wi-ao-- 369.00m <-- way too small! usr t420 -wi-ao-- 8.38g var t420 -wi-ao-- 2.79g
This was not working for me. Doing backups using the easy backintime was proving difficult, as backintime relied on more /tmp space than I had.
As I rarely touched swap space, I figured that 15.5G was probably a bit large for my needs. Thankfully, nabbing swap space and reusing it for the filesystem is easy as pie – and all achieved with no downtime.
Here’s the sequence I typed into a terminal. First, turn off swap:
$ sudo swapoff -a
Then resize the swap volume:
$ sudo lvresize -L 8GB /dev/t420/swap_1
Now re-format the swap partition before using it again:
$ sudo mkswap /dev/t420/swap_1
Then turn swap availability back on:
$ sudo swapon -a
And finally, resize the /tmp partition on-the-fly:
$ sudo lvextend -L +1G -r -v /dev/t420/tmp
Because the LVM tools have semi-awareness with respect to filesystems, the resizing of /tmp (using the -r switch) was achieved on-line – no need to log out, reboot or anything else. The verbose (-v) switch allowed me to see everything that was happening.
The new partition sizing is:
LV VG Attr LSize home t420 -wi-ao-- 438.10g root t420 -wi-ao-- 332.00m swap_1 t420 -wi-ao-- 8.00g tmp t420 -wi-ao-- 1.37g usr t420 -wi-ao-- 8.38g var t420 -wi-ao-- 2.79g
I also have 6.5G spare on the hard drive now, in case it’s needed by another logical volume.
LVM rocks for easy filesystem management! Try it out!
“Fun” with Windows 7
So.. been having lots of fun with Windows 7 this morning. Got hold of a refurb PC for doing some client system testing.
Win7 install completes and there are 3 updates to do. Start the update process and two modal windows open up behind the update window, waiting for me to do something. Have to click on task bar’s flashing icon to bring windows to the front. On Windows. Windows.
Anyway, I give the “OK” for Microsoft Security Essentials to install and it does, then starts to run an update within itself (!). Due (perhaps) to the length of time of this process on this ageing P4, the main MS software updater kicks out another window saying “The application Microsoft Essentials may not have installed correctly.”
I’m sorry. “May“??
Choices are “That’s ok, it installed correctly” or “Reinstall this application”. Except the application is installed and already running an update. Err…? So.. how do I know it has installed correctly? Because it’s running…(?!) (Does the computer not know??!)
With 20 minutes of Windows use this morning, I can’t believe just how bad things are on the other side of the fence. Someone fresh to Windows will see all this flashing icons, hidden windows, alerts, worries… and not have the first clue what to do.
Someone close to me was one of those unfortunate souls. She’d persisted for about a year with her Win7 machine and was constantly anxious with its scaremongering. Hardly a productive environment.
Luckily, she’s now running #debian #wheezy with the #gnomeshell and immediately found it intuitive and straightforward. Go #freesoftware !!
This is a blog post for personal interest and probably not of much amusement to others.
My work machine has a fresh install of the (soon-to-be released) Debian version 7 (codename “Wheezy”). There are a couple of modifications I’ve had to make to the installed software to get things working as desired.
Firstly, I’ve read really good things about mu4e – the “maildir-utils for emacs” email client. (Just for clarity, the author of maildir-utils has abbreviated its name to mu.) mu4e provides an interface to your email in emacs which is fast and efficient. I like things that are fast and efficient.
I installed debian’s standard mu and mu4e packages, but found that mu (the wheezy-based package) was not indexing all of my email. Firing up mu4e within emacs then trying to browse the ~/Maildir/INBOX – and being told there were no messages – raised some suspicions! So I removed that package and installed from source instead and, now, indexing works much better.
how to do this
Basically, it’s pretty simple. Just:
# apt-get remove mu4e
This will replace maildir-utils (0.9.8) and mu4e. Then download the mu-0.9.9.5 source (list of mu releases) and follow compilation and installation instructions from its install page.
On Debian, this will result in you installing mu and mu4e to /usr/local/share instead of the default installation point, /usr/share. To enable the use of /usr/local/share/emacs/site-packages/mu4e/ from within your standard emacs23 install, just create a symlink pointing to it from /usr/share/emacs/site-packages/ :
# ln -s /usr/local/share/emacs/site-packages/mu4e/ .
The software replacements are:
other modifications
(Edit) I also installed gnu tramp for Emacs from source, but the reasons why I originally did this now escape me, as tramp has been part of Emacs for a while.
unrelated issues
I have found a worrisome issue in wheezy. When I attach an eSATA drive to my ThinkPad (T420) and copy lots of data – e.g. GBs of photos – to my ~/Pictures, I get some kind of kernel panic/X error. I’m still investigating this at present.
I will attempt to keep this list updated as I continue getting this set-up just as I want it 🙂
[ EDIT 10 April 2012 10:00 ]
Grabbing the currently stable, newest kernel source (ver 3.8.6) and compiling it in the debian way has seemingly fixed this crashing/locking issue.
As a Debian user, you may choose to adopt the distro-managed rebuild of the world’s greatest web browser. But, by doing so, you may not be able to use G+. Don’t worry, the answer is at hand.
Visit the Firefox add-on page for User Agent Switcher:
https://addons.mozilla.org/en-US/firefox/addon/user–agent–switcher/
Install the add-on and restart your browser.
Now, go to Tools > User Agent Switcher > User Agent Switcher > Options…
Add a new User Agent, call it Firefox 11.
Add the following text in the fields:
If you’re running an amd64 build, plonk that in the Platform field instead (it’ll probably already be populated).
Make sure there is no reference to Iceweasel in the User Agent field.
Make sure this user agent is active, and then browse to Google+.
Have fun! 🙂
Less is more, as the saying goes.
While I love using Fedora in my daily work, sometimes when I want to relax I find using an alternative distribution is good therapy. Fedora is fabulous with its GNOME Shell finery, but occasionally I hanker for something simpler and more lightweight. It’s also good to see how the other half lives 🙂
So, I decided to put Debian on my netbook. With no GUI. Everything I do on it must be by the command line, including web research. Compared to Fedora, Debian‘s system requirements are practically non-existent, which is especially good if you want your system to still run nice and quick.
I visited the Debian Mirror List and grabbed a NetInst CD image.
Therefore, my software changes are:
$ sudo aptitude remove exim4 exim4-base exim4-config exim4-daemon-light vi mutt
$ sudo aptitude install emacs w3m-el sendmail
$ sudo aptitude install xserver-xorg-video-intel
You’re on to a winner here, because Debian Squeeze is already set up for Kernel Mode Setting. In other words, as soon as your system starts booting up, the video drivers get loaded and the optimal video mode is enabled (or, at least, that’s the intention).
Whether or not it’s worth specifying screenmode in grub is open for debate. FWIW, I put this in /etc/default/grub:
GRUB_GFXMODE=1024x600
GRUB_GFXPAYLOAD=1024x600x16
… And in /etc/grub.d/40_custom:
set gfxpayload=1024x600x16
Then, I simply updated grub with the new config:
$ sudo update-grub
Please note that this step relates to my Intel-based netbook. Yours may vary.
$ sudo aptitude install wireless-tools iw wpasupplicant autofs nfs-common
** PLEASE NOTE: this step assumes your wireless network device doesn’t require firmware or that you already have the firmware installed in /lib/firmware. **
Once done, you need to uncomment the /net line in /etc/auto.master and restart autofs:
$ service restart autofs
If you want to refer to server by hostname and are not running a DNS server, add the hostname to /etc/hosts (somewhere below the localhost lines):
111.222.333.444 myserver.mydomain.com myserver
At this point, assuming all went well, you can cd to /net/
So, this takes care of a basic local network configuration, but we still need to actually get connected to it on wifi. So, there is, in my /etc/network/interfaces:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
# Wireless
auto wlan0
iface wlan_mynet inet dhcp
wpa_ssid my-network-ssid
wpa-psk my-network-key
Once done, save this file and change the permissions for extra security:
$ sudo chmod 0600 /etc/network/interfaces
– and connect up, like this:
$ sudo ifup wlan0=wlan_mynet
Voila! With luck, maybe a little patience, and possibly an extra step or two (which you can hopefully figure out, if needed) these are the key set up steps which will make your netbook/laptop nice and lean, and perhaps more fun to play with.
Next time, I’ll go through a few tools I use for ‘net stuff.