07 Jan 2016

feedPlanet Maemo

2015-12-01 Meeting Minutes

Meeting held 2015-12-01 on FreeNode, channel #maemo-meeting (logs)

Attending: Peter Leinchen (peterleinchen), Halit Bal (HtheB), Gido Griese (Win7Mac), Jussi Ohenoja (juiceme)

Partial: Bernardo Reino (reinob)

Absent:

Summary of topics (ordered by discussion):


(Topic Discussing handling of ex-members accounts):

(Topic Automatic calculation of election results):

(Topic Finalizing the rules for the coding competition):


Action Items:
  • old items:
    • Looking into automatic calculation of election results ...
    • Discuss spam handling with techstaff.
  • new items:
    • Finalize the coding competition rules.
    • Post to TMO announcing the competition and requesting for donations.
    • Discuss competition entries storing with OpenRepos people.

0 Add to favourites0 Bury

07 Jan 2016 11:18am GMT

29 Dec 2015

feedPlanet Maemo

Learning Modern 3D Graphics Programming

one of the best resources to learn modern OpenGL and the one which helped me quite a lot is the Book at www.arcsynthesis.org/gltut/ - or lets better say was. Unfortunately the domain expired so the content is no longer reachable.

Luckily the Book was designed as an open source project and the code to generate the website is still available at Bitbucket. Unfortunately this repository does not seem to be actively maintained any more.

Therefore I set out to make the Book to be available again using Github Pages. You can find the results here:

https://paroj.github.io/gltut/

However I did not simply mirror the pages, but also improved it at several places. So what has changed so far?

hopefully these changes will generate some momentum so this great Book gets extended again. As there were also non-cosmetical changes like the new Chapter I also tagged a 0.3.9 release.

I the process of the above work I found out that there is also a mirror of the original Book at http://alfonse.bitbucket.org/oldtut/. This one is however at the state of the 0.3.8 release, meaning it does not only misses the above changes but also some adjustment happened post 0.3.8 at bitbucket.

1 Add to favourites0 Bury

29 Dec 2015 10:26pm GMT

18 Dec 2015

feedPlanet Maemo

Coding Competition 2016

As you may have already noticed in the recent Meeting Minutes, current Council is about to prepare a Coding Competition (CC) for 2016. In times like these, without Nokia or any other corporate entity sponsoring prizes/devices, there are of course limited resources for big giveaways. Nevertheless we believe the approach is worth it. :) We are relying on your donations.

Looking at last CC's, this time it will probably be more of the supportive kind than rival in the first place. Basically we want to support the ongoing AND future software development in a way that ideally, the winners will get the "right" devices to carry on their efforts or even to the next level (e.g. cross-platform).

Now since no current Councilor has ever arranged a CC, we would like to hear your thoughts on how to get it "right", satisfying community demands (SW) as well as individual developer demands (HW). Please share your ideas! And if you've been involved in organizing recent CC's and are willing to help, please holler. And we sure need help in having an uptodate wiki page.

Furthermore, we are calling all owners of now unused devices to consider donating* them for this CC, respectively to MC e.V., who will be responsible for collecting donations and funds. Especially we are looking at those that got rewarded in recent CC's or device programs (N950 anyone? ;)).

* or selling them for a reasonable price.

The voting webinterface will be the same as for the Maemo Council elections, so jury will be you. We also need you to scrutinize the submitted code (ideally installable/executable + binary). It is undecided yet wether or not to accept closed source apps. As the Council is organizing this CC, it will only intervene if a need occurs. Please help make sure conditions and rules are distinct.

Ideas for categories:

- Old NIT's

- Fremantle

- Harmattan

- Sailfish OS

- "Port it/cross-platform"

- "Maintain it" (packages, CSSU)

- "Update/Fix it"

- "Bugfix it" (known, yet unresolved bugs)

- Core development or "Free it" (backport, clone, replace or supersede closed packages)

- Recent contributions (recent major releases)

- Wishlist (rewarded if/when completed)

- Beginner (first release)

A variant could be to have category "Update/Fix it" for each of the 4 device categories if it can be expected to have enough entries (and prizes).

Ideas and suggestions welcome. :)

1 Add to favourites0 Bury

18 Dec 2015 8:55pm GMT

01 Dec 2015

feedPlanet Maemo

2015-11-24 Meeting Minutes

Meeting held 2015-11-24 on FreeNode, channel #maemo-meeting (logs)

Attending: Peter Leinchen (peterleinchen), Bernardo Reino (reinob), Halit Bal (HtheB), Gido Griese (Win7Mac), Jussi Ohenoja (juiceme)

Partial: Rudiger Schiller (chem|st)

Absent:

Summary of topics (ordered by discussion):


(Topic Council roles reorganization):

(Topic Spam mail through Maemo accounts):

(Topic How to handle user requests to remove projects):

(Topic Code of Conduct):

(Topic Maemo Coding Competition 2015):

(Topic Elections handling and management):


Action Items:
  • old items:
    • The selected Code of Conduct (KDE) still needs to be published on TMO.
    • Looking into automatic calculation of election results ...
    • Arrange Council status on TMO for new Council members
  • new items:
    • Discuss spam handling with techstaff.
    • Finalize the coding competition rules.

1 Add to favourites0 Bury

01 Dec 2015 9:20am GMT

23 Nov 2015

feedPlanet Maemo

IOCTL Android

IOCTL is a very useful system call: it is simple and multiplexes the different commands to the appropriate kernel space function. In this post, I want to describe how you can implement a module with IOCTL support for Android. There are a lot of good articles about it (links below), and I just describe the differences regarding to the Android platform.

So, let's create a very simple misc device and let's play with it, doing some reads and writes. Initially, let's define a very simple kernel module (most of the code was taken from here).

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/miscdevice.h>
#include <asm/uaccess.h>


#define MY_MACIG 'G'
#define READ_IOCTL _IOR(MY_MACIG, 0, int)
#define WRITE_IOCTL _IOW(MY_MACIG, 1, int)

static int used;
static char msg[200];

static ssize_t device_read(struct file *filp, char __user *buffer, size_t length, loff_t *offset)
{
return simple_read_from_buffer(buffer, length, offset, msg, 200);
}

static ssize_t device_write(struct file *filp, const char __user *buff, size_t len, loff_t *off)
{
if (len > 199)
return -EINVAL;
copy_from_user(msg, buff, len);
msg[len] = '\0';
return len;
}

static int device_open(struct inode *inode, struct file *file)
{
used++;
return 0;
}

static int device_release(struct inode *inode, struct file *file)
{
used--;
return 0;
}

char buf[200];
int device_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
{
int len = 200;
switch(cmd) {
case READ_IOCTL:
copy_to_user((char *)arg, buf, 200);
break;

case WRITE_IOCTL:
copy_from_user(buf, (char *)arg, len);
break;

default:
return -ENOTTY;
}
return len;
}

static struct file_operations fops = {
.owner = THIS_MODULE,
.read = device_read,
.write = device_write,
.open = device_open,
.release = device_release,
.unlocked_ioctl = device_ioctl
};

static struct miscdevice my_miscdev = {
.name = "my_device",
.mode = S_IRWXUGO,
.fops = &fops,
};

static int __init cdevexample_module_init(void)
{
int ret = misc_register(&my_miscdev);
if (ret < 0) {
printk ("Registering the character device failed\n");
return ret;
}
printk("create node with mknod /dev/my_device\n");
return 0;
}

static void __exit cdevexample_module_exit(void)
{
misc_deregister(&my_miscdev);
}

module_init(cdevexample_module_init);
module_exit(cdevexample_module_exit);
MODULE_LICENSE("GPL");


Compile it and insert into Android kernel.

shell@flounder:/ $ su
shell@flounder:/ $ insmod my_module.ko

Now, we can check the new device in /dev:

shell@flounder:/ $ su
shell@flounder:/ $ ls -l /dev
...
crw-rw---- root mtp 10, 23 2015-11-23 18:04 mtp_usb
crw------- root root 10, 0 2015-11-23 18:11 my_device
crw------- root root 10, 36 2015-11-23 18:04 network_latency
crw------- root root 10, 35 2015-11-23 18:04 network_throughput
crw-rw-rw- root root 1, 3 2015-11-23 18:04 null

...

See that the permissions are limited. Don't forget to set it to:

shell@flounder:/ $ chmod 666 /dev/my_device
shell@flounder:/ $ ls -l /dev
...
crw-rw---- root mtp 10, 23 2015-11-23 18:04 mtp_usb
crw-rw-rw- root root 10, 0 2015-11-23 18:11 my_device
crw------- root root 10, 36 2015-11-23 18:04 network_latency
crw------- root root 10, 35 2015-11-23 18:04 network_throughput
crw-rw-rw- root root 1, 3 2015-11-23 18:04 null

...

Now, let's try to do some operations with our device driver:

shell@flounder:/ $ echo "Hello world" > /dev/my_device
shell@flounder:/ $ cat /dev/my_device

You will see the following error on the logcat:

avc: denied { read write } for name="my_device" dev="tmpfs" scontext=u:r:system_app:s0 tcontext

This means that SELinux (yes, Android makes heavy usage of it) also controls the access to device drivers and you cannot read/write from/to your new drive. You have two options: i) disable SELinux in Android (you need to change some kernel options and rebuild it) or ii) add some new rules into SELinux. Let's do the last to learn a bit more :-)

So, we change the following files and give access (read, write, getattr, ioctl, open and create) to our new device /dev/my_device. If you need to restrict the access, you can adapt the policies according to your needs. For more information about SELinux and Android, take a look in this doc (specially the section "Implementation").

external/sepolicy/device.te
type fscklogs, dev_type;
type full_device, dev_type;
type my_device, dev_type;


external/sepolicy/file_contexts
/dev/rproc_user u:object_r:rpmsg_device:s0
/dev/my_device u:object_r:my_device:s0
/dev/snd(/.*)? u:object_r:audio_device:s0


external/sepolicy/app.te
allow appdomain usb_device:chr_file { read write getattr ioctl };
allow appdomain usbaccessory_device:chr_file { read write getattr };
allow appdomain my_device:chr_file { read write getattr ioctl open create };


Now, let's build the Android framework again and flash the device. Everything should work fine.

shell@flounder:/ $ echo "Hello world" > /dev/my_device
shell@flounder:/ $ cat /dev/my_device
Hello world

That's it!! You can also check the following links


0 Add to favourites0 Bury

23 Nov 2015 6:33pm GMT

17 Nov 2015

feedPlanet Maemo

2015-11-03 Meeting Minutes

Meeting held 2015-11-03 on FreeNode, channel #maemo-meeting (logs)

Attending: Bernardo Reino (reinob), Jussi Ohenoja (juiceme), Peter Leinchen (peterleinchen)

Partial: Rudiger Schiller (chem|st)

Absent: Halit Bal (HtheB), Gido Griese (Win7Mac)

Summary of topics (ordered by discussion):


(Topic TMO forum swearword filter):

(Topic Maemo Coding Competition 2015):


Action Items:
  • old items:
    • The selected Code of Conduct (KDE) still needs to be published on TMO.
    • Looking into automatic calculation of election results ...
  • new items:
    • Arrange Council status on TMO for new Council members

1 Add to favourites0 Bury

17 Nov 2015 6:05pm GMT

11 Nov 2015

feedPlanet Maemo

Latency/Bandwidth and Performance

I've been always interested in scrapping a bit more my application... no matter its level: frontend, framework or native. That's why I guess I have decided to study a bit more Software Systems. Some weeks ago, I was implementing some tests to evaluate my current project in terms of "time spent for certain operations". In addition, I had to force some cache/memory fault, work on some *non* cache-friendly program and, at the end, I was thinking about other aspects of my system. Usually, for software systems, we pretty much focus on latency and bandwidth. For example, when you are developing an application to have an efficient access to memory (cache-friendly!), you are thinking about latency, as you want to avoid (expensive) access to a lower-level memory. Of course, depending on the operation (network, memory access, etc.), latency and bandwidth have a bit different meaning. For example, for network, latency is measured by sending a packet that is returned to the sender. For memory access, latency can be explained as "the delay time between the moment a memory controller tells the memory module to access a particular memory column on a RAM module, and the moment the data from the given array location is available on the module's output pins". [Wiki]

I took a look on some amazing links that gave me a very precise and detailed view about such discussion and here they are:



1 Add to favourites0 Bury

11 Nov 2015 3:43pm GMT

20 Oct 2015

feedPlanet Maemo

2015-09-15 Meeting Minutes

Meeting held 2015-09-15 on FreeNode, channel #maemo-meeting (logs)

Attending: Bernado Reino (reinob), Halit Bal (HtheB), Jussi Ohenoja (juiceme), Peter Leinchen (peterleinchen), Gido Griese (Win7Mac), Rudiger Schiller (chem|st), William McBee (gerbick), Paul Carlin (endsormeans)

Partial:

Absent:

Summary of topics (ordered by discussion):


(Topic Inaugural meeting of the new Maemo Council 2Q/2014):

(Topic Other business):


Action Items:
  • old items:
    • The selected Code of Conduct (KDE) still needs to be published on TMO.
    • Looking into automatic calculation of election results ...
    • Contacting freemangordon and merlin1991 about auto-builder: CSSU-thumb target, GCC versions?
    • Getting maemo trademark registration (everywhere?) renewed (and transferred to MCeV) by the end of February (or within six months since expiry date).
    • Archiving Ovi/Nokia store, especially for Harmattan.
    • Contacting Daphne Won on Facebook and LinkedIn to get administrator rights on Facebook for a Maemo member to migrate the plugin to v2.0 API and maintain it in the future.
  • new items:
    • Arrange user rights for new Council members

1 Add to favourites0 Bury

20 Oct 2015 5:01pm GMT

09 Oct 2015

feedPlanet Maemo

Canon i-Sensys MF8280Cw on 64bit Debian

I've gotten my hands on a Canon i-Sensys MF8280Cw multifunction colour laser printer, in part because I noticed that Canon has published CUPS drivers for Debian (that is Ubuntu), so it should work. It also does work, but I had to jump a few hoops. The driver is available from here (Italian site). Running Debian […]0 Add to favourites0 Bury

09 Oct 2015 3:38pm GMT

13 Sep 2015

feedPlanet Maemo

Meet the new Q2 2015 Maemo Community Council

Dear Maemo community, I have the great honor of introducing the new Community Council for the upcoming Q2/2015 period.

The members of the new council are (in alphabetical order):

The voting results can be seen on the voting page

I want to thank warmly all the members of the community who participated in this most important action of choosing a new council for us!

The new council shall meet on the #maemo-meeting IRC channel next tuesday at 20:00 UTC for the formal handover with the passing council.

Jussi Ohenoja, On behalf of the outgoing Maemo Community Council

1 Add to favourites0 Bury

13 Sep 2015 12:01pm GMT

07 Sep 2015

feedPlanet Maemo

Asynchronous and synchronous I/O in Android NDK

This week, I had some issues on my tests in a Lollipop device with AOSP. I really wanted to have synchronous reads/writes so that I could evaluate my solution in a different way. I am also trying to minimize the effects of caching as much as possible. If you check for async and sync I/O operations for Linux, you'll a lot of references to the flags O_DIRECT, O_SYNC, O_DSYNC, ...

Actually, that's a good way to implement. However, with Android NDK apps, things are not so straightforward.

First, to have a good understanding about the O_*SYNC flags, check this link. Of course, the man page for the command open as well.

First, O_DIRECT does not work in Android since 4.4. See this link for more details about it. That's sad. So, let's try to use the O_*SYNC data.

O_SYNC and O_DSYNC work fine in Android. But, as the description say, only for writes. Another detail: for Android, O_SYNC has the same semantics as O_DSYNC. That's good, but I still want something similar to reads as well.

Why don't we use O_RSYNC? Well, Android does not implement it :-( But it's not the only one... there are other Linux distributions that don't do it either.

What about dropping caches?? See this link for more details. Hum, that works, but after the first read, the data will be cached again :-(

So, I am still looking for a solution for Android Lollipop. Hope to post it soon!


0 Add to favourites0 Bury

07 Sep 2015 9:13am GMT

17 Aug 2015

feedPlanet Maemo

Android - Using Crypto extensions

I had some problems compiling ASM code as part of an Android kernel module.

As part of my system, I need to encrypt/decrypt data inside the kernel and I decided to use AES CBC with 128 bits keys. I am also using a Nexus 9 (arm64 v8), which means that I have access to crypto extensions, including instructions for AES operations :-)

Considering this scenario, I implemented 3 options (of course, I picked the most efficient one at the end):

  1. A "standard" AES CBC implementation in C (the worst performance);
  2. The Linux kernel Crypto lib with crypto extensions set to ON (good performance and very easy to use);
  3. The AES CBC asm implementation from the OpenSSL lib (good performance and it took me extra time to integrate it into my code);

At the end, I took the option #03. Both #02 and #03 have good performance, but #03 is slightly better.

Let's discuss #02 and #03 in this post.

As the very first step, check if your kernel has the proper options enabled for the crypto extension usage. The following ones should be set to "y":

CONFIG_CRYPTO_HW
CONFIG_ARM64_CRYPTO
CONFIG_CRYPTO_AES_ARM64_CE
CONFIG_CRYPTO_AES_ARM64_CE_CCM
CONFIG_CRYPTO_AES_ARM64_CE_BLK

The Crypto lib

The Linux kernel provides the Crypto library, with several cryptography operations, such as AES, including different block/streams ciphers. The following code use AES 128-bits CBC, and a 0-ed IV (don't do that!)

static int pc_aes_encrypt_kernel(const void *key, int key_len,
void *dst, size_t *dst_len,
const void *src, size_t src_len)
{
struct crypto_blkcipher *blkcipher = NULL;
char *cipher = "__cbc-aes-ce";
char iv[AES_BLOCK_SIZE];
char *charkey = (unsigned char *) key;

unsigned int ivsize = 0;
char *scratchpad_in = NULL, *scratchpad_out = NULL;
struct scatterlist sg_in, sg_out;
struct blkcipher_desc desc;
int ret = -EFAULT;
int len = ((int)(src_len/16) + 1) * 16;

memset(iv, 0x00, AES_BLOCK_SIZE); // set the iv to a proper value!!

blkcipher = crypto_alloc_blkcipher(cipher, 0, 0);
if (IS_ERR(blkcipher)) {
PC_LOGV("could not allocate blkcipher handle for %s\n", cipher);
return -PTR_ERR(blkcipher);
}

if (crypto_blkcipher_setkey(blkcipher, charkey, key_len)) {
PC_LOGV("key could not be set\n");
ret = -EAGAIN;
goto out;
}

ivsize = crypto_blkcipher_ivsize(blkcipher);
if (ivsize) {
if (ivsize != AES_BLOCK_SIZE)
PC_LOGV("IV length differs from expected length. It should be : %d\n",ivsize);
crypto_blkcipher_set_iv(blkcipher, iv, ivsize);
}

scratchpad_in = kmalloc(src_len, GFP_KERNEL);
if (!scratchpad_in) {
PC_LOGV("could not allocate scratchpad_in for %s\n", cipher);
goto out;
}

scratchpad_out = kmalloc(len, GFP_KERNEL);
if (!scratchpad_out) {
PC_LOGV("could not allocate scratchpad_in for %s\n", cipher);
goto out;
}

memcpy(scratchpad_in,src,src_len);

desc.flags = 0;
desc.tfm = blkcipher;
sg_init_one(&sg_in, scratchpad_in, src_len);
sg_init_one(&sg_out, scratchpad_out, len);

crypto_blkcipher_encrypt(&desc, &sg_out, &sg_in, src_len);

// for decryption, use the following
// crypto_blkcipher_decrypt(&desc, &sg_out, &sg_in, src_len);

memcpy(dst,scratchpad_out,sg_out.length);

*dst_len = sg_out.length;

ret = 0;
goto out;

out:
if (blkcipher)
crypto_free_blkcipher(blkcipher);
if (scratchpad_out)
kzfree(scratchpad_out);
if (scratchpad_in)
kzfree(scratchpad_in);

return ret;

}


For decryption, you can use the same code, but use the function crypto_blkcipher_decrypt instead.

Integrating a *.S file as part if your module built process

As said, I used an existing implementation from OpenSSL, which uses the crypto extensions of arm64-v8. I only had to change the "includes" of the asm file. In addition, I included the object file into my Makefile, like this:


pc_module-objs := ...
src/pc_utility.o src/asm/aesv8-armx-64.o \
src/crypto/aes.o src/crypto/crypto.o


However, I had some problems with different asm files that I was testing. For example, for the OpenSSL library, some of them will not compile if you use GCC 4.8/4.9. The point is that they use a different architectural syntax (Apple) and you'll see several "Error: unknown mnemonic" error messages.

So, you can use LLVM to compile the asm files with the Apple architectural syntax. LLVM is available in the Android NDK. Then, you can copy the *.o files into your code and build your project. The symbols should match as a charm.

The following code shows the usage of the functions defined in the file aesv8-armx-64.S (available into the folder /external/openssl/)


static int pc_aes_encrypt_hw(const void *key, int key_len,
void *dst, size_t *dst_len,
const void *src, size_t src_len)
{
AES_KEY enc_key;

unsigned char enc_out[src_len];
unsigned char iv[AES_BLOCK_SIZE];
unsigned char *aes_input = (unsigned char *) src;
unsigned char *aes_key = (unsigned char *) key;

memset(iv, 0x00, AES_BLOCK_SIZE);

HWAES_set_encrypt_key(aes_key, key_len*8, &enc_key);
HWAES_cbc_encrypt(aes_input, enc_out, src_len, &enc_key, iv, AES_ENCRYPT);

*dst_len = src_len;
memcpy(dst,&enc_out[0],src_len);

return 0;
}

static int pc_aes_decrypt_hw(const void *key, int key_len,
void *dst, size_t *dst_len,
const void *src, size_t src_len)
{
AES_KEY dec_key;

unsigned char iv[AES_BLOCK_SIZE];
unsigned char dec_out[src_len];
unsigned char *aes_input = (unsigned char *) src;
unsigned char *aes_key = (unsigned char *) key;

memset(iv, 0x00, AES_BLOCK_SIZE);

HWAES_set_decrypt_key(aes_key, key_len*8, &dec_key);
HWAES_cbc_encrypt(aes_input, dec_out, src_len, &dec_key, iv, AES_DECRYPT);

*dst_len = src_len;
memcpy(dst,&dec_out[0],src_len);

return 0;
}



The functions HWAES_set_encrypt_key, HWAES_set_decrypt_key, HWAES_cbc_encrypt and HWAES_cbc_decrypt are implemented in a asm file (aesv8-armx-64.S) and defined in a header file (aes_cbc.h). Again, I used AES 128-bits CBC, with 0-ed IV (don't do that!).


0 Add to favourites0 Bury

17 Aug 2015 4:28pm GMT

07 Aug 2015

feedPlanet Maemo

Microsoft Education Delivery


We spent last year designing and creating MED so it was nice to find this video created by Microsoft explaining what it is and how it works
0 Add to favourites0 Bury

07 Aug 2015 5:06pm GMT

05 Aug 2015

feedPlanet Maemo

Converting a Ubuntu and Windows dual-boot installation to UEFI

UEFI is the successor to BIOS for communicating with the Firmware on your Mainboard.
While the first BIOS was released with the IBM-PC in 1981, the first UEFI version (EFI 2.0) was released 25 years later in 2006 building upon the lessons learned in that timespan. So UEFI is without any doubt the more modern solution.

The user-visible advantages of using UEFI instead of BIOS are

You could reinstall both Windows and Ubuntu to get UEFI. However it is also possible to convert existing installations of both on the fly - without the backup/ restore cycle. You should still do a backup in case something goes wrong though.

Prerequisites

Only the 64bit Versions of Windows support UEFI. Therefore this guide assumes that you run the 64bit versions of both Windows and Ubuntu.

Furthermore verify the following items before you continue - otherwise you will not be able to finish the conversion. Use GParted in case you have not enough space before the first or after the last partition.

to test that the sticks are indeed UEFI compatible, try booting them with CSM Mode disabled in your BIOS.

Convert the drive to GPT

UEFI requires a GUID Partition Table (GPT), so first we need to convert from MBR to GPT.

After this step you will not be able to boot your system any more. So make sure you have the Ubuntu USB drive ready.

We will use gdisk to perform the conversion as following:

sudo gdisk /dev/sdX
Command (? for help): w

where sdX is your system drive (e.g. sda)

Convert Windows to UEFI

Now boot your Windows USB drive and enter the command prompt as described in this Microsoft Technet article at step 6.

Continue with the following steps from the Article. Note that we have skipped steps 1-4 as we used Ubuntu to convert the disk to GPT.

We have now created a EFI partition, a new EFI compatible Windows System Partition and we have installed the Windows Bootloader to the EFI partition. Your Windows installation should now start again.
At this point you could also perform an upgrade to Windows 10, as the upgrade would erase grub from the EFI partition anyway.

Next we are going to install grub to the EFI partition and make it manage the boot.

Enter a Ubuntu chroot

As we can not directly boot our Ubuntu installation, we will instead boot from the Ubuntu USB drive and the switch to the installed Ubuntu.
To do the switch we have to setup and enter a chroot as following

sudo mount /dev/sdXY /mnt 
sudo mount /dev/sdX1 /mnt/boot/efi 
sudo mount -o bind /dev /mnt/dev
sudo mount -o bind /sys /mnt/sys
sudo mount -t proc /proc /mnt/proc
sudo cp /proc/mounts /mnt/etc/mtab
sudo cp /etc/resolv.conf /mnt/etc/resolv.conf
sudo chroot /mnt

where sdXY is the partition where your Ubuntu system is installed (e.g. sda5)

Convert Ubuntu to UEFI

Inside your Ubuntu Installation we have to replace grub for BIOS (aka grub-pc) with grub for UEFI (aka grub-efi) as:

sudo apt-get --reinstall install grub-common grub-efi-amd64 os-prober

this would be enough to get the system booting again, however we also aim for secure boot so we also need to install the following:

sudo apt-get install shim-signed grub-efi-amd64-signed linux-signed-generic

This installs signatures for grub and the kernel which are used to verify the integrity of these at boot. Furthermore we install shim, which is a passthrough bootloader that translates from the Microsoft signatures on you mainboard to the signatures by Canonical used to sign grub and the kernel (see this for details).

Next we finally install grub to the EFI partition by:

sudo grub-install --uefi-secure-boot /dev/sdX
sudo update-grub

where sdX is again your system drive (e.g. sda).

Now you can enable secure boot in your BIOS and benefit. Note that some BIOS implementations additionaly require you to select the trusted signatures. Look out for an option called "Install Default Secure Boot keys" or similar to select the Microsoft signatures.

0 Add to favourites0 Bury

05 Aug 2015 2:13pm GMT

02 Aug 2015

feedPlanet Maemo

Re-Announcement of the Q2 2015 Community Council Election

Dear friends and Maemoans, as it happens we did not get enough confirmed candidates in the set nomination period, so according to the Council Election Rules we need to extend the nomination period by 4 weeks.

This will push all dates one month to future. The new schedule of the voting is as follows:

Currently we have 5 confirmed candidates. (endsormeans, juiceme, reinob, Win7Mac, peterleinchen)

On behalf of the outgoing community council,

Jussi Ohenoja

1 Add to favourites0 Bury

02 Aug 2015 10:00pm GMT

2015-07-28 Council Meeting Minutes

Meeting held 2015-07-28 on FreeNode, channel #maemo-meeting (logs)

Attending: Jussi Ohenoja (juiceme), Peter Leinchen (peterleinchen), Gido Griese (Win7Mac), Paul Carlin (endsormeans)

Partial: Ruediger Schiller (chem|st)

Absent: Oksana Tkachenko (Oksana/Wikiwide), William McBee (gerbick), Alexander Kozhevnikov (MentalistTraceur)

Summary of topics (ordered by discussion):


(Topic Ongoing Council Elections):

(Topic TM donation status):


Action Items:
  • old items:
    • The selected Code of Conduct (KDE) still needs to be published on TMO.
    • Looking into automatic calculation of election results ...
    • Contacting freemangordon and merlin1991 about auto-builder: CSSU-thumb target, GCC versions?
    • Getting maemo trademark registration (everywhere?) renewed (and transferred to MCeV) by the end of February (or within six months since expiry date).
    • Archiving Ovi/Nokia store, especially for Harmattan.
    • Contacting Daphne Won on Facebook and LinkedIn to get administrator rights on Facebook for a Maemo member to migrate the plugin to v2.0 API and maintain it in the future.
  • new items:

1 Add to favourites0 Bury

02 Aug 2015 8:23pm GMT