Download | Devuan.org | Git | Bugs | Packages

The officially official Devuan Forum!

You are not logged in.

Pages: 1 … 12 13 14 15 16 … 79

#326 Re: Hardware & System Configuration » Brightness module? » 2025-03-10 18:23:08

Altoid

Hello:

fsmithred wrote:

brightness.dpkg-dist is the saved copy of a new config file when the old one was kept in place

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^ )

... if you have brightness.dpkg-dist but not brightness, then something is wrong.

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.

fsmithred wrote:

Sorry, I have no other answers.

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.

#327 Re: Hardware & System Configuration » Brightness module? » 2025-03-10 12:06:47

Altoid

Hello:

fsmithred wrote:
$ apt-file find init.d/brightness

Yes, I had already found it there.

My Daedalus installation also has it:

~$ locate brightness
/etc/init.d/brightness.dpkg-dist
/etc/systemd/system/brightness.service
--- snip --- 
~$

But it is not a in the service status printout:

~$ sudo service --status-all | grep brightness
 [ ? ]  alsa-utils
 [ ? ]  binfmt-support
 [ ? ]  hwclock.sh
 [ ? ]  kmod
 [ ? ]  lpd
 [ ? ]  mount-configfs
 [ ? ]  networking
 [ ? ]  vboxautostart-service
~$

Q1: why do all these other services show up when I am not asking grep to find them?

Then this is the script I find in /etc/init.d:

~$ ls /etc/init.d/ | grep brightness
brightness.dpkg-dist
~$

Q2: why it is being started in my Chimaera headless VM but not in my Daedalus desktop installation?

The Chimaera VM does not have the same name for the /etc/init.d/brightness.dpkg-dist script.

root@chimaera:~# ls /etc/init.d | grep brightness
brightness
root@chimaera:~#

 

The script in the Chimaera VM indicates the usage:

root@chimaera:~# cat /etc/init.d/brightness
#!/bin/sh
### BEGIN INIT INFO
# Provides:          brightness
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     S
# Default-Stop:      0 6
# Short-Description: Save and restore brightness level between restarts.
# Description:       This script saves the brightness level between restarts.
#                    It is called from the boot, halt and reboot scripts.
### END INIT INFO

readonly SAVEFILE_PREFIX=/var/lib/initscripts/brightness

. /lib/init/vars.sh
. /lib/lsb/init-functions

do_invoke() {
	local rv=0 rc
	# ACPI (without explicit label)
	do_$1 '' \
	    /sys/class/backlight/acpi_video0/brightness \
	    /sys/class/backlight/acpi_video0/max_brightness
	rc=$?
	test $rc -lt $rv || rv=$rc
	# Intel
	do_$1 intel \
	    /sys/class/backlight/intel_backlight/brightness \
	    /sys/class/backlight/intel_backlight/max_brightness
	rc=$?
	test $rc -lt $rv || rv=$rc
	# could insert others using the same scheme here
	return $rv
}

do_status() {
	local label=$1 knob=$2 max=$3 file=$SAVEFILE_PREFIX${1:+.$1}
	test -e "$knob" || return 0

	MSG="Current${label:+ $label} brightness level is $(cat "$knob")"
	if test -f "$file"; then
		log_success_msg "${MSG}, saved value is $(cat "$file")"
		return 0
	fi
	log_failure_msg "${MSG}, there is no saved value"
	return 4
}

do_start() {
	local label=$1 knob=$2 max=$3 file=$SAVEFILE_PREFIX${1:+.$1}
	test -e "$knob" || return 0

	test x"$VERBOSE" = x"no" || \
	    log_action_begin_msg Initialising $label brightness level

	if test -f "$file"; then
		cat "$file" >"$knob"
	else
		cat "$max" >"$knob"
	fi
	local rv=$?
	test x"$VERBOSE" = x"no" || log_action_end_msg $rv
	return $rv
}

do_stop() {
	local label=$1 knob=$2 max=$3 file=$SAVEFILE_PREFIX${1:+.$1}
	test -e "$knob" || return 0

	test x"$VERBOSE" = x"no" || \
	    log_action_begin_msg Saving $label brightness level
	cat "$knob" >"$file"
	local rv=$?
	test x"$VERBOSE" = x"no" || log_action_end_msg $rv
	return $rv
}

case $1 in
(start|restart|reload|force-reload)
	do_invoke start
	;;
(stop)
	do_invoke stop
	;;
(status)
	do_invoke status
	;;
(*)
	echo >&2 "Usage: $0 {start|stop|restart|reload|force-reload|status}"   ##########   <----
	exit 3
	;;
esac
root@chimaera:~#

What is going on?

Best,

A.

#328 Hardware & System Configuration » Brightness module? » 2025-03-10 09:05:32

Altoid
Replies: 9

Hello:

I run Pi-hole in a headless Devuan Chimaera VM in my box:

root@chimaera:~# uname -a
Linux chimaera 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
root@chimaera:~#

The last Pi-hole upgrade (to 6.0.4) had a small issue and I had to remove the apparmor service (which was not running) for the upgrade to complete properly. Jury is still out there as to what was going on so it is a matter to be dealt with in another thread.

The thing is that while going over the service status list I found one which I did not know about and had never seen before:

root@chimaera:~# service --status-all
--- snip ---
 [ - ]  brightness
--- snip ---
root@chimaera:~#

I have no idea how it got there.

I see it is all over:

root@chimaera:~# locate brightness
/etc/init.d/brightness
/etc/rc0.d/K01brightness
/etc/rc6.d/K01brightness
/etc/rcS.d/S12brightness
/etc/systemd/system/brightness.service
/usr/src/linux-headers-5.10.0-9-amd64/include/config/leds/brightness
/usr/src/linux-headers-5.10.0-9-amd64/include/config/leds/brightness/hw
/usr/src/linux-headers-5.10.0-9-amd64/include/config/leds/brightness/hw/changed.h
root@chimaera:~#

But this is a headless VM installation and I never installed a desktop.
And it is certainly not a laptop.

The problem is that I cannot get rid of it.
Or do anything with it:

root@chimaera:~# service brightness status
root@chimaera:~# 
root@chimaera:~# service brightness start
root@chimaera:~# 
root@chimaera:~# service brightness stop
root@chimaera:~#

Where did this come from?
How can I get rid of it?

Best,

A.

#329 Re: Forum Feedback » I can't believe you closed the Joke thread. » 2025-02-28 10:55:11

Altoid

Hello:

golinux wrote:

Temporarily closing that thread ...

If you were to ask me (which you did not) I'd say it can stay that way.

Camtaf wrote:

No loss ...
... only once looked in to see ...

Yes, same here.
Just once.

I get my dose of humour here.

As always, YMMV.

Best,

A.

#330 News & Announcements » Chrome based browsers and uBlock Origin » 2025-02-24 18:44:28

Altoid
Replies: 35

Hello:

From today's edition of The Register:

Richard Speed @theregister.com wrote:

uBlock Origin dead for many as Google purges Manifest v2 extensions
Chrome ad blocker stopped working? Time to look elsewhere

Best,

A.

#331 Re: Hardware & System Configuration » ddr3 sdram upgrade » 2025-02-24 12:58:39

Altoid

Hello:

... ddr3 sdram for my old lenovo w530 pc ...

Check the manual, specifically pages 13 and 82.

Edit:
You may also want to read this post at one of the better known thinkpad forums.

Best,

A.

#332 Re: Hardware & System Configuration » [SOLVED] sudoers.d file for ifup / ifdown » 2025-02-20 16:56:25

Altoid

Hello:

fsmithred wrote:

... log out and log in ...

Of course ...  8^)

fsmithred wrote:

I use commas ...

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.

#333 Re: Hardware & System Configuration » [SOLVED] sudoers.d file for ifup / ifdown » 2025-02-20 16:41:28

Altoid

Hello:

rolfie wrote:

Give that ...

Nope, no dice.

# cat /etc/sudoers.d/user_eth0
groucho ALL=(root) NOPASSWD: /sbin/ifup eth0  /sbin/ifdown eth0
# 
~$ sudo ifdown eth0
--- snip ---
Sorry, user groucho is not allowed to execute '/sbin/ifdown eth0' as root on localhost.
~$ 
~$ sudo ifup eth0
--- snip ---
Sorry, user groucho is not allowed to execute '/sbin/ifup eth0' as root on localhost.
~$

BTW: found this -> https://hackliza.gal/en/posts/cambiar_dns_linux/ to chew on
Never saw it before, probably because I was looking for /etc/resolv.conf in relation to connman or network-manager.

Thanks for your input.

Best,

A.

#334 Hardware & System Configuration » [SOLVED] sudoers.d file for ifup / ifdown » 2025-02-20 13:31:15

Altoid
Replies: 4

Hello:

Finally got fed up and decided to ditch connman and as there is no WiCD for the foreseable future (if there is such a thing), went for the time proven ifup / ifdown solution.

One less layer of abstraction or so it is said, can't be a bad thing.

To test things out, I disabled connman, checked all settings and verified that ifup eth0 and ifdown eth0 (as root) worked properly.
My cable connection comes up at boot time as expected.

But at one point I realised that, in spite of what my /etc/resolv.conf file read, I was back at my ISPs cable provider's DNS, so I ran chattr +i /etc/resolv.conf and that was it. Evidently ditching connman was not the solution.

And (by chance) I was actually able to verify it:

1. take down the connection:

# /sbin/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
# 
[code]

2. bring up the connection:

[/code]
# /sbin/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 3
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
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  ### WTHF is *this*?

bound to 192.168.1.10 -- renewal in 12402 seconds.
#

Obviously, chattr +i /etc/resolv.conf was working properly.

I then opened up /sbin/dhclient-script to have a look.
Not in any way script savvy but this part of it immediately called my attention:

--- snip ---
# update /etc/resolv.conf based on received values     <---- #######?
  make_resolv_conf() {
      local new_resolv_conf
--- snip ---

According to jed, the whole snippet would be from line 39 to line 125 and it would seem (?) to be the routine that constantly overwrites /etc/resolv.conf.

Anyone have an idea on this?
I thought that disabling the connman service would be a solution but ...

But I digress ...
In order to avoid having to bring down the connection without being root, I made a file in /etc/sudoers.d:

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

But it does not work and I don't understand why.

~$ sudo ifup
--- snip ---
Sorry, user groucho is not allowed to execute '/sbin/ifup' as root on localhost.
~$
~$ sudo ifdown
--- snip ---
Sorry, user groucho is not allowed to execute '/sbin/ifdown' as root on localhost.
~$

The file syntax is correct:

# visudo -c
--- snip ---
/etc/sudoers.d/user_eth0: parsed OK
--- snip ---
#

I then checked and saw that /sbin/ifup is a (dynamically linked) executable and that /sbin/ifdown is a symbolic link to /sbin/ifup but I have no idea how to get around that.

That said, I'd appreciate pointers on how to get the /etc/sudoers.d file working.

Best,

A.

#335 Re: Hardware & System Configuration » Devuan Daedalus: /i386-pc/normal.mod not found » 2025-02-19 18:48:04

Altoid

Hello:

Update:

Altoid wrote:

... no way of knowing what caused the sudden death ...

Before opening it up, I decided to have a forensic look at the failed USB stick.

Always reported in dmesg as a Kingston DataTraveler 2.0 device, after going south it was reported as a GENERIC USB Mass Storage device, but there was also idVendor and idProduct data which I had not had a close look at.

--- snip ---
[12061.088773] usb 2-1.3: new high-speed USB device number 18 using xhci_hcd
[12061.216524] usb 2-1.3: New USB device found, idVendor=0c76, idProduct=0005, bcdDevice= 1.00
[12061.216531] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12061.216535] usb 2-1.3: Product: USB Mass Storage
[12061.216538] usb 2-1.3: Manufacturer: GENERIC
[12061.221201] usb-storage 2-1.3:1.0: USB Mass Storage device detected
[12061.221381] scsi host8: usb-storage 2-1.3:1.0
[12062.249584] scsi 8:0:0:0: Direct-Access     GENERIC  USB Mass Storage 1.00 PQ: 0 ANSI: 4 CCS
[12062.249852] scsi 8:0:0:0: Attached scsi generic sg6 type 0
[12062.250232] sd 8:0:0:0: [sdg] Media removed, stopped polling
[12062.250651] sd 8:0:0:0: [sdg] Attached SCSI removable disk
--- snip ---

According to devicehunt.com:

idVendor=0c76    -> JMTek, LLC.
idProduct=0005    -> Transcend Flash disk

Not Kingston hardware.
Or so it would seem.

Unfortunately I don't have a complete dmesg printout for the USB stick before it failed, so I cannot say if it was reported with the proper id* codes but I am absolutely sure that it was reported as a Kingston DataTraveler 2.0 device and these should have been idVendor=0951, idProduct=1665.

So there may be a good chance that the dead USB stick may have not been a genuine Kingston device, hence its early? demise.
All I can say for it is that it worked perfectly well for many years.

Best,

A.

#336 Re: Hardware & System Configuration » Loading unneeded modules? » 2025-02-11 16:57:40

Altoid

Hello:

stopAI wrote:

... read Debian wiki ...

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.

#337 Hardware & System Configuration » Loading unneeded modules? » 2025-02-11 15:35:59

Altoid
Replies: 2

Hello:

Running on Devuan Daedalus:

~$ uname -a
Linux devuan 6.1.0-31-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.128-1 (2025-02-07) x86_64 GNU/Linux
~$

At boot, dmesg prints out this:

~$ sudo dmesg
--- snip ---
[   24.257488] at24 0-0050: supply vcc not found, using dummy regulator
[   24.260227] at24 0-0050: 256 byte spd EEPROM, read-only
[   24.260817] at24 0-0051: supply vcc not found, using dummy regulator
--- snip ---
[   24.263031] at24 0-0051: 256 byte spd EEPROM, read-only
[   24.263475] at24 0-0052: supply vcc not found, using dummy regulator
[   24.264991] at24 0-0052: 256 byte spd EEPROM, read-only
[   24.265389] at24 0-0053: supply vcc not found, using dummy regulator
[   24.266865] at24 0-0053: 256 byte spd EEPROM, read-only
~$

And lsmod prints out this:

~$ lsmod
--- snip ---
joydev                 28672  0
--- snip ---
at24                   28672  0
--- snip ---
~$ lsmod

From what I understand (?) the at24 cannot be used in my system.
ie: 256 byte spd EEPROM, read-only

The kernel config file says ...

~$ cat /boot/config-6.1.0-31-amd64 | grep -i at24
CONFIG_EEPROM_AT24=m
~$

... that it is loaded as a module.

Same as joydev:

~$ cat /boot/config-6.1.0-31-amd64 | grep -i joydev
CONFIG_INPUT_JOYDEV=m
~$

The MB surely has an EEPROM, albeit read-only which the installer probably cannot ID as such.

With respect to joydev, I looked it up and it seems to be for joystick support which I don't need.
How can I find out if something in my box uses it?

If possible, I would like to keep those unused modules from loading.

Best,

A.

#338 Off-topic » Microcode » 2025-02-10 18:31:55

Altoid
Replies: 1

Hello:

A very interesting opinion article from The Register.

Rupert Goodwins @The Register wrote:

The biggest microcode attack in our history is underway
When your state machines are vulnerable, all bets are off

Best,

A.

#339 Re: Installation » Unable to install from the Excalibur netinstall ISO » 2025-02-05 11:50:40

Altoid

Hello:

Lauwenmark wrote:

... result of using the ISO netinstall image ...

I recently had a very hard time with a couple of netinstall *.iso images, devuan_chimaera_4.0.0_amd64_netinstall.iso and daedalus/devuan_daedalus_5.0.1_amd64_netinstall.iso while attempting to install a basic Devuan to a small capacity USB stick.

Have a read here to see how I finally managed to get it done.
Dev1 admin's help was crucial, no way I would have found a way out of the problem I was having.

The thing is that (IMO) the Debian installer (not forked by Devuan) definitely has something wrong with it.
I seriously doubt the Debian devs will do anything about it.

I assume that you have already tried basic dd'ing the *.iso to a USB stick (no Ventoy, etc.), with the usual precautions.
ie: *.iso file SHA256SUM prior to burning to USB and installation media check before proceding with the installation.

I so, check here to see the process which allowed me to get the installer to start working.
And even so, it refused to write GRUB to the indicated location so I had to reboot the installer, drop to rescue mode and install it by hand.

While my box is a standard BIOS boot / non-UEFI workstation, it may solve your problem.

Please keep us posted on how you fare with this.

Best,

A.

#340 Re: Off-topic » Statement regarding X community » 2025-01-30 23:07:05

Altoid

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.

#341 Re: Devuan » Update of Devuan causes VirtualBox shared folder corruption » 2025-01-28 22:35:01

Altoid

Hello:

Welcome to Dev1.

dftd wrote:

... using Chimaera (within VirtualBox on Win 10 system) ...

You run a Win10 box + VirtualBox 7.0 to run Devuan Chimaera VM?

It is not quite clear to me where the problem lies but it would seem that it is with VirtualBox.
If the issues are indeed with VirtualBox, I'd say that it is something to ask about either in a Win10 or VBox forum.

That said, you may want to consider running a Devuan box + VirtualBox and then drop in whatever VM you want to run.
I would not trust any MSOS box to run my VMs in, but maybe that's just me getting old. 8^°

As always, YMMV.

I have been running VirtualBox in my Devuan installations to host three VMs since Devuan ascii: W98 for a pair of applications I cannot replace and two Devuan Linux, one to run a PiHole+ a recursive DNS and another for testing purposes and such.

Never had any problems.

Best,

A.

Edit: do take 5' to read this article.

#342 Re: Hardware & System Configuration » Devuan Daedalus: /i386-pc/normal.mod not found » 2025-01-22 11:38:49

Altoid

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.

#343 Re: Hardware & System Configuration » Devuan Daedalus: /i386-pc/normal.mod not found » 2025-01-21 10:48:08

Altoid

Hello:

... oldish cards or drives can't deal with GPT partition table ...

Nice way to generate landfill.
And force compliance.

... check that by trying again with the first card but then make sure to create a DOS table on it before partitioning.

The USB stick I used as the installation target had been previously partitioned and formatted on my main Daedalus box using gparted.

To do so, I first deleted all previous partitions by first formatting them as cleared then deleting them and creating a new ms-dos partiton table prior to partitioning and formatting as required. ie: / and an extended partition with a logical /home and /swap.

/ and /home filesystems were checked and passed.

So the installer had no hand in all that, on installation I chose both the drive and the partitions to be used.

Use expert mode with activated lowest possible priority level, or perhaps use ctrl-f2 shell and fdisk

I'm sorry, you lost me there.

Use the installer to partition and format the target SDCard?

... usb sticks that don't support boot setup ...

I recall having used the dead Kingston USB stick as a boot disk (no EFI) at some time or another.
No problem.

Thanks for the quick reply.

Best,

A.

#344 Re: Hardware & System Configuration » Devuan Daedalus: /i386-pc/normal.mod not found » 2025-01-21 09:59:29

Altoid

Hello:

... try to install onto that third partition of the installer USB ...

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:

Altoid wrote:

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.

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.

#345 Re: Hardware & System Configuration » Devuan Daedalus: /i386-pc/normal.mod not found » 2025-01-21 02:58:30

Altoid

Hello:

Altoid wrote:

... if the installer works as expected.
... and screwing everything up in the process.

An incredibly accurate description of what transpired.

After, clearing and reformatting a 14Gb USB stick, I booted the installer and after selecting language, keyboard and checking the installation media, continued with no issues.

Once the installation was finished, I rebooted my box and F8'ed my way into the boot menu where I selected the USB stick to boot from.

I felt something was not right when the boot menu listed the USB stick as 'Generic USB Mass Storage' instead of 'Kingston DataTraveller 2.0'.
And wrong it was: my box did not boot into the system installed on the USB stick but into its own system.
ie: no OS by the BIOS

"No matter, we've been here before.
I'll just boot into rescue, install GRUB and see what happens" I said to myself.

File manager showed me nothing so I checked with dmesg and there is was:

[  ] usb 4-1.3: new high-speed USB device number 4 using xhci_hcd
[  ] usb 4-1.3: New USB device found, idVendor=0c76, idProduct=0005, bcdDevice= 1.00
[  ] usb 4-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  ] usb 4-1.3: Product: USB Mass Storage
[  ] usb 4-1.3: Manufacturer: GENERIC 
[  ] usb-storage 4-1.3:1.0: USB Mass Storage device detected
[  ] scsi host7: usb-storage 4-1.3:1.0
[  ] scsi 7:0:0:0: Direct-Access     GENERIC  USB Mass Storage 1.00 PQ: 0 ANSI: 4 CCS
[  ] sd 7:0:0:0: Attached scsi generic sg2 type 0
[  ] sd 7:0:0:0: [sdc] Media removed, stopped polling        
[  ] sd 7:0:0:0: [sdc] Attached SCSI removable disk

But the 'Media removed' bit did not look good.

I then checked with fdisk ...

# fdisk /dev/sdc -l
fdisk: cannot open /dev/sdc: No medium found
#

... and with blkid:

# blkid | grep sdc
#

gparted does not register /dev/sdc and disks sees it as No Media.

I'd say the installer got angry and nuked the USB stick.

No Media is what I get from disks when I plug in a USB/SD Card adapter with no card inserted.

A USB/SD Card adapter with no card inserted gets the same response from dmesg and fdisk as what I am getting with the USB stick.

It is important to note that the installaton started and continued till the end without issues, selecting the USB stick as destination (/dev/sdc) for GRUB which was correctly identified as 'Kingston DataTraveller 2.0'.

So up to that point, things were looking quite normal.

---
Something is definitely wrong with the installer, the worst that should have happened is that the installation failed.
What has to be done to nuke a USB stick in this manner?

I'll see what testdisk says.

Any ideas?

Best,

A.

#346 Re: Hardware & System Configuration » Devuan Daedalus: /i386-pc/normal.mod not found » 2025-01-20 23:26:40

Altoid

Hello:

Update

... get this done today ...

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.

#347 Re: Hardware & System Configuration » Devuan Daedalus: /i386-pc/normal.mod not found » 2025-01-20 16:03:47

Altoid

Hello:

... how I could have imagined something ...

If I told you about the things I have imagined that were not there ...

No matter, everything is in order and fdisk does not give us another issue to tangle with.

... restore the disk image apart from the first sector after having changed the partition table.

Let me see if I have this right:

1. burn the *.iso image to the SD card as before.
2. change the partition table as per your instructions.
3. do this ...

dd if=devuan_daedalus_5.0.1_amd64_netinstall.iso of=/dev/sdg skip=1 seek=1 conv=notrunc

... which will restore the ISO9660 signature and DEVUAN501 label to the first partition so that disks will show this ...

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

... and make it visible to the installer.

All that plus the renaming the EFI directories / files so that the it will work (?) properly.

... apologise for making this so confusing and convoluted.

Absolutely no need to apologise for anything.
You have been nothing but helpful and patient.

Confusing and convoluted seems to be the crap Debian installer which should work as expected but does not.
Probably by design more than by incompetence, but that is just me being overy sceptical.

I'll try to get this done today and report back.

Once again, thank you for your help with this.

Best,

A.

#348 Re: Hardware & System Configuration » Devuan Daedalus: /i386-pc/normal.mod not found » 2025-01-20 12:52:11

Altoid

Hello:

... peculiar that partition 1 (and the disk) loses its label....

Yes, and with the same fdisk version.

... had it mounted(!) when changing parition table.

Yes ... 8^°

It got remounted when I unmounted, ejected and inserted it again.
Did not notice.

But then, I think the only partition mounted was Partition 2.
As seen by disks:   <- gparted does not reveal it

---
Partition 2
Size: 23 MB (22507520 bytes)
Contents: FAT (16-bit version) — Not Mounted
Device: /dev/sdg2
UUID: FAE4-C64A
Partition Type: EFI (FAT-12/16/32)
---

The partition we were editing was not mounted. (IIRC)
I think that if it had been mounted fdisk would have printed out a warning.

... not a good idea.

Indeed, fdisk says so.
But then it also says 'probably'.

... re-run the test without that?

Of course.
I saw the error right after posting so I rewrote the *.iso file and reedited the partition like before.

The end result was the same.

---

# blkid /dev/sdg
/dev/sdg: PTUUID="3488f3e0" PTTYPE="dos"
# 
# blkid /dev/sdg1
/dev/sdg1: PTUUID="3488f3e0" PTTYPE="dos" PARTUUID="3488f3e0-01"
# 
# blkid /dev/sdg2
/dev/sdg2: SEC_TYPE="msdos" UUID="FAE4-C64A" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3488f3e0-02"
# 
# blkid /dev/sdg3
/dev/sdg3: PARTUUID="3488f3e0-03"
#

What could / would prevent fdisk to make good on its warning?

Thanks for your input.

Best,

A.

#349 Re: Hardware & System Configuration » Devuan Daedalus: /i386-pc/normal.mod not found » 2025-01-20 11:37:51

Altoid

Hello:

Sorry for the delay, I re-did the testing as the SD card had been used in another test.

Note:
My Daedalus fdisk version is 2.38.1-5+deb12u1devuan1

Here it is, from the start:

----

Kingston 4.0GB SD Card
Formatted as 'Cleared'

Listed by gparted:
Size: 3.64 GiB
File system: unallocated

Partition
Path: unallocated    First sector:  0
                    Last sector:   7626751
                    Total sectors: 7626752
Listed by disks:
Size: 3.9 GB (3904897024 bytes)
Contents: 3.9 GB (3904897024 bytes)
Device: 3.9 GB (3904897024 bytes)

---

Writing *.iso image to SD card:

# dd if=/media/storage/isos/daedalus/devuan_daedalus_5.0.1_amd64_netinstall.iso of=/dev/sdg
978560+0 records in
978560+0 records out
501022720 bytes (501 MB, 478 MiB) copied, 228.066 s, 2.2 MB/s
#

Detected by dmesg:

$ sudo dmesg
--- snip ---
[ ] usb 6-6: new high-speed USB device number 7 using ehci-pci
[ ] usb 6-6: New USB device found, idVendor=14cd, idProduct=125d, bcdDevice= 1.00
[ ] usb 6-6: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ ] usb 6-6: Product: Mass Storage Device
[ ] usb 6-6: Manufacturer: Generic
[ ] usb 6-6: SerialNumber: 125D20140310
[ ] usb-storage 6-6:1.0: USB Mass Storage device detected
[ ] scsi host8: usb-storage 6-6:1.0
[ ] scsi 8:0:0:0: Direct-Access     Mass     Storage Device        PQ: 0 ANSI: 0 CCS
[ ] sd 8:0:0:0: Attached scsi generic sg6 type 0
[ ] sd 8:0:0:0: [sdg] 7626752 512-byte logical blocks: (3.90 GB/3.64 GiB)
[ ] sd 8:0:0:0: [sdg] Write Protect is off
[ ] sd 8:0:0:0: [sdg] Mode Sense: 03 00 00 00
[ ] sd 8:0:0:0: [sdg] No Caching mode page found
[ ] sd 8:0:0:0: [sdg] Assuming drive cache: write through
[ ]  sdg: sdg1 sdg2
[ ] sd 8:0:0:0: [sdg] Attached SCSI removable disk
$

blkid output:

# blkid /dev/sdg
/dev/sdg: BLOCK_SIZE="2048" UUID="2023-09-14-08-09-20-00" LABEL="DEVUAN501" TYPE="iso9660" PTUUID="3488f3e0" PTTYPE="dos"
#
# blkid /dev/sdg1
/dev/sdg1: BLOCK_SIZE="2048" UUID="2023-09-14-08-09-20-00" LABEL="DEVUAN501" TYPE="iso9660" PTUUID="3488f3e0" PTTYPE="dos" PARTUUID="3488f3e0-01"
#

Listed by gparted:
Size: 3.64 GiB
File system: iso9660
Label: DEVUAN501

Partition
Path: unallocated    First sector:  0
                    Last sector:   7626751
                    Total sectors: 7626752

Listed by disks:

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

Partition 2
Size: 23 MB (22507520 bytes)
Contents: FAT (16-bit version) — Not Mounted
Device: /dev/sdg2
UUID: FAE4-C64A
Partition Type: EFI (FAT-12/16/32)

Free Space: 3.4 GB

---

*****
Edit Partition 1 with fdisk as per your instructions.
*****

# fdisk -V
fdisk from util-linux 2.38.1
#
# fdisk -l
--- snip ---
Disk /dev/sdg: 3.64 GiB, 3904897024 bytes, 7626752 sectors
Disk model: Storage Device
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: 0x3488f3e0

Device     Boot  Start    End Sectors  Size Id Type
/dev/sdg1  *         0 933887  933888  456M  0 Empty
/dev/sdg2       933888 977847   43960 21.5M ef EFI (FAT-12/16/32)
#
# fdisk /dev/sdg

Welcome to fdisk (util-linux 2.38.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.

The device contains 'iso9660' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.

Command (m for help): t
Partition number (1,2, default 2): 2
Hex code or alias (type L to list all): c

Changed type of partition 'EFI (FAT-12/16/32)' to 'W95 FAT32 (LBA)'.

Command (m for help): n
Partition type
   p   primary (2 primary, 0 extended, 2 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (3,4, default 3): 3
First sector (977848-7626751, default 978944):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (978944-7626751, default 7626751):

Created a new partition 3 of type 'Linux' and of size 3.2 GiB.

Command (m for help): w
The partition table has been altered.
Syncing disks.
#

Detected by dmesg:

$ sudo dmesg
--- snip ---
[ ] usb 6-6: new high-speed USB device number 8 using ehci-pci
[ ] usb 6-6: New USB device found, idVendor=14cd, idProduct=125d, bcdDevice= 1.00
[ ] usb 6-6: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ ] usb 6-6: Product: Mass Storage Device
[ ] usb 6-6: Manufacturer: Generic
[ ] usb 6-6: SerialNumber: 125D20140310
[ ] usb-storage 6-6:1.0: USB Mass Storage device detected
[ ] scsi host8: usb-storage 6-6:1.0
[ ] scsi 8:0:0:0: Direct-Access     Mass     Storage Device        PQ: 0 ANSI: 0 CCS
[ ] sd 8:0:0:0: Attached scsi generic sg6 type 0
[ ] sd 8:0:0:0: [sdg] 7626752 512-byte logical blocks: (3.90 GB/3.64 GiB)
[ ] sd 8:0:0:0: [sdg] Write Protect is off
[ ] sd 8:0:0:0: [sdg] Mode Sense: 03 00 00 00
[ ] sd 8:0:0:0: [sdg] No Caching mode page found
[ ] sd 8:0:0:0: [sdg] Assuming drive cache: write through
[ ]  sdg: sdg1 sdg2 sdg3
[ ] sd 8:0:0:0: [sdg] Attached SCSI removable disk
$

blkid output:

# blkid /dev/sdg
/dev/sdg: PTUUID="3488f3e0" PTTYPE="dos"
#
# blkid /dev/sdg1
/dev/sdg1: PTUUID="3488f3e0" PTTYPE="dos" PARTUUID="3488f3e0-01"
#
# blkid /dev/sdg2
/dev/sdg2: SEC_TYPE="msdos" UUID="FAE4-C64A" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3488f3e0-02"
#
# blkid /dev/sdg3
/dev/sdg3: PARTUUID="3488f3e0-03"
#

Listed by gparted:
Size: 3.64 GiB

File System
File system: unallocated
Size: 456.00 MiB
Path: unallocated
First sector: 0
Last sector: 933887
Total sectors: 933888

File system: fat16
Size: 21.46 MiB
Label:
UUID: FAE4-C64A

Partition
Path: /dev/sdg2
Name:
Flags: lba
First sector: 933888
Last sector: 977847
Total sectors: 43960

File system: unknown
Size: 3.17 GiB
Label:
UUID:

Partition
Path: /dev/sdg3
Name:
Flags:
First sector: 978944
Last sector: 7626751
Total sectors: 6647808

---

Listed by disks:

Unallocated space
478 MB (478150656 bytes)
Device: /dev/sdg

Filesystem
Partition 2
Size: 23 MB — 2.1 MB free (90.8% full)
Contents: FAT (16-bit version) — Mounted at /media/groucho/FAE4-C64A
Device: /dev/sdg2
UUID: FAE4-C64A
Partition Type: W95 FAT32 (LBA)

Partition 3
Size: 3.4 GB (3403677696 bytes)
Contents: Unknown
Device: /dev/sdg3
Partition Type: Linux

---

I only have one other Linux box to check this:

$ uname -a
Linux eee-dev3 5.10.0-0.deb10.16-686-pae #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) i686 GNU/Linux
$
# fdisk -V
fdisk from util-linux 2.33.1
#
$ sudo fdisk -l
--- snip ---
Disk /dev/sdb: 3.7 GiB, 3904897024 bytes, 7626752 sectors
Disk model: Storage Device
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: 0x3488f3e0

Device     Boot  Start     End Sectors  Size Id Type
/dev/sdb1  *         0  933887  933888  456M  0 Empty
/dev/sdb2       933888  977847   43960 21.5M  c W95 FAT32 (LBA)
/dev/sdb3       978944 7626751 6647808  3.2G 83 Linux

$ sudo blkid /dev/sdb
/dev/sdb: PTUUID="3488f3e0" PTTYPE="dos"
$
$ sudo blkid /dev/sdb1
/dev/sdb1: PTUUID="3488f3e0" PTTYPE="dos" PARTUUID="3488f3e0-01"
$
groucho@eee-dev3:~$ sudo blkid /dev/sdb2
/dev/sdb2: SEC_TYPE="msdos" UUID="FAE4-C64A" TYPE="vfat" PARTUUID="3488f3e0-02"
$
sudo blkid /dev/sdb3
/dev/sdb3: PARTUUID="3488f3e0-03"
$

Sorry for the length but I wanted to get everything from the screen printout as it happened, from the start and not have to come and go from other posts.
Please let me know if you need more data.

Thank you for your help.

Best,

A.

#350 Re: Off-topic » Getting there, slowly but steadily ... » 2025-01-19 21:29:26

Altoid

Hello:

... old L.T. management style verbally smacking younglings doing dumb things.

While I agree, it is not the solution.

What failed here was management.

-> Big -> Time -> Fail

Borislav Petkov wrote:

... went in without a single x86 maintainer Ack ...
...  still there instead of getting reverted.

Uncanny.

Coming from where it came from, I think this was a test to see what would happen if ...
The response must be swift and ruthless.

ie:
The 'unfortunate individual' should be banned from the Linux team.
Permanently.

There is far too much at risk to do anything else.

Of course, YMMV.

Best,

A.

Pages: 1 … 12 13 14 15 16 … 79

Board footer

Forum Software