Hello:

You're welcome.

Before we continue:
When posting a terminal printout, for easier reading, the text must be placed between code blocks.
eg:

code
printout text goes here
/code

That way what the reader sees is this:

printout text goes here

You can generate a pair of code blocks by clicking on [ code ] while editing / replying.

---

Now, with respect to your reader:

--- snip ---
[ 1755.552055] usb 1-3: new high-speed USB device number 5 using xhci_hcd
[ 1755.803573] usb 1-3: New USB device found, idVendor=0dda, idProduct=2005, bcdDevice= 1.9c      ### <----
[ 1755.803584] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1755.803588] usb 1-3: Product: Hama Card Reader
[ 1755.803592] usb 1-3: Manufacturer: Hama Card Reader
[ 1755.803595] usb 1-3: SerialNumber: ABCD12345683
--- snip ---

1.
dmesg informs that your reader is id'd as idVendor=0dda, idProduct=2005, 0dda being the id of the OEM, Integrated Circuit Solution, Inc. and 2005 the id of their Datalux DLX-1611 16in1 Card Reader. In your case, it has been rebadged as a Hama Card Reader.

This means that you are not lacking a driver as it is recognised by the system and that the problem is (most probably) not the hardware.

--- snip ---
[ 1756.845648] scsi 9:0:0:0: Direct-Access     Hama     Card Reader   CF 1.9C PQ: 0 ANSI: 0 CCS
[ 1756.847337] scsi 9:0:0:1: Direct-Access     Hama     Card Reader   MS 1.9C PQ: 0 ANSI: 0 CCS
[ 1756.849084] scsi 9:0:0:2: Direct-Access     Hama     CardReaderMMC/SD 1.9C PQ: 0 ANSI: 0 CCS
[ 1756.850885] scsi 9:0:0:3: Direct-Access     Hama     Card Reader   SM 1.9C PQ: 0 ANSI: 0 CCS
--- snip ---

Here you see the different slots where the "35" are plugged in.
ie: CF, MMC/SD, MS, SM, etc.

Up to that point it seems that everything is as expected.

Q1: are you using a laptop/portable machine?
Q2: if so, were you running on main or battery power?
Q3: was there any card in the reader when you plugged it in?

If there was a card in the reader, please remove the card and repeat 2. without any cards in the reader.

ie:
sudo dmesg -w

... then plug in the reader and post the terminal printout as indicated.

Best,

A.

Hello:

Starts to make sense.

/etc/init.d/brightness.dpkg-dist belongs to what is today a Daedalus installation.

But (IIRC) started as Jessie (!) and was dist-upgraded to ASCII and eventually Beowulf.
Then to a backported kernel and when Beowulf was about to be archived, almost directly to Daedalus via Chimaera.
This because the XFCE upgrade in Chimaera generated a totally unusable desktop environment.

I have to say that compared to anything MS branded I have had to deal with, it was smooth as silk.  8^ )

I don't recall ever seeing brightness in the list of services printed out by service --status-all, much less messing with debconf which I don't have a clue about.

I checked my Asus 1000HE netbook (runs on a 32bit Chimaera) and service brightness status properly reports current and saved brightness and intel brightness levels and just like in my Chimaera VM, it cannot be stopped or started. But then it is only one LCD monitor, my Daedalus box runs three monitors with two NVidia cards with brightness levels controlled individually via the monitors' screen controls

My guess is that it does not report anything with service brightness status because it is a headless VM.
ie: no monitor.

So the problem (if one at all) would be the lack of a brightness service in my Daedalus installation, situation I cannot account for.
That said, besides the curiosity it generates, I have not experienced any issues.

No problem, I look around and see if I catch something worth reporting.
If not, I'll may well leave it at that.

Edit:
I just realised that Daedalus is the first version of Devuan in which I installed the nouveau drivers for my NVidia cards.
Had no choice as there was no clear way to get the OEM drivers working in Linux.

Maybe that has something to do with the module not being present?

Thanks for your input.

Best,

A.

Hello:

Of course ...  8^)

You and everyone else knowing how to do this properly.

Solved.
It was the lack of a comma between the commands.

# cat /etc/sudoers.d/user_eth0
groucho ALL=(ALL) NOPASSWD: /sbin/ifup eth0, /sbin/ifdown eth0
# 

~$ sudo ifdown eth0
Killed old client process
Internet Systems Consortium DHCP Client 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:14:4f:4a:a2:81
Sending on   LPF/eth0/00:14:4f:4a:a2:81
Sending on   Socket/fallback
DHCPRELEASE of 192.168.1.10 on eth0 to 192.168.1.1 port 67

~$ sudo ifup eth0
Internet Systems Consortium DHCP Client 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:14:4f:4a:a2:81
Sending on   LPF/eth0/00:14:4f:4a:a2:81
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPOFFER of 192.168.1.10 from 192.168.1.1
DHCPREQUEST for 192.168.1.10 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.1.10 from 192.168.1.1
/sbin/dhclient-script: 88: cannot create /etc/resolv.conf: Operation not permitted
bound to 192.168.1.10 -- renewal in 13983 seconds.
~$ 

So much then for visudo -c ...  8^°
After all, it is a syntax error.

Thank you very much for your input.

Best,

A.

Hello:

No need, I know how to blacklist a kernel module.
My question was not "how to blacklist a module" but how to I could find out why these modules are being loaded.

Because whatever EEPROM resides in my box* is ID'd as read-only and I have never had  a joystick attached/installed.
* same box since ~ 2015, running on Devuan since ~ 2017

Thanks for your input.

Best,

A.

Hello:

@fsmithred:
I think the OP makes reference to X (the social media thing) and Debian Publicity's presence there.
Not the X Window System we all love and cherish.

@blackhole:
+1

Best,

A.

Hello:

Update

@ralph.ronnquist

I went through the whole process again, exactly as detailed in my previous post.
As before, every part of the installer priming process worked exactly as you said it would, the result being as reported.

The only differences were that this time I used another (smaller) *.iso file (devuan_chimaera_4.0.0_amd64_netinstall.iso) and the target was the 4GB SDCard in a USB/SDCard adapter.

The installer was burned to the 8Gb Kingston DataTraveller 2.0 stick to risk only the low capacity SD card in case things went awry again.
The target SDCard was previously cleared, repatitioned and formatted to EXT-4 with the filesystem checked via gparted on my box.   

It was interesting to see that the EFI partition for this *.iso file is only 754 KB, a sharp contrast with the one in the daedalus/devuan_daedalus_5.0.1_amd64_netinstall.iso which has grown to a huge 23 MB.

Which begs the question: bloated by over 30X and on account of exactly what?

---

With everything as expected ...

    The Kingston DataTraveller 2.0 stick SD card, as listed by disks:

---
    Partition 1
    Size: 390 MB (390070272 bytes)
    Contents: ISO 9660 (version Joliet Extension) — Mounted at /media/groucho/Devuan 4.0
    Device: /dev/sdc1
    Partition Type: 0x00 (bootable)

    Partition 2
    Size: 754 KB -- 25 KB
    Contents: FAT (16-bit version) —  Mounted at /media/groucho/7E06-DA56
    Device: /dev/sdc2
    UUID: 7E06-DA56
    Partition Type: W95 FAT32 (LBA)

    Free Space: 3.4 GB

    Success:
    Partition 1 has retained its ISO9660 signature and Devuan 4.0 label.
---

... I went ahead with the installation as before, taking the usual precautions (*.iso file SHA256SUM and installation media check).
Everything worked as expected but the installer (as every other time) did not write GRUB where it was pointed to.

So I rebooted my box with the installer, dropped into rescue mode and not without some trepidation, installed GRUB to the target SDCard.

This time it worked.  8^)
Thank you ralph.ronnquist !

I was able to boot into a minimal Devuan Chimaera from which I now need to weed out all unnecessary applications and files.

Comments

I have no way of knowing what caused the sudden death of my 16Gb Kingston DataTraveller 2.0 (as described in another post).
It could could well be that it had been written to just one to many times.
Happens.

That said, the 8Gb Kingston DataTraveller 2.0 I used at the installer media this time has been in use for at least two/three years longer and it is still going strong.

One thing I can say is that the Debian installer in use at the moment by Devuan is not fit for purpose.
At least not for installing to a USB stick from a non-UEFI box to be used in a non-UEFI box.

Granted, mine may be a bit of a corner case: a user with a ca. 2007 Sun Ultra 24 WS which works perfectly well and does not have UEFI.
And absolutely no need for any forseeable hardware upgrades, save maybe a monitor or a drive.

This thread has had almost 900 views and no one has had much to say about the specifics exposed in it, so it would seem that I am indeed in a corner.

I cannot say for sure that this happens with every Devuan installer *.iso as I decided to use an older one because of its smaller size and the smaller size of the installation.

ie:
Devuan Chimaera netinstall *.iso: 372.00 MB - UEFI installer: 00.754 MB
Devuan Daedalus netinstall *.iso: 477.80 MB - UEFI installer:  23.00  MB

30X more code has been added to the UEFI partition on the road between Chimaera and Daedalus.

Does anyone really know exactly what all that added code does?

Today it is a 'bug' preventing a non-UEFI installation in a USB stick with a lot of hoops to jump through.
Tomorrow it may well be another 'bug' preventing a non-UEFI installation on a hard drive without certain 'characteristics'.
From there to not being able to install Linux on a non-UEFI box there is just a bit more MB of bloat in the installer's UEFI partition.

My sincere thanks to ralph.ronnquist for his knowledge (and patience) both of which are greatly appreciated.

Best,

A.

Hello:

No.

But it seems that I have not expressed myself correctly.
My apologies.

The installer USB is a 4Gb SD Card using a USB/SDCard adapter.
Works without issues.

The destination USB stick is a Kingston DataTraveller 16Gb USB2.0 which was ID'd as such by the installer all through the installation process, the last instance being when I selected it as the destination for GRUB.

Every part of the installer (ie: the 4GB SDCard) priming process worked exactly as you said it would, the result being as reported in a previous post:

The installer (ie: the 4GB SDCard) booted exactly as expected, passed the integrity check and went through the entire process without any issue whatsoever.

I have another one of these, a Kingston DataTraveller 8GB USB 2.0 stick I could try this out with or maybe another 4Gb SDCard and use the Kingston as the installer media.

It could well be that the previous Kingston USB stick failed because it was at EOL.
Or not, cannot say.

Let me know what you think.

Best,

A.

Hello:

Update

Right.

# dd if=/media/storage/isos/daedalus/devuan_daedalus_5.0.1_amd64_netinstall.iso of=/dev/sdc skip=1 seek=1 conv=notrunc
978559+0 records in
978559+0 records out
501022208 bytes (501 MB, 478 MiB) copied, 183.526 s, 2.7 MB/s
#

The SD card, as listed by disks:

Partition 1
Size: 478 MB (478150656 bytes)
Contents: ISO 9660 (version Joliet Extension) — Mounted at /media/groucho/DEVUAN501
Device: /dev/sdc1
Partition Type: 0x00 (bootable)

Partition 2
Size: 23 MB (22507520 bytes)
Contents: FAT (16-bit version) — Not Mounted
Device: /dev/sdc2
UUID: FAE4-C64A
Partition Type: W95 FAT32 (LBA)

Free Space: 3.4 GB

Success:
Partition 1 has retained its ISO9660 signature and DEVUAN501 label.
Thank you for that.

Now to see if the installer works as expected.
ie: instead of assuming that my box has a UEFI BIOS and screwing everything up in the process.

Best,

A.