Samsung Laptops Still Can't Run Linux

Those keeping themselves apprised of Linux news will be aware of a particularly nasty issue that reared its head earlier this year. It was discovered that installing Linux could end up bricking some Samsung laptops.

Subsequently, Matthew Garrett discovered that it wasn't just Linux; Windows could also brick these laptops (although it seemed not to do so naturally).

So it came to be understood that the problem was a bug in Samsung's UEFI firmware, and might be something akin to a buffer overflow.

Linus et al were quick off the mark, removing the samsung-laptop kernel driver, which seemed most capable of triggering the bug. Of course, the new kernel version takes time to work its way into the distro's installation discs, but I would imagine it exists in Ubuntu 13.04 now.

Whether this change removes all possible triggers is another question. Nobody seems to know for sure. There are rumours that bricked systems may be recoverable by clearing the CMOS. But who really wants to risk it?

Like many people, I have a Samsung laptop on which I intend to install Linux, and had been following developments with interest. I kept expecting a BIOS update to emerge, yet nothing appeared forthcoming.

The end user community was still waiting; the Launchpad bug report was still open, and Ask Ubuntu's various questions were still open issues.

So, last month, having waited quite some time already, I sent Samsung support an email requesting a status update. Their response noted:

A BIOS update has been released for most systems that are effected by this problem. To see if there is a BIOS update this can be checked automatically by a program called SW Updater available on the support page (link below):
http://www.samsung.com/uk/support/model/NP350V5C-A0EUK-downloads?downloadName=FM

At that time (25th March), there was no BIOS update available, but a couple of weeks later BIOS update P08ABE became available in SW updater.

There was no description and no changelog. Furthermore, there was no information available about it anywhere online. Was this the update allured to in Samsung support's email?

I upgraded anyway, but without any confirmation that this fixed the problem, I turned to support a second time, requesting some more information on P08ABE. Their response was courteously worded, but wasn't what many of us was hoping to hear:

I am sorry that this information is not more readily available. I understand this is frustrating if you have been waiting to add Linux to
your machine.

Technical Support are only here for hardware faults and as such we only have access to the same information as that which is released to the public. As such I have no further information for you at this time.

I have approached Samsung regarding the issues surrounding the loading of Linux and the official response received was that we do not support the operating system. 

As such I am unable to help with the matter and can only advise that any problem caused by changes to the OEM operating system will not be repaired under warranty.
 
If there is anything else we can help with, please let us know.

I do appreciate support's frankness; when you're the bearer of bad news, it's often easier to try to gloss over things than it is to lay out the facts clearly and plainly.

To summarise:

• No update for the public as of yet, and no timeframe at present
• It's not yet known whether BIOS update P08ABE fixes the UEFI issue
• Any problems caused by their serious firmware bug under Linux "will not be repaired under warranty" (although I'm not certain that's in keeping with their warranty policy)

Frankly, I did expect more from Samsung; I expected dev & test prioritisation, an unprompted flow of information to end users with an indication of a timescale, and an immediate acceptance that any firmware bugs would be covered by the warranty.

However, at this stage, things are still in flux; we'll have to wait to see where the pieces come to rest. The hope is just that they do so sooner rather than later.

Update: The support contact I'm in dialogue with (a most friendly and amiable chap) has offered to look into the P08ABE BIOS update. Hopefully I'll have some more information soon. I suspect that P08ABE won't be the fix we're waiting for, but it will be nice to have that clarity.

Update 2: Support has informed me that they are unable to provide any information about P08ABE.

Truecrypt under FreeBSD

Truecrypt does work under FreeBSD, but it's not always as smooth an experience as on Linux.

A common problem is receiving an "Operation not permitted" error when trying to mount your volume. In my case, has almost always been attributable to an unclean filesystem.

1. How to get access to your data.

Mount the volume with read-only disabled, and with do-not-mount enabled. This gives you a decrypted virtual device under /dev. You can obtain the device path with:

# truecrypt -l

You're now in a position to run a fsck:

# fsck -t <filesystem> /dev/<device>

NB: If you can't remember the filesystem type, you may find testdisk's Analyze mode useful.

Assuming that the fsck completes successfully (probably returning ***** FILE SYSTEM MARKED CLEAN *****) you can remount normally:

# mount -t <filesystem> -w /dev/<device> /mnt

2. How to prevent it reoccurring.

Follow these three steps:

• Always unmount before rebooting/removing the media. 
• Ensure all unmounts are successful (e.g., they shouldn't fail with "Device busy").
• If you have Gamin running, then use a mountpoint under /media or /mnt

The third point is important. gam_server has a tendency to set up a large number of directory and file watches with nautilus. If you're stuck with umount returning the "Device busy" error, check what's preventing umount:

# lsof +D <mountpoint>
COMMAND     PID USER FD  TYPE DEVICE SIZE/OFF     NODE NAME
gam_serve 33424  ace 48r VDIR  0,176     1024        2 /export/d1
gam_serve 33424  ace 49r VDIR  0,176      512        3 /export/d1/.snap
gam_serve 33424  ace 50r VDIR  0,176      512 62507008 /export/d1/2011 

In such a case, Killing gam_server (Gamin) should work. The problem with this is that Gamin is restarted instantly once killed. And Gamin doesn't appear, at a glance, to be awfully configurable in terms of directory exclusions and suchlike.

Your best bet is to try to get a umount in just after killing the process:

# kill 33424 && umount <mountpoint>

That rarely works, since Gamin is restarted so quickly. But sometimes you can just beat it and get your umount in. Running a simple script, something like this (note that this hack only handles one PID), should manage to umount eventually. It's always worked in my case. It may take some time though - be prepared to let it run for a half hour or so before giving up.

# false || while [[ $? -ne 0 ]] ; do kill -9 $(lsof +D <mountpoint> 2>/dev/null | grep gam_serv | awk '{ print $2 }' | uniq) && umount <mountpoint>; done

So the moral of the story is, if you're running Gamin, mount to a mountpoint which is under one of Gamin's preconfigured exclude directories. And as far as I'm aware (without checking the source code), the only two preconfigured exclude directories are /media and /mnt.

The Best Mind Mapping Software on Linux

I generally dislike 'best of' posts, since it's rarely the case that the author has properly analyzed every alternative, or that a 'best' option can be determined objectively.

It's hard to argue that this is an exception. I haven't even tried any of the Linux mind-mapping alternatives; I have no desire to now. I just ask you to try this application. Try it. You'll see what I mean. It is just... superb. It is XMind.

XMind is clearly heavily based on the Eclipse codebase (I will forever be grateful to the Eclipse Foundation for the supremely liberal Eclipse license). As such, the GUI is highly customisable to a degree that would satisfy even the most hardcore KDE advocate.

In true Eclipse style, there is an outline pane, a properties pane, and the usual comprehensive key mapping configuration.

The maps produced with the default settings are indisputably aesthetically pleasing. Unfortunately, the "markers" (clipart graphics for use in maps) included with the software aren't quite to my taste, but are perfectly adequate nonetheless.

The real benefit comes when you really start using the software properly. You'll find that everything 'just works' in an intuitive manner. Dragging a subtopic away from a central topic 'breaks' the link and converts it into a floating topic. Add graphics to anything; attach files to anything. Need to break a subtopic out into more detail? Just hyperlink it to another sheet (or separate mindmap file, or anything else).

Provide easy navigation between associated maps with hyperlinked 'floating topics'. Add custom graphics to the marker list (native is 32px and PNG is supported. You can find some to import in the Open Icon Library). Import/export options are good, including support for other mind mapping software formats; so you can work with the output of popular Android applications, for example.

The base application is FOSS; dual-licensed with EPL and LGPL. However, a few of the lesser-used and more advanced pieces of functionality are both highly expensive and proprietary. This mightn't be enough to satisfy staunch FSF supporters, but I see it as a perfectly reasonable trade-off that has resulted in a very high quality application. I'd be interested to hear your thoughts.

For my personal mind-mapping requirements on the desktop, the free version of XMind is what I'll be using for the foreseeable future.

In case this post is irreparably tarnishing my reputation in the FOSS world, let me reassure you; for my wider diagramming needs, I do, of course, exclusively use Dia!