Linux Mint: Restart Unresponsive Desktop, Recover Missing Terminal Icon, Restore to Menu

I was using Linux Mint 18.3 Cinnamon. I edited the Menu. Among other things, I made a copy of the Terminal icon. Then I decided I didn’t want the copy. I deleted it. Unless there was something else going on that I didn’t know about, that bizarrely deleted the original icon from the Start menu as well. I also didn’t have a Terminal icon pinned to the taskbar anymore. And at the moment, the desktop was unresponsive: right-clicking didn’t open a context menu. This post explains how I dug myself out of this hole — how I got the system going again, and restored Terminal icons to the Start menu, the taskbar, and the desktop.

(Notes: in this post, commands are in italics. WordPress reproduces a double hyphen (i.e., “- -” with no space between) as a dash (i.e., –). “WinKey” or “Win-” (in e.g., Win-E) refers to the key with the Windows icon on it, usually located next to the Alt key on one or both sides of the keyboard. I used Windows terms for Start menu, rather than merely Menu, and for taskbar, rather than panel or panel taskbar, because Linux Mint had or could have many menus and panels. I found the Windows terms more familiar and specific. For example, I encountered discussions of how to add a launcher to the panel, which could be confusing: it could seem to mean simply running the program, which would automatically put an entry for it into the taskbar. What they seemed to mean was not merely adding the launcher to the taskbar, but rather pinning it there, so that it would persist after the program was closed.)

I discovered Gnome Tweaks (a/k/a Gnome Tweak Tool), installed via sudo apt-get install gnome-tweak-tool. I hoped Gnome Tweaks would be like the Ultimate Windows Tweaker, and to some extent it was. To run Gnome Tweaks, I went to Start > Preferences > Tweak Tool (or gnome-tweak-tool). From there, to fix my unresponsive desktop right-click menu, the advice (at least in Ubuntu) was to go to Keyboard and Mouse section > enable “Have file manager handle the desktop” or try Icons on Desktop > On. My Linux Mint did not offer those options, unfortunately, so for present purposes Gnome Tweaks was a mere distraction.

Alternately, to rectify the unresponsive right-click menu, an AskUbuntu discussion suggested multiple ways of restarting Cinnamon. The most highly voted solution was to use Alt-F2 > r > Enter (followed, if necessary, by Ctrl-Alt-Backspace and then sudo service mdm restart). Another upvoted solution was to use killall -HUP -f cinnamon –replace, which would reportedly restart the Cinnamon desktop while preserving open windows and running applications. But killall -h seemed to indicate that none of those options were available for killall in Linux Mint. Another possibility: Ctrl-Alt-Esc. By the time I found those solutions, however, I had already rebooted, which also worked.

So now at least the desktop was responding. That opened up several ways of running a Terminal session. The easiest was Ctrl-Alt-T. Another: right-click on the desktop > Open in Terminal. If those hadn’t worked, another approach (recommended in a Linux Mint forum) was to use Alt-F2 to open a Run dialog, and type gnome-terminal there. Another method: Start > Administration > Software Manager > search for Terminal > Gnome-terminal > Launch.

I could put a Terminal shortcut on the desktop by using desktop > right-click > Create a new launcher here > Name = Terminal, Command = gnome-terminal. But the resulting shortcut did not have the usual square black Terminal icon. Alternately, according to a SuperUser discussion, I could have put a Terminal shortcut on the desktop by dragging the Terminal shortcut from the Start menu, if I’d had one there. In another approach, I found that locate gnome-terminal.desktop produced a list of several locations for copies of gnome-terminal.desktop. One of those locations was /usr/share/applications. Thus, someone in Stack Exchange said I could go to WinKey-E (i.e., open Nemo) > File System > /usr/share/applications > drag Terminal to the desktop. That last method worked for me: now I had a Terminal shortcut on my desktop, bearing the standard Terminal icon.

I was able to add a Terminal entry to the Start menu by going to Start > right-click > Configure > Menu > Open the menu editor > Accessories > New Item > Name = Terminal, Command = gnome-terminal. But the new item did not have the standard Terminal icon, either in the menu editor or in Start > Accessories > Terminal. Restarting Cinnamon, using the methods mentioned above (aside from rebooting, which I did not try), did not fix that. I did notice, however, that the process of adding the new item created a new .desktop file in ~/.local/share/applications. The new .desktop file had a weird name, beginning with “alacarte-made” and then adding a string of letters and numbers (e.g., “alacarte-made-ff53a43e … .desktop”). (The mention of alacarte presumably derived from the alacarte program which, while apparently not recommended for Linux Mint, was at least a source for the developers of the Linux Mint Start menu editor.) I noticed that, when I went to right-click > Open with > Text Editor, for both that alacarte…desktop file and for gnome-terminal.desktop (in ~/.local/share/applications), the gnome-terminal desktop file specified “Icon=utilities-terminal” while the alacarte desktop file didn’t. I copied that Icon line into the alacarte file, saved, and exited. That fixed it: now Start > Accessories > Terminal had the ordinary Terminal icon.

Note that it was also possible to use a similar process to create shortcuts for programs that did not seem to have any. I did not tinker with suggestions of this nature, at this point, but the general idea seemed to be that I could copy and rename some other .desktop file, editing its internal contents to fit the particulars of the program in question. To find the location of the program’s executable file, MakeUseOf (Lee, 2015) suggested which [command]. In the present context, an example would be which gnome-terminal.

Mint did not offer the Windows-style option of right-clicking on an open icon in the taskbar and selecting something like “Pin to taskbar.” To restore a permanent Terminal icon to the taskbar, I tried taskbar > right-click > turn on Panel Edit Mode, and then taskbar > right-click > Add applets to the panel. But a search in that box did not indicate that Terminal was among the available applets. Likewise Taskbar > right-click > System Settings > Preferences > Desklets. In addition, Taskbar > right-click > Modify panel likewise yielded no joy. Fortunately, there was a solution. Now that I had a working Terminal icon in the Start menu, I could use that to pin Terminal to the taskbar. All I had to do was to go to Start > Accessories > Terminal > right-click > Add to panel.

Having a working Terminal icon in the Start menu also provided a solution for Favorites (i.e., the left-hand pane in the Start menu, which I could turn off if desired via Start > right-click > Configure > Menu > Show favorites and quit options > Off). All I had to do, to add Terminal to Favorites, was go to Start > Accessories > Terminal > drag the Terminal icon to the Favorites panel. To remove it, if I correctly recalled my mistake, the solution was not to highlight it and hit Delete; that was apparently what had caused deletion of the Terminal shortcut from Start > Accessories > Terminal as well. Instead, I just needed to drag the Terminal icon from Favorites back to the Start menu. Doing so didn’t seem to add a duplicate copy of that icon to the menu; it just seemed to dissolve it.

Going back to ~/.local/share/applications, there was still the question of why the standard gnome-terminal.desktop did not appear in the Start menu list, whereas this new alacarte…desktop file did. It seemed that the existence of a .desktop file in ~/.local/share/applications did not guarantee that the file would be automatically reflected in a Start menu entry. Plainly, my original mistake of removing or deleting the Terminal icon from the Start menu did not delete this gnome-terminal.desktop file; it somehow just made it inoperative. I didn’t understand that. I revised my previously posted question and awaited further enlightenment.

Unable to Boot Acronis True Image on an Acer Aspire V3-772G-9829 Laptop

I had an Acer Aspire V3-772G-9829. Its Windows 7 installation suddenly went south. I needed to reinstall Windows. I had used Acronis True Image Home 2011 to make an image of drive C, where the operating system was installed. Now I wanted to use Acronis to restore that image, replacing my defunct Windows 7 installation with the working earlier installation saved in that drive image. I ran into some problems with that. This post describes steps I took in response.

I had Acronis in two forms: on CD and on two different USB drives. I tried booting the Acer with one of those USB drives. This one had been created using Unetbootin or some similar tool to create a single-purpose bootable USB drive. That is, the Acronis USB drive would function about the same as an Acronis CD: just plug it in, turn the machine on, keep hitting F12 during the initial power-up to bring up a boot menu, choose the appropriate (USB or CD) drive, and Acronis would run.

When I tried booting the Acer with this Acronis USB drive, it looked like Acronis was going to run, but then it started scrolling what appeared to be Linux command-line information down the screen. It ended with these two lines:

usb 1-1: new high speed USB device number 2 using ehci_hcd

Reading all physical volumes. This may take a while. . .

It did take a while. And then it took another while. That is, the system seemed to be frozen. The hard drive light displayed no sign of disk activity. I believed the system was frozen.

A search brought up a discussion thread in which the problem appeared to be the computer hardware. In another thread, a simple system restart apparently solved the problem. Another search led, like the first, to a number of remarks focused on the Linux kernel. It did seem possible that the Linux programming in that version of Acronis was not compatible with the Acer’s hardware. It was also possible that there was a problem with the Acer’s hardware itself; possibly some hardware problem was also the reason why Windows had suddenly gone flaky on this machine. The USB drive itself seemed to be OK: it would start Acronis without problems on another laptop.

I did a cold reboot. Checking that term, it appeared that definitions differed. Normally I used it to mean just that I powered down the machine and waited 30 seconds or more, but this time I disconnected the power cord as well. (I had already disconnected the battery to keep it from being worn down by constant charging.) Then I tried again with the same Acronis USB drive. Again it scrolled numerous Linux lines, but this time it froze with several “Using /lib/modules” messages, the last of which was “Using /lib/modules/nfs.ko.” On another occasion, it had frozen with what was, I think, a line saying something about “end trace”: I could see a similar line onscreen this time.

Next, I tried booting with the other USB drive. On this one, I had used YUMI to create a multiboot drive. That is, when I booted the system with this USB drive, I got a menu offering a choice among multiple tools, one of which was Acronis. When I chose the Acronis option, I was presented with choices between 32-bit and 64-bit Acronis. I had been puzzled to see this recent innovation, after years of just going directly into Acronis. These days, when I chose the 64-bit option, it did not work. On this particular occasion, when I chose the 32-bit option instead, the system scrolled Linux commands and concluded with the “using ehci_hcd” line quoted above. This USB drive, too, did work properly on another computer.

Then I attempted to boot from an Acronis CD (not multiboot). Although I did select the DVD drive as my boot choice after hitting F12, the system seemed to disregard it, proceeding directly to run Windows instead. I did not recheck this CD, but I assumed it had functioned adequately in the past, else I would not have kept it.

I had installed Acronis on the Acer’s Windows installation. At this point I went into that Acronis installation and saw that it offered no obvious means of restoring Windows from an Acronis backup (which would be saved as a *.TIB file). That is, among other things, it did not show any of my existing TIBs. I went into its Tools and Utilities > Mount Image, and then canceled out. That step was sufficient to get it to scan my drives. Now its main screen allowed me to browse to a recent TIB, click its Recover button, and indicate that I wanted this TIB to overwrite my existing Windows partition. Acronis began its recovery process. It said, “Reboot is required.” We went ahead with the reboot. The Windows restoration finished, and I was able to boot the restored system. Mission accomplished.

If I had not been able to run Acronis from an existing Windows installation, I could have installed Windows temporarily for the purpose of then installing Acronis on it. Alternately, I would have considered removing the drive containing my Windows (drive C) partition, putting it into another computer capable of booting an Acronis or YUMI USB drive or CD, and restoring the Acronis TIB to that partition in that other computer. Another possibility was that Acronis True Image Home 2011 was out of date, at least for purposes of the Acer’s hardware, and that the problem would have been solved if I had installed True Image 2014 onto the USB or CD drives instead. But I heard bad things about True Image 2014, and decided not to go that route.

I had already booted those USB drives successfully on the Acer. This led me to suspect that the problem was not with the Acer per se, but rather with the mSATA drive that I had lately installed; that was where my Windows drive C partition was now located. The solution I eventually reached was to use a multiboot DVD as an alternative to a multiboot USB drive; the mSATA drive did not interfere with booting from the DVD.