Yes, it would be nice to have a built-in option. As is, one has to resort to manual output filtering, e.g. by adding

 | sed "/^  /{s/\\b /\n  /g}"

to the command. That merely "pretty-prints" and doesn't provide the version details.

hmm; don't you think the silent "non-" could be confusing for a casual visitor ?

I think synclient has an option to disable the "TouchPad" - see man synaptics. Though that might be co-joined with the nipple as well.

It's a good observation. The ISO sets of 2.0.0 and 2.1 where produced in different ways, and obviosuly the 2.1 method is somewhat lacking in care. A re-release of the latter would indeed be a good thing.

thanks,

Ralph.

ah right. I'm still in the ipv4 universe. lucky me

EDIT:

"onefang", who does ipv6 in his sleep, suggests that there probably are some networking issues at the client end, and that an investigation with traceroute, or traceroute6 I suppose, might tell something.

When your SSL client says the above, most likely the actual response from dev1galaxy is (in clear text):

Your IP address has been tagged as dubious. If this is in error,
please contact dev1galaxy forum adminstrators on #d1g-users at freenode.

Like many/most forum sites, dev1galaxy includes a couple of attempted barriers against spam and unwanted intrusions, which results in IP addresses becoming tagged as "dubious". Due to being fully automated, it sometimes (but rarely) makes a false positive judgement, and then it requires some corrective hands-on.

Perhaps it's worth trying an extlinux boot rather than grub. There's an excellent instruction for this at https://wiki.syslinux.org/wiki/index.php?title=EXTLINUX, and in general it involves 3 steps:

1. install the extlinux package

2. run its boot loader installer (which replaces grub's boot loader on MBR)

3. prepare the boot configuration for your system

Notionally it follows the same procedure as a grub boot; that the boot loader loads the configuration file, which points out where the kernel and initrd are found, and then it runs that kernel. The differences between them are probably plenty in the nitty-gritty, most of which I don't know anything about.

For your system, I think the configuration file /boot/extlinux/extlinux.conf could be along the lines of

DEFAULT Devuan
SAY Now booting Devuan using exlinux just like Ralph said...
LABEL Devuan
    KERNEL /vmlinuz
    APPEND ro root=/dev/sda1 initrd=/initrd.img vga=auto nomodeset

Check out https://wiki.syslinux.org/wiki/index.php?title=Config for details and extras. Note that I dropped in a nomodeset kernel boot parameter just for illustration.

extlinux and grub are alternative bootstrap solutions, and while you may have them both installed in the sense of their software and configurations residing on the file system, the one whose boot loader gets installed to MBR (i.e., disk block zero) is the ruling one, and you may as well purge the one you are not using. As always with these things, some people prefer the one and others prefer the other, and many people don't care either way as long as it works.

Final note: the installation disk probably uses extlinux.

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.