Restarting Icedove after a full reinstall of Trisquel_8
In days long gone by, I was able to upgrade from Trisquel_7 to Trsiquel_8 directly from the Software Updater menu,
whereupon I could subsequently start Icedove as though nothing had changed.
Alas, recently I was forced to wipe Trisquel_8's partition clean and reinstall Trisquel_8 from the installation
flash drive for Trisquel_8. Everything in Trisquel_8 now seems to work OK, and the Icedove data folder in my hard
drive seems to be fully intact, but the process for starting Icedove is eluding me.
Yes, I did all the updates & upgrades and let trisquel pick the best archive server.
All there is in the /etc/icedove folder is a single javascript file, syspref.js, which says:
// This file can be used to configure global preferences for Abrowser
// Example: Homepage
//pref("browser.startup.homepage", "http://www.weebls-stuff.com/wab/");
The main Icedove folder is in a data partition which I mount after each restart of the computer.
Any interesting message if you execute 'icedove' in a terminal emulator?
When I executed "icedove" in the terminal, a great commotion ensued, with many warning messages and
a great flurry of activity in the processor, sending its temperatures into the nineties.
When I attempted to check the permissions with the file manager, it froze, whereupon this page and
my first attempt at a reply vanished. Enigmail even made a stab at starting an installation,
ignoring my huge icedove file on the data section of the hard drive.
I should mention that there were six nmap search scripts taking place whilst all this was occurring.
They're still running in spite of the disturbance that executing icedove set in motion. The System
Monitor registers only 10% usage from this network activity.
It looks as though the file manager has frozen, and several scripts want to be re-started; I'll
be checking the progress of the ones still running in the morning. Re-starting involves evaluating
where in the source files they stopped and picking up the searches so as to avoid re-doing the data
that they've manage to retrieve so far. There are two still running & getting results. The hard
drive is still registering new saves, judging from the time stamps in the file manager. Oddly, the
mouse/cursor is ineffective within the file manager but the system is still running "normally" otherwise.
The scripts that stopped had been running slowly enough during a peak period on the Internet that the
individual nmap scripts over-ran the password timeout. At the next opportunity I'll adjust that setting.
Found 'em, lurking behind a frozen instance of File Manager ...
Magic Banana asked innocently;
Any interesting message if you execute 'icedove' in a terminal emulator?
Yes...!
george@george-ThinkPad-T420:~$ icedove
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "topmenu-gtk-module"
/usr/lib/icedove/defaults/pref/vendor.js:55: prefs parse error: expected ',' or ')' after pref value
1607815960948 addons.xpi WARN Not converting unknown addon type undefined
1607815961733 addons.xpi WARN Can't get modified time of name at domain
console.log: WebExtensions: Loading packed extension from /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
console.log: WebExtensions: Loading add-on preferences from /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
console.log: WebExtensions: Firing profile-after-change listeners for {e2fda1a4-762b-4020-b5ad-a41df1933103}
[calBackendLoader] Using Icedove's builtin libical backend
1607815962632 addons.xpi-utils WARN addMetadata: Add-on name at domain is invalid: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.isFile]" nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)" location: "JS frame :: resource://gre/modules/addons/XPIInstall.jsm :: get :: line 235" data: no] Stack trace: get()@resource://gre/modules/addons/XPIInstall.jsm:235
syncLoadManifest()@resource://gre/modules/addons/XPIInstall.jsm:754
addMetadata()@resource://gre/modules/addons/XPIDatabase.jsm:2711
processFileChanges()@resource://gre/modules/addons/XPIDatabase.jsm:3152
getNewSideloads()@resource://gre/modules/addons/XPIProvider.jsm:2982
wait()@subprocess.jsm:392
setAgentPath()@gpgAgent.jsm:487
initialize()@core.jsm:389
getEnigmailService()@setupWizard2.js:228
checkGnupgInstallation/<()@setupWizard2.js:157
checkGnupgInstallation()@setupWizard2.js:156
onLoadAsync()@setupWizard2.js:67
callbackWrapper()@timer.jsm:32
notify()@resource://gre/modules/Timer.jsm:62
fetchOverlay()@resource:///modules/Overlays.jsm:524
load()@resource:///modules/Overlays.jsm:101
load()@resource:///modules/Overlays.jsm:48
registerNonBootstrapped/<()@ext-legacy.js:242
registerNonBootstrapped()@ext-legacy.js:236
openModalWindow()@resource://gre/modules/Prompter.jsm:456
openPrompt()@resource://gre/modules/Prompter.jsm:702
alert()@resource://gre/modules/Prompter.jsm:751
loadStartFolder()@msgMail3PaneWindow.js:1036
1607815962638 addons.xpi-utils WARN Could not uninstall invalid item from locked install location
1607815962646 addons.xpi-utils WARN addMetadata: Add-on name at domain is invalid: Error: File name at domain does not contain a valid manifest(resource://gre/modules/addons/XPIInstall.jsm:671:11) JS Stack trace: name at domain:671:11
name at domain:228:15
name at domain:755:22
name at domain:2711:32
name at domain:3152:26
name at domain:2982:28
name at domain:392:22
name at domain:487:40
name at domain:389:27
name at domain:228:20
checkGnupgInstallation/<@setupWizard2.js:157:9
name at domain:156:10
name at domain:67:24
name at domain:32:7
name at domain:62:17
name at domain:524:9
name at domain:101:22
name at domain:48:14
registerNonBootstrapped/<@ext-legacy.js:242:18
name at domain:236:21
name at domain:456:15
name at domain:702:5
name at domain:751:10
name at domain:1036:21
1607815962646 addons.xpi-utils WARN Could not uninstall invalid item from locked install location
Also,enigmail made a stab at starting up, but it's not seeing my huge icedove data ...
I was going to check the ownership of the files on that hard drive ... but not with that File Manager ...
Wait ! There's more:
There was an error while getting the sharing information:
'net usershare' returned error 255: mkdir failed on directory /var/run/samba/msg.lock: Permission denied
net usershare: cannot open usershare directory /var/lib/samba/usershares. Error No such file or directory
Please ask your system administrator to enable user sharing.
After gathering that dope together, File Manager became unstuck ...
I tried on my system and got:
$ icedove
/usr/lib/icedove/defaults/pref/vendor.js:55: prefs parse error: expected ',' or ')' after pref value
1607875644884 addons.xpi WARN Can't get modified time of name at domain
There is indeed an error in /usr/lib/icedove/defaults/pref/vendor.js. Deleting the offending line solves it (not that it matters...):
$ sudo sed -i 54d /usr/lib/icedove/defaults/pref/vendor.js
All the subsequent messages deal with your addons. That is why I would first see if there is any problem with a new profile you could create by executing:
$ icedove -P
Please show us again the output in the terminal emulator.
The penultimate script ran without a peep.
Running icedove -P produced the following complaints:
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "topmenu-gtk-module"
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
And Icedove's familiar Choose User Profile box popped up ... I chose _not_ to use that one without asking
at startup, and I didn't choose to work offline.
Last communication:
Unable to locate mail spool file
Looks like progress ... three of my six nmap scripts are still running; the other three finished OK.
I asked sudo apt-get to install the two missing modules ... never heard of them ...
Does that mean Icedove seems to properly work using a new profile? If so, try to remove some of your add-ons in the profile you normally use. Do that from the graphical interface, if it lets you do so (does it?). I only use Enigmail and face no issue.
The Icedove directory in my hard drive has the profile that I want icedove to pick up ...
The Kmail mail importing tool wants to create a new folder into which to import mail.
I want to inform icedove where all its data is sitting already.
At present the graphical interface is a bare-bones icedove that's suggesting a couple
of profiles, neither my own; and it won't let me simply copy & paste mine in.
I poked around in Trisquel_7's /home/george folder (in another T420) and found a file called IceDoveProblem-8092015.txt,
which begins with "icedove -P profilemanager" I used the absolute path to my icedove profile in the
Icedove folder. Here's what ensued:
icedove -P /media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/Icedove/gqat6csx.08202015Gtk-Message:
Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "topmenu-gtk-module"
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/AsyncShutdown.jsm, line 694: Error: Phase "xpcom-will-shutdown"
is finished, it is too late to register completion condition "UserInteractionTimer 1 for document 7fe84b178000"
If you want help, please clearly explain what actually happens when you try to start Icedove 1) with your regular profile and 2) with a new profile. I still do not understand if Icedove's window appears, if it is responsive, etc.
To remove the extensions from all profiles, I guess this command would work:
$ rm .icedove/*/extensions/*
In a brief moment of lucidity, when the usual popup box appeared (as it does whenever I start icedove
on the other two T420's), it dawned on me that I could "rename the profile" to the actual profile by
which I have started icedove on the other computers since way back when ... alas, here I am, patting
myself on the back like the corpse in the film "Deliverance" and nothing more than a virgin setup page
appears instead.
Just in case, I ran sudo chown -R george Icedove before the next step:
Here's what the terminal reveals when I try to start icedove ==>
(the good news is that my usual icedove profile is shown in the popup box):
icedove
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "topmenu-gtk-module"
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/AsyncShutdown.jsm, line 694: Error: Phase "xpcom-will-shutdown" is finished, it is too late to register completion condition "UserInteractionTimer 1 for document 7f3f98d7b000"
###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "topmenu-gtk-module"
1607910215747 addons.xpi WARN Not converting unknown addon type undefined
1607910215801 addons.xpi-utils WARN addMetadata: Add-on name at domain is invalid: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.isFile]" nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)" location: "JS frame :: resource://gre/modules/addons/XPIInstall.jsm :: get :: line 235" data: no] Stack trace: get()@resource://gre/modules/addons/XPIInstall.jsm:235
syncLoadManifest()@resource://gre/modules/addons/XPIInstall.jsm:754
addMetadata()@resource://gre/modules/addons/XPIDatabase.jsm:2711
processFileChanges()@resource://gre/modules/addons/XPIDatabase.jsm:3152
checkForChanges()@resource://gre/modules/addons/XPIProvider.jsm:2946
startup()@resource://gre/modules/addons/XPIProvider.jsm:2406
callProvider()@resource://gre/modules/AddonManager.jsm:213
_startProvider()@resource://gre/modules/AddonManager.jsm:649
startup()@resource://gre/modules/AddonManager.jsm:873
startup()@resource://gre/modules/AddonManager.jsm:3470
observe()@resource://gre/modules/addonManager.js:70
1607910215803 addons.xpi-utils WARN Could not uninstall invalid item from locked install location
1607910215804 addons.xpi-utils WARN addMetadata: Add-on name at domain is invalid: Error: File name at domain does not contain a valid manifest(resource://gre/modules/addons/XPIInstall.jsm:671:11) JS Stack trace: name at domain:671:11
name at domain:228:15
name at domain:755:22
name at domain:2711:32
name at domain:3152:26
name at domain:2946:55
name at domain:2406:12
name at domain:213:31
name at domain:649:5
name at domain:873:14
name at domain:3470:26
name at domain:70:29
1607910215804 addons.xpi-utils WARN Could not uninstall invalid item from locked install location
console.log: WebExtensions: Loading packed extension from /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
console.log: WebExtensions: Loading add-on preferences from /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
console.log: WebExtensions: Firing profile-after-change listeners for {e2fda1a4-762b-4020-b5ad-a41df1933103}
[calBackendLoader] Using Icedove's builtin libical backend
1607910221887 addons.xpi WARN Can't get modified time of name at domain
1607910221892 addons.xpi-utils WARN addMetadata: Add-on name at domain is invalid: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.isFile]" nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)" location: "JS frame :: resource://gre/modules/addons/XPIInstall.jsm :: get :: line 235" data: no] Stack trace: get()@resource://gre/modules/addons/XPIInstall.jsm:235
syncLoadManifest()@resource://gre/modules/addons/XPIInstall.jsm:754
addMetadata()@resource://gre/modules/addons/XPIDatabase.jsm:2711
processFileChanges()@resource://gre/modules/addons/XPIDatabase.jsm:3152
getNewSideloads()@resource://gre/modules/addons/XPIProvider.jsm:2982
1607910221893 addons.xpi-utils WARN Could not uninstall invalid item from locked install location
1607910221895 addons.xpi-utils WARN addMetadata: Add-on name at domain is invalid: Error: File name at domain does not contain a valid manifest(resource://gre/modules/addons/XPIInstall.jsm:671:11) JS Stack trace: name at domain:671:11
name at domain:228:15
name at domain:755:22
name at domain:2711:32
name at domain:3152:26
name at domain:2982:28
1607910221895 addons.xpi-utils WARN Could not uninstall invalid item from locked install location
JavaScript error: resource://gre/modules/addons/XPIProvider.jsm, line 228: TypeError: NetworkError when attempting to fetch resource.
Magic Banana insists that I read this message again:
If you want help, please clearly explain what actually happens when you try to start Icedove 1) with your regular profile and 2) with a new profile. I still do not understand if Icedove's window appears, if it is responsive, etc.
This morning, after Trisquel_8 has had time to "think about it" overnight, when I simply typed icedove at the terminal prompt, the familiar small pop-up box appeared with a list of two profiles, one a generic profile, and the other, my own personal profile name that I've been using for many years (screenshot attached !).
When I select "start icedove" another pop-up window appears (also attached) from which I select "manual config" which brings up a third pop-up window (attached) beyond which further progress depends on knowing what are the exact settings.
My actual cPanel server is reached through my Internet Service Provider and is labelled "secure{redacted].[redacted ISP name]:[redacted port number]/" but I'm unsure whether any or all of that belongs in the spot where ".[my domain name]" is suggested. Whatever I've tried so far elicits the reply that "Icedove has failed to find the settings for you account." Those settings ought to be included in my icedove profile. I can try to find them by using one of my other T420's that have all by themselves themselves solved the Icedove riddle.
What I'm showing in the attachments has never happened until this morning when that first popup had a live version of my icedove profile for the very first time, as it otherwise always does when starting icedove on the other trisquel operating systems, Trisquel_7 through Trisquel_9, in my two other T420's.
Behind those windows there's a blank set-up-icedove-from scratch window that I needn't include, which obscures the usual detailed complaints that appear in the terminal window (also attached).
| Attachment | Size |
|---|---|
| TerminalResponse-12142020.txt | 4.55 KB |
OK. And all that is with your usual profile, right? What happens if you click the Cancel button? Does Icedove's main window appear? Without your email accounts? Do you still have the CPU usage going to 100% (as you reported in your first post)? You still have many messages in the terminal about add-ons. I would (re)move the extensions, as I explained. Have you done it? That said, you now have new and apparently more problematic errors, which you did not have yesterday. Starting with:
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
I do not know what you have done in between to get those new errors.
Our dialog continues:
OK. And all that is with your usual profile, right?
Yes.
What happens if you click the Cancel button?
Does Icedove's main window appear?
See screenshot, attached.
Without your email accounts?
Nothing.
Do you still have the CPU usage going to 100% (as you reported in your first post)?
Thankfully, no.
You still have many messages in the terminal about add-ons.
Yes, indeed:
1608045057154 addons.xpi
1608045057234 addons.xpi-utils
addMetadata: Add-on name at domain is invalid
location: "JS frame :: resource://gre/modules/addons/XPIInstall.jsm :: get :: line 235"
data: no] Stack trace: get()@resource://gre/modules/addons/XPIInstall.jsm:235
syncLoadManifest()@resource://gre/modules/addons/XPIInstall.jsm:754
addMetadata()@resource://gre/modules/addons/XPIDatabase.jsm:2711
processFileChanges()@resource://gre/modules/addons/XPIDatabase.jsm:3152
checkForChanges()@resource://gre/modules/addons/XPIProvider.jsm:2946
startup()@resource://gre/modules/addons/XPIProvider.jsm:2406
callProvider()@resource://gre/modules/AddonManager.jsm:213
_startProvider()@resource://gre/modules/AddonManager.jsm:649
startup()@resource://gre/modules/AddonManager.jsm:873
startup()@resource://gre/modules/AddonManager.jsm:3470
observe()@resource://gre/modules/addonManager.js:70
1608045057236 addons.xpi-utils WARN Could not uninstall invalid item from locked install location
1608045057237 addons.xpi-utils WARN addMetadata: Add-on name at domain is invalid: Error: File name at domain does not contain a valid manifest(resource://gre/modules/addons/XPIInstall.jsm:671:11) JS Stack trace: name at domain:671:11
name at domain:228:15
name at domain:755:22
name at domain:2711:32
name at domain:3152:26
name at domain:2946:55
name at domain:2406:12
name at domain:213:31
name at domain:649:5
name at domain:873:14
name at domain:3470:26
name at domain:70:29
1608045057238 addons.xpi-utils WARN Could not uninstall invalid item from locked install location
console.log: WebExtensions: Loading packed extension from /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
console.log: WebExtensions: Loading add-on preferences from /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
console.log: WebExtensions: Firing profile-after-change listeners for {e2fda1a4-762b-4020-b5ad-a41df1933103}
[calBackendLoader] Using Icedove's builtin libical backend
1608045063683 addons.xpi WARN Can't get modified time of name at domain
1608045063690 addons.xpi-utils WARN addMetadata: Add-on name at domain is invalid: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.isFile]" nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)" location: "JS frame :: resource://gre/modules/addons/XPIInstall.jsm :: get :: line 235" data: no] Stack trace: get()@resource://gre/modules/addons/XPIInstall.jsm:235
syncLoadManifest()@resource://gre/modules/addons/XPIInstall.jsm:754
addMetadata()@resource://gre/modules/addons/XPIDatabase.jsm:2711
processFileChanges()@resource://gre/modules/addons/XPIDatabase.jsm:3152
getNewSideloads()@resource://gre/modules/addons/XPIProvider.jsm:2982
1608045063691 addons.xpi-utils WARN Could not uninstall invalid item from locked install location
1608045063705 addons.xpi-utils WARN addMetadata: Add-on name at domain is invalid: Error: File name at domain does not contain a valid manifest(resource://gre/modules/addons/XPIInstall.jsm:671:11) JS Stack trace: name at domain:671:11
name at domain:228:15
name at domain:755:22
name at domain:2711:32
name at domain:3152:26
name at domain:2982:28
1608045063705 addons.xpi-utils WARN Could not uninstall invalid item from locked install location
JavaScript error: resource://gre/modules/addons/XPIProvider.jsm, line 228: TypeError: NetworkError when attempting to fetch resource.
I would (re)move the extensions, as I explained. Have you done it?
Referring to this Trisquel.info resource:
https://trisquel.info/en/forum/icedove-6880-cannot-get-add-ons-trisquel-8
Where it's said (in part):
Trying to install add-ons on Icedove:
1. Open Icedove. (see screenshot)
2. Open the Add-on Manager by pressing F10 to make the Menu bar visible ..., (not possible ...)
If I could only access any live icedove ...
...then deploying the Tools menu, then clicking on the Add-ons item.
That said, you now have new and apparently more problematic errors, which you did not have yesterday.
Starting with: JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
I had already made sure to set the permissions on the Data partition ...
A new set of icedove profiles has emerged which may be the ones in the initial icedove start-up pop-up window:
/home/george/.icedove/9yceysz7.default-release
/home/george/.icedove/sl1dobdz.default
/home/george/.icedove/installs.ini
/home/george/.icedove/profiles.ini
_My_ icedove has my profile in the Data partition:
/media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/Icedove/gqat6csx.08202015
/media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/Icedove/jkrky702.default
/media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/Icedove/TedxTalks
/media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/Icedove/profiles.ini
Adjacent to which there's an Add-Ons folder:
/media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/IceDoveAddOns/IcedoveAddOns/remove_duplicate_messages-0.1.14-tb.xpi
/media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/IceDoveAddOns/IcedoveAddOns/remove_duplicate_messages_alternate-0.3.12-tb.xpi
I do not know what you have done in between to get those new errors.
.bash_history ==>
icedove -P
sudo apt-get install canberra-gtk-module
sudo apt-get install topmenu-gtk-module
...
icedove -profilemanager
icedove -P gqat6csx.08202015
icedove -P /media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/Icedove/gqat6csx.08202015
icedove -P profilemanager /media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/Icedove/gqat6csx.08202015
grep ' .' TrisquelQuestion.txt > Temp-12132020TQ9.txt
grep ' .' TrisquelQuestionSalted.txt > Temp-12132020TQ9S.txt
...
icedove
The ellipses cover irrelevant text processing ...
There appears to be a disconnect between the partition containing Trisquel_8's code
and the Data partition where my icedove folder is and where my .icedove profile and data actually are.
_My_ icedove has my profile in the Data partition
Icedove searches your profile in ~/.icedove. Not in /media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/Icedove/. Do you really want your emails on a removable medium?
Magic Banana wondered: Do you really want your emails on a removable medium?
It's part of the same /dev/sda as Trisquel_9 (far left), swap, Trisquel_8, and the data partition (far right).
I've never called it removable, Maybe this will help to reveal what I've failed to do a little more clearly.
/media is supposed to be for removable media. Your partitioning is bad. Currently, if you put Icedove's profile where it should be, in ~/.icedove, it will occupy space on /dev/sda1, which is small. Also, /dev/sda3 should not have the boot flag.
/dev/sda4 should be for user data, with a filesystem mounted at /home, which could be shared by Trisquel 8 and 9. But that would require editing /etc/fstab and I doubt you need Trisquel 8 anymore. An easier solution is:
- back up all user data on /dev/sda3 and /dev/sda4;
- boot a live system;
- delete /dev/sda2, /dev/sda3 and /dev/sda4;
- recreate a swap partition at the end of the disk;
- enlarge /dev/sda1 to take the whole free space (do not format it!);
- reboot on the installed system;
- restore the files of the backup where they should be, in your home directory, in ~/.icedove for Icedove's profile.
Almost all of the problems you describe in this forum are problems that you created for yourself. You might save yourself (and Magic Banana) some time by accepting defaults more often and using software the way it was intended to be used.
chaosmonk isn't buying any of it:
... accepting defaults more often and using software the way it was intended to be used.
There was a joint advisory issued in October this year about ransomware applied to hospitals, etc.:
https://us-cert.cisa.gov/sites/default/files/publications/AA20-302A_Ransomware%20_Activity_Targeting_the_Healthcare_and_Public_Health_Sector.pdf
Wherein a list of 31 confiscated IPv4's was presented.
I applied the search techniques that Magic Banana has been helping me with and found that several of the CIDR/24 blocks wherein the confiscated servers resided have multi-addressed PTR's and single hostnames that cannot easily be resolved that are reminiscent of the CIDR/24 blocks that I've found related to on-line Recent Visitors databases.
Putting chasomonk's statement a little differently:
CISA may have confiscated those thirty-one ransomware servers, but the faults are still active
Magic Banana is keeping me on the straight & narrow by insisting that I use those text-processing tools correctly without taking expedient short cuts.
His suggestions are always right on the money. All the data I'm collecting is freely available on the Internet or accessible from the Trisquel repository.
George Langford
That has nothing to do with your partitioning schema. Accepting the defaults (most of the disk taken by a large filesystem mounted at /home), you would indeed have a working email client, I believe.
> Putting chasomonk's statement a little differently:
> CISA may have confiscated those thirty-one ransomware servers, but the faults are still active
That's putting my statement more than a *little* differently. It's a completely different (and completely irrelevant) statement.
The reason your system is broken is that you messed around instead of accepting Trisquel and Icedove's working defaults. It has nothing to do with ransomware. Just put everything back how it belongs. Magic Banana has already explained how:
=> https://trisquel.info/en/forum/restarting-icedove-after-full-reinstall-trisquel8#comment-154610
Magic Banana suggests:
Accepting the defaults (most of the disk taken by a large filesystem mounted at /home), you would indeed have a working email client, I believe.
The first two screenshots illustrate what usually happens when I invoke icedove from the terminal; in the present instance:
icedove -P default-release
The smaller pop-up arrives immediately after the larger window; closing the smaller pop-up releases access to the larger window.
The smaller one says "Unable to locate mail spool file." The larger one has been as far as I can get.
There are two mail importer tools available, one graphical (Kmail Import Wizard), the other (mboximporter) invoked from the terminal.
Invoking either one brings up the (largest screenshot) third window, which is expecting settings that have eluded me before it can proceed.
I believe you can just copy the profile directory, installs.ini and profiles.ini to ~/.icedove. There is no need for "importer tools". But, again, your home directory is on /dev/sda1, which is small. If you have like me 14 GB of emails archives, it will not fit.
Back to Square One.
After shutting down a running script to investigate whether my still-remaining Trisquel_7
had the bridging information to bring icedove back to life, I discovered that icedove
didn't exist back in those old days.
So I let Software Updater do its "upgrade system" thing, which went OK until it came time
to restart. The restart brought me to a home page with no "Panel."
This link gave the critical correction:
https://trisquel.info/en/forum/gnome-panel-lost, where it's said to enter (which I could get by right-clicking on the home/wallpaper)
sudo apt-get install xfce4-panel in the terminal
However, while I can make most of the usual panel with which I'm familiar, as soon as I
close the terminal, the panel disappears, even after selecting "lockpanel."
Here's what the terminal has to say about starting xfce4-panel:
xfce4-panel
(xfce4-panel:2156): libxfce4ui-WARNING **: ICE I/O Error
xfce4-panel: Failed to connect to session manager: Failed to connect to the session manager: IO error occured doing Protocol Setup on connection
libpager-Message: Setting the pager rows returned false. Maybe the setting is not applied.
/usr/share/alacarte/Alacarte/MainWindow.py:22: PyGIWarning: GMenu was imported without specifying a version first. Use gi.require_version('GMenu', '3.0') before import to ensure that the right version gets loaded.
from gi.repository import Gtk, GdkPixbuf, Gdk, GMenu
Gtk-Message: Failed to load module "canberra-gtk-module"
(alacarte:2164): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
(alacarte:2164): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"
Further, the usual Trisquel logo ikon is absent, and I cannot access the start/stop/restart
menu ... and the terminal has no hint as to where the now-familiar canberra-gtk-module is.
Killing what little of the new Trisquel_8 home page.desktop there is and restarting one of
the earlier versions of trisquel that exist in the (updated) grub menu, I get back to a
desktop with (still) no panel(s).
Be patient; there's a SATA hard drive caddy & another SATA hard drive on the way; I'll use
those as home for a brand-spanking-new Trisquel_9 (all by itself) hard drive, move all the
data on /ver/sda4 into the new drive's Data partion, and proceed normally.
Dual Boot on this particular multi-Trisquel, zero Windows hard drive is an abject failure.
I offer my "Thank You" to Magic Banana for persevering through this frustrating process.
George Langford
I repeat: your partitioning scheme is bad. Follow the steps I gave in https://trisquel.info/forum/restarting-icedove-after-full-reinstall-trisquel8#comment-154610 to have a large single /dev/sda1 partition for Trisquel 9, where you can restore the configuration files where your programs expect them, in your home directory.
Progress:
A couple of days ago a new hard drive arrived. I installed it in the CDROM-drive ==> SATA caddy and
installed Trisquel_9 from the Installer/Flash drive I made by the usual Trisquel procedure.
In my case a voice whispered in my ear when I was partioning that new hard drive that I should make
a lager operating system partition, so I doubled it to 40 GB. Good thing.
A couple of "secret handshake" tips come to mind:
When the Installer says to restart the computer, don't yank that flash drive out of the USB port;
and don't rely on the grub menu; let the machine start the way it wants to. The flash drive won't
start the install process over; it's meant to let you run Trisquel_9 to finish the software updates.
Be sure to open Software Updater right away and change the mirror site to what trisquel's site
checker says is best. Then run update-grub so you'll know where the new operating system is in the
scheme of things, ordered top to bottom like /dev/sda, /dev/sdb, /dev/sdc would be.
Bringing your old Icedove mail collection back to life: Back in 2018, I published my best understanding
of this particular "hack:"
https://trisquel.info/en/forum/icedove-profile-migration Repeated here with updated terminology.
0. Be sure to install icedove from the terminal first; if you don't, there won't be a /home/username/.icedove
directory from which to begin.
1. The .icedove folder is indeed right there in the home folder. In the terminal, type
cd /home/username/.icedove and a list of profiles (one from each attempt to get Icedove
started) and a profiles.ini file. We'll get to the matter of editing profiles.ini later
... It's the oddly named profile folder (looks like a password !) that you want to migrate.
2. Be aware that going to /home/username and typing ls or cd .icedove doesn't work; the path
has to have a visible file listed before the hidden file. Then run
sudo chown -R username /media/username/[name of hard drive containing your Icedove
collection]
If you don't, the system won't know your username is the same guy who created that Icedove
folder in the first place.
3. To prepare for the move of your Icedove profile, either cut & paste or copy that profile
into its new location, also in the /home/username/.icedove folder of the new HDD. [Or from the
/media/username/HardDrive/Icedove/user.profile to the /home/username/user.profile.] In my
case it was a long wait for the 18GB of data. Don't try to rename the target location's
profile first, or the system will make your profile a subdirectory of the target profile;
make sure there's just the /path to target drectory/ in the copy command.
4. ...
5. While still in the source [or target] HDD's /home/username/.icedove folder, copy the existing
profiles.ini file with the terminal while giving the copy a new name:
cp profiles.ini profilesTarget.ini
In the present situation, making the /home/username/.icedove folder aware of the location of
my Icedove collection in the Data partition of the new hard drive, the move was in the opposite
direction.
6. Copy profilesTarget.ini from the source HDD to the equivalent location in the target HDD
with your file manager. Or it could be in the opposite diection ...
7. In the target [Data partition of the] HDD, edit the existing profiles.ini file. I used
sudo nano profiles.ini.
8. The original profiles.ini file will have one line called Path=vkhf0fqm.default or similar.
Your profilesTarget.ini file will have _your_ profile folder's name in place of the above
Path=vkhf0fqm.default. To avoid any dramatic consequences, I transcribed the correct profile
folder's name instead of attempting copy & paste, and then checked its accuracy. Do not
change anything else in the profiles.ini file. Once you're sure, hit Contr.+X and say yes
(Y) when asked to save it over its original name. This technique avoids changing anything
[else] in your profilesTarget.ini file. In the present example, I just put my user.profle
where another [arbitrary] user.profile had been, over-writing that profile without changing
anything else. Never anything else ...
9. Start your installation of Icedove from its new position in the Internet menu of your
browser (in my case, Abrowser, though only Konquerer comprehends my ISP's cpanel mail
application). You won't see much ... yet. If the choose-your-profile pop-up box appears,
choose the "rename profile" link and type in the name of your user.profile [carefully].
You ought to be given the opportunity to edit the connection data (link at lower left
of the connection screen) by entering all you know about your ISP's details. In my case
the mail.domain.name connection is deprecated because it draws malevolence like flies to
honey; it has to be replaced with the URL of the secure cPanel mail connection. If you get
enough of that data right, on the next restart of Trisquel_9 and Icedove, you should reach
your Icedove mail collection OK. In my case, 18,000 old emails (2 GB) were awaiting retrieval.
George Langford
I should make a lager operating system partition, so I doubled it to 40 GB.
The problem with your partition schema was missing space for user data, not for the system. However, if /home is not on a separate partition, it is indeed the root partition, /, that should be large... and 40 GB is not large nowadays. I do not understand why you did not follow the steps I gave you. They required no new installation and no new hard drive.
You list many instructions that were not needed. Assuming, the whole content of Icedove's configuration directory was in /media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/Icedove, you could have just moved that folder to ~/.icedove with the file manager or that command:
$ mv /media/george/24dbecab-3704-43ee-87b8-54fa4aabba5e/george/Icedove ~/.icedove
You can delete the profiles you do not use (not that they take much disk space), selecting them and using the eponymous button in the window that appears right after you execute 'icedove -P'.
I have been laboring under the proposition that the operating system ought to have its own partition and that all
user data should be in a separate but much larger partition. Putting the entirety of the Icedove data in ~/.icedove
goes against that popular wisdom ... but as my data increased only one gigabyte in the past year or so, having 12 GB
of free room in the Trisquel_9 partition ought to carry me another twelve years, by which time I'd be 96 years old.
I've ordered two CDROM/DVD caddies at ~$8 each; one will be for that hybrid SS/Disc drive into which Trisquel_9
ought to fit and into which I ought to be able to install my ~/.icedove data.
Should there be a way of pointing the installed Icedove at the data in the Data partition of the hard drive with
hard links ?
Getting rid of no-longer-needed trisquel operating system files with autoremove in Trisquel_8 & Trisquel_9 has been
a boon to users like me who are so busy actually using the operating system that we were having to re-learn the
process over again every few months.
> I have been laboring under the proposition that the operating system ought to have its own partition and that all
> user data should be in a separate but much larger partition. Putting the entirety of the Icedove data in ~/.icedove
> goes against that popular wisdom
The "entirety of the Icedove data" is not in ~/.icedove. That folder contains user data. System data is in other locations, like /etc and /usr. .icedove belongs in your home partition. Fix your partitioning scheme like Magic Banana told you, move .icedove to ~ where it belongs, and end this nonsense.
> I've ordered two CDROM/DVD caddies at ~$8 each; one will be for that hybrid SS/Disc drive into which Trisquel_9
> ought to fit and into which I ought to be able to install my ~/.icedove data.
That is unnecessary and silly. You caused this problem by coming up with your own ideas and acting on them. The solution is to undo what you did, not to come up with more ideas and act on those too. That's just going to lead to more problems.
I'm reminded of a cat that knows how to climb trees, but does not know how to get down, and when anyone tries to help the cat get down it takes a long time to do so because the cat keeps explaining *why* it climbed the tree and coming up with it's own ideas about how to get down, which get it stuck even higher in the tree, and then explaning why it did that.
I have been laboring under the proposition that the operating system ought to have its own partition and that all user data should be in a separate but much larger partition. Putting the entirety of the Icedove data in ~/.icedove goes against that popular wisdom ...
User data belong to /home. "~" in "~/.icedove" stands for your home folder: /home/george since your username is george. It is in /home.
/home can be on a separate partition. That brings some advantages, such as being able to replace a GNU/Linux system with another keeping the same /home, but also a drawback: repartitioning is needed if the partitions were not well dimensioned (one of the two partitions is full while the other one has much free space). If /home is not on a separate partition, it is under /, the root partition.
Typically, most data on a disk are user data. As a consequence, the partition with /home usually takes most of the disk. Applications expect your data to be in your home folder. It is, in particular, the case of Icedove's profiles, which can contain many GB of emails.
Your /home is on the root partition. Yet that partition is small, 40 GB. You create additional partitions where you put user data. But, again, you cannot put there data that applications expect to find in your home folder.
Unless you have specific needs (you do not) or several internal disks (partitions cannot span over several disks), there is no reason to create any data partition besides /home. Even if you do, they are not supposed to be mounted in /media, which exists for removable media.
In the end, all you want is at most three partitions on your internal disk: a root partition, a swap partition, and a partition for /home. It is Trisquel's default: you create your problems for yourself, as chaosmonks wrote. The swap partition can be tiny (8 GB). The root partition can be small (here, 40 GB are appropriate), if there is indeed a separate partition, taking the rest of the disk, with a filesystem mounted at /home. Without a separate partition for /home (your case, currently), the root partition should occupy the whole disk, minus the swap partition. Do you understand?
Magic Banana advises:
User data belong to /home. "~" in "~/.icedove" stands for your home folder: /home/george since your username is george.
It is in /home.
After a while last night I came to that realization, arose before 7:00 Am today and set about making the Data partition
/home. Just about when I thought I had worked that out by changing fstab with sudo nano /etc/fstab so that /dev/sdb3 had a
mount point of /home, etc. I fumble-fingered an untraceable mess, and the system insisted on trying to open icedove on
startup no matter which operating system I tried.
I made sure that a re-install of Trisquel_9 would not obliterate precious data and started that process from my trusty
Trisquel_9 Install flash drive.
Not only is it crucial to set /dev/sdb as the starting place for boot-up, it is also crucial to double-click on /dev/sdb1
to bring up that elusive partition menu so as to set /dev/sdb1 as root (/), and equally crucial to perform the same secret
ritual with /dev/sdb3 (the Data partition) to designate that partition as home (/home). /dev/sda is the main HDD, and /dev/sdb
is the adjunct HDD, residingon the helpful caddy in the CDROM/DVD slot. GParted confirms that root (/) and home (/home) are
in their proper places.
At this stage my confidence evaporated. So far I have managed to edit my /home/george/.icedove/profiles.Target.ini file and
send home/george/.icedove/profile.ini to digital oblivion with sudo mv /home/george/.icedove/profiles.ini /dev/null. However,
starting Icedove fails to bring up that familiar pop-up window giving me the choice of profile to use; and profiles.ini is
re-created.
Here is profiles.Target.ini, residing in the /home/george/.icedove folder:
[InstallC8F8355A6A14EE43]
Default=67npsz4c.default-release
Locked=1
[Profile1]
Name=default
IsRelative=1
Path=2gziqw1b.default
Default=1
[Profile0]
Name=[Redacted].08202015
IsRelative=1
Path=67npsz4c.default-release
[General]
StartWithLastProfile=1
Version=2
The 08/20/2015 date is around the time that you and ADFENO helped me get that [Redacted] Icedove profile started.
The /etc/icedove directory contains only one file, quoted in its entirety:
/etc/icedove$ cat syspref.js
// This file can be used to configure global preferences for Abrowser
// Example: Homepage
//pref("browser.startup.homepage", "http://www.weebls-stuff.com/wab/");
Taking a look at the /home/george/.icedove directory with the Caja file manager, I discovered that profiles.Target.ini was locked.
That's to be expected (?) considering all the copy & paste activity getting the Data (/home) partition ready for the Trisquel_9
reinstall. Therefore, I executed sudo chown -R george /home/george/; afterwards, profiles.Target.ini was no longer "locked."
I restarted Trisquel_9, checked to be sure that profiles.Target.ini was not locked and that there was no profiles.ini to
interfere. Initiating Icedove from the main menu brought disappointment yet again, so I'm at a complete loss.
Another reference to the "method" is here:
https://trisquel.info/en/forum/icedove-profile-migration (#2)
It worked back then; why not now ?
Thanks to Magic Banana & chaosmonk for their patience.
George Langford
> It worked back then; why not now ?
You were just fumbling around without knowing what you were doing. If what you did worked, that just means you got lucky. More likely, the problems were just not immediately noticeable to you.
Trisquel software is packaged and preconfigured so that all of its components work together correctly. If you change the behavior of one component, even if it apppears to work at first glance, it may stop working when you make another change elsewhere on the system, which will require you to make more changes. Over time, this creates more and more work for yourself as things keep breaking unexpectedly.
> At this stage my confidence evaporated.
Good. Hopefully you will now start listening to the people trying to help you rather than trusting your own judgement.
At this point, I recommend doing a fresh install of Trisquel 9. DO NOT PARTITION IT YOURSELF. Just accept the default partitioning scheme proposed by the installer. Install the applications that you need, including Icedove, but DO NOT CONFIGURE THEM apart from simple settings that you can change using the GUI. Do not make any changes that require you to use the terminal or manually edit any configuration files, especially as root. Only make changes that are absolutely necessary to use the program (like entering your email account). Don't make changes just because you have some idea of how things should be done, like changing the location of files.
If anything seems wrong, or if you are not sure how to import some of your data into the freshly installed system, DO NOT TRY TO FIX IT. Tell us what the problem is, and we will tell you how to fix it.
Once everything is installed and configured correctly, you should be able to leave it alone for a long time. As Trisquel is an LTS distro, you should not have to do any work to maintain your system other than install updates using the package manager. You just need to stop breaking things.
Just about when I thought I had worked that out by changing fstab with sudo nano /etc/fstab so that /dev/sdb3 had a mount point of /home, etc.
What have you written in /etc/fstab? Have you created at the root of the partition a directory named "george"?
In https://trisquel.info/forum/restarting-icedove-after-full-reinstall-trisquel8#comment-154610 I gave you "an easier solution", which does not require editing /etc/fstab, as I specifically wrote...
I have managed to edit my /home/george/.icedove/profiles.Target.ini file and send home/george/.icedove/profile.ini to digital oblivion with sudo mv /home/george/.icedove/profiles.ini /dev/null.
And you do not have any backup, I assume. It appears you constantly work at making your problem worse. Also, 'rm' (not 'mv') is the command to remove, and it does not require 'sudo' for the files you own.
Changing in ~/.icedove/profiles.ini the Path value for that of your profile (so, it actually appears you can have your profile somewhere else), should work.
A fresh install too, as chaosmonk proposed. It has the advantage of correcting the other problems you probably created (for instance constantly using 'sudo chown -R', although it should essentially never be needed).
For five of six instances of reluctant icedove installations, until I found out that ~/.icedove had a hidden meaning,
I was forced to rely on editing fstab with the assistance of nano and blkid, while reading man fstab carefully, then
making sure that it was indeed the Data partition (and its vast storage capacity) mounted at /home/username/.icedove
and that the .icedove folder contained my icedove profile and a suitably edited (Leafpad works fine) profiles.ini
file. That profiles.ini file has two places which must contain the name of the operative profile: after Name=, and
after Path=. Icedove always started when I made sure of those criteria.
Then I came to my original nemesis, an installation of Trisquel_8 (flidas) that would not even start reliably. An
earlier version, appearing in grub's list of "Advanced Options" could start OK, but without the panel at the bottom
of the page. I was forced to retrieve my Triquel_8 flash drive and use that with the "something else" option so I
could be sure of reformatting only the partition wherein flidas was intended to be located during the reinstall.
Not only is it necessary to bring the secretive partition manager window up from its hiding place by double-clicking
the /dev/sda# partition in order to select that place for the operating system and to set the root (/) location there,
it is also necessary to select "back" and use that opportunity to double-click on the /dev/sda(Data) partition in
order to set its mount point to /home. I always select for reformatting only the location for the trisquel operating
system.
And you should make sure to select the appropriate place for the boot loader (/dev/sda in my case). I don't know
what grub will turn out to be if one accidentally selects a different hard drive ...
Again, without Magic Banana, ADFENO, and chaosmonk, I would never have gotten this far; thank you.
George Langford
the Data partition (and its vast storage capacity) mounted at /home/username/.icedove
A "vast" partition only for your email client. That does not make much sense. At some point, you will probably have another partition (maybe your root partition, especially if /home is on it) full, next to that "Icedove partition" with a single-digit percentage of usage.
Please, read again https://trisquel.info/forum/restarting-icedove-after-full-reinstall-trisquel8#comment-154734 until the last two paragraphs where I conclude that you have no good reason to create any data partition besides /home and that the partionning scheme you want is Trisquel's default.
> For five of six instances of reluctant icedove installations, until I found out that ~/.icedove had a hidden meaning,
> I was forced to rely on editing fstab with the assistance of nano and blkid, while reading man fstab carefully, then
> making sure that it was indeed the Data partition (and its vast storage capacity) mounted at /home/username/.icedove
> and that the .icedove folder contained my icedove profile and a suitably edited (Leafpad works fine) profiles.ini
> file.
You did not have to do any of this. You could have just installed Icedove normally, input your email credentials, and started using it. That's what everybody else does, and they don't have all these problems.
> Not only is it necessary to bring the secretive partition manager window up from its hiding place by double-clicking
> the /dev/sda# partition in order to select that place for the operating system and to set the root (/) location there,
> it is also necessary to select "back" and use that opportunity to double-click on the /dev/sda(Data) partition in
> order to set its mount point to /home. I always select for reformatting only the location for the trisquel operating
> system.
It was not necessary to do any of this either. If you had just installed Trisquel normally, accepting the default partitioning scheme, everything would have been fine.
Reinstall Trisquel like I said. Accept the defaults. Stop trying to make decisions for yourself. You don't know what you are doing, and it is selfish to keep doing it anyway and then wasting other people's time asking them to clean up the mess.
> Again, without Magic Banana, ADFENO, and chaosmonk, I would never have gotten this far; thank you.
I guess it was a mistake for anyone to ever help you then. Those who did were only giving you rope to hang yourself by, as you now have just enough half-knowledge to be dangerous to yourself, and you refuse to stop using it. It would have been better if everyone had ignored you.