An additional reason appeared when I started researching the topic.
Apparently, Windows 10 no longer even creates the recovery partition during installation!
The entire WinRE is now stored on that same system reserved partition, which contains your window’s BCD!
The recovery partitions should only be present on Windows 10 installations which were either upgrades from a previous Windows version, or (as in my case) were installed within about 6 months after Windows 10 became available.

These instructions are also useful if you wish to increase the size of your system reserved partition – for example, if Windows 10 updates are failing because of that partition’s lack of free space.

WARNING: changing partition tables on your hard/solid-state disk may easily result in complete data loss!
Instructions below are provided as-is, to be used at your own risk. See full disclaimer on the About page.

WARNING: although it is also possible to merge the system reserved partition and windows 10 partition (so that the entire Windows 10 uses only 1 primary partition), I do not (and will not) offer instructions to do so. In fact, I recommend that you don’t merge the system reserved and windows 10 partitions.

Merging system reserved and recovery partitions, step by step.

1. First, we need a convenient partition manager; I have used a free MiniTool Partition Wizard, but other great free partition managers (like AOMEI Partition Assistant and I guess a few others) should be sufficient for us. Download and install one of those. It is impossible to use Window’s own Disk Manager for the steps below.
2. My starting state is this:

   [ 189MB free space ] [ system reserved, 100MB ] [ windows 10, 100GB ] [ recovery, 450MB ] [ free space ]

3. Your starting state may look a bit simpler, like this:

   [ system reserved, 100MB ] [ windows 10, 100GB ] [ recovery, 450MB ]

   Presence or absence of free space at the beginning or end of the disk should not make any difference (unless your windows partition has very little free space).

4. Our goal state is:

   [ system reserved, 900 MB ] [ windows, 100 GB ] [ free space ]

5. Create a full disk backup! Yes, I really did that. I can highly recommend booting into Clonezilla (or your Linux, if you dual-boot), and performing a full disk-to-image backup. If anything at all goes wrong – you should be able to completely restore your system to the previous functional state.
6. Verify that your full-disk backup can be restored (is readable/decompressible/whatever). Clonezilla has an option (enabled by default) to perform this check after disk imaging is complete – this was sufficient for me.
7. Verify that you have a functional WinRE: start Administrator CMD (or PowerShell), and run reagentc /info – it should tell you that WinRE is enabled, and also tell you that it’s using partition 3. I’d also strongly suggest that you create a separate bootable USB with WinRE – Windows 10 has its own tool to do so.
8. (optional) If you, like me, had some free space at the beginning of the disk, before the system reserved partition – then it makes sense to first extend the system reserved partition there. Use your partition manager to do so – either as a one-click Extend partition operation (and then select the free space upstream, all of it), or as a Resize partition to move the left edge of system reserved to disk’s beginning. Reboot. This worked flawlessly for me. If your Windows 10 does not boot anymore – try fixing boot using your bootable WinRE, or the WinRE on your disk. If that fails – restore your disk backup, and look for a different solution…
9. When merging system reserved and recovery partitions, one has to keep in mind the free space requirements of these two partitions (for UEFI, for MBR). They are a bit weird, so I picked 900 MB as the target size for system reserved; with this size, at least 320 MB have to be free on that partition after we are done. After merging the free space (189 MB) and the sysres partition (100 MB) I already had 289 MB, and needed to add (900-289=) 611 MB. Start your partition manager again, Extend system reserved partition using your Windows 10 partition, and reboot again. If there is no option to extend: first shrink the windows partition from the left edge by the calculated number of MB (611 in my case), then extended sysres partition into the freed space – and reboot. After this step, the disk should look like this:

   [ system reserved, 900 MB ] [ windows 10, ~100GB ] [ recovery, 450 MB ] [ free space]

10. Now we are going to move the WinRE from a dedicated partition to a sysres partition, in a few easy commands. Start Administrator CMD or PowerShell, check that your WinRE is still active: reagentc /info. Now disable it: reagentc /disable. Verify with another reagentc /info. If disabling failed, and you wish to have the WinRE functionality – do not proceed! I have no idea if proceeding after failure here would result in a functional WinRE. Do not reboot, keep the CMD/PowerShell open!
11. Delete the recovery partition, apply changes, do not reboot! (although it should actually be safe to…)
12. (possibly optional) Create an unformatted placeholder partition where your recovery partition used to be, to prevent Windows from creating it again when you re-enable WinRE. In my case, disk layout after this step is:

    [ system reserved, 900 MB ] [ windows 10, about 100 GB ] [ Unformatted primary partition ]

    Do not reboot.

13. Back to your elevated privileges CMD/PowerShell window: simply run reagentc /enable, and confirm with reagentc /info. As there is no other place to put WinRE now, reagentc should save it to the (now big enough) system reserved partition.
14. Delete the placeholder partition. Your final state should be similar to:

    [ system reserved, 900 MB ] [ Windows 10, ~100 GB ] [ free space ]

Congratulations, you have just successfully merged the system reserved and recovery partitions of Windows 10!

This will duplicate both metadata and btrfs system data.
Verify with: sudo btrfs fi df /toplevel:

Data, single: total=10.00GiB, used=3.88GiB
System, DUP: total=64.00MiB, used=4.00KiB
Metadata, DUP: total=512.00MiB, used=286.18MiB
GlobalReserve, single: total=96.00MiB, used=0.00B

Explanation: on SSDs, mkfs.btrfs creates metadata in single mode (because of widely spread SSD deduplication algorithms negating duplicate entries). However, second copy of metadata increases recovery chances, especially so if your SSD does not deduplicate writes. Hence the desire to add metadata/systemdata duplication after the filesystem is created.

There are two major obstacles for a somewhat-dated Windows 7 when it sees modern hardware:

• USB 3.0
• SSDs and newer disk drives in general

Fortunately, both problems are easy to fix.
Just follow the steps below; skip steps 1 and 2 if you already have a bootable Win7 flash drive.

1. Obtain/buy/create the Windows 7 ISO image.
   On Linux, creating an ISO image is as easy as dd if=/dev/sr0 of=/path/to/image.iso – assuming that /dev/sr0 is your DVD reader.
2. Create a bootable Windows 7 installation flash drive.
   On Linux, WinUSB can handle this; on Windows, you can use Rufus, or Microsoft’s own tool for this.
3. To add USB 3.0 drivers to the Win7 on your flash drive, download and use this: Windows 7 USB 3.0 Creator Utility:
   1. Run the utility as Administrator.
   2. Depending on the speed of your USB stick, this may take up to 15 minutes.
   3. Wait for a message along the lines of Creation finished! or Upgrade finished.
4. The steps above fix the first obstacle: lack of USB 3.0 drivers in the Windows 7 installation image.
   Now we are going to preemptively fix the second obstacle: not recognizing modern HDDs/SSDs.
5. Go to your hardware manufacturer’s website and locate the (model-specific) SATA/storage driver.
   Using Dell’s hardware as an example:
   1. go to downloads.dell.com
   2. there, click Laptops (or Desktops), then find and click your hardware model
   3. you will see a list of drivers for that model; search for “serial-ata” or “storage”
   4. download the latest version of the driver that you have found (it would be intel storage technology in Dell’s example case)
6. Depending on the manufacturer, drivers may need to be extracted from the (self-extracting) archive. In the case of Dell’s drivers,
   1. launch the downloaded executable file
   2. it will usually present 2 options: Install and Extract; you should extract
7. In the downloaded (and, possibly, extracted) drivers folder locate Windows7-specific drivers folder, and simply copy that folder to the USB stick with your Win7 installation.
8. Be sure to remember what is the driver’s folder name – if Windows fails to see your SSD, you will need to manually browse for these drivers during installation.

That’s it!

Sources used:

• this video – or rather this one;
• Install Win7 to USB3.0 Computers Readme – also has information on other methods of injecting USB 3.0 drivers into windows USB stick.

the notebook you are searching in has been moved or renamed since the saved search was created

(which is not true).

I had this problem, and found a solution.

Go to your Evernote on a client where you can edit saved searches (Windows for me),
edit all the searches, and make sure that notebook name is quoted in the search (and also, possibly, with all proper letter cases).

I found this solution by first creating a search from the web-beta interface, it looked like this: notebook:"Mynotebook" tag:1-now
All the crossed-out searches (despite working totally fine on Windows) looked like this: notebook:Mynotebook tag:1-now
or even like this (note the lower-case 1st letter of the notebook name): notebook:mynotebook tag:1-now.

After editing saved searches and synchronizing, they all appear (and work) just fine in the beta web-interface.

If you cannot edit your searches right now, there is another workaround: all the saved searches work fine for me from the Shortcuts menu (a star in the left panel).

Hope this helps!

So I have decided to add a swap partition.
It worked amazingly (and very easily), there was even no need to reboot – at all.
I still did restart, just to make sure the system is bootable – and all was perfectly fine.

My initial setup is very simple: a single /dev/sda1 partition on the /dev/sda disk, fully used by btrfs.
Different important paths/mountpoints are btrfs subvolumes, using flat hierarchy.
For this example, let us assume that /dev/sda (and /dev/sda1) is 25GB large, and that I want to add a 2GB swap /dev/sda2 after /dev/sda1.

Brief explanation before we start:

1. shrink btrfs filesystem by more than 2GB;
2. shrink btrfs partition by 2GB;
3. create new 2GB partition for the swap;
4. resize btrfs filesystem to full size of its new-size partition;
5. initialize swap and turn it on.

Here are the very easy steps! Just make sure you do not make mistakes anywhere

1. If your btrfs volume with ID 5 (top level) is a separate mountpoint: mount it now, e.g. sudo mount /toplevel.
2. Take note of your current partition label and UUID: sudo blkid.
3. Resize btrfs filesystem down (shrink) with a good margin; for example, if I want to add a 2 GB swap, then I can sudo btrfs fi resize -3g /toplevel – here, I’m shrinking btrfs filesystem by about a gigabyte more than necessary. The process is very quick if you have free space, so you can even use a larger margin – say, sudo btrfs fi resize -5g /toplevel.
4. sudo parted, then print to make sure what is the number of your btrfs partition, then resizepart 1 (where 1 is the partition number), and answer a few questions: yes, new_size_here (in our example: 23.0GB), yes. You can also create a swap partition from parted, then quit parted with q and Enter.
5. sudo partprobe to let the OS know that partitions have changed.
6. I have used cfdisk to create a 2GB swap partition: it has a very simple ncurses UI, and is very intuitive. After creating swap partition, do run sudo partprobe again.
7. Resize btrfs filesystem back up to take all of the partition: sudo btrfs fi resize max /toplevel.
8. Simply to be sure, run a scrub: sudo btrfs scrub start -B -r /toplevel.
9. Initialize swap; you can specify uuid and/or label which you may already have in your fstab: mkswap --label=swap --uuid=your1234-your-uuid-1234-youruuid1234 /dev/sda2.
10. sudo blkid to make sure your /dev/sda1 UUID stayed the same (or to get swap uuid/label if you haven’t specified any).
11. Optionally, add the swap line to your /etc/fstab. Then turn on swap with swapon -a.

That’s it! Amazing, isn’t it? On-the-fly filesystem and partition resizing!

There is an easy solution to get Notes-only without editing the PDF.

If you have a PDf printer installed (most Linux distributions, and Windows 10), just do File -> Print from Impress,
then under the Print sub-header choose Notes from the Document drop-down (see picture).
Make sure to set the proper paper format for the PDF printer (A4 in my case).
Then print, and save the resulting PDF.

Sources:

• question on ask.libreoffice.org
• LibreOffice bug report

I’ve purchased a fairly cheap VPS with an easy, one-click upgrade option for after I’m done configuring it.
It comes with a wide selection of OSes to pre-install; I’ve chosen Debian Jessie, version 8.3 as of this writing.

I wanted to use btrfs from the beginning, so could have installed Debian myself, but… VPS provider does some initial configuration (like their Debian mirror and some other things), so I’ve felt that converting to btrfs after the fact would be easier. Now that I’ve done this – I guess it was fairly easy, although preparation did take some time.

Below, I’m providing step-by-step instructions on how to convert your root filesystem from (most likely) ext4 to btrfs.

I’ll be using my provider’s rescue boot mode: this is a live Debian system which is network-booted on my own VPS, and thus has access to the SSD/HDD of my VPS. Hopefully, your provider has a similar feature.

Preparing for this conversion, I had mostly used two sources:

• an older howtoforge conversion tutorial, and
• Sysadmin Guide

Before we begin with actual conversion, here is a

List of hints and useful practices/commands for a future btrfs user

• Changing the default subvolume with btrfs subvolume set-default will make the top level of the filesystem inaccessible, except by use of the subvol=/ or subvolid=5 mount options.
• If top level is no longer your default subvolume, it is useful to have an fstab entry for the top level (note the noauto option!):
  LABEL=toplevel /root/btrfs-top-lvl btrfs subvol=/,defaults,noauto,noatime 0 0
• scurbbing and repairing btrfs; most of the hints below originate from Marc’s 2014 btrfs presentation
• scrub script: http://marc.merlins.org/linux/scripts/btrfs-scrub
• mount -o compress=lzo is fast and best for SSDs; mount -o compress=zlib compresses better but is slower
• you can turn off COW (copy-on-write) for specific files and directories with chattr ­-C /path (new files will inherit this)
• for a highly fragmented VM, btrfs filesystem defragment vbox.vdi could take hours; cp -reflink=never vbox.vdi vbox.vdi.new; rm vbox.vdi is much faster
• cp -reflink=always copies within and between subvolumes without duplicating data
• run scrub nightly or weekly on all btrfs filesystems
• noatime is the best fstab mount option for btrfs IF USING SNAPSHOTS, because relatime still causes at least 1 write every 24h
• if you have errors=remount-ro in your fstab for extX-filesystem, you should remove it after converting to btrfs as it does not understand the option.

We are almost ready to start! Just one last thing: partitioning!

On my previous server, I did have a certain partition scheme, with separate /boot, /home, /var, /usr, and everything else under / partition.
It worked very well for me, never ran into problems (although this is more like a Debian’s feature, not that of my partition scheme ).
However… With the current VPS, it started initially with just everything under /, in a single partition.
I could have re-partitioned everything from the rescue system while converting to btrfs, but what for? What would be the benefits?

Let’s have a look and evaluate

Advantages/disadvantages of keeping specific partitions separate.

• /boot comes the first. Normally I format it with ext2, and set aside just 100-200 megabytes for this small partition.
  This improves boot-reliability of the system. With btrfs, it was also the case that grub could not use /boot on a btrfs volume.
  However,

  Newer GRUBs can handle a /boot partition which is btrfs, so you need not have a separate /boot partition formatted as ext3/4.

  So this time I’m going without a separate /boot.
  I will not even create a separate subvolume for it: for snapshotting purposes, /boot fits perfectly under the / snapshots.

• Next comes /home.
  The reason to separate it is to safeguard user data when upgrading/reinstalling the OS.
  This, however, can be achieved with btrfs subvolumes – no need for partitions!
  I’m going with a “subvolume for home” here, then.
• Next comes /var, or more precisely /var/log.
  One of the reasons to keep /var/log separate is to prevent filesystem overfill if logs suddenly start growing too fast.
  This, however, can be achieved with subvolume quotas. No need for a partition!
• There is also /var/lib/ (and also /var/lib/lxc/…), which hold fairly big data files, often with random write access patterns.
  There are two reasons to make them subvolumes:
  1. for data-only snapshots
  2. to enable nocow/nodatacow at mount time, to avoid high fragmentation with random writes

  However, this can be done later, when these databases/LXC get installed – in just a few commands, without rebooting.

• Finally, / itself should be a separate subvolume – mostly for snapshot and reinstall/upgrade reasons.

Ok, now we are really going to

Convert the filesystem

1. Enable rescue system, write down access credentials. You may need to restart your VPS to boot into rescue system, but check with your VPS provider first.
2. Connect to and log in to the rescue system.
3. Install btrfs-tools in the rescue system, if not there yet. We’ll need btrfs-convert, which should be included in btrfs-tools.
4. I’m assuming that your SSD/HDD is device /dev/sda, and that the only (root) partition there is /dev/sda1; adjust the next steps if your setup is different. Only proceed with commands if you understand what they are doing!
5. It never hurts to fsck /dev/sda1 before doing filesystem conversion You should see something like /dev/sda1: clean, 27282/1564672 files, 351853/6249472 blocks.
6. btrfs-convert -l toplevel /dev/sda1; note that I’m adding a “toplevel” LABEL to the top level of btrfs, for easier mounting it later. The output should look like this:
   

   creating btrfs metadata.
   creating ext2fs image file.
   cleaning up system chunk.
   conversion complete.

   At this point the system is already btrfs!

7. If you forgot to set btrfs label, or decide to do it later: list the filesystems with btrfs filesystem show, or just look for the label with btrfs filesystem label /dev/sda1 (which will produce an empty line if there is no label), then simply btrfs filesystem label /dev/sda1 toplevel; it will produce no output on success.
8. Let’s change into the new system, and start configuring it:
   mount /dev/sda1 /mnt
for fs in proc sys dev dev/pts; do mount --bind /$fs /mnt/$fs; done
chroot /mnt
9. ls now should show your root filesystem files and directories, plus the ext2_saved “directory” (which is a subvolume, actually):
   

   bin dev ext2_saved initrd.img installimage.debug lib64 media opt root sbin sys usr vmlinuz
   boot etc home installimage.conf lib lost+found mnt proc run srv tmp var

10. Run blkid /dev/sda1 to find out the UUID of the new btrfs top-level volume. You can also see it with btrfs filesystem show:
    

    /dev/sda1: LABEL=”toplevel” UUID=”3124c827-c3bd-4a62-843f-1d5a552f1858″ UUID_SUB=”ffad5668-2ac7-4ea4-83ad-e6ccba7ccf96″ TYPE=”btrfs” PARTUUID=”750b31a7-01″

11. Edit /etc/fstab (with e.g. nano /etc/fstab):
    • change UUID of / to the new one
    • change the filesystem type from ext3/ext4 to btrfs
    • change the options to subvol=root,defaults,noatime,compress=lzo,ssd,discard (yes, subvol=root does not exist yet… also, ssd,discard are for SSDs only, and instead of adding discard here it might be better to setup an fstrim cronjob. Finally, noatime can be left out if you are not going to make snapshots.)
    • change the last number in the line from 1 to 0 (the fsck passes – btrfs does not want boot-time filesystem checking)
12. Some guides mention editing /etc/grub.d/00_header in a specific way, running grub-mkconfig | grep ” ro “ to see if it adds the proper rootflags=subvol=root, then even run update-grub and grub-install /dev/sda here… But all of this seems redundant or plain unnecessary. First of all, the root subvolume simply does not exist yet, so grub-mkconfig will not produce correct rootflags. Secondly, we are not yet done with setting up subvolumes, and we are not going to reboot right now, so running update-grub/grub-install is a bit premature at this stage
13. Now we are going to create some subvolumes. As I want to name the root subvolume simply root, I should first move the root user’s home files somewhere else (otherwise btrfs snapshot complains “ERROR: incorrect snapshot name ‘/’”):
    mv /root /root_orig
btrfs subvolume snapshot / /root
14. The same problem with /home, need to move it as well: mv /home /home_orig
15. I can NOT snapshot /home like I did with /, because it is just a directory, not a volume like /, so:
    btrfs subvolume create /home
    Note: my /home (/home_orig) is still empty, as this is a brand-new installation with only the root user, so double-check steps below, as I haven’t really run them.
    rsync --progress -aHAX /home_orig/* /home
ls -la /home/
ls -la /home_orig/
rm -fr /home_orig/*
ls -la /root/home/
rm -fr /root/home/* # be sure to leave the empty /root/home/ in place: it will be the mount point.
16. nano /etc/fstab to add the /home mount line, using the same UUID as earlier for the / partition, but a different subvol option:
    UUID=3124c827-c3bd-4a62-843f-1d5a552f1858 /home btrfs subvol=home,defaults 0 0
    Feel free to add more mount options, similar to those for root subvolume. While we are editing /etc/fstab, it also makes sense to add a non-automount /toplevel entry (UUID=3124c827-c3bd-4a62-843f-1d5a552f1858 /toplevel btrfs subvol=/,defaults,noauto 0 0) and create mountpoint for it: mkdir /root/toplevel
17. Follow the same procedure to create the /var/log subvolume. I’m using flat subvolumes layout here:
    btrfs subvolume create /log
rsync --progress -aHAX /var/log/* /log
ls -la /log/
ls -la /var/log/
rm -fr /var/log/*
ls -la /root/var/log/
rm -fr /root/var/log/*

18. Add /var/log entry to fstab:
    UUID=”3124c827-c3bd-4a62-843f-1d5a552f1858″ /var/log btrfs subvol=log,defaults,ssd,discard,compress=lzo,noatime 0 0
19. /var/lib/ – databases, LXC, nodatacow/nocow – can be created later, not doing it here and now.
20. cp /etc/fstab /root/etc/fstab
21. exit # chroot
22. for fs in proc sys dev/pts dev; do umount /mnt/$fs; done
umount /mnt
23. Let’s enter the new root subvolume!
    mount -o subvol=root /dev/sda1 /mnt
for fs in proc sys dev dev/pts; do mount --bind /$fs /mnt/$fs; done
chroot /mnt
24. Oh, we forgot to move back root_orig into /root! That’s easy: mv root_orig root. If you want your root’s aliases/profile to load, then just exit and chroot /mnt again (I had to do that for the nice pre-configured prompt colours )
25. btrfs subvolume list / to see our new and shiny subvolumes:
    

    ID 256 gen 8 top level 5 path ext2_saved
    ID 260 gen 49 top level 5 path root
    ID 261 gen 35 top level 5 path home
    ID 262 gen 42 top level 5 path log

26. Let’s make root the default subvolume! If suddenly rootflags get lost during grub configuration, then the system should still be able to boot. Subvol ID comes from the output of the command above (260 in my case):
    btrfs subvolume set-default 260 / # no output
    btrfs subvolume get-default / # to verify

    ID 260 gen 49 top level 5 path root

27. Now let’s check grub-mkconfig output: grub-mkconfig | grep " ro ". Now that the subvolume exists, it does show all the desired rootflags=subvol=root.
28. Let’s make sure our system will be bootable:
    update-grub
grub-install /dev/sda
29. Leave the chroot:
    exit
for fs in proc sys dev/pts dev; do umount /mnt/$fs; done
umount /mnt
30. Now let’s mount top-level again, for cleanup. If you remember, we had all the / files there – which are now in the root subvolume:
    mount -o subvol=/ /dev/sda1 /mnt
31. Navigate to /mnt (cd /mnt, yes ) and delete from here everything that is NOT a subvolume.
    The command which supposedly does this is find /mnt -xdev -delete (-xdev is supposed to not descend into mounts of other filesystems), but I haven’t used it – was a bit tired and did not want to screw up the so-far-successful conversion, so I just did rm -rf bin boot dev etc initrd.img lib lib64 lost+found media mnt opt proc run sbin srv sys tmp usr vmlinuz var root_orig – basically, deleted everything except for ext2_saved, home, root, and log – which are all subvolumes.
32. Confirm that only subvolumes are left now:
    ls -la:

    drwxr-xr-x 1 root root 10 Feb 13 21:30 ext2_saved
    drwxr-xr-x 1 root root 0 Feb 13 22:04 home
    drwxr-xr-x 1 root root 510 Feb 13 22:13 log
    drwxr-xr-x 1 root root 318 Feb 13 22:18 root

    btrfs subvolume list /mnt:

    ID 256 gen 8 top level 5 path ext2_saved
    ID 260 gen 52 top level 5 path root
    ID 261 gen 35 top level 5 path home
    ID 262 gen 42 top level 5 path log

    btrfs subvolume get-default /mnt:

    ID 260 gen 52 top level 5 path root

33. We can leave now: cd / && umount /mnt
34. Reboot into the new system. If this fails: can boot rescue again, chroot and check what went wrong…
35. In my case, conversion seemed to have succeeded, BUT: a) for some reason /toplevel was mounted at boot and full of root-like files which should not have been there anymore; b) I could not delete ext2_saved, at all, neither from / nor from /toplevel. The problem was with the toplevel mount line in /etc/fstab (initially, I forgot to specify the filesystem type). After fixing this and rebooting once more, everything was perfect: /toplevel not mounted, and when mounted it only had subvolumes in it. And of course the system booted without any problems. Now I could delete the previous filesystem snapshot: mount /toplevel; btrfs subvolume delete /toplevel/ext2_saved; umount /toplevel. Note that there was also another, different ext2_saved in the root subvolume: it is NOT a subvolume, which was not carried over when we created the / snapshot – only the empty directory was left in place. (Yes, snapshots do not descend into subvolumes.)

The last 2 commands to issue (after mount /toplevel) are btrfs filesystem defragment -r /toplevel and btrfs balance start /toplevel.
I’m not including them in the instructions above: they are not strictly required, and if your filesystem had some heavy use before conversion, you may want to run these 2 commands more intelligently, in phases (metadata first, then big files, then smaller, etc). Another reason is that it may produce significant system load. On my fresh system both finished very quickly.

…And we are done!

The simplest solution to forward requests from the web-frontend to your API is by using mod_proxy.
If you want to forward any requests to /api/* to your custom back-end server on port 8000, you just add the following lines to your VirtualHost configuration:

ProxyPass “/api” “http://localhost:8000″
ProxyPassReverse “/api” “http://localhost:8000″

I’d suggest not wrapping this fragment with the classical IfModule: as your application will not really work without its API back-end, you actually want Apache to fail as soon as possible if mod_proxy is missing.

That was easy, right? What, it doesn’t work? Can’t be! It’s dead simple! No way you could make a mistake in 2 lines of configuration!!! :mad_rage:

Oh wait… I remember I had this problem before…

Let’s check:

1. Step 1. Did you disable (using a2dissite default or a2dissite 000-default, depending on your Debian-based GNU/Linux) the default website? If your application and the default website are configured in a similar way, then it might be the default site which is serving your app’s pages. The most sure way is to just disable it.
2. Step 2. Did you enable also the proxy_http sub-module? (Using a2enmod proxy_http, followed by service apache2 restart) mod_proxy is only the core module, actual per-protocol work is done by these sub-modules.

Your requests to /api should now be passed on to your API server. If not – please write in the comments what was the problem in your case and how you solved it. HTH!

You can create hard links and symbolic links using C-x l and C-x s keyboard shortcuts. However, these two shortcuts invoke two completely different dialogs.

While for C-x s you get 2 pre-populated fields (path to the existing file, and path to the link – which is pre-populated with your opposite file panel path plus the name of the file under cursor; simply try it to see what I mean), for C-x l you only get 1 empty field: path of the hard link to create for a file under cursor. Symlink’s behaviour would be much more convenient…

Fortunately, a good man called Wiseman1024 created a feature request in the MC’s bug tracker 6 years ago. Not only had he done so, but he had also uploaded a sample mc user menu script (local copy), which works wonderfully! You can select multiple files, then F2 l (lower-case L), and hard-links to your selected files (or a file under cursor) will be created in the opposite file panel. Great, thank you Wiseman1024!

Word of warning: you must know what hard links are and what their limitations are before using this menu script. You also must check and understand the user menu code before adding it to your mc (by F9 C m u, and then pasting the script from the file).

Word of hope: 4 years ago Wiseman’s feature request was assigned to Future Releases version, so a more convenient C-x l will (sooner or later) become the part of mc. Hopefully.

• synchronization appears to work correctly;
• total count of steps is updated, but when you click it – there are no per-hour details;
• in the older app version: after sync completes, there is no green message “Updated X items”;
• night sleep tracker does not update at all: neither total hours slept, nor per-hour details;
• the band is otherwise functional, e.g. “Find the band” works – it vibrates and flashes diodes.

Warangelo00 found a solution, which worked for me (and no, you do not need to hard reset the device):
note: the fix below will most probably not work for Mi Band 2, see comments; iPhone owners may try switching iPhone from AM/PM (12-hour clock) to 24-hour clock to fix the non-synchronization problems with MiBand2 – please write in the comments if this method works for you.

1. enable Bluetooth, if it is disabled;
2. start Mi Fit, go to Play –> Incoming call (or, in older app version, Settings – Incoming calls);
3. enable it – set to On;
4. now call your mobile phone from a different one – wait for the band to vibrate and flash lights;
5. you should now be able to refresh Mi Fit main page, and see both current day and previous night per-hour details; in the older app version, it should also show the green “Updated X items” message after syncing;
6. you can now disable incoming calls notification if you don’t need it.

According to Holly, the trick may also work for Mi Pulse.

Not sure if this fix will last, but it did help me – thanks, Warangelo00!

DEFAULT -d sat -H -f -p -t -W 0,40,45 -n standby -S on -m example@example.com
# Attributes 1, 230, and 231 are very important (-r 1! -r 230! -R 230! -r 231! -R 231!), but likely covered by -t.
/dev/sda -s (S/../../6/01|L/../(01|02|03|04|05|06|07)/7/00) -C 0 -I 189 -I 194
# -a implies -f and -p (through -t)
DEFAULT -d sat -a -I 194 -W 0,40,45 -n standby -o on -S on -m example@example.com
/dev/sdb -s (S/../../6/02|L/../(01|02|03|04|05|06|07)/7/02)
# This drive does not decrement Offline_Uncorrectable (198) after re-allocation,
# so only monitoring for increase, not for non-zero value.
/dev/sdc -s (S/../../6/03|L/../(01|02|03|04|05|06|07)/7/04) -U 198+
# This drive has 40 “normally”.
/dev/sdd -s (S/../../6/04|L/../(01|02|03|04|05|06|07)/7/06) -W 0,42,45

Note: explanations below are intentionally simplified; please consult man smartd.conf for more precise, complete, and up-to-date information.

Ok, so what do these settings mean, and how is this different from default settings?

By default, smartd assumes a DEVICESCAN directive, which auto-detects all HDDs, and enables reasonable default monitoring of SMART attributes.
However, there are several benefits to individually specifying your disks:

• less verbose smartd startup log messages (no messages about auto-detection and missing attributes)
• ability to run scheduled offline, short, and long SMART self-tests
• ability to monitor or exclude attributes individually for each drive (including temperature)

Reasonable default mentioned above is the -a option, equivalent to the following individual options:

-H -f -t -l error -l selftest -C 197 -U 198

This is important to know, because my only SSD has no attribute 197, no self-test log, no error log, and no automatic offline testing.
But I still want to start with quasi-default settings, and that is why the first configuration line includes all the options from -a, except those that my SSD does not support:

DEFAULT -d sat -H -f -p -t -W 0,40,45 -n standby -S on -m example@example.com

Here and in the -a options above,

• -H: monitor overall health status (passed/failed)
• -d sat: HDD type is SATA
• -f: check if any of the Usage attributes (those not marked as Pre-fail) are below the manufacturer-set thresholds
• -p: report changes in Pre-fail attributes (implied by -t below, so can be omitted)
• -t: same as -p (above) with -u (report changes in Usage attributes)
• -W 0,40,45: log a message if drive’s temperature goes above 40 degrees Celsius; log a critical messages if above 45
• -n standby: do not wake-up (spin-up) the HDD if it is in sleep or standby mode (in which platters do not spin)
• -S on: enable attributes auto-saving
• -m example@example.com: address (or several comma-separated addresses) to receive warnings from smartd

The DEFAULT directive is for convenience: options set by this directive apply to all the individual disk configuration lines below, until a different DEFAULT line is encountered.
Here, I had used it to separate all /dev/sda options into 2 logical groups: supported defaults, and drive-specific configuration.
SSD’s configuration is

/dev/sda -s (S/../../6/01|L/../(01|02|03|04|05|06|07)/7/00) -C 0 -I 189 -I 194

Here,

• -C 0: explicitly disable attribute 197 monitoring (which is not present in this SSD)
• -I 189 and -I 194: ignore attributes 189 and 194 (they both show temperature in this SSD)
• -s (S/../../6/01|L/../(01|02|03|04|05|06|07)/7/00): schedule for short and long tests

As for the tests…
I want short self-tests every Saturday night, between 1 AM and 5 AM (shifted by 1H for every disk).
I want long self-tests on the 1st Sunday of every month, between midnight and 8 AM (shifted by 2H for every disk).
This is exactly what is encoded in my configuration for all drives. The easiest way to figure out the format is to read the relevant section of man smartd.conf.

The remaining 3 drives are all HDDs, so I had defined a different common DEFAULT for them.
The only new option that we see is -U 198+, which instructs smartd to only report increases of the Offline_Uncorrectable (198) attribute.
This is necessary because my /dev/sdc does not decrement this attribute after sector re-allocation.

I hope you found this post helpful.

Running a short SMART self-test (sudo smartctl -t short /dev/sdc) produced a read error at sector 1289:

Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
1 Short offline Completed: read failure 80% 22339 1289

Looking at the partition table of /dev/sdc, we see that this sector is outside of the only RAID partition on the disk, which starts at sector 2048:

Device Boot Start End Blocks Id System
/dev/sdc1 2048 117209087 58605088 fd Lnx RAID auto

To make sure that sector 1289 is re-allocated, some data needs to be written to it, e.g. with sudo dd if=/dev/zero of=/dev/sdc count=1 seek=1289.
You may also try to read the sector first, then – if successful – write it back to the disk:
i=1289 ; sudo dd if=/dev/sdc of=/tmp/sector count=1 skip=$i && sleep 1 && sudo dd if=/tmp/sector of=/dev/sdc count=1 seek=$i

Another solution (untested!) would be to read/write a bunch of sectors around the problematic one (this is similar to what badblocks -n does):

export i=1280
while [ $i -lt 1300 ]
do echo $i
# read once (count=1) 512 bytes (default ibs/obs values of dd) to a temporary file, skipping first $i ibs-sized blocks (skip=$i);
# if successful, then (wait a bit and) write the same data back to disk, skipping $i obs-sized blocks (seek=$i)
dd if=/dev/sdc of=/tmp/sector count=1 skip=$i && sleep 1 && dd if=/tmp/sector of=/dev/sdc count=1 seek=$i
let i+=1
done


After sector re-allocation both Reallocated_Sector_Ct (5) and Reallocated_Event_Count (196) SMART attributes increased from 0 to 1, while Current_Pending_Sector (197) decreased from 1 to 0. In addition, running badblocks /dev/sdc and diskscan --output diskscan-sdc-out-25-02-2015.json /dev/sdc (both in read-only mode, of course) has not shown any read errors, and another short SMART self-test also finished successfully. So, is the problem solved?

Unfortunately, Offline_Uncorrectable (198) stayed at 1, and I kept getting warning emails. Apparently, my HDD simply does not decrease the Offline_Uncorrectable (198) attribute after sector re-allocation.

In this case the proper solution is to edit /etc/smartd.conf so that it only sends emails if Offline_Uncorrectable (198) attribute increases, and not if it is non-zero. Just add this option to your HDD scan line in smartd.conf: -U 198+.

I am updating a multisite Drupal 6 installation. To the best of my knowledge, the only difference for Drupal 7 is that instead of the site_offline D6 variable the maintenance_mode variable is used in D7.

On Debian stable and later, you can sudo aptitude install drush and then just use it immediately after that.

Note: I recommend su webuser (or sudo -s followed by sudo -s -u webuser) before you run any non-testing drush commands, where webuser is the user which owns your web-exposed files (e.g. Debian’s default is, I think, www-data). I’ve seen a lot of recommendations to run drush as a super-user, but that does not make sense, and may actually cause problems with file ownership.

One last thing before we start: if your drush seems to work fine but hangs when untarring modules – check this solution.

1. Run some innocent command in drush to see if it produces any PHP warnings/errors you may want to fix before running actual update: drush @sites core-status. In my case, all the sites had the CacheRouter module for in-RAM caching with a server daemon back-end, which was not initialized properly when drush bootstrapped Drupal from the command line. In my case, the only working solution was to edit settings.php files of every site to comment out the CacheRouter configuration for the period of update. If you get no warnings/errors, proceed to the next step. Note: I was running drush from the Drupal’s root (directory which has top-level index.php and .htaccess files), but this should also work if you run from sites/ or even sites/sitename.
2. Here would be several more steps – copying your production website(s) to a dev-server (if you do not have one already), performing an update on the dev-server first to see if anything breaks and needs fixes, then migrating updated website(s) from the dev-server to production server. Drush actually has tools to simplify all of these procedures. However, the websites I was updating were not critical, and short downtime was not a problem, so I was updating live websites. Modify these steps as you see fit to make the process more reliable.
3. Backup databases of all your sites. With drush: drush @sites sql-dump --result-file --gzip. This puts backups somewhere into the home directory of your webuser. Backups are named with a human-readable timestamp. Of course, you can also create a manual Backup and Migrate backup, or use phpMyAdmin, or just mysqldump.
4. Backup your site’s files. This step might be unnecessary, as drush seems to backup modules it is upgrading. I would still recommend making a backup, e.g. with tar -acf multidrupal.tar.bz2 html, where html is the directory containing your multisite Drupal’s root index.php.
5. Put the websites into maintenance mode and clear all caches; see the D7-specific note above: drush @sites variable-set site_offline 1 ; drush @sites cache-clear all.
6. The actual update! The easiest way would probably be to drush @sites pm-update, but I haven’t tested that and used a process which I understand better, and which seems more reliable to me (if anything goes wrong). If in your drupal root you have sites/site1 and sites/site2, then run:
   
drush site1 pm-updatecode
drush @sites updatedb
drush site2 pm-updatecode
drush @sites updatedb

   The pm-updatecode command only updates files, and does not run database update. So with these commands I am first updating modules from site1, then running database update on all sites, then update modules of site2, and run database update on all sites again. Running drush @sites updatedb multiple times, even when there are no updates, should be safe. Take note of any warnings/errors reported, you will want to fix them later, for example:

   WARNING: Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt. If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.

7. Disable maintenance mode. Cleaning the cache seems unnecessary, as updatedb command does that. drush @sites variable-set site_offline 0.
8. Finalize: re-enable anything disabled before the updates, fix warnings/errors you noted during the update.

This worked well for me, and I hope it works well for you.

As VihangD points out in his serverfault answer, the same can be achieved with aptitude, while also excluding dependent, automatically installed packages (which are included by the classical method). To create the list of packages, run aptitude search -F '%p' '~i!~M' > package_list. Here, -F '%p' asks aptitude to only print package names (instead of the default output, which also contains package state and description); search term ‘~i!~M’ asks for all non-automatically installed packages.

To install packages using the created list, run xargs aptitude --schedule-only install < package_list; aptitude install. The first of these two commands instructs aptitude to mark all the packages from the list as scheduled for installation. The second command actually performs the installation.

Hamish Downer suggests an alternative way of getting the initial package_list: using the deborphan utility, deborphan -a --no-show-section > package_list. This command asks deborphan to show a list of packages, which have no dependencies on them. Sounds very similar to what we did with aptitude above, but using deborphan will most likely result in a much shorter list of packages (on my system, deborphan printed 291 package names, aptitude printed 847, and dpkg printed 3650 package names). One more potentially important difference between aptitude- and deborphan-produced package lists is that aptitude only specifies package architecture when it is different from native (e.g. 'googleearth:i386' on a 64-bit system), while deborphan specifies architectures for all the packages (resulting in e.g. 'google-talkplugin:amd64' and 'googleearth-package:all' on a 64-bit system).

Current setup:

• MX records point to the spam protection mail servers, which then
• connect to my server and deliver (hopefully spam-free) mail.

Problem: some senders (like last.fm) do have proper, strict SPF records. Tumgreyspf on my server then rejects emails relayed through the spam-protection service.

If these spam protection relay servers are the only which send mail to your server, then it makes sense to fully disable/uninstall tumgreyspf. Putting tumgreyspf into the permanent “learning mode” (set defaultSeedOnly = 1 in /etc/tumgreyspf/tumgreyspf.conf) may not fix the SPF problem described above, as SeedOnly seems to only affect greylisting, and not rejecting unauthorized senders.

Solution: whitelist relay server IPs.

I will use MXGuardDog spam blocker as an example. This solution is a slightly extended version of this one, and used tumgreyspf README as the reference.

• For each of the IPs you want to whitelist, create a directory tree under /var/lib/tumgreyspf/config/client_address. Here is a copy-pasteable example for MXGuardDog, based on their list of server IPs, valid as of August 2013:
  
mkdir -p /var/lib/tumgreyspf/config/client_address/108/166/117
mkdir -p /var/lib/tumgreyspf/config/client_address/174/129/28
mkdir -p /var/lib/tumgreyspf/config/client_address/216/58/39
mkdir -p /var/lib/tumgreyspf/config/client_address/222/229/219
mkdir -p /var/lib/tumgreyspf/config/client_address/64/15/147
mkdir -p /var/lib/tumgreyspf/config/client_address/66/85/178

• Into each of these IP range-specific directories, put a config file, which disables checks (or symlink one). First, create /etc/tumgreyspf/disable.conf with the following lines in it:
  
SPFSEEDONLY = 0
GREYLISTTIME = 600
CHECKERS =
OTHERCONFIGS =

  It is just like the default.conf, but has empty CHECKERS and OTHERCONFIGS lines.
  Now, symlink it into each of the IP range directories:
  
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/108/166/117/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/174/129/28/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/216/58/39/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/222/229/219/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/64/15/147/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/66/85/178/__default__


Note the double-underscores to the left and right of default.

That’s it.

• current HDD is /dev/sda, it has a GPT (with bios_grub being /dev/sda1), separate /boot partition (/dev/sda2), and a physical LVM volume (/dev/sda3), where LVM holds all the remaining partitions (root, /home, /srv, …); LVM is properly configured, and system reboots with no problems
• your new drive is /dev/sdb, it is identical to /dev/sda, and it comes empty from the manufacturer (this is important! wipe the drive if it is not empty, especially if it used to be a part of another RAID)
• your system is Debian or Debian-based; in this exact example I’ve been using Ubuntu Server 10.04
• your LVM volume group is named vg0
• make sure you understand what each command does before executing it
• you do have an external backup of all your important data, and you do understand that the following operations are potentially dangerous to your data integrity

Inspired by: Debian Etch RAID guide, serverfault question.

1. Create the GPT on the new drive:
   parted /dev/sdb mklabel gpt
2. Get the list of partitions on /dev/sda:
   parted -m /dev/sda print
3. Create /dev/sdb partitions similarly to what you have on /dev/sda (my example numbers follow, use your numbers here):
   parted /dev/sdb mkpart bios_grub 1049kB 2097kB
   parted /dev/sdb mkpart boot 2097kB 258MB
   parted /dev/sdb mkpart lvm 258MB 2000GB
4. Set proper flags on partitions:
   parted /dev/sdb set 1 bios_grub on (GPT doesn’t have MBR, so you create a 1-MB partition instead to hold grub2′s boot code)
   (possibly optional) parted /dev/sdb set 2 raid on
   (possibly optional) parted /dev/sdb set 3 raid on
5. (possibly optional) To make sure /dev/sdb1 (the bios_grub) indeed contains grub’s boot code, I did dd if=/dev/sda1 of=/dev/sdb1
6. apt-get install mdadm
7. Note: at this point, older tutorials suggest adding a bunch of raid* kernel modules to /etc/modules and to grub’s list of modules to load. I’m not sure this is really necessary, but do see the tutorials mentioned at the top for more information. If you do modify the lists of modules – don’t forget to run update-initramfs -u.
8. Create two initially-degraded RAID1 devices (one for /boot, another for LVM):
   mdadm ––create /dev/md0 ––level=1 ––raid-devices=2 /dev/sdb2 missing
   mdadm ––create /dev/md1 ––level=1 ––raid-devices=2 /dev/sdb3 missing
9. Store the configuration of your RAID1 to the mdadm.conf file (important! this is not done automatically!)
   mdadm -Es >> /etc/mdadm/mdadm.conf
10. Verify the contents of your mdadm.conf:
    cat /etc/mdadm/mdadm.conf
    dpkg-reconfigure mdadm, and enable booting in degraded mode
11. Copy your current /boot (/dev/sda2) to the new /dev/md0 /boot partition:
    (one can use something like dd -if /dev/sda2 -of /dev/md0 here as well, but for some reason my attempt at dd failed writing 1 last byte of data)
    mkdir /mnt/md0
    mkfs.ext4 /dev/md0 (one can also use other filesystems here, e.g. mkfs.ext3 or even mkfs.ext2)
    mount /dev/md0 /mnt/md0
    cp -a /boot/* /mnt/md0/
    umount /dev/md0
    rmdir /mnt/md0
12. Now extend your existing volume group to include the newly-created /dev/md1:
    pvcreate /dev/md1
    vgextend vg0 /dev/md1
13. Verify the list of logical volumes you curently have: enter lvm shell, and type lvs. Here’s what I had:
    LV VG Attr LSize Origin Snap% Move Log Copy% Convert
    home vg0 -wi-ao 1.70t
    logs vg0 -wi-ao 4.66g
    root vg0 -wi-ao 10.24g
    srv vg0 -wc-ao 100.00g
    swap vg0 -wi-ao 1.86g
    tmp vg0 -wi-ao 4.66g
14. Now, you can move all the logical volumes to new physical volume in one command: pvmove /dev/sda3 /dev/md1. Personally, remembering the problem I had with dd from /dev/sda2 to /dev/md0, I decided to move all logical volumes one-by-one; as this takes time, you may consider joining these operations with ; or &&, and putting the /tmp last (as the easiest one to re-create if it fails to move):
    pvmove ––name home /dev/sda3 /dev/md1
    pvmove ––name srv /dev/sda3 /dev/md1
    pvmove ––name logs /dev/sda3 /dev/md1
    pvmove ––name swap /dev/sda3 /dev/md1
    pvmove ––name root /dev/sda3 /dev/md1
    pvmove ––name tmp /dev/sda3 /dev/md1
15. To be safer, I ran FS check on a few volumes I could umount:
    umount /dev/mapper/vg0-srv
    fsck -f /dev/mapper/vg0-srv
    mount /dev/mapper/vg0-srv
    umount /dev/mapper/vg0-tmp
    fsck -f /dev/mapper/vg0-tmp
    mount /dev/mapper/vg0-tmp
16. Remove /dev/sda3 from the physical space available to your volume group:
    vgreduce vg0 /dev/sda3
17. Install grub2 to both drives, so as to make them both bootable in case of failure:
    grub-install ‘(hd0)’
    grub-install ‘(hd1)’
18. Edit /etc/fstab, pointing /boot to /dev/md0. You may use UUIDs here, but please do not use UUIDs from mdadm.conf – those are different from FS-UUIDs, instead do ls -l /dev/disk/by-uuid to find the UUID of /dev/md0. Personally, I had no problems just using /dev/md0.
19. Now is the time to add your original /dev/sda to the RAID1; be absolutely sure you have moved all the data off that drive, because these commands will destroy it:
    mdadm ––manage ––add /dev/md0 /dev/sda2
    mdadm ––manage ––add /dev/md1 /dev/sda3
    Re-syncing array will take some time.
20. To be on the safe side, you may want to run again update-initramfs -u and update-grub; I have also edited /etc/grub.d/40_custom, adding there 2 more boot options: from /dev/sda2 and /dev/sdb2 (/boot on both drives) – have no idea if that will work, but having more boot options didn’t hurt
21. Reboot into your new system. Actually, at this point reboot is only necessary to verify that your system is bootable – you may delay this reboot as long as you want to.
22. Many tutorials also suggest testing your RAID1 by manually “degrading” it, trying to boot, and then rebuilding it back. I haven’t done that, but you may want to.

Improvement suggestions, criticism and thank-you are welcome in the comments.

Here’s a sample script (call it e.g. git-truncate and put into your ~/bin or whichever location you have in PATH).


#!/bin/bash
git checkout --orphan temp $1
git commit -m "Truncated history"
git rebase --onto temp $1 master
git branch -D temp
# The following 2 commands are optional - they keep your git repo in good shape.
git prune --progress # delete all the objects w/o references
git gc --aggressive # aggressively collect garbage; may take a lot of time on large repos


Invocation: cd to your repository, then git-truncate refspec, where refspec is either a commit’s SHA1 hash-id, or a tag.

Expected result: a git repository starting with “Truncated history” initial commit, and continuing to the tip of the branch you were on when calling the script.

If you truncate repositories often, then consider adding an optional 2nd argument (truncate-commit message) and also some safeguards against improper use – currently, even if refspec is wrong, the script will not abort after a failed checkout.

Thanks for posting any improvements you may have.

Source: Tekkub’s post on github discussions.
See also: how to remove a single file from all of git’s commits.

Nokia Ovi Suite could not connect to the Nokia account server. Make sure the internet connection is working properly and try again.

However, both my internet connection, and logging into ovi.com using a browser work fine. Even looking for updates from within Ovi Suite works fine!

Here’s the solution (tested on Nokia Ovi Suite 3.0.0.290):

Important: before trying the solution below, try downloading and running root certificates update program from Microsoft, then restarting Ovi Suite to see if the problem is gone. (Thanks Finn for sharing this one.)

• Navigate to Start – Control panel – Internet options (or: start Internet Explorer – Tools – Internet options). It doesn’t matter that your default browser is not IE.
• Select Content tab.
  
• Click Certificates, select Trusted root certification authorities tab, and sort ascending by expiration date.
  
• Now delete all GTE CyberTrust certificates whose expiration date has passed.
• Click Close, then OK
• Restart Ovi suite.

If that didn’t help: try removing all expired certificates:

A word of warning

Deleting all expired trusted root certs is not a good idea. You could end up with vital parts of the system not working, or unable to access some documents (especially if you have encryption turned on). Thing is, expired certs can still be valid for anything signed or encrypted before they expired.

Sources used:

• http://discussions.europe.nokia.com/t5/Nokia-Ovi-Suite/NOKIA-OVI-Suite-could-not-connect-to-the-nokia-account-server/m-p/878427
• http://betalabs.nokia.com/apps/nokia-ovi-suite-3-0-beta/bugreport/19143/ovi-sign-in-failed
• http://betalabs.nokia.com/node/5251

• if you don’t have the python-stdeb package: sudo aptitude install python-stdeb
• pypi-install pycassa

That’s it.

Refer to stdeb readme for more information. You will need that if there are dependencies – which might not be resolved automatically by stdeb.

Before stdeb, it wasn’t exactly trivial to make a .deb from python module.