Hello:

I understand, your ascii art makes it quite clear.
I have always used gparted, which does not show the detail disks shows so I was not aware of this layout.

Not good if your hardware is not UEFIable, like mine.

Good to know.
Buy still no joy.

I'm sorry, I have not expressed myself correctly.

I started the installation with the USB stick which I first formatted to cleared and then as a single primary FAT32 partition.
But during the installation I deleted that partition it and re-partitioned it like this:

# fdisk -l
Disk /dev/sdg: 57.62 GiB, 61872793600 bytes, 120845300 sectors
Disk model: DataTraveler 3.0
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: 0x6a8163af

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdg1  *         2048   4990975   4988928  2.4G 83 Linux
/dev/sdg2       120258560 120844287    585728  286M 82 Linux swap / Solaris
/dev/sdg3         4993022 120258559 115265538   55G  5 Extended
/dev/sdg5         4993024 120258559 115265536   55G 83 Linux

When the time came for the installer to write GRUB to the disk, I selected the boot partition of the USB stick.
But it did not get installed so the BIOS did not see an OS when I tried to boot.

Both disks and gparted report a healthy filesystem on the USB drive.

Besides testing my system's memory, what do you suggest?

Thanks in advance.

Best,

A.

Hello:

Sorry for the delay in answering, it has taken me some time to test all this.

I have never had to deal with any of that, no idea how.

Just to rule out my having placed the old index finger on the wrong key during the install, I decided to do it all again and see.
I confirmed that I did exactly that and reinstalled but with no luck.

I'll cut this short so as to spare you the details of my last week attempting to see what was going on.

After achiving the two Kingston DataTraveller USB 2.0 drives I was using as installation candidates I purchased another two 64Gb Kingston USB 3.0 Exordia drives, checked the SHA256SUM of the a newly downloaded devuan_daedalus_5.0.1_amd64_netinstall.iso, dd'd it on a 2.0Gb MicroSD card and after booting checked that the installation media was healthy.

Everything was as it should be so I went on to install Daedalus 5.0.1 to one of the 64Gb drives with nothing but an msdos partition table and FAT32 format. ie: no previous partitioning / EXT4-fs formatting and nothing but the default options for the installation.

This is all on a Sun Ultra 24 box with a BIOS boot, no UEFI.

---

On attempting to boot I see that there is no OS.

I then reboot the installation media, run rescue mode and install GRUB to the USB drive containing the Daedalus installation.
Save the fact that GRUB was not where it should have been, no issues.

I shut down the box, reboot and press F8 to get the BIOS boot menu, choose the Kingston USB drive and hit enter.

At first things go as expected:

---

GRUB loading.
Welcome to GRUB!
GNU GRUB version 2.06-13+deb12u1 -> [choose Devuan GNU/Linux]

Booting  Devuan GNU/Linux
Loading Linux 6.10.0-10-AMD64 ...
Loading initial ramdisk ...
---
Here the usual ACPI BIOS Error (bug) printouts we have all seen for years
---
/dev/sda1/: clean, 41420/156160 files, 353650/623616 blocks
INIT: version 3.06 booting
INIT: No inittab.d directory found
Using makefile-style concurrent boot in runlevel S.
Starting hot-plug events dispatcher: udevd.
Synthesizing the intial hotplug events (subsystems) ...done
Synthesizing the intial hotplug events (devices) ...done
Waiting for /dev to be fully populated ...

Then all hell breaks loose ...

INIT: cannot execute "/sbin/getty"
INIT: cannot execute "/sbin/getty"
INIT: cannot execute "/sbin/getty"
INIT: cannot execute "/sbin/getty"
--- snip ---
INIT: cannot execute "/sbin/getty"
INIT: Id "3" respawning too fast: disabled for 5 minutes
INIT: cannot execute "/sbin/getty"
INIT: Id "2" respawning too fast: disabled for 5 minutes
INIT: Id "4" respawning too fast: disabled for 5 minutes
INIT: Id "6" respawning too fast: disabled for 5 minutes
INIT: cannot execute "/sbin/getty"
INIT: Id "5" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel
[35.xxx] Ext-fs error (device sda1): __ext4_find_entry:1678: inode #2:
com init: reading lblock 0
[36.xxx] Ext-fs error (device sda1): __ext4_find_entry:1678: inode #13:
com init: reading lblock 0
[36.xxx] Ext-fs error (device sda1): __ext4_find_entry:1678: inode #1443:
com init: reading lblock 0
--- snip ---

--------------------------------------------------------------------
Note:
There's no /etc/inittab.d directory present.
/sbin/getty is a link to /sbin/agetty
--------------------------------------------------------------------

It goes on and on till I do a hard reset, no other way out.

Now, this has also happened with the previous USB sticks and SD cards when attempting to install devuan_beowulf_3.1.1_amd64_netinstall.iso.

I ran a few tests on the USB 2.0 sticks and they showed no issues but got a new pair just to be sure they were not at fault.

When I look at the installation media with gparted, it shows me a single ISO9660 file system taking up the whole 2.0Gb MicroSD card.
But when I look at it with the gnome-disk-utility, it shows me two partitions and free space.

I know about the free space because the *.iso file is only ~478Mb.
But it turns out that between the 478Mb ISO9660 Partition 1 and the free space at the end there is a 23Mb FAT Partition 2.

In any case, I don't have much of a clue as to what is going on but I would not be at all surprised if it is some side effect of whatever the UEFI/secureboot crowd is up to these days.

I'd appreciate some insight on this.

Thanks in advance.

Best,

A.

Hello:

After a while I traced back to the installation process of any/most Linux installation/s.
The data I needed was located in /etc/default/keyboard, which is where the installation process stores those options.

In my specific case it is this:

$ cat /etc/default/keyboard
# KEYBOARD CONFIGURATION FILE
# Consult the keyboard(5) manual page.
# Set for IBM 82G3294 Model 'M'
#
XKBMODEL="pc105"
XKBLAYOUT="latam"
XKBVARIANT="deadtilde"
XKBOPTIONS="lv3:ralt_switch,terminate:ctrl_alt_bksp"
BACKSPACE="guess"
$ 

So I edited syslinux.cfg to reflect that set of parameters, hoping that the syntax would hold:

--- snip ---
label Clonezilla live
  MENU DEFAULT
  # MENU HIDE
  MENU LABEL Clonezilla live (VGA 800x600)
  # MENU PASSWD
  kernel /live/vmlinuz
  append initrd=/live/initrd.img boot=live union=overlay username=user config components quiet loglevel=0 noswap
edd=on nomodeset enforcing=0 locales=en_GB.UTF-8 keyboard-model=pc105 keyboard-layouts=latam
keyboard-variants=deadtilde ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_batch="no" vga=788
net.ifnames=0 nosplash i915.blacklist=yes radeonhd.blacklist=yes nouveau.blacklist=yes vmwgfx.enable_fbdev=1
--- snip ---

It worked properly: no questions asked and locale/keyboard configuration hard coded in.
That hurdle passed, I got rid of quiet and added all the command line options I use with my Devuan installations.

ie: security=none apparmor=0 nmi_watchdog=0 agp=off ipv6.disable=1 enable_mtrr_cleanup=1

Now, how is it that this tidbit ie: keyboard configuration is not part of the Clonezilla documentation is beyond me.
Not everyone uses what Clonezilla offers as the default settings for locale and keyboard model/layout/variants.
And, just like me they will also find it tiresome to have to set it up every time Clonezilla boots.

One problem I see is that Clonezilla-Live is Debian based ie: systemd crapped and (to me) not trustworthy.
But no doubt about it, I think Clonezilla is a life saver.

Have a Happy New Year.

Best,

A.

Hello:

Not CSD?

Anyway, there was a really huge row about the nimplementation of CSD in Xfce a couple of years ago at the Xfce forum.
Anyone with a modicum of common sense would have taken notice.

See https://forum.xfce.org/viewtopic.php?id=13689
But no, and here we are.

After all these years (!), devs and maintainers at Xfce haven't managed to get a properly functioning menu editor for Xfce.
Or the only two things I miss from MS Explorer: the Send To -> Any Folder and Snap to Grid actions.
Xfce4 desktop icons still have an atavistic tendency to position themselves as they please on the desktop

It would seem that devs and maintainers at Xfce just copy the shiny flashy crap but can't get the necessary basics right.

Maybe it is the same virus that has been affecting Mozilla devs for the longest time?

Here's another one.

Best,

A.

Hello:

It seems that the term enshitification was coined especially this type of crap.

Unbelievable (albeit not unexpected).
The Xfce crowd have been heading towards it for the longest while.

Best,

A.

Hello:

Hmmm ...
Never?

See?

Best,

A.

Hello:

Check one of these, there may be something useful.

https://www.youtube.com/watch?v=UTXXvxUjd-A
https://www.youtube.com/watch?v=B9wbCOajZ2A
https://www.youtube.com/watch?v=_M_yOwBoCA8

No, I have not seen the videos.

Best,

A.

Hello.

Not willing to let it go at that, I went over the error message again ...

# update-initramfs -u
--- snip ---
/usr/sbin/mkinitramfs: 5: /etc/initramfs-tools/conf.d/resume: none: not found
--- snip ---
#

... because it had to be a spelling or syntax problem.
ie: my bad.

I tried with misspelling none -> nones and got this:

# update-initramfs -u
--- snip ---
W: initramfs-tools configuration sets RESUME=nones
W: but no matching swap device is available.
--- snip ---
#

The system does not find a matching swap device, but that is not the error I previously had.

So I tried using the syntax that the error message actually printed out, ie: resume: none <- a space in the wrong place
and then got the original error message:

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.1.0-28-amd64
/usr/sbin/mkinitramfs: 5: /etc/initramfs-tools/conf.d/resume: none: not found
I: The initramfs will attempt to resume from /dev/sda3
I: (UUID=f0187ff0-be52-4bbc-9461-40f744554b85)
I: Set the RESUME variable to override this.
live-boot: core filesystems dm-verity devices utils udev blockdev dns.
# 

So ...
Mystery solved.
ie: a severe case of PEBCAK.  8^°

Once again, thanks for your input.

Best,

A.

Hello:

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=f0187ff0-be52-4bbc-9461-40f744554b85
$ 

$ sudo blkid
--- snip ---
/dev/sdb3: UUID="f0187ff0-be52-4bbc-9461-40f744554b85" TYPE="swap" PARTUUID="0004a8f4-03"
--- snip ---
$ 

No, just that one.

$ ls /etc/initramfs-tools/conf.d/
resume
$ 

Thank you for your input.

Best,

A.

Hello:

Thanks, but it is your thread ie: started by you.

... is the reason I made reference to thread-jacking.

But I see no need to change anything.

My piggybacked question was posted on the answer fsmithred posted for you.
Still your thread.

Best,

A.