Hello:

You're welcome.

I see.

From my limited understanding of the problem at hand, there is something (could be a bug) that is not allowing access to your mailbox.
My gut tells me that the issue is like the one that was affecting mutt.

Maybe there's something in the /var/log/auth file that could be of use.

Is there a log file for evolution you could look at?

I've seen that version 3.2.3 has/had a debug setting you can enable to start it from the command line:
See: https://askubuntu.com/questions/301665/ … -a-logfile

I do not use apparmor or any of the other 'security' applications like tomoyo that are quietly enabled by default (!) in Linux these days, so my kernel command line includes security=none apparmor=0.

You may want to try adding the same stanza at boot time to see if it has any effect as as well as temporarily disabling firejail while you are at it.

Hope that helps, can't think of anything else.

Best,

A.

EDIT:

It would seem that it's a bug ...

https://bugs.debian.org/cgi-bin/bugrepo … 1006603#10

... albeit with a temporary workaround:

Best,

A.

Hello:

It's well worth trying ...

First I zapped with sgdisk:

~$ sudo sgdisk --zap-all /dev/sdf

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************

GPT data structures destroyed! You may now partition the disk using fdisk or other utilities.
~$

Then I used fdisk to create a partition and delete the iso9660 signature:

~$ sudo fdisk /dev/sdf

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x0be77ae3.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)

Select (default p): p
Partition number (1-4, default 1):
First sector (2048-585937499, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-585937499, default 585937499):

Created a new partition 1 of type 'Linux' and of size 279.4 GiB.
Partition #1 contains a iso9660 signature.

Do you want to remove the signature? [Y]es/[N]o: y

The signature will be removed by a write command.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
~$

Unfortunately I was not able to recover anything from fsck and any of the listed superblocks.
ie: 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 and 71663616

They were all corrupted.  8^|

At this point I decided to cut my losses and cleared the #$%& drive, formatted as ext4 and put it back on-line.
Fortunately, I was able to scrape back some files using PhotoRec but, as I posted earlier, it is a huge mess I have to sift through by hand.

My sincere thank you to all who pitched in.

Best,

A.

Hello:

Hmm ...
Nice club we belong to.

TestDisk has saved my hide once or twice.
But I had never before had to face such a screw up.

I dd'id the *iso file to a data HDD drive instead of dd'ing it to the USB stick. 8^/

~$ sudo dd if=/home/user/Downloads/chimaera_amd64_desktop-live.iso of=/dev/sdg1 bs=1M

I've realised that this happened because I used lsblk to re-check the USB drive's asigned letter.

This instead of checking it with gparted as I always do.
Big mistake ...

For some reason the USB drive did not mount.
As a result of that, /dev/sdg1 ended up being assigned to the data HDD drive drive instead of the USB drive.

I knew (from the last time I plugged it in) that the USB drive mounted at /dev/sdg1, so when I saw it in the lsblk printout, I assumed everything was all right.

Obviously, I did not notice that the size was 279.4G instead of 7.2G.     
Had I checked with gparted, this would have not happened.

No idea how to do that.
Would you mind explaining how to  do it?

Indeed ...
A real mess.
See my previous post.

Thanks in advance,

A.

Hello:

Hmm ...
No idea as to how to do that.
Never done that.

This is what fdisk says about the botched drive:

groucho@devuan:~$ sudo fdisk -l
--- snip ---
Disk /dev/sdf: 279.4 GiB, 300000000000 bytes, 585937500 sectors
Disk model: HUS153030VLS300 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x563437db

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdf1  *     2048 585936895 585934848 279.4G 83 Linux
groucho@devuan:~$ 

Even if I knew how to do it, TestDisk was not able to write recovered new partition data to the drive.

Thanks for your input.
   
Best,

A.

Hello:

https://dev1galaxy.org/viewtopic.php?pid=33932#p33932

Hello:

MS software is and has been for the longest time notorious for not adhering to established standards/rules.
To MS, if it works with their software and the drivers hardware OEMs write for their OSs, it is good enough.

The web is full of examples, the most annoying one being all the horribly written BIOSs Linux OSs have had to deal with for ages.
As long any crap ridden BIOS worked with a MS OS, it was Windows XX Certified.

Obviously, it was not an issue if it did not work with any other OS.
eg: a Linux based OS.

All PCs were/are still sold with a MS OS, whether you want/ed it or not, so what problem could there possibly be?

I doubt that gparted is lying to you.
It does not have a will of its own.  8^D

What is most probably happening is that the data gparted is reading from the drive does not conform to the established standard.
ie: whatever the MS software wrote on the drive is not written in such a way that gparted can understand it correctly.

Like they say: rubbish in, rubbish out.

Best,

A.

Hello:

Please *stop* with all the Windows stuff ...
It's probably what screwed up the Micro SDs in the first place.

Now, did you follow Head_on_a_Stick's instructions?

ie:

As root do:
# wipefs --all --backup /dev/sdx

--> Make sure you do this with the proper drive letter and omit the --backup bit<--
There's no turning back from wipefs. 

After you have done that, do # partprobe /dev/sdx

The OS will know what the drive is now all about.

Then do sudo fdisk -l /dev/sdx

Please post the terminal output of the whole process.

Best,

A.

Hello:

Again?
Lol !!!  8^D

Maybe there should be a STICKY like this, somewhere appropiate:

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Note:

FOR ALL RELEASES/NEW INSTALLATIONS ------>   ----->   --->  --> -> READ THE %&$#" RELEASE NOTES

Especially the section with the title "Notes on Specific Packages and Issues".

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Cheers,

A.

Hello:

There can be no doubt about that.

No, I don't think so.

I for one find it to be an essential part of human existence/experience.
Now and 64K years ago.
From the Maltravieso cave in Spain to Rembrandt's Night Watch, any Turner, Modigliani, Klimt or Schiele, just to name a few. 

Please do count me among them.

Indeed.
I fully agree with that.

Thank you for that.
Hopefully, I may eventually be able to contribute more.

Best,

A.

Hello:

It worked for me.
Which is why I posted the process with the terminal output so it would be detailed and easy to follow for anyone with the same problem.

You may want to read the posts after mine for further info.
Some steps I took may have been redundant.

No idea.
I have not had good experiences with bug reporting.

Probably, but I would not hold my breath.

Best,

A.

Hello:

Why not?

https://support.brother.com/g/b/oslist. … ds1200_all

See here: https://support.brother.com/g/b/downloa … ds1200_all

Drivers available (*.deb and *.rpm packages) for both 32 and 64 bit Linux:

See here: https://support.brother.com/g/b/downloa … all&os=128

That should (?) get you set.
Please let us know if it worked.  =^)

Best,

A.

Hello:

I think there's still some problem with your memory stick.
Can't really say what but it may well bring you problems when you least expect/need one.
Murphy and all that.

Like I mentioned before, you may want to back up whatever files are in the stick and nuke it.

In my experience, the best way to do it is with the command line to clear it completely and then format it.

Do sudo dd if=/dev/zero of=/dev/sdx bs=4096 .
It takes a while depending of drive size, just wait for it till the printout shows up.

--> Make sure you do this with the proper drive letter <--
There's no turning back from dd. 

To check the drive letter you can use lsblk, dmesg, gparted or all three, just in case.
You don't want to nuke your laptop drive.

Once this is done and unless there's a hardware issue such as a fake USB drive, it should be clear of whatever is going on and you can use gparted or the command line to format it again.

I'd use FAT32 as there's no advantage in using FAT16 unless you have a use case which requires filling it with +50% very small files.

FAT32 is understood by practically every modern device using USB and there's no 8.3 filename restriction.
ie: kingstonusb.txt ends up being kingst~1.txt.

Best,

A.