Hello:

From where I stand ie: not a coder or developer, just a 65+ advanced (?) user, what you say makes a lot of sense.

But I also believe that it makes sense to take into account that for Devuan, which has a hard time as things stand, things won't get easier if it has no access to or ignores SBC hardware such as RPis of which over 35 million have been sold.

These inexpensive SBP are the entry point to IT for a great many people who maybe cannot afford something else, just want to play and see what it is like or just need an inexpensive solution to a small and simple problem.

And if you leave it all to Raspbian, you will have lost a lot of potential users many of which may eventually become IT staff or pros ie: just the people Devuan needs to survive in the future.

I'm afraid that spawning dozens of derivatives will not be enough.

The Devuan project is not just a distribution, it also represents a core philosophy (Unix) or an ideology if you will.
Exactly the opposite of what mainstream MS software represents today. 

It urgently needs to develop a strategy to occupy the RPi field or get permanently pushed out of it.

Just another point of view and as always, YMMV.

Cheers,

A.

Hello:

While my WS ascii installaton gets me this ...

groucho@devuan:~$ apt list --installed | grep -i linux-image
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
linux-image-4.9.0-12-amd64/oldstable-security,now 4.9.210-1+deb9u1 amd64 [installed,automatic]
linux-image-amd64/oldstable,now 4.9+80+deb9u10 amd64 [installed]
groucho@devuan:~$ 

... my RPi installation (image) gets me this:

pi@rpidevuan:~$ apt list --installed | grep -i linux-image
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
pi@rpidevuan:~$ 

Please explain as I'm not getting the point.

Thnaks,

A.

Hello:

There's only one (have I missed something?) image for RPi3 and it is from 2 years ago.
Would it be the same as an image of the last/latest Devuan ascii 2.1 old-stable?

This is what I have installed on my RPi +B+ now:

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

This is what I have on my up-to-date Devuan ascii rig:

groucho@devuan:~$ uname -a
Linux devuan 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1+deb9u1 (2020-06-07) x86_64 GNU/Linux
groucho@devuan:~$ 

If I counted (toes/fingers) correctly, it (4.16) is 12 major revisions behind.

A.

Hello:

Brigade?
Not that I know much about this, but from what I have read, a brigade is composed of ~3 batallions and this could be from 2000 to 8000 troops.
From the amount of RPi traffic I've seen there at Dev1G, I doubt we have a squad, ie: 7 to 14 troops.

That said, if not a netinstall, now that it is old-stable, at least the latest ARM Build Devuan ascii 2.1 image would be very nice to have at hand.
The one available for download is over two years old (06-Jun-2018).

A.

Hello:

I beg to differ.
Not having a designated maintainer is not the same as support being a joke.
There could be/are many reasons for not having a maintainer.

Right.

I have seen more than one application with no apparent dependency issues eg: apt-get install -f not installing anything but they would still not work because an unlisted dependency was (obviously) not installed.   

These are the apparmor related (by name) packages that show up in synaptic:

apparmor-easyprof
apparmor-notify
apparmor-utils
dh-apparmor

See if installing these changes anything, especially apparmor-utils and dh-apparmor.

Then check these sites:
https://apparmor.net/
https://medium.com/information-and-tech … 4d7ae211ed

Cheers,

A.

Hello:

Right ...
Seems to have worked.
Good sport!   ;^ )

Good.

I see.

Please have a look at /etc/default/grub.d/apparmor.cfg:

~$ cat /etc/default/grub.d/apparmor.cfg

There should be a line like this one:

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=1 security=apparmor"

Cheers,

A.

Hello:

No one?

Thanks in advance,

A.

Hello:

Still trying to figure this out.

From what I have read at the RPi forunm, the over-current change output in dmesg is directly related to an underpowered power supply but one thing that sort of stumped me was finding that some people having this issue has official RPi power supplies.

It seems that what is happening here is this:

Getting the over-current change line in dmesg when the external HDD is connected to one of the power supply's USB ports leads me to think that the PS is indeed underpowered, but then the RPi does complete the boot process as if nothing had happened.

If I had not looked throught the dmesg output, I would not have been the wiser.
Like I mentioned before, there have been no indications of power issues: no red light blink or on-screen warnings, even when overclocked and running a severe stress test.

But then, not getting the over-current change line in dmesg when the external HDD is powered from one of the RPi's USB ports sort of does away with the underpowered PS theory.

So, what's up?

I think that the PS is on the edge of being underpowered and having both the RPi and the external HDD draw power at the same time pushes it over that edge for a bit less than 1.5s ...

pi@rpidevuan:~$ sudo dmesg | grep current
--- snip ---
[    3.194560] usb 1-1-port3: over-current change    <--- first over-current event 
--- snip ---
[ 4.570348] usb 1-1.1-port3: over-current change    <--- last over-current event
--- snip ---
pi@rpidevuan:~$ 

... but then recovers as soon as the HDDs spin-up current draw, which could be up to and even over 1.0A, is gone.
And it is for such as short time that the RPi does not throw any warnings.

Powering the HDD from one of the RPi's USB ports has the RPi powering up before it powers up the HDD (1s, 2s?), so then there's no simultaneous power draw from the RPi and the HDD.

I am hacking up an old 360W Sun Microsystems PS that puts out +5V/30A to make a bench power source and will see if I can reproduce the over-current issue while powering the RPi and HDD from there.

Any ideas?

Cheers,

A.

Hello:

I'm not too clear on how the boot process in ARM64 works.
I've always been on x86/x86_64 ie: w/BIOS booting     

But like you, I don't think it is a size issue but cannot rule it out.

Found this:

Here it is most probably a question of the size of the partition vs. the size of the update.
One would think that in a properly packaged upgrade, instead of a crash, some script would check that the update would actually fit the partition.

But I digress.

Thinking that the problem is probably in the type of partition and not the size, I had a look at their main characteristics.
I burned different images for Raspberry Pi 3B + on an SDcard and did blkid, parted -l and fdisk-l on each to compare the results:

1. devuan_ascii_2.0.0_arm64_raspi3.img

blkid

/dev/sdf1: SEC_TYPE="msdos" UUID="EEA4-304A" TYPE="vfat" PARTUUID="ac806f8a-01"
/dev/sdf2: UUID="589c7999-62be-47ac-8847-32b62fd9fdc9" TYPE="ext4" PARTUUID="ac806f8a-02"

parted -l

Model: Generic Mass-Storage (scsi)
Disk /dev/sdf: 2033MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  135MB   134MB   primary  fat16        boot, lba
 2      135MB   1983MB  1848MB  primary  ext4

fdisk -l

Disk /dev/sdf: 1.9 GiB, 2032664576 bytes, 3970048 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/sdf1  *      2048  264191  262144  128M  c W95 FAT32 (LBA)
/dev/sdf2       264192 3872767 3608576  1.7G 83 Linux

2. 2020-02-13-raspbian-buster-lite.img

blkid

/dev/sdf1: LABEL="boot" UUID="4BBD-D3E7" TYPE="vfat" PARTUUID="738a4d67-01"
/dev/sdf2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" TYPE="ext4" PARTUUID="738a4d67-02"

parted -l

Model: Generic Mass-Storage (scsi)
Disk /dev/sdf: 2033MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      4194kB  273MB   268MB   primary  fat32        lba
 2      273MB   1850MB  1577MB  primary  ext4

fdisk -l

Disk /dev/sdf: 1.9 GiB, 2032664576 bytes, 3970048 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: 0x738a4d67

Device     Boot  Start     End Sectors  Size Id Type
/dev/sdf1         8192  532479  524288  256M  c W95 FAT32 (LBA)
/dev/sdf2       532480 3612671 3080192  1.5G 83 Linux

3. LibreELEC-RPi2.arm-9.2.1.img

blkid

/dev/sdf1: LABEL="BOOT" UUID="22BD-E464" TYPE="vfat" PARTUUID="08de5300-01"
/dev/sdf2: LABEL="RECALBOX" UUID="9c7b2218-a4be-431c-900c-733cb0382b28" TYPE="ext4" PARTUUID="08de5300-02"
/dev/sdf3: LABEL="SHARE" UUID="e5113429-80b8-4347-bd0d-802da4c4726e" TYPE="ext4" PARTUUID="08de5300-03"

parted -l

Model: Generic Mass-Storage (scsi)
Disk /dev/sdf: 31.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      512B    67.1MB  67.1MB  primary  fat32        lba
 2      67.1MB  2215MB  2147MB  primary  ext4
 3      2215MB  31.9GB  29.7GB  primary  ext4

fdisk -l

Disk /dev/sdf: 29.7 GiB, 31914983424 bytes, 62333952 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: 0x08de5300

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sdf1             1   131072   131072   64M  c W95 FAT32 (LBA)
/dev/sdf2        131073  4325376  4194304    2G 83 Linux
/dev/sdf3       4325377 62333951 58008575 27.7G 83 Linux

It was parted -l that showed me what the real difference was:

1. Devuan ascii 2.0.0

Disk Flags:
Number  Start   End     Size    Type     File system  Flags
 1      1049kB  135MB   134MB   primary  fat16        boot, lba

2. Raspbian Buster-lite

Disk Flags:
Number  Start   End     Size    Type     File system  Flags
 1      4194kB  273MB   268MB   primary  fat32        lba

3. LibreElec 9.2.1

Disk Flags:
Number  Start   End     Size    Type     File system  Flags
 1      512B    67.1MB  67.1MB  primary  fat32        lba

In Devuan ascii the first partition is primary fat16 boot, lba.
But while in the other two Raspbian/Debian based images the first partition is also primary and lba, it is fat32 and does not have the boot flag set.

Any one with more experience in these matters care to pitch in?

The RPi 3b+ with the OTP bit set (now by default) allows more flexibility in that instead of booting only from the SDCard slot, it will first try to boot from an SDCard and if there's no boot system there, from a USB slot.

It would be great if the Devuan ARM64 images could take advantage of this feature.

Thanks in advance,

A.

Hello:

Ah.
Sorry.

I always keep a *.bak.
Same result.

Cheers,

A.

Hello:

Yes ...
But as I mentioned in my OP, the plugins were in the system:

The only one that looked like it could be (xcb) was that one.
ie: /usr/share/artisan/PyQt5/Qt/plugins/platforms/libqxcb.so

No matter, the problem is now solved. 8^)

Any idea as what to do with the warning?

root@rpidevuan:/home/pi# /usr/share/artisan/artisan
libEGL warning: DRI2: failed to authenticate
root@rpidevuan:/home/pi#

From what I have seen it is a common issue with RPis and Broadmcom chips.
It crops up if the application is started from the terminal but it could be that it is not a RPi issue.

And again, thanks a lot.

Cheers,

A.