When a Windows 10 update breaks the dual boot

Execute the following commands using a LiveCD:

sudo mount /dev/sdXY /mnt
sudo mount /dev/sdXX /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
grub-install /dev/sdX
update-grub

Note that X and Y are only used as an example. E.g. it can be that the EFI system partition is on a completely different disk (hard drive) than the Linux system, which needs to be repaired.

Garmin GPSmap 60C and Linux

Since I don't have a Windows machine at home I tried to download the logs from a Garmin GPSMap 60C under Linux. It's not that convenient like using MapSource or such, but it's a little challenge. :) The output of lsusb after connecting the device:

Bus 006 Device 001: ID 0000:0000
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 003: ID 05e3:1205 Genesys Logic, Inc. Afilias Optical Mouse H3003
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 008: ID 091e:0003 Garmin International GPSmap (various models)
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

The kernel module garmin_gps seems to work well. The gpstrans utility recognized the device without any problems:

GPStrans (ASCII) - Version 0.41
Copyright (c) 2005 by Carsten Tschach (tschach@zedat.fu-berlin.de)
Linux/KKJ mods by Janne Sinkkonen (1996)
Copyright (c) 2000 German Grid by Andreas Lange
Copyright (c) 1998,2000 Mayko-mXmap mods by Matthias Kattanek
Copyright (c) 2001 Development by Joao Seabra-CT2GNL
Copyright (c) 2005 Development by Jim Van Zandt
Connected GPS [/dev/ttyUSB0] is: Garmin GPSMap60C Software Version - V4.2

Downloading the logs is easy from command line. The gpstrans utility will produce a simple text file. That text file can be converted to any kind of formats using your own AWK script... I haven't tried uploading yet. There are a lot of other graphical or non-graphical GPS utilities for Linux (e.g. QLandKarte, GPSMan), but I found them a quite unstable for the first sight.

Upgrading Dell Latitude 131L BIOS

I'm currently using BIOS 2.3.0. I decided to try to upgrade to BIOS 2.4.1, however the only enhancement was only "AMD logo posting support".

The most simple solution didn't work for my Dell Latitude 131L. There's a good description about that at http://www.len.ro/work/tools/ubuntu-gutsy-on-a-dell-latitude-d820/bios-upgrade-with-no-windows-or-floppy/view or http://gentoo-wiki.com/HOWTO_Dell_BIOS_Upgrade. The boot floppy version 131L241.exe booted up, but it didn't do anything for a few minutes, so I decided to reboot. Fortunately the old BIOS was still in place. I couldn't try the other method with the SMBIOS utilities, because my "System ID" (0x01F6) was not listed at http://linux.dell.com/repo/software/bios-hdrs and I didn't want to mess up my system with a BIOS for a similar machine.

Strange X11 errors

Last night my battery discharged and my machine turned off immediately. After a restart I was unable to log in as a normal user, but it worked as root. There wasn't any useful information in /var/log/Xorg.0.log, but in ~/.xsession-errors I found error messages like these:

Xsession: X session started for feri at Wed Jul 2 07:29:34 CEST 2008
Protocol not supported by server
xrdb: Can't open display ':0'
wmsetbg warning: could not open domain file /home/feri/GNUstep/Defaults/WindowMaker
Protocol not supported by server
wmsetbg fatal error: could not open display
Protocol not supported by server
xset: unable to open display ":0"
Protocol not supported by server
xmodmap: unable to open display ':0'
Protocol not supported by server
unclutter: could not open display
Protocol not supported by server
Error: Can't open display: :0
Protocol not supported by server
wmmon: can't open display :0
Protocol not supported by server
wmgtemp: can't open display :0
wmgtemp: Primary Sensor - k8temp on PCI adapter
wmnd [linux_proc]: detected eth0
wmnd [linux_proc]: detected wmaster0
wmnd [linux_proc]: detected wlan0
wmnd [testing_dummy]: detected off

The solution was really simple, but it needed some forum browsing. With removing ~/.Xauthority I could log in again.

-m32 vs. -m64

Finally I was able to compile GCC with --enable-multilib. At least the C front end on openSUSE 10.2. I had troubles with Ubuntu 7.10 earlier, but it was long ago. I have to check it again. At that time it wasn't an issue for me to --disable-multilib, but now I want to do some experiments with -m32 on 64-bit platforms.

According to http://gcc.gnu.org/ml/gcc-help/2007-01/msg00352.html, Ubuntu places the libraries into unstandard locations and not into ${PREFIX}/lib and ${PREFIX}/lib64, but into ${PREFIX}/lib32 and ${PREFIX}/lib. It confuses GCC, because the MULTILIB_OSDIRNAMES in ${SRCDIR}/gcc/config/i386/t-linux64 was not modified accordingly. (Yes. It works for me now on Ubuntu 8.04.) The file command shows the differences.

Compiled with -m64 or without -m32:

a.out: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), for GNU/Linux 2.6.4, not stripped

With -m32:

a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), for GNU/Linux 2.6.4, not stripped

With -m32 it's possible to build 32-bit applications on 64-bit platforms. The only prerequisite is a GCC configured with --enable-multilib. The 32-bit libraries will be installed into ${PREFIX}/lib and the 64-bit libraries will be installed into ${PREFIX}/lib64. The following results show that there's no noticable difference in the sizes of data types between an application compiled on a native 32-bit system and between an application compiled on a 64-bit system with -m32. The test program was obvious.

Results with -m64 or without -m32 and with -m32:

sizeof (char) = 1 / 1
sizeof (short) = 2 / 2
sizeof (int) = 4 / 4
sizeof (long) = 8 / 4
sizeof (long long) = 8 / 8

sizeof (float) = 4 / 4
sizeof (double) = 8 / 8
sizeof (long double) = 16 / 12

sizeof (int *) = 8 / 4
sizeof (void *) = 8 / 4

Okay, it's not a big deal anyway, but there were no posts in the blog for a month. :)