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.

Hello:

Looking for the [*.deb] files I am needing I found two possible sources:

https://miroir.blueline.mg/debian-security/dists/
https://debian.sipwise.com/debian-security/dists/

Are these legitimate Debian mirrors?

Best,

A.

Hello:

Welcome to Dev1.

Have you tried installing Devuan with the default/standard [GRUB] package?
If so, was there something that you found lacking with it?

I have been running Linux in my boxes for ~12 years (Devuan since 2017) and have never had any issues with [GRUB].
To the point of being practically transparent to me, except for custom boot screen configurations I needed.

Best,

A.

Edit:
You will get valuable insight from this post by [fsmithred].
Point to remember: the forum's [Search] function (between [User list] and [Profile]) is your best friend.

Hello:

Quite so ...

Yes, I agree.

It seems that there was a fire/accident that took down the servers and a new forum had to be set up.
Apparently some stuff was lost and I cannot log-in or recover my PW.
Will try again when I have time.

Don't understand ...
No reliable off-site back-ups? 8^°

In any case, Texstar [packager/main dev] posted this earlier this year.
Seems he does not have contact information for one of his forum's senior admins. (?)
Go figure ...

Best,

A.