blog.crox.net

As seen here, 7-Zip can extract the contents:

$ file PGPexch.ole
PGPexch.ole: Composite Document File V2 Document, No summary info
$ 7z x PGPexch.ole

7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)

Processing archive: PGPexch.ole

Extracting  [1]CompObj
Extracting  [1]Ole
Extracting  CONTENTS
Extracting  [3]ObjInfo
Extracting  [2]OlePres000
Extracting  [3]MailStream

Everything is Ok

Files: 6
Size:       104336
Compressed: 108544
$ file CONTENTS
CONTENTS: PDF document, version 1.5
$ 

(If the OLE data is hidden in a WINMAIL.DAT file, you may have to extract it with tnef first.)

Recently I wanted to install Ubuntu next to a pre-installed Windows on a brand-new HP EliteBook.

The notebook came with four primary partitions, with Windows installed on the biggest one:

- sda1 (1 GB, NTFS, label=SYSTEM)
- sda2 (457 GB, NTFS)
- sda3 (16 GB, NTFS, label=HP_RECOVERY)
- sda4 (2 GB, FAT32)

In order to install Ubuntu it's not enough to resize the Windows partition, as you cannot have more than four primary partitions. Removing one of the other partitions is a bad idea according to several reports, as it might render the system unable to start, or prevent BIOS updates. So the idea is to convert the Windows partition to a logical one in addition to resizing it. Fortunately everything you need to do that is already included on the Ubuntu installation image.

1. Use gparted to resize and move the Windows partition. I resized it to 100 GB and added 10 MB free space before it (to leave some space to create the extended partition later on). This will take a while, depending on the performance of your hard drive.

2. Use fixparts to convert sda2 to a logical partition:

# fixparts /dev/sda

Type l then 2, write the changes to the disk with w.

3. Restart the computer without the Ubuntu install media so that Windows fixes itself. This will take even longer than the partition resize, be patient. Restart once more to make sure the Windows install is fine.

4. Proceed with installing Ubuntu, choose the option to "install Ubuntu alongside Windows".

It looks like you need some systemd "magic" to successfully mount an NFS share on OSMC. Adding "x-systemd.automount,noauto" to the mount options in /etc/fstab did the trick for me.

Despite having read the opposite, it looks like IPv6 is disabled by default on the latest OSMC release (2015.06-1). I've tried adding a sysctl.d file to set /proc/sys/net/ipv6/conf/eth0/disable_ipv6 to 0, but this did not help. It worked only when I ran the command manually. By going through numerous forum posts I eventually found out that you need to use the connmanctl CLI tool:

root@osmc:~# connmanctl
connmanctl> services
*AO Wired                ethernet_b827ebaabbcc_cable
connmanctl> config ethernet_b827ebaabbcc_cable --ipv6 auto preferred
connmanctl> quit
root@osmc:~# 

This enables IPv6 with autoconfiguration, turns on Privacy Extensions and prefers these ephemeral addresses over the autoconfigured ones.

The same command works for wireless as well, you just need to select the appropriate interface (the service name will start with wifi_).

"help" will display basic usage info.

If for some reason you would like to disable IPv6, the command would be "config ... --ipv6 off".

While trying to restore two files with BackupPC I got the following error message:

Remote[1]: Internal hashtable error: illegal key supplied!
Remote[1]: rsync error: errors with program diagnostics (code 13) at hashtable.c(65) [Receiver=3.0.9]
Read EOF: 
Tried again: got 0 bytes
Done: 2 files, 760646 bytes
restore failed: Unable to read 4 bytes

Other restores worked flawlessly. All hosts involved were running the same version of Debian Linux, with the same version of rsync. The same two files could be restored as a zip file from the BackupPC web front-end.

After spending some time on the issue with a colleague we eventually found the explanation, albeit not the solution: one of the files was a hard link. It looks like we hit a bug similar to what is described here: http://sourceforge.net/p/backuppc/mailman/message/20762995/

> This results in one subtle bug that can't be easily fixed: if you
> switch the Xfer method from tar to rsync, old backups that have
> hardlinks stored with tar won't be correctly restored with rsync.
> The workaround is generate a tar file and extract it, or switch
> the Xfer method back to tar before you do the restore.

We did not switch Xfer method (we've always used rsync over ssh). Possibly the issue was caused by attempting to restore two hard links to the same file at once - more testing would be required to confirm this.