The core problem seems to be with the partition identifier for the root file system. At some time it was 9cb7fe29-135e-4471-8b2c-d3e08d6ad44f, and now it appears to be something else. But that identifier has got into /etc/fstab.

So replace that to say /dev/sda1 instead.

And you would "activate" the swap space by replacing #UUID=b10e083f-db41-40e4-ac56-13e66da6ee32 (including the #) with /dev/sda2.

Well, I think it should be possible to get it to boot, yes. And I think you should make sure to install the boot loader on /dev/sda (the disk) rather than /dev/sda1 (the first partition).

afaui, grub's boot loader once installed, is directed to a partition with a /boot/grub/grub.cfg file declaring the available systems to boot up, but that file is found by the boot loader looking at a certain byte offset relative to itself rather than a kernel assisted file system access. It's grub itself that accesses the disk blocks of the file for digesting the boot declarations, and then it uses those to find the selected kernel and initrd (if any). So when the boot loader is "misplaced", it doesn't work.

Yes. Specifically consolekit (of some version) didn't use gettext properly, and so ended up with locale directories named like br.gmo/ etc, for it's localizations. Then, grub-install attempts to copy all /usr/share/locale/*mo files into the boot partition, but can't handle these directories and bails out.

By removing those directories, one ends up with a consolekit without localizations, but it works otherwise.

The consolekit version in beowulf (and unstable) have been patched for this, so this particular problem won't arise for them.

Perhaps it's important that the id of the entry is different from the id of the origin class. E.g. in post#8 above, the origin class id, 11, is the same as the id of the entry it concerns, and it should therefore be ignored. This logic could be done as:

xinput list --id-only | \
    xargs -n 1 -I+ sh -c "xinput list + | grep -wv + | grep XIKeyClass" | \
    grep -oE "[0-9]+"

I.e., in words: for each of the available ids, check the details for the id, but ignoring lines containing the id, for a XIKeyClass line, and then reduce resulting lines to the number they contains. Ideally there should be only one resulting line, but if there are more... well.

Then you might want to check out https://unix.stackexchange.com/question … ress-a-key on how to "really" do this

Perhaps it's merely incidental, or perhaps it's because it's the detail associated with the 'master keyboard' where something in the xinput code makes it a reliable feature. I did do a quick test with a couple of different hardware set ups, including a laptop with a USB keyboard, and it seemed to offer the right result for those.

It's also a guess that the label XIKeyClass is a code label without i18n, and that no i18n of that detail line will morph the id number, or add any other digits into the mix.

It works while it works

Eventually someone with direct insight into the source might pass by, to confirm or refute.

Interesting. Possibly a reinstall would make your problem go away; it tends to work on Windows, so why not with Linux ;D

I just verified that in order to chroot into a directory /BLAH you only need 5 files:

/BLAH/bin/bash
/BLAH/lib/x86_64-linux-gnu/libtinfo.so.5
/BLAH/lib/x86_64-linux-gnu/libc.so.6
/BLAH/lib/x86_64-linux-gnu/libdl.so.2
/BLAH/lib64/ld-linux-x86-64.so.2

So, getting tedious: check that the files concerned are not links that points out of /mnt:

# ls -l /mnt/lib64/ld-linux-x86-64.so.2
# ls -l /mnt/lib/x86_64-linux-gnu/libtinfo.so.5
# ls -l /mnt/lib/x86_64-linux-gnu/libdl.so.2
# ls -l /mnt/lib/x86_64-linux-gnu/libc.so.6
# ls -l /mnt/bin/bash

The first one in particular might point to /lib/x86_64-linux-gnu/ld-2.24.so (or something) and maybe /mnt/lib/x86_64-linux-gnu/ld-2.24.so (or something) is missing. That could explain why it "looks right" in the prior checks, without actually being right under chroot.

Yes, it *should* work. But it doesn't

I guess you verified that the libs are available:

# ls -lL /mnt/lib/x86_64-linux-gnu/libtinfo.so.5
# ls -lL /mnt/lib/x86_64-linux-gnu/libdl.so.2
# ls -lL /mnt//lib/x86_64-linux-gnu/libc.so.6

Does something else work? Eg
# chroot /mnt ls

... it's gradually rising to be a "peculiar" problem ...

Apparently sda6 does not contain a complete file system, and in particular it doesn't have an executable program /bin/bash.

I suggest you investigate this directly after the first mount command, which makes the file system of sda6 available under /mnt.

All the other commands (except chroot) are just extra noise here, and they serve no purpose for you being able to change the root file system for a process.

So the investigation sequence would be two commands, with the first one optional (if you have doen it already):

# mount /dev/sda6 /mnt
# ls -l /mnt/bin/bash

Consistently with the chroot error you may get the result:

ls: cannot access '/mnt/bin/bash': No such file or directory

or you may get something else, which in any case should provide something for understanding the chroot error report.

Later, when you have sorted out your chroot problem, you return to also use the other commands, when/if you need access to those virtual file system components.

It's possible this is not due to the partitioning, but that you've got a sightly buggy consolekit package installed, which makes directories in /usr/share/locale/ with names ending in .gmo, and that this upsets grub-install. One way to work around that would be to remove those directories, and then redo grub-install. Doing so makes consolekit lose its internationalization, but all else would be fine.

For that particular issue, you might want to temporarily put jessie/main back into the sources list, just to pick up the libpng12-0=1.2.50-2+deb8u3 package, and then restore the sources list again (and update egain).

I don't remember the exact details, but when libpng16 came about, libpng12 got left behind, with the result of needlessly but forcefully deprecating dependent packages. Whatever the case was, the "missing" libpng12 from jessie installs without issues on ascii (and both are merged directly from Debian).

It's not clear to me why you have a problem with installing lsb-desktop. It's a "standard" ascii package and version.
Try doing:

# apt-get update
# apt-get -f install

to ensure you have a workable apt state.

Thereafter a normal ad-hoc installation

# dpkg -i epson-inkjet-printer-escpr.deb
# apt-get -f install

should work fine.

Nothing special, other than the name.

In fact, maybe a scavenge hunt at https://git.devuan.org/devuan, https://git.devuan.org/devuan-infrastructure and https://git.devuan.org/devuan-packages would bring some nuggets for you; and if you'd then accrue notes on the what, how and where, it could yield a (new) "Devuan Package Maintainer Cheat Sheet" (or "Comprehensive Guide, Part 1", even), as well as corrections and updates to whatever documentation there is.