Tag Archives: Debian

Debian 12 on a 2-drive NUC

After my relative success with Debian 12 on my Hades Canyon I decided to install Debian 12 on an older NUC as well, the NUC D54250WYKH with an i5-4250U. The nice thing with this NUC is that it both has an mSATA slot and room for a good old 2.5-inch drive. So I have:

  • 1 TB 5400 rpm HDD
  • 240 GB SSD

The annoying thing is that the BIOS/UEFI only wants to boot from the SATA drive, and the SATA drive shows up first in Linux. The easy way for me to install this computer would be

  • 240 GB SSD: /, /boot, /swap, /home
  • 1000 GB HDD: /home/sync (for syncthing data)

I could do a simple guided-encrypted-lvm-all-drive on the 240 GB, and a single encrypted partition on 1TB. But Debian 12 installation fails when it comes to installing GRUB, and the installed system does not boot.

Using LVM to make a logical volume spanning a small fast SSD and a large slow HDD makes no sense.

Partitioning in Debian

There is a guided option and a manual option to do Partitioning in Debian. I feel neither is good for me.

  • Guided: fails to lay out things easily on the two drives in a way that works
  • Manual: honestly, too complicated, particularly:
    • LVM and encryption hide few details, requires many steps, and hard to undo half-way
    • I understood that LILO needed to go the beginning of the drive BIOS was set to boot, and that LILO needed to see /boot (whether its own partition or root). However, with GRUB and UEFI, there are two separate extra partitions (/boot and some FAT-partition I think) and I am not allowed to control where the GRUB code goes (if anywhere). So I do not dare to set up this manually.

To make things worse (admittedly, I used the minimal.iso Debian installer which pulls things over the network to make things slower), when restarting the computer/installer there are quite many steps until my drives are detected and I can even erase partition tables and start over.

What I did

After two failed installation attempts, and several more restarts of the installer, I found a working solution.

I first erased all traces of partitions and boot code on both drives to be on the safe side. /dev/sda is the installation media.

  1. # dd if=/dev/zero of=/dev/sdb bs=1024 count=10240
  2. # dd if=/dev/zero of=/dev/sdc bs=1024 count=10240
  3. Guided non encrypted setup of 1000 TB drive, with separate /home
  4. I didn’t even install X/Gnome this time to save time

This gave me working computer that makes no use of my SSD. As root on the console I did:

  1. Backup the home directory of my non-root-user (just in case) to /root
  2. Remove /home from fstab
  3. Restart
  4. install cryptsetup and cryptsetup-run
  5. encrypt /dev/sda4 using cryptsetup (900GB+ HDD partition)
  6. encrypt /dev/sdb1 using cryptsetup (240GB SSD only partition)
  7. add entries to /etc/crypttab:
    sda4enc /dev/sda4
    sdb1enc /dev/sdb1
  8. Restart
  9. Give master encryption password (just once since I used the same)
  10. mkfs.ext4 /dev/mapper/sda4enc
  11. mkfs.ext4 /dev/mapper/sdb1enc
  12. add entries to /etc/fstab
    /dev/sdb1enc /home +options
    /dev/sda4enc /home/sync +options
  13. Restart

The result is almost 100% good. A few comments:

  • swap ended up on slow 1TB HDD, which I am fine with since I have 16GB RAM
  • root filesystem (with /usr, /root, /var, /etc and more) is not encrypted now, but I can live with having only my data (/home, /home/sync) encrypted
  • using cryptsetup/luks directly on partitions, not bothering with LVM, is much more simple
  • with /etc/crypttab and cryptsetup-run, encryption is really simple and understandable

As long as I do not run into something strange with X/Wayland/Gnome and drivers for this old NUC, I think I am good now.

What I would have wanted

I hear people have been fearing the Debian installer, up to Debian 12. I have not feared it in the past, but now I kind of do (after having issues installing two different NUCs the same week).

This is the partitioning experience I would have liked. My input/selections as [ ].

You have three drives with multiple partitions. Select all you want to keep, use as is, or delete:

/dev/sda (Debian installation media)
[KEEP] /dev/sda1 ...
[KEEP] /dev/sda2 ...
[KEEP] /dev/sda3 ...

/dev/sdb (1000 GB HITACHI)
[DELETE] /dev/sdb1  200 GB NTFS
[DELETE] /dev/sdb2  750 GB ext4
[/mnt/backup] /dev/sdb3 50 GB (just an example of something to keep

/dev/sdc (240 GB SAMSUNG)
[DELETE] /dev/sdc1  500MB FAT
[DELETE] /dev/sdc2  400MB ext2
[DELETE] /dev/sdc3  239GB ext4

With that out of the way, I would like Debian to ask me:

What device should contain 2 small partitions for boot purposes?
[X] /dev/sdb  -- 950 GB free
[ ] /dev/sdc  -- 240 GB free

Where do you want swap partitions, and what size?
[      ] /dev/sdb -- 950 GB free
[ 16GB ] /dev/sdc -- 240 GB free

Where do you want /, and what size
[      ] /dev/sdb -- 950 GB free
[ 30GB ] /dev/scd -- 224 GB free

Do you want a separate /home, and what size
[       ] /dev/sdb -- 950 GB free
[ 194GB ] /dev/scd -- 194 GB free

Do you want a separate /var, and what size
[       ] /dev/sdb -- 950 GB free
[       ] /dev/scd --   0 GB free

Do you want to set up extra non-standard mounts?
[ 950GB ] [ /home/sync ] /dev/sdb -- 950 GB free

Now it is time to choose encryption and format options:

UEFI-BOOT    500MB   [ FAT ]
/boot        500MB   [ ext2 ]
/             30GB   [ ext4 + encrypt ]
/home        194GB   [ ext4 + encrypt ]
/home/sync   950GB   [ ext4 + encrypt ]
/mnt/backup   50GB   [ KEEP ]

Finally, choose encryption password (the same, or separate).

This would have been a much better experience for me. I understand there can be more cases:

  • Computers with multiple disks may want to use LVM for to make logical volumes spanning several physical volumes. That would probably be a question between (1) and (2) above.
  • Multiple filesystems could live on a common encrypted volume, with a common encryption key, making use of LVM. That could be a question in the end:
    /usr and /var are on the same disk, do you want them to share encryption key on a common volume

Summary

I would guess that the use cases are:

  • 80% Simple 1-drive computers (Guided, automatic, defaults)
  • 10% Multi-disk servers with specific requirements (Manual, expert mode)
  • 10% 2-3 drive computers (not well supported today with Debian 12)

I am just making 80/10/10 up, of course. The unsupported 10% can be made up of:

  • Laptops or desktops that come with a small SSD and a large HDD (it happens)
  • Desktop computers with extra drives installed
  • Simple servers

Perhaps in Debian 13!

Debian 12 on Hades Canyon NUC

I have a Hades Canyon NUC (NUC8i7HVK) that I have been running Ubuntu and later Fedora on. Ubuntu has been fine for years but I didn’t want Snap (especially not for Firefox) so I tried out Fedora and that was also fine.

I realize that I did not leave Ubuntu because I did not want to have Snap, I left it because I want 100% apt. So in the long run I feel a bit alienated with Fedora and with Debian 12 out and getting good reviews I thought about giving it a try.

This desktop computer is a bit like your typical laptop when it comes to Linux, not sure everything works out of the box. I used to struggle a bit with Bluetooth and Audio, but I don’t do those things on this machine anymore. Ubuntu and Fedora are kind of already configured with proprietary non-free drivers for this NUC, but Debian is not.

TLDR

I am running Debian 12 now, installed from the “minimal.iso” debian image, and with a number of extra packages installed. The InstallingDebianOn-page for this machine is ok. All I actually did was to add non-free and contrib to sources.list and install the extra packages recommended:

I have done no extra configuration or tweaking on Debian 12, but I am not using Audio-IN, Bluetooth or Wifi so I have not tested.

Broken Live Image

I didn’t throw Fedora 38 out without doing some testing first, so I downloaded the Live image for Debian 12 and successfully tried it. Then I installed Debian 12 from the Live image (choosing install immediately at the Grub menu), which was 99% successful. But it left some Raspberry-Pi packages and some stuff in /boot, resulting in that apt could not finish rebuilding the ramdisk. Computer started, but error remained. I searched on forums, it is a known problem with the Live image, there are solutions and when I tried I just got more errors. So I ended up reinstalling Debian 12 from scratch.

minimal.iso

I downloaded the minimal.iso, convenient so I did not have to use a large USB-key, and installed from it. What a nice text/curses based installation! Then I got a non booting system!

I had to disable “Intel IGD” (I think that was how it was called) in “BIOS” (it is not BIOS anymore), becuase this machine has an Intel GPU that is not connected to any output, and with this rudimentary Debian install, somehow the system would not start.

When that was done, and I started Debian and logged in, Gnome (and neofetch I presume) reported GPU=Software. I could watch Youtube with high CPU load. That was when I installed the extra packages listed above, and since then I have been happy.

Conclusion

Debian 12 is fine on Hades Canyon NUC8i7HVK. The InstallingDebianOn-page linked above tells you more than you need. It was written from Debian 10.7.

Upgrading Qnap TS109 from Jessie to Stretch

I have an old Qnap TS109 NAS that has been running Debian since long. I have previously written about my upgrade to Wheezy and Jessie.

The upgrade to Strech is the same procedure, and it was fine in the end, but…

In a very late phase of the upgrade I got:

update-initramfs: Generating /boot/initrd.img-4.9.0-5-marvell
flash-kernel: installing version 4.9.0-5-marvell

The initial ramdisk is too large. This is often due to the unnecessary inclusion
of all kernel modules in the image. To fix this set MODULES=dep in one or both
/etc/initramfs-tools/conf.d/driver-policy (if it exists) and
/etc/initramfs-tools/initramfs.conf and then run 'update-initramfs -u -k 4.9.0-5-marvell'

Not enough space for initrd in MTD 'RootFS1' (need 4210887 but is actually 4194304).

Well, the MODULES=dep thing does not help, but there is a another fix. You can compress your initramfs image. The procedure is described in the end of troubleshooting TS109.

The very short procedure is (I recommend you read the real article above):

echo "COMPRESS=xz" > /etc/initramfs-tools/conf.d/compress
apt-get install xz-utils
update-initramfs -u

Apart from that little problem, Stretch is just fine on QNAP TS109.

Raspberry PI performance and freezes

On a daily basis I use a Raspberry Pi v2 (4x900MHz) with Raspian as a work station and web server. It is connected to a big display, I edit multiple files and it runs multiple Node.js instances. These Node.js processes serve HTTP and access (both read and write) local files.

I experienced regular freezes. Things that could take 2-3 seconds were listing files in a directory, opening a file, saving a file and so on.

I moved my working directory from my (high performance) SD-card to a regular spinning USB hard drive. That completely solved the problem. I experience zero freezes now, compared to plenty before.

My usual experience with Linux is that the block caching layer is highly effective: things get synced to disk when there is time to do so. I dont know if Linux handles SD-cards fundamentally different from other hard drives (syncing more often) or if the SD card (or the Raspberry Pi SD card hardware) is just slower.

So, for making real use of a Raspberry Pi I would clearly recommend a harddrive.

Lighttpd, Debian and CGI

I installed lighttpd in Debian (Jessie), and I wanted CGI to work.

The Welcome/Placeholder page has some information, and part of it is:
CGI scripts are looked for in /usr/lib/cgi-bin, which is where Debian packages will place their scripts. You can enable cgi module by using command “lighty-enable-mod cgi”.

This appears to just not be true. CGI-programs worked perfectly when placed /var/www/html/cgi-bin, but not in /usr/lib/cgi-bin (or /var/www/cgi-bin). This is with default configuration.

Getting your locale right

So, you get this annoying error (in Debian, some Ubuntu, or perhaps any other Linux or even Unix system):

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Perhaps you get it when running apt-get?
You Google for answers and you find nothing useful and/or just contradictory information?
You are connecting over SSH?
You are connecting from another system (like Mac OS X)?
Read on…
In it simplest incarnation, the problem looks like this.

$ man some-none-existing-program
man: can't set the locale; make sure $LC_* and $LANG are correct
No manual entry for some-none-existing-program

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE=UTF-8
LC_NUMERIC=sv_SE.UTF-8
LC_TIME=sv_SE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=sv_SE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=sv_SE.UTF-8
LC_NAME=sv_SE.UTF-8
LC_ADDRESS=sv_SE.UTF-8
LC_TELEPHONE=sv_SE.UTF-8
LC_MEASUREMENT=sv_SE.UTF-8
LC_IDENTIFICATION=sv_SE.UTF-8
LC_ALL=

What happens here, in the second case is that “UTF-8” is not a valid LC_CTYPE (in Debian) and since LC_ALL is not set it can not fall back properly. That is all. Why is LC_CTYPE invalid? Perhaps because you have used ssh from Mac OS X (or something else):

mac $ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

mac $ ssh user@debianhost

The point is, here LC_CTYPE=UTF-8, and it is valid in OS X. But it is not valid in Debian. That is all there is to it. Try:

# This will fix the problem
mac $ LC_CTYPE=en_US.UTF-8 ssh user@debianhost

# This will produce the problem even from a Debian machine
debianclient $ LC_CTYPE=UTF-8 ssh user@debianhost

# This will (kind of) eleminate the problem when already logged in
$ LC_CTYPE=en_US.UTF-8 locale
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8)
LANG=en_US.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=sv_SE.UTF-8
LC_TIME=sv_SE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=sv_SE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=sv_SE.UTF-8
LC_NAME=sv_SE.UTF-8
LC_ADDRESS=sv_SE.UTF-8
LC_TELEPHONE=sv_SE.UTF-8
LC_MEASUREMENT=sv_SE.UTF-8
LC_IDENTIFICATION=sv_SE.UTF-8
LC_ALL=

So, the problem is that all the guides on the internet presume you have a problem with your locales on your server, which you dont! The locale is probably fine. It is just that the ssh client computer has an LC_CTYPE which does not happen to be valid on the server.

The Debian Locale guide itself is of course correct. And it states that you should not set LC_ALL=en_US.UTF-8 (!). That is however the only “working” answer I found online.

Solution
I guess the easiest thing is to add a line to your .profile file (on the server):

$ cat .profile 
.
.
.
LC_CTYPE="en_US.UTF-8"

If you are not using a bourne-shell you probably know how to set a variable for your shell. Any other method that will set LC_CTYPE to a locale valid on your Debian machine will also work. Clearly, you dont need (and you probably should not) set LC_ALL.

Not happy with en_US.UTF-8?
Not everyone use the American locale. To find out what locales are available/valid on your system:

$ locale -a
C
C.UTF-8
en_GB.utf8
en_US.utf8
POSIX
sv_SE.utf8

Want others?

$ sudo dpkg-reconfigure locales

or read the Debian Locale Guide.

Upgrading Qnap TS109 from Wheezy to Jessie

The Qnap TS-109 runs Debian Wheezy just fine, but it has to be upgraded from Squeeze (no direct install). How about upgrading Wheezy to Jessie? This device is old and slow, so I decided to find out, and if it does not work, so be it.

Debian links:

Below follows a shorter version of the upgrade guide, focusing on what I actually did with my Qnap.

Getting ready
First you should of course backup your stuff if the device contains anything you can not lose.

It can also be a good idea to clean out packages that you dont need (to both avoid problems when upgrading them, and to save time during the upgrade):

$ sudo dpkg -l
$ sudo apt-get purge SOMEPACKAGES

It is also adviced to make sure you dont have packages on hold. You can do this with:

$ sudo dpkg --get-selections | grep 'hold$'

I confirmed that my system was then fully wheezy-updated

$ sudo apt-get update

$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

With that, I decided I was ready for an upgrade to Jessie.

Upgrade itself
I first updated /etc/apt/sources.list.

Old version:

deb http://ftp.se.debian.org/debian/ wheezy main
deb-src http://ftp.se.debian.org/debian/ wheezy main non-free

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main non-free

deb http://ftp.df.lth.se/debian wheezy-backports main

New version:

deb http://ftp.se.debian.org/debian/ jessie main
deb-src http://ftp.se.debian.org/debian/ jessie main non-free

deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main non-free

I just deleted the backports source.

And begin upgrade:

$ sudo apt-get update
$ sudo apt-get upgrade

That went fine, so I did a reboot. It took longer than usual, but it came up. So I proceeded with:

$ sudo apt-get dist-upgrade

…which went fine, and I rebooted.

System came up and it seems good! If I encounter problems later I will write about it here.

Installing Citrix Receiver 13.1 in Ubuntu/Debian

The best thing with Citrix Receiver for Linux is that it exists. Apart from that it kind of sucks. Last days I have tried to install it on Xubuntu 14.10 and Debian 7.7, both 64-bit version.

The good thing is that for both Debian and Ubuntu the 64-bit deb-file is actually installable using “dpkg -i”, if you fix all dependencies. I did:

1) #dpkg --add-architecture i386
2) #apt-get update
3) #dpkg -i icaclient_13.1.0.285639_amd64.deb
  ... list of failed dependencies...
4) #dpkg -r icaclient
5) #apt-get install [all packages from (3)]
6) #dpkg -i icaclient_13.1.0.285639_amd64.deb

Step (1) and (2) only needed in Debian.

selfservice is hard to get to start from the start menu. And selfservice gets segmentation fault when OpenVPN is on (WTF?). So for now, I have given up on it.

npica.so is supposed to make the browser plugin work, but not much luck there (guess it is because I have a 64 bit browser). I deleted system-wide symbolic links to npica.so (do: find | grep npica.so in the root directory).

#rm /usr/lib/mozilla/plugins/npica.so
#rm /usr/local/lib/netscape/plugins/npica.so

Then I could tell the Citrix portal that I do have the Receiver even though the browser does not recognize it, and as I launch an application I have choose to run it with wfica.sh (the good old way).

keyboard settings can no longer be made in the GUI but you have to edit your ~/.ICAClient/wfclient.ini file. The following makes Swedish keyboard work for me:

KeyboardLayout = SWEDISH
KeyboardMappingFile = linux.kbd
KeyboardDescription = Automatic (User Profile)
KeyboardType=(Default)

The problem is, when you fix the file, you need to restart all Citrix-related processes for the new settings to apply. If you feel you got the settings right but no success, just restart your computer. I wasted too much time thinking I had killed all processes, and thinking my wfclient.ini-file was bad, when a simple restart fixed it.

Debian on NUC and boot problems

I got a NUC (D54250WYKH) that I installed Debian 7.7 on.

Advice: First update the NUC “BIOS”.

  1. Download from Intel
  2. Put on USB memory
  3. Put USB memory in NUC
  4. Start NUC, Press F7 to upgrade BIOS

If I had done this first I would have saved some time and some reading about EFI stuff I don’t want to know anyway. A few more conclusions follow.

EFI requires a special little EFI-partition. Debian will set it up automatically for you, unless you are an expert and choose manual partitioning, of course 😉 That would also have saved me some time.

(X)Ubuntu 14.10 had no problems even without upgrading BIOS.

The NUC is very nice! In case it is not clear: there is space for both an mSATA drive and a 2.5′ drive in my model. In fact, I think there is also space for an extra extra small mSATA drive. Unless building a gaming computer I believe NUC (or similar) is the way to go.

Finally, Debian 7.7 comes with Linux 3.2 kernel which has old audio drivers that produce bad audio quality. I learnt about Debian backports and currently run Linux 3.16 with Debian 7.7 and I have perfect audio now.

Upgrading Qnap TS109 from Squeeze to Wheezy

Update: new instructions for upgrading Wheezy to Jessie

Now that Wheezy has been out for a while I thought it is stable enough even for my old QNAP TS109. A great source of information for Debian on Qnaps is Martin Michlmeyr, so I decided to upgrade from squeeze to wheezy using Debain standard instructions.

Package Checking
I did not have any packages on hold, but over the years I have installed quite many packages I dont need. So I spent some time listing and removing packages:

$ sudo dpkg -l
$ sudo apt-get purge SOMEPACKAGES

I thought, faster to delete them now, than to upgrade them a little later.

/etc/apt/sources.list
First real upgrade-related step is fixing /etc/apt/sources.list:

deb http://ftp.se.debian.org/debian/ wheezy main
deb-src http://ftp.se.debian.org/debian/ wheezy main non-free

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main non-free

I have just replaced ‘squeeze’ for ‘wheezy’ four times.

update upgrade
Now the point of no return:

$ sudo apt-get update
$ sudo apt-get upgrade

This presented me with a few challenges.

???????????????????????????Configuring linux-base?????????????????????????????
? Boot loader configuration check needed                                     ?
?                                                                            ?
? The boot loader configuration for this system was not recognized. These    ?
? settings in the configuration may need to be updated:                      ?
?                                                                            ?
?  * The root device ID passed as a kernel parameter;                        ?
?  * The boot device ID used to install and update the boot loader.          ?
?                                                                            ?
?                                                                            ?
? You should generally identify these devices by UUID or label. However,     ?
? on MIPS systems the root device must be identified by name.                ?
?                                                                            ?
?                                                                            ?
??????????????????????????????????????????????????????????????????????????????
?                                 <  OK  >                                   ?
??????????????????????????????????????????????????????????????????????????????

What is an ARM user gonna do about it? You can safely ignore this (if you are upgrading Debian on a QNAP – probably not if you are upgrading Ubuntu on your laptop!). This is supposed to be grub/lilo-related, and not relevant.

In the end of apt-get upgrade I got these messages, ensuring my system will boot properly even after upgrade. You should probably see something like this too, or consider to find out how to do it manually.

Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.32-5-orion5x
flash-kernel: installing version 2.6.32-5-orion5x
Generating kernel u-boot image... done.
Flashing kernel... done.
Flashing initramfs... done.

Sudo was a little challenge:

Configuration file `/etc/sudoers'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sudoers (Y/I/N/O/D/Z) [default=N] ? D

The “diff” told me that it intended to delete my sudo line related to me; the new way is to add people to the group (/etc/group) named sudo. So I added myself to the sudo group and bravely answered ‘Y’ to the question above.

Immediately, sudo did not work, as I was no longer in the sudoers file… However, a little logout/login fixed that, and the group works all fine.

After apt-get upgrade had completed I decided to reboot my system, before proceeding. For the first time ever it came up with another IP-address than usual. Obviously the dhcp-client did not bother to ask for the same address anymore, and the dhcp-server did not bother to hand out the same address either. So, a few nervous minutes before I found my QNAP on another IP.

apt-get dist-upgrade
Now that the system rebooted properly it was time for the final upgrade step:

$ sudo apt-get dist-upgrade

This procedure mostly works on it own, occationally asking something.

I answered Yes to this question (after reading the diff, not remembering having edited this file)

Configuration file `/etc/default/rcS'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** rcS (Y/I/N/O/D/Z) [default=N] ? y

The dist-upgrade once again replaced the kernel…

Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-3.2.0-4-orion5x
flash-kernel: installing version 3.2.0-4-orion5x
Generating kernel u-boot image... done.
Flashing kernel... done.
Flashing initramfs... done.

…so I made a final reboot. Everything seems just fine.