I used devuan_excalibur_6.1.0_amd64_netinstall.iso obtained from the devuan excaliber download page. Then dd to setup a 2GB USB stick (wildly oversized; the iso is only 593MB).

sudo dd if=devuan_excalibur_6.1.0_amd64_netinstall.iso of=/dev/sdc bs=1M && sync

My existing screen has a HDMI option, so that was plugged into the Byte, as were an aged Dell keyboard via USB, mouse via USB, a LAN connection to my Virgin Media cable box, the external 18v power via DC jack + the USB stick.

Setup was a doddle:

The first issue was to spot the console warning to access the BIOS at startup. It was "F2", but that was on-screen for a very brief time.

Inside the BIOS it was easy to spot 'choose boot disk', with the internal 2TB SSD or the USB as options after that choice. Choosing 'USB' and 'reboot', everything occurred at astonishing speed afterwards.

My existing box is 10 years old, and one of the main reasons for getting a replacement is the gigabit LAN in the new one. Virgin have upgraded their Cable to an astonishing speed, but the old box was 10/100 LAN & that was the max it could handle. The new box is tiny outside but has 10 x the speed & capacity of the old one.

I was impressed by the intelligence of the setup in the ISO. It spotted my GB location & all the options for LAN setup (lan, wlan + bluetooth). The defaults for disk setup were also intelligent.

Finally, if you have not yet spotted it, only the intelligence of me & the Devuan page is lacking. I'm an ex-internet professional + server admin and yet was flummoxed by "amd64" as the supported architecture.

The Star-Labs Byte3 is working fine with Devuan. My main problem now is the amount of time that it is going to take me to set it up to my liking, so that I can drag myself away from the old box.

[added later]:

Here is my sources.list for Excaliber:

$ grep ^[^#] /etc/apt/sources.list /etc/apt/sources.list.d/*
/etc/apt/sources.list:deb http://deb.devuan.org/merged excalibur                 main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged excalibur-updates         main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged excalibur-security        main non-free-firmware non-free contrib

hth

And Dev1palaxy.org finally hits spam central. Been expecting it from all the noise recently.

Interim update:

Synopsis:

The ODT load on a 600 page document has become so high as to freeze LibreOffice and, on a couple of occasions, also freeze Devuan solid.

$ lscpu | fgrep 'Model name'
Model name:                           AMD A8-7410 APU with AMD Radeon R5 Graphics

Work is in process to reduce that load.

The following has been completed:

1. All Direct Paragraph Style have been changed for other styles (mostly Text Body)
   [note: in 24.8 “Text Body” has been renamed to “Body Text”]

2. Each Heading x style (levels 1, 2, 3 + 4) contains a Text-Box (TB) at the far-right as an extra visual clue. Each TB has been swapped out for a Frame
   [styles: H1Frame, H2Frame, H3Frame + H4Frame]

The following is still in process:

• DrawObjects are being swapped out for PNG images

• Several hundred Direct Formats with a FreeMono font are being swapped out with a self-created “Console” Character Style
  [the original PDF described this style as “Lightface”]

Bug-Traces

Just like slugs, Bugs leave sure-fire notice of their existence.

1. On document load the page count (Status Bar at bottom left) would vary wildly from moment-to-moment

2. The DrawObjects would move location, often across pages as well as within them, and that could also be within the page header or footer. From observation I believe that it may be this latter that caused the freeze-ups.

3. (added 20 Nov) Images + Tables would also move location through the text from their original place.

4. (added 20 Nov) In the Navigator (F5) Tables, Images, DrawObjects, etc.would be listed out-of-order from their position in the text-flow

Under 7.4.7.2 it currently takes 14 seconds after document load for the system load to fall from 30% to a trivial level. Before the changes above it *never* fell below 30%.

(added 20 Nov): After vast amounts of work to create "Proper" styling, a freshly-loaded document takes 10 seconds before the load falls below 30% (an extra 4 seconds saved on earlier work)

There is one main route that requires a reboot, and that is following install of a new kernel. The kernel will need installing at bootup (the only time it gets installed) and the process to that requires an initramfs, which makes a setup from RAM & at the end loads the kernel, etc., etc. initramfs is always specific to a specific kernel.
Here is some user-level info on the setup device:

dpkg -l initramfs-toolss
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name            Version       Architecture Description
+++-===============-=============-============-================================>
ii  initramfs-tools 0.142+deb12u1 all          generic modular initramfs genera

This sorry tale continues.

To re-iterate: somewhere within a 600 page Writer ODT is *something* that has triggered a weird bug.

A long-time expert on the ask.libreoffice.org website fingered my use of "Default Paragraph Style" as one source for system slowdown (should be "Text Body" / "Body Text" instead). I set out to change every one of the thousands of 'ordinary' (not indented, or list, etc) Default-paragraphs to Text Body-paragraphs. Having got almost halfway through those manual changes, I have:

1. Discovered that LO-7.6.7.2 allowed access to edit + save the odt, although the system was at 30% load throughout

2. Changing the 43 paragraphs in the 'Introduction' / save / re-open caused all the excess load to go away

3. Restarting LibreOffice (after no further changes) the load was back

4. Reaching page 113 of 599 with edits the excess load goes away again.

5. Simply restarting LibreOffice (no further changes) and the load is back.

6. Restarting computer then LibreOffice at page 233, after changing 3 paragraphs LibreOffice freezes & has to be dismissed with prejudice (ps aux | fgrep -i libreoffice then kill -9 4112 4171).

7. At some page before this LibreOffice froze so hard that the entire computer system also froze; it required Ctrl+Alt+F1 (go to the command-line) | login | startx | restart computer)

I can't take much more of this.

A significant report to make:

1. Some folks reported that it opened fine in old versions of LO:
   PedroReina :: LO-5.0.0.5
   Babarosa :: LO-7.6.7.2

2. I had a strong suspicion that the mantra of 'use the newest version' may be skew-whiff (winXP v winVista, anyone?)

3. From LO AppImages listing I downloaded & installed "LibreOffice-7.2.3.2.basic-x86_64.AppImage"

4. It was pointed out to me on ask lo org that I was "using Direct Paragraph Formatting instead of Body Text" and that "Direct formatting puts stress on Writer because every occurrence must be handled individually whereas style effects can be cached and reused at will"

5. 3_new.odt loaded up under 7.2.3.2 & allowed me to operate LO
   (the load was still 30%, but this time I had full access to LO).

6. I modified the Text Body style to single line-spacing
   (that matches the original document closely).

7. Ctrl-h gave Search+Replace. Using "Paragraph Styles" I searched for "Default Paragraph Style" & replaced with "Text Body"

8. Changing only the paragraphs within the Introduction I saved as 4_paragraph-fix.odt, closed then re-opened.

9. Opening 4_paragraph-fix.odt again all the excess load was magically gone. Good Lord.

Added later:

Going to re-open 4_paragraph-fix.odt I thought to open 7.4.7 & see if it would also open the ODT at less than 30% load. It turned out to be worse than that. LO froze up. What?

Opening 24.8.2 the ODT was at 30% load but *did* allow access to ODT.

I'll change the rest of the paragraphs & see what happens.

Note 1:
In 24.8.2 "Text Body" style has been changed to "Body Text"

Note 2:
The above is the 2nd time that I've been through all this. The first time I changed not just the plain paragraphs but also Tables & SideBars. I got about halfway through & changed something (do not know what) that caused the load to go through the roof & freeze LO solid (this was under 7.2.3.2). This time I'm re-doing it from the beginning, going slowly & saving damn near every minute.

OK, now I'm confused.

That is why I did an 'apt search', so that I could get advised of the range of different LO versions available. And it only offered me 7.4.7. Yet I've already got backports in my listing:

$ grep ^[^#] /etc/apt/sources.list /etc/apt/sources.list.d/*
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus                  main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-updates          main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-security         main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-proposed-updates main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-backports        main non-free-firmware non-free contrib
/etc/apt/sources.list.d/josm.list:deb https://josm.openstreetmap.de/apt/ alldist universe

I run an update every day, but I've never been offered 24.8.2.

So, how would I tell it to update from backports (or have I pinned it somehow)?

Added later:

I've looked at the search listing (which is huge) more closely & have discovered a number of bpo, but the main element appears missing. Here is the closest:

• libreoffice-uiconfig-writer/stable-backports 4:24.8.2-1~bpo12+1 all
    UI data ("config") for LibreOffice Writer

What I mean by 'main element' is a straightforward "libreoffice-writer" etc, which is present for 7.4.7 but not 24.8.2. I think that an error has been made.

I think that I shall try to install an AppImage & pray that there are no systemD viruses tucked in there.

Hi Ron.

Couple of things:

• No time to do the copy/paste before LO freezes

• One of the bugs I found (listed at the bottom of GitHub) is that Tables encapsulated in a Frame are missed on a Copy. So it wouldn't even transfer accurately if I could copy/paste.

Thanks stargate, I'll pay attention to that & discover whether it will become responsive again (if so, perhaps the no-Contents production was an identical issue).

However, all that will have to take a back-seat. I've got pressing issues coming up shortly, and will have to attend to those first.