Hello:

Hmm ...
Yeees?

I downloaded both the netinstall-arm64.iso and the desktop-arm64.iso, wrote them to a 32Gb SD card with the Mintstick software at some time suggested by greenjeans and attempted to boot the RPi3B+ first with the netinstall and later with the desktop *.iso.     

When nothing* happened I checked the sha256sum files again but found no discrepancy.
* not even a blink from the activity on-board led or the GbE port.

Then I thought* ...
* not really, please bear with me

"This absolute-waste-of-money™ boots from a MicroSD card.
Could it be the that the *.isos are used to install Devuan arm64 'on' the MicroSD cards?
Lets give it a try"

Granted, a dumb idea when seen in retrospective, not with a glass of scotch by my kb.
But when the installer screen appeared on my monitor it suddenly seemed to make sense.

Till it did not.   8^°

Like I mentioned, the idea is to install a headless Devuan to the RPi3B+ to see what can be done with it, if anything (useful) at all.
I have already been able to install the latest OpenWRT but I would like to install some Devuan version.
RaspberryOS works OOTB, but it is systemd crippled, so ...

Now I understand what was going on.
An 'unrecognised whatever' would have been nice.
And avoided me some embarrassment.

I recall that I once managed to install a Devuan (Chimaera?) desktop version and kept an image somewhere.
I'll see if I can find it and get rid of the excess baggage.

That said, I don't think I'll get too far with 1Gb RAM and a GbE port on the same bus as the 4xUSB 2.0 ports.
The Ethernet throughput will probably be lower than what I get with the WD-MBL via FTP.

Ideas / suggestions welcome.

As always, thanks for your input.

Best,

A.

Hello:

The OP asked about much more than that.
Running in an emulator is only a necessary part of what OP ultimately wanted to do.

The app the OP refers to is the bank's custom application running on a smartphone in the way I previously described.

So the answer to the question/s I posed in my previous post would seem to be a hard no.

Exactly.

As far as I can tell, Google et al have absolutely no involvement (at least for the time being) in the client <-> bank transaction through their authenticating servers, none whatsoever.

Banks are run by experienced white collar crooks, not idiots.

Many years ago, I tried to log into one of my bank's websites using the Tor browser, thinking it would be better and safer.
It took a few seconds to get kicked out of the session and instantly get an email summoning me to the head branch to speak with an accounts officer who, sternly produced a disclaimer for me to sign because "third party malware had been detected during my last log in" and assume full responsibility for whatever could happen, lest they terminate my account on the spot if I did not sign it.

Needless to say, he did not take lightly my asking if he was referring to the MS operating system (Win98SE) running on the boxes I used at the office and at home.

So no, for all the reasons I explained in my lengthy post, I do not think it is possible to avoid using a smartphone to do any banking unless the bank allows the use of an 'on-device' authenticator running on your smartphone, something that will never happen.

Basically because, among other things, it is an integral part of the the meta-data farming system that has been put in place in the past 5/10 years.
With no government oversight whatsoever.

Soon enough, you will not even be able to order a pizza at a resturant without a smartphone.
The absence of a printed menu has recently started to become a widespread trend.
ie: sitting at a table in the joint, you actually have to use a smartphone to see the menu on the restautant's web site.

And it is going to get worse.  8^|

Best,

A.

Hello:

Indeed ...
The final objective is that everyone uses a smartphone for everything.

Same here.
And the local telcos do not offer any dumbphone options.

A local doctor's association (or whatever it is) has intere$ted / offered their associated physicians access to a dedicated website where, instead of handing you the usual hand written prescription while you are in front to them, they will send it to you via email.

To that effect, all your data and prescription history is stored (safely, never shared or sold mind you) in the association's server.
Not only that, it seems that the chaps actually get some cash for every patient that gets uploaded to the data base.

Like my proctologist's secretary ignorantly explained: "the Dr. saves time when not having to write the prescription".  8^D !!!

The bank where I get my pension deposit and have been a client for more than 25 years one day decided that I would no longer be able to transfer money between my account and any other account (mine or not) if I did not have a token which was (to them) the only possible way to ID myself before the bank's infrastructure if I was using their website.

Gone was the 2FA Auth I had been using and as you would expect, said token could only be generated by an app running in a smartphone I did not have (used a Blackberry at the time).

Needless to say that the process of installing the app involved (you guessed it) uploading photos of your mug like if you were being processed for murder. ie: front / right / left / smiling / not smiling and so on. It's a wonder they did not also want a photo of my tonsils.

I could go on as examples of this bulshit abound so I will stop now and explain why all this is happening worldwide:

It is all about control.
A smartphone is basically a tracking device and all these app shennanigans are meta-data harvesting procedures.

The moment you get your mug shot on-line is the moment it is shared worldwide, istantly associated to all the information you shed permanently with absolutely everything you do with a smartphone. eg: banking, digital wallet payments, etc.

The added bonus for banking institutions is that, sooner than later, any and all client banking activity will have to be done via a smartphone.
Forget your secure Linux box behind a router / firewall at home and, to their shareholder's delight as all their clients will then work for them, welcome to the world of banks without branches, ATMs, tellers, employees, etc.

Like stores of all sorts that, as time goes by, have more self-service checkout tills and less cashiers or humans: you are both the employee (weighing/sorting/checking out the goods) and the client (paying for it all).

I flatly refuse to use them and point out to the employee at the till that if I do, eventually they will be out of a job, a job which they are good at.
Their reply? "I find it very helpful, especially when there are many clients in the store"
Unbelievable.

I do not think there is one and given how the system works, I there will not ever be one.

This because the key to all this is that the app runs on the smartphone, ie: the portable data harvesting device registered (via an IMEI <-> your ID pair) to you and working with / through the telco's infrastructure which is (obviously) linked to the rest of the world-wide telco infrastructure and whatever other infrastructure feeds from it.

As far as I know, it is impossible to access that infrastructure directly with a computer / emulator but you can do it if your computer accesses it via your smartphone, I believe there is such a thing for whatsup. You would need to fake quite a few things, the main one being a valid IMEI / your ID pair.

Soon there will be no way of using any telco infrastructure without a registered smartphone.

No dumphones or burner phones will be allowed and all communication devices will have to be linked to a valid ID, meta-data* included, of course.
* full name, address, full facial recognition data, some ID number (passport, etc.) and who knows what else.

Best,

A.

Hello:

For lack of a better reply, I'd say that what you have is a very specific CUPS issue.

Unfortunately, Apple Corp. has blocked all acess to the huge source of data/information that were the CUPS archives.

That said, there is are new lists set up by the chap who wrote CUPS:

See here for general instructions:
https://subspace.kernel.org/subscribing.html

See here for specific CUPS lists instructions:
https://subspace.kernel.org/lists.linux.dev.html

For printing-architecture
subscribe       printing-architecture+subscribe@lists.linux.dev   
unsubscribe   printing-architecture+unsubscribe@lists.linux.dev
posting          printing-architecture@lists.linux.dev
archive          https://lore.kernel.org/printing-architecture/

For printing-users
subscribe      printing-users+subscribe@lists.linux.dev
unsubscribe  printing-users+unsubscribe@lists.linux.dev
posting          printing-users@lists.linux.dev
archive          https://lore.kernel.org/printing-users/

The background to all this hassle, more specifically, the archives at https://lists.cups.org/pipermail/cups/:

Up to (at least) May last year, the archive was accessible to anyone, suscribed or not.
Those suscribed to the list could post to all list members by sending mail to cups@cups.org
Just like most standard issue mailing lists ...

Some time ago I needed to look up something and found that attempting to access the archives
returned a *403 Forbidden* page.

A mail to cups-owner@cups org got me this reply:
---
More recent cups related stuff can be found at openprinting.org.
When apple bought cups, those lists went to their servers.
Mike quietly left apple years ago, and it appears that apple has removed the lists.
They own "cups". So Mike had to make a new name.
---
'Mike' obviously refers to Michael Sweet who left Apple in December 2019.

Unfortunately, a further email asking for more information went unanswered.
Bad vibes ...

It seems that I can still post to the list (ie: email does not bounce) and I receive other people's
posts containing replies so the list works, but the thread is not accessible.

I then posted to the OpenPrinting GitHub page asking about this and right away received a
reply from M.R. Sweet himself:

https://github.com/OpenPrinting/cups/discussions/1237

---
Unfortunately, lists.cups.org is an Apple-managed site and we have no control over its
contents or configuration...
The printing-users and printing-architecture lists on kernel.org are the current place for
discussing printing-related issues.
---

The thing is that all this went down without *any* notice sent to the list and the wealth of information that made up the archives are, thanks to the assholes at Apple Corp., lost to any and everyone who ever posted anything there.

The first example of such shitty behaviour came from yet another well known corporation (Oracle): after taking over Sun Microsystems, they blocked all access (mailing lists and downlaods) to anyone without a $ervice contract.

Best,

A.

Hello:

@SlySven
I'm afraid you have misquoted me.
The quote belongs to the OP, kapqa.

I would never* spell systemd like that.  8^D !!!

* lest I summon an instant rebuke from our (long time) absentee member, HoaS.

Best,

A.

Hello:

I'm sure you will concur with me in that few and minor are basically relative concepts.

That said, consider having a read at the post I linked to earlier in this thread.
Having done so, reflect upon what place few and minor could possibly have in what transpired.

For a long time now, the established idea has been that any current Linux *.iso (in this case Devuan/Debian) properly dd'd to a USB stick would be able to boot from any machine, provided hardware compatiblity was complied with.

I'd say it is one of those essential parts of the jazz that Linux is all about.
eg: like TCP/IP

With the advent of this UEFI shitload and without having been said otherwise, it stands to reason the idea referenced above still stands.
If that is not what is happening, something is definitely wrong.

And having to apply any modifications, however few and minor, is neither convenient nor acceptable.
The implications of it being considered as such are huge and of significant and extensive reach.

I think my opinion reflects that of a great many Linux users.
As always, YMMV.

Thanks for your input.

A.

Hello:

Right, those are the ones I'veen looking at.

Yes. I was planning on doing that in my present 1000HE setup.

Re: enabling UEFI

So the function to enable UEFI in the *.iso, be it installer or live, is in some part of the respective *.sdk?

If so, maybe the installer could have an option to turn it on/off, depending on the default setting.

As always, thanks for your input.

Best,

A.

Hello:

Yes but not if you are booting a box with no UEFI.
eg: Asus 1000HE
You can just delete the UEFI partition with disks albeit not with gparted which does not see it.

My guess is that because of how the installer works now, any *.iso made for a post Chimaera/Bullseye kernel will produce a UEFI partition, independently of the kernel present in the installation.

This complicates everything.
eg: try to install Daedalus or any post Chimaera/Bullseye release on a USB drive.

All this UEFI, secureboot, apparmor, SELinux et al crap being imposed manu militari by the WinTel consortium will not end well for us. 

Best,

A.

Hello:

No problem.

No, did not touch it.
Just copied the script, labelled and made executable.

Apparently ...

But I think I found a use case where the script does not work.
ie: in UEFI boxes.

As you may recall, I used a Chimaera i386 *.iso.file from the Devuan repository.
devuan_chimaera_4.0.3_i386_desktop-live.iso

This *.iso file did not generate a #$%& UEFI partition when I wrote it to the SD Card.
ie: as expected, gparted reported a single *.iso file while disks reported an *.iso file and the remaining unformatted/empty space.

Then I tried a Bookworm based #!++ i386 *.iso file to see how it would work. -> cbpp-12.0-i386-20230611.iso
Find it here you may want to try it out and see what happens.

TL;DR
Using the #!++ *.iso, Mintstick generates a first partition with an *.iso image, a second UEFI partiton and the remaining empty space.
As a result, the script will delete the partition containing the UEFI shit.

I expect that the same thing will happen with any modern *.iso file beyond Chimaera or equivalent.

In this last test, it deleted the partition with the UEFI shit, left the unformatted empty space untouched and threw the same error we both experienced.
You may want to consider the script looking only for empty and unformatted space.

It's fine with me, all my hardware is non-UEFI (BIOS boot) so I just created a a FAT32 DATA partition by hand.
But how about the cases you will be working on?

That said, the error does not seem to be reproducible.
And since both of us have seen it ie: different hardware, a pause may be effectively needed somewhere in the script.

Best,

A.

Hello:

I've given that some thought.
The weakest link here is the Class 2 2.0Gb SD Card + SD Card reader.
disks clocks it at an average read rate of 10.5MB/s, average write speed is probably slower.
By comparison, the SAS drive from which the *.iso file was read is clocked at an average read rate of 105.2 MB/s.
ie: 10X higher using the same size (10MB) sample.

No need.
Patch the script, test it and let me know the additions.
ie: line number and syntax so I can just add them verbatim to the original.

Best,

A.

Edit:
Posts crossed while I was making espresso.
I'll run the tests and post as soon as I get it done, later tonight or early tomorrow.

.

Hello:

Glad I could be of help.

Box is a ca. 2009 Sun Microsystems Ultra 24 WS with an Intel Q9550 / 8Gb RAM - Linux 6.1.0-37-amd64 x86_64
Swap file in RAM.

$ sudo swapon -s
Filename				Type		Size		Used		Priority
/dev/sdb3                               partition	2749436		0		-2
/dev/zram0                              partition	6291452		0		100
$ 

The memory is a standard Sandisk SD (Class 2) 2.0Gb  Card on a generic USB 2.0 SD /MicroSD Card reader plugged into a USB 3.0 slot.

The difference in read/access speeds between a Class 2 SD card, USB 2.0 reader in a USB 3.0 slot and a swapfile in RAM may (?) account for whatever happens timing wise. I'd say that, in this specific case, you don't need fast.
ie: accurate and reliable would be the thing to aim for.

Best,

A.