Upgrading to Excalibur - lxdm and /boot

Geoff 42 · Today 10:16:21

It is reported in :-
https://dev1galaxy.org/viewtopic.php?id=7345

that /boot needs to be at least 768 MB with 300 MB free.

On my machine df reports :-

Filesystem Size Used Avail Use% Mounted on
/dev/sdb5 237M 133M 87M 61% /boot

It also reported that lxdm has problems.

My first attempt at upgrading from Daedalus to Excalibur was on a virtual machine, running under Xen.
This was a fairly simple set up with a single partition and access was via VNC rather than lxdm.
The upgrade went very smoothly with nothing much to report.

The second attempt was my laptop. This had /boot as part of the root partition, so there was little difficulty in upgrading, although when I logged in through lxdm, it failed to start the panel. I was able to open a terminal from the background menu and from there I could run lxpanel, which let me carry on fairly normally.

The laptop had originally been set up with lxdm and lxde, which is how I had lxpanel available. I had later moved over to using lxQt. After some investigation I found that some package was being held back. I tried :-

apt -f install

which provided some useful info on the problem, which seemed to be that an older version of upower was installed. Unfortunately, the version number had "1:" in front of it and apt thought that it was newer than the new version, which did not have "1:". I then switched to using Synaptic, as that seems to make it easy to fix. I found upower, which displayed the 2 versions with the old one labelled (now) and the new one (stable). Selecting Package>force version I was able to select the (stable) version and then install it. It did highlight that I was downgrading it, but did do it. After that I made sure that lxQt was properly installed and I am now able to log in through lxdm selecting either lxde or lxQt.

Boot partition
==============

I then set about my main desktop machine. I see that /lost+found is dated Sept 2013, which I take to be when I set the machine up. The machine was set up using lvm to make it easy adjust the partitions and set up more partitions for virtual machines. I vaguely recall that at that time grub may not have been able to boot with a /boot partition on lvm. Probably because of that I had /boot as a real partition while root was on an lvm partition. I also gathered that now grub is able to boot off an lvm partition, so my plan was to unmount /boot and then copy its contents over to what was the /boot mount point.

I did this by booting of a USB memory stick. I downloaded a Daedalus minimal live iso and dd-ed it to the stick, checking up with :-

https://pendrivelinux.com/create-bootab … -using-dd/

I was able to boot up and then mount root and the old /boot separately and copy over the content:-

mount /dev/mapper/SSD0-root /mnt
mount /dev/sda5 /mnt/old-boot

cd /mnt/old-boot
tar -cf - . | tar -C /mnt/boot -xpBSf -

I then set about setting up grub and initramfs for the new set up.

I followed these two pieces of advice :-

https://www.youtube.com/watch?v=9nbuKIM78BQ
https://aaronlauterer.com/blog/2021/mov … ther-disk/

mount your real file systems on /mnt, as described in the above links

chroot /mnt
grub-install /dev/sd? #This is the actual device itself and not the root partition
                #the system seems to swap sda and sdb, especially when booting off a memory stick
                #don't get them the wrong way round. It is the device with the root partition
update-grub
update-initramfs -u -k all

update /etc/fstab by commenting out the /boot partition

exit from chroot, unmount your file systems and reboot, removing USB stick.

This seemed to work nicely and I was able to boot with the /boot as part of the root partition on lvm.

I then installed usrmerge, updated the sources.list and proceeded with the upgrade.
It did report that I had run out of disk space, so I ran

apt autoremove --purge
apt autoclean

and re-ran the upgrade. This continued smoothly, although when I was watching in a different window df was reporting that root was 100% full, but didn't actually run out of space. After it was all done and I had re-run the autoremove and autoclean, df reported that there was 1.5G available on the root partition.

I am now just going round checking that everything is running correctly.

Last edited by Geoff 42 (Today 10:18:12)

fsmithred · Today 15:13:30

After reading your post I realized that I don't have an excalibur install with a separate /boot partition, but I do have a couple of daedalus installs with boot partitions that are 500M or smaller. I'm not ready to upgrade those, so I did a test in a VM. Results below:

200M /boot was too small. I'm not sure why it failed to boot and dropped me to initramfs prompt. I rebooted with a live iso, went into chroot to reinstall grub, update-grub and then run 'update-initramfs -u -k all'. It ran out of disk space and failed.

360M /boot works. I don't recommend using such a small size, but only because we're getting so many kernel upgrades lately, it's easy to accumulate too many to fit. (I think 300M will hold three kernels)

Disk /dev/sda: 8 GiB, 8589934592 bytes, 16777216 sectors
Disk model: QEMU HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x460d0caf

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1         2048   739327   737280  360M 83 Linux
/dev/sda2       739328 16777215 16037888  7.6G 83 Linux

Disk /dev/mapper/root_fs: 7.63 GiB, 8194621440 bytes, 16005120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/root_fs  7.5G  4.2G  3.0G  59% /
/dev/sda1            328M   65M  242M  21% /boot

The officially official Devuan Forum!

#1 Today 10:16:21

Upgrading to Excalibur - lxdm and /boot

#2 Today 15:13:30

Re: Upgrading to Excalibur - lxdm and /boot

Board footer