Hello:

Indeed ...

I'll take your word for it.  =-)
I have no idea how all that works.

All I know is that if I need a module, that is one way to load it. 

The thing is that vcgencmd is specific to Broadcom chips but we don't have a *.deb for it.
And all the GPIO stuff that the RPi uses for things much more complex than the one I am implementing does not seem (at least I have not found it) to be anywhere but in Raspbian.

It would seem that ARM64, as far as Linux is concerned, is systemd land.
Exclusively.

Thanks for your input.

Cheers,

A.

Hello:

Quite so ...

As you may have read, originally I started powering the HDD from one of the RPi's USB ports.
There was a problem with the SDD not spinning up but it was nothing other than the usual in these cases: the length and gauge of the cable with the micro-USB plug.

I wonder how they say too long / too thin in Chinese?   8^7

So I just got rid of it through some light PS surgery and replaced it with nothing.
The PS has three comfortable USB charging ports on the back and are enough.

Done that, I started powering the RPi with shorter and much better quality power only usb cable (Blackberry phone, I think) from one of the USB ports.
Voltage measurements taken at idle read 5.14V which would seem to be correct.

I also thought as much.
So I switched to powering the HDD from one of the PS's USB ports.

Not being under RPi control, the HDD's shut down timing/scheme would be different.
ie: not as sudden.

Well ...
Turns out that the HDD's shutdown is exactly the same whether the HDD is powered from a USB port on the RPi or a USB port on a separate power supply.
A separate power supply that is not switched off when the RPi is shut down.

Whatever controls this HDD shutdown is within the Devuan image's configuration and evidently does it under the assumption that it is controlling a SD Card and not a HDD.
But I have not been able to figure out what/where it is.

I say this because I have observed that this same HDD does not shut down in the same manner when connected to my Asus 1000HE netbook.

Thanks for your input.

Cheers,

A.

Hello:

Yes, I had read about that.

But then I asked myself about the swap priority beng -2 in particular this image (Devuan ascii ARM64) and thought that is was because there was another one somewhere.
ie: a swapfile somewhere in the SD Card, which I do not use save for reading the rootfs.

Then I concluded (as I mention above) that is was due to the use of an SD Card.

I have only one.

Yes, that's checked.

I recall having used that at some time with my workstation which has 8Gb RAM.

Quite so ...
I need to get my VGA/HDMI adaptor (stuck somewhere in the mail delivery pipe) and set up the desktop/coffee roasting software.
That will be the test and then I'll be able to adjust swap accordingly.

You too ...  =-)

Thanks for your input.

Cheers,

A.

Hello:

Quite so.

As a precautionary measure, I only used the appimage version but it also writes to $HOME/.config.
So, after using it I'd just exit the application and delete the config file it wrote.

I used it last night without any issue and this morning, for unknown reasons, the application would not start.
So I deleted everything etcher related from my system, downloaded the appimage version and tried again.

No dice.
It won't start.

I have not run any system updates/upgrades since the last time I used it, so I really don't think this could be due to some system glitch/incompatibility.

So I'm back to (and will stay with) the well known and trusty dd.

If there's anything I should look into, please advise.

Thanks in advance,

A.

Hello:

Like I mentioned I use sudo shutdown -h now.
If I do sudo halt -p it will have (it has) the same effect I describe in my OP (as far as I know) as they are mostly the same.

ie: shutdown -h = shutdown --halt

Yes, that is exactly what I am doing.

Thanks a lot for your input.

Cheers,

A.

Hello:

Wrote the Devuan ascii *.img files to the SD card and another 40Gb HDD, then made the modifications mentioned in my OP.
You can see the instructions in a video here.

Changed the size of the swap partition, was a bit overboard.
Will try with 3.0Gb and see how it goes when I run the coffee roasting software as 1Gb RAM is rather tight.

groucho@devuan:~$ cat /etc/fstab
# <file system>  <mount point> <type> <options>              <dump><pass>

# bootfs
# was /dev/mmcblk0p1
UUID=EEA4-304A                             /boot    vfat  defaults          0  1

# root on HDD - was /dev/sda2
UUID=589c7999-62be-47ac-8847-32b62fd9fdc9  /        ext4  defaults,noatime  0  1

# /var/log on HDD - was /dev/sda5
UUID=80f008d9-7f6e-49d2-8df7-d370a02be5df  /var/log ext4  defaults,noatime  0  1

# /home on HDD - was /dev/sda6
UUID=58b362ef-c02d-45c0-8085-dc3996a7d947  /home    ext4  defaults,noatime  0  2

# /swap - was /dev/sda7
UUID=5535c86a-ff6f-46d2-a53b-bad0f38d23fc  none     swap  defaults          0  0

## blkid as of 20200505
# 2.0Gb SD card
# /dev/mmcblk0: PTUUID="ac806f8a" PTTYPE="dos"
# /dev/mmcblk0p1: SEC_TYPE="msdos" UUID="EEA4-304A" TYPE="vfat" PARTUUID="ac806f8a-01"
# /dev/mmcblk0p2: UUID="589c7999-62be-47ac-8847-32b62fd9fdc9" TYPE="ext4" PARTUUID="ac806f8a-02"
#
# 40Gb HDD 
# /dev/sda1: SEC_TYPE="msdos" UUID="EEA4-304A" TYPE="vfat" PARTUUID="d34db33f-01"
# /dev/sda2: UUID="589c7999-62be-47ac-8847-32b62fd9fdc9" TYPE="ext4" PARTUUID="d34db33f-02"
# /dev/sda5: LABEL="log" UUID="80f008d9-7f6e-49d2-8df7-d370a02be5df" TYPE="ext4" PARTUUID="d34db33f-05"
# /dev/sda6: LABEL="home" UUID="58b362ef-c02d-45c0-8085-dc3996a7d947" TYPE="ext4" PARTUUID="d34db33f-06"
# /dev/sda7: LABEL="swap" UUID="5535c86a-ff6f-46d2-a53b-bad0f38d23fc" TYPE="swap" PARTUUID="d34db33f-07"
groucho@devuan:~$ 

I have found it to be a good idea to keep a (dated and commented) output of blkid in the /etc/fstab file.
Keeps everything on the same page when needing to edit or check it.

root@devuan:/home/groucho# findmnt --verify --verbose
/boot
   [ ] target exists
   [ ] UUID=EEA4-304A translated to /dev/sda1
   [ ] source /dev/sda1 exists
   [ ] FS type is vfat
/
   [ ] target exists
   [ ] VFS options: noatime
   [ ] UUID=589c7999-62be-47ac-8847-32b62fd9fdc9 translated to /dev/sda2
   [ ] source /dev/sda2 exists
   [ ] FS type is ext4
/var/log
   [ ] target exists
   [ ] VFS options: noatime
   [ ] UUID=80f008d9-7f6e-49d2-8df7-d370a02be5df translated to /dev/sda5
   [ ] source /dev/sda5 exists
   [ ] FS type is ext4
/home
   [ ] target exists
   [ ] VFS options: noatime
   [ ] UUID=58b362ef-c02d-45c0-8085-dc3996a7d947 translated to /dev/sda6
   [ ] source /dev/sda6 exists
   [ ] FS type is ext4
none
   [ ] UUID=5535c86a-ff6f-46d2-a53b-bad0f38d23fc translated to /dev/sda7
   [ ] source /dev/sda7 exists
   [ ] FS type is swap
Success, no errors or warnings detected
root@devuan:/home/groucho# 

The warnings issued by findmnt --verify --verbose were permission related.
Must be run as root or without  the --verbose modifier.

Had nothing to do with update-initramfs -u.  8^7

root@devuan:/home/groucho# fdisk -l
--- snip ---
Disk /dev/mmcblk0: 1.9 GiB, 1990197248 bytes, 3887104 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: 0xac806f8a

Device         Boot  Start     End Sectors  Size Id Type
/dev/mmcblk0p1        2048  264191  262144  128M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      264192 3872767 3608576  1.7G 83 Linux

Disk /dev/sda: 37.3 GiB, 40060403712 bytes, 78242976 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: 0xd34db33f

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1           2048   264191   262144  128M  c W95 FAT32 (LBA)
/dev/sda2         264192 14942207 14678016    7G 83 Linux
/dev/sda3       14942208 78241791 63299584 30.2G  5 Extended
/dev/sda5       14944256 17041407  2097152    1G 83 Linux
/dev/sda6       17043456 71948287 54904832 26.2G 83 Linux
/dev/sda7       71950336 78241791  6291456    3G 82 Linux swap / Solaris
root@devuan:/home/groucho# 

root@devuan:/home/groucho# swapon -s
Filename				Type		Size	Used	Priority
/dev/sda7                              	partition	3145724	0	-2
root@devuan:/home/groucho# 

root@devuan:/home/groucho# swapon -a
root@devuan:/home/groucho# 

As for the swapon -a parse error, it remains a mystery.
When confronted by something like that again, maybe the MS way is better.
ie: delete and rewrite the line.   8^°

Now to finish the install and do some housekeeping (host name, user, sudoers.d, etc.)
I have another doubt I must address but will do so in a different thread.

Thanks a lot to everyone who helped out with this.

Cheers,

A.

Hello:

Quite so ...

Very sharp!  8^D

Can't look at it now as the drive is toast.
But I'll check that the next install is properly written (maybe tonight) and report back.

Thanks a lot for your input.

Cheers,

A.

Hello:

No ...

Here it is:

groucho@rpidevuan:~$ sudo modprobe configs
groucho@rpidevuan:~$ 

But the issue has been solved.
Problem was a PS thing, long cable with voltage drop.

See my previous post.

Cheers,

A.

Hello again:

I see ...

Yes.

On your reply, I decided that it would be be a good idea to step back a bit and look at this from the hardware side.
So I ran some additional tests.

All tests are with machines running Devuan ascii 2.0
32-bit version on a netbook / 64-bit version on a WS and the RPi3B+

There are various testing stages:

Stage 1
Netbook
Drive plugged into USB1
Power plugged into USB2
Result: works as expected, properly detected and accesible.

Stage 2
Workstation
Drive plugged into USB1
Power plugged into USB2
Result: works as expected, properly detected and accesible.

Stage 3
Raspberry Pi
Drive plugged into USB1
Power plugged into USB2
Result: does not work

Stage 3-1
Raspberry Pi
Drive plugged into USB1
Power plugged into netbooks' USB1
Result: does not work

Stage 3-2
Raspberry Pi
Drive plugged into USB1
Power plugged into workstation's USB1
Result: does not work

Stage 3-3
Raspberry Pi
Drive plugged into USB1
Power plugged into PS USB charging port
Result: works   8^o!

Great, problem solved but ...
This drive draws ~700mA and probably uses a bit more to start up.

The USB ports in both the netbook and the workstation obviously provide enough power.
ie: Port USB1 + Port USB2 in each machine provide enough power for the drive

Now, if the drive does not work when using power from the workstation/netbook USB ports, it begs the question:

How much power are/voltage the RPi's USB ports providing then?
Obviously less than the 500mA that they should be.

The red light stays on, no indication of a power issue.

The RPi's power supply (says) it is rated at 5.0v 5100mA max, more than the usual 2500/3000mA.

By default, the RPi USB ports are rated at a max global of 600mA but a line in the /boot/config.txt file sets it to 1200mA max.

max_usb_current=1

Don't know if it is the same but it is definitely (like you said) a power supply problem.

I think that the PS I have can probably manage the stated 5100mA but not at a stable 5.0V.
Which is why the drive won't spin.

I think it is a smartphone type charger and those are not necessarily made to put out rock stable 5.0v as they are used to charge 3.8 volt Li-ion/Li-iPo batteries.
I'll have to look for something else.

Thank you very much for you input, you have been most helpful.
Kudos, you had it right from the start.  ;^ )

Now I can see about installing the image in the SDD.

Cheers,

A.