Hello:

Right.

So, there you have it: not in [Debian]*? ---> not in [Devuan] either.

Being available in the [Hyperbola] repositories makes it explicitly suitable for [Hyperbola GNU/Linux-libre].
Not necessarily for [Debian] or [Devuan] for that matter.

* there is surely a reason for that being so, you could ask them.

Best,

A.

.

Hello:

Easiest is using [synaptic] and some command line:

1. open up [synaptic]
2. hit the [reload] button
3. go to [settings] -> [repositories]
4. look for the check-box for [http:/deb/devuan.org/merged daedalus-proposed-updates]   
5. check the box and hit reload again
6. exit [synaptic]

Now you have enabled [http:/deb/devuan.org/merged daedalus-proposed-updates].

7. open a terminal
8. become [root] and do:

# apt install apt

Once done, exit [root] and check the installed version:

$ apt -v
apt 2.6.2devuan1 (amd64)   ### this is the upgraded version for [daedalus].
~$ 

Next, disable [http:/deb/devuan.org/merged daedalus-proposed-updates] which is not usually needed/desired.

Redo steps 1-6, this time unchecking the box for [http:/deb/devuan.org/merged daedalus-proposed-updates], hitting the reload button and exiting [synaptic].   

Best,

A.

Hello:

Indeed ...

Unless your distribution of choice uses [runit] by default, in which case it would be:

Any one of the aforementioned situations (necessarily) imply a justification for doing so, the second implication being that the user is sufficiently versed in the options being considered to be able to make an informed choice.

Like I have said a few times now: [systemd] was never about anything but an orchestrated putsch, not against Debian per se, but against the Linux ecosystem as a whole.

Debian is just the viral vector to deliver [systemd] to the Linux ecosystem.
As such, it will end up being nothing but collateral damage.

Best,

A.

Hello:

Done. 8^)

Best,

A.

Hello:

See* this thread: https://dev1galaxy.org/viewtopic.php?id=6845

Best,

A.

* the search function in this forum is a very useful tool.

Hello:

@KindlyDoRight

Yes, I have used the [testdisk] [PhotoRec] utility to recover files from an accidental [dd] stopped at 1.5MB.

The problem is that losing the directory structure results is an endless stream of [recup_dir.X] directories with a few files in each of them, many times repeated in other directories. ie: a nightmare.
Better than nothing, I guess.

I have yet to find a properly documented (understandable) set of instructions to reset partiton sizes and such operations.
That said, most important step is to make an image of the damaged drive before doing anything with [testdisk].

@dzz

Right.

Thank you both for your input.

Best,

A.

Hello:

Sorry for the delayed reply.

I see.

I did it so:
1. formatted the sd card (clear and then as FAT32 or ext4)
2. remount it and check the device name (with dmesg, Gparted, Disks and lsblk) <- imagine why...*
All these printed [/dev/sdX1], so I used that for [dd].
Made sense to me as the SD Card was not partitioned.
ie: just one single partition

OT ->
When new to Linux, I read about [dd] being called "disk destroyer") so I have always been weary of using it.
But I have used it in a few occasions, inevitably resulting in lack of practise / experience.
Something you may have noticed. 8^°

But I will insist, I think it is a very powerful and versatile tool, just have to learn to master it.
Eventually. * even with all these precautions, I have lost more than one partition table to [dd].
<- OT

# fdisk -l rpi_chimaera.img
Disk rpi_chimaera.img: 7.22 GiB, 7757398016 bytes, 15151168 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
Disklabel type: dos
Disk identifier: 0xd9d859d0

Device            Boot  Start      End  Sectors  Size Id Type
rpi_chimaera.img1 *      2048   524287   522240  255M  b W95 FAT32
rpi_chimaera.img2      524288 15151103 14626816    7G 83 Linux
# 

I have managed to properly write an image to the sd card using [disks]; boots/works as expected.
[rpi-3-devuan-chimaera-5.10.74-v8-ext4-2021-10-19.img] from the Devuan repository.

# fdisk -l rpi-3-devuan-chimaera-5.10.74-v8-ext4-2021-10-19.img
Disk rpi-3-devuan-chimaera-5.10.74-v8-ext4-2021-10-19.img: 1.82 GiB, 1958482432 bytes, 3825161 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
Disklabel type: dos
Disk identifier: 0xd9d859d0

Device                                                Boot  Start     End Sectors  Size Id Type
rpi-3-devuan-chimaera-5.10.74-v8-ext4-2021-10-19.img1 *      2048  524287  522240  255M  b W95 FAT32
rpi-3-devuan-chimaera-5.10.74-v8-ext4-2021-10-19.img2      524288 3825160 3300873  1.6G 83 Linux
# 

I now have to pull configuration and files I need from the last working image which can be mounted with [disks].
Only remaining problem (if I stay with Chimaera) is the repository not working yet.
Again, eventually.

Thanks for your input.

Best,

A.

Hello:

Unfortunately, I am getting the same results I posted previously.

This is the [dd] process:

# dd if=/media/storage/isos/chimaera/rpi_chimaera.img of=/dev/sdg1 bs=4M status=progress
7755268096 bytes (7.8 GB, 7.2 GiB) copied, 668 s, 11.6 MB/s^[[B
1849+1 records in
1849+1 records out
7757398016 bytes (7.8 GB, 7.2 GiB) copied, 787.312 s, 9.9 MB/s
# 

ie: all records written but only 7.2 GB of 7.8 GB copied. <-- what did not get copied?

# mount /dev/sdg1 /mnt/SD
mount: /mnt/SD: wrong fs type, bad option, bad superblock on /dev/sdg1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.
# 

As I was able to install an old Devuan Beowulf and boot without issues it would seem that the SD Card is working properly,
I will try to burn and [*iso] file to see what happens.

Will post with results.

Best,

A.

Hello:

@Camtaf
Thanks for the link, but [uBlock] gives me a warning, probably false.

That said, the card is an original/store purchased Sandisk Ultra which worked perfectly well until I screwed it up.
If there was some issue with respect to its real capacity or provenance it would have shown up once I used it for the first time.

Methinks there is something else afoot here ...

Best,

A.

Hello:

I'd tend to agree, but with one caveat: by no means that can be a blanket to be cast over all of them.
There are a lot of very capable/valuable people out there doing excellent/useful work.

And even then, I will support their absolute right of anyone to do as they please, vanity or not.
That is not the point.

What gets me is the time and (mostly capable) manpower invested by thousands individually instead of harnessing it all towards a common goal. ie: a brick/set of bricks, part of a huge building within the metropolis that is the Linux ecosystem.
Instead of a small / temporary tent for two or three set up in a shanty town.

But with your name on the door, of course. 8^°

Right.
I think we have unwittingly veered way off-topic.
So I will end my participation now.

Thanks for the input.

Best,

A.

Hello:

I have managed to update/upgrade my RPi 3b+ to [chimaera] via apt but, just like [steve_graham], the thingy is still using the kernel it was using before.

rpi3b:~$ cat /etc/os-release
PRETTY_NAME="Devuan GNU/Linux 4 (chimaera)"
NAME="Devuan GNU/Linux"
VERSION_ID="4"
VERSION="4 (chimaera)"
VERSION_CODENAME="chimaera"
--- snip ---
rpi3b:~$ 

rpi3b:~$ uname -asrm
Linux rpi3b 4.16.14-v8+ #1 SMP PREEMPT Tue Jun 5 18:50:10 CEST 2018 aarch64 GNU/Linux
rpi3b:~$ 

The [/boot] directory has three kernel images ...

rpi3b:/boot# ls | grep ker
kernel.img        <--- to be removed?
kernel7.img       <--- to be removed? 
kernel8.img
pi3b:/boot# 

... and [/boot/config.txt] uses the [kernel=8] option:

rpi3b:~$ cat /boot/config.txt | grep kernel=
kernel=kernel8.img
rpi3b:~$ 

@fsmithred
Looking around I found a recent paper [*.pdf] published by the people at [raspberrypi.com]: Updating Raspberry Pi firmware.

The interesting (?) part is in p. 7:

Is this the information you would need to manually upgrade the RPi kernel manually or maybe this would not work in Devuan?

Best,

A.

Hello:

Could be.
My command of the english language is rather lacking, so I won't argue that point.

But ...

Consider the possibility of what you see as predetermined was, at some stage in *IT time*, previously decided* by those who were interested in a specific outcome. eg: interested parties that wrote/timed and executed the rule of the game for their own advantage, something I see as evident.
* planned

Thus it began and as a result we now have MS-registry's half brother, [systemd], among us.

Best,

A.