hmmm fdisk (mine, of package version 2.38.1-5+deb12u3devuan1) doesn't change the signature (despite the warning), and the partition is correctly marked as Empty in the partition table. It further preserves the partition label (DEVUAN501) which is the access detail used by the installer's mounting.

When you plug in the USB (on another linux) without mounting it, what does blkid /dev/sdg and blkid /dev/sdg1 say? I'd expect it to be like

/dev/sdg1: BLOCK_SIZE="2048" UUID="2023-09-14-08-12-43-00" LABEL="DEVUAN501" TYPE="iso9660" PTUUID="0650bbcb" PTTYPE="dos" PARTUUID="0650bbcb-01"

Actually you can run fdisk on the USB stick and change the partition type to 0x0c. I.e., mark it as plain FAT32 instead of EFI (0xef). Then the partition should not be seen as an EFI partition.... and you may further mount the partition somewhere and rename its EFI directory, say to OFF, to further reduce its appearance as EFI partition.

While in fdisk, you may also add another partition for the remaining portion of the USB stick.

I wouldn't try any other partitioning tool since I would fear it may well be too intelligent and eager to be helpful to not destroy the hybrid ISO setup.

note that you also need to follow up with

apt-get dist-upgrade

which, in addition upgrading packages, adds and removes packages according to the dependency network. To quote the man page:

Note that it's never too early to start reading man pages...

The installation ISOs are set up as "Hybrid ISOs". This means that the ISO is a union of two data perspectives: on the one hand the ISO is a single iso9660 filesystem, and on the other hand it's a disk image with two partitions; the first partition spans the whole ISO and the second partition spans a raw image in format FAT32 within that first partition.

It's kind of like this (in beautiful ascii art):

+----------------------------------------+
|              ISO image                 |
|        +-------+    	      	      	 |
|        | fat32 |                       |
|        | image |                       |
|        +-------+                       |
+----------------------------------------+

The iso9660 file format allows for having a DOS partition table in its first 512 bytes, so those two data perspectives blend nicely and leaves it to the device driver to pick and choose which view it adopts. A cdrom drive will adopt the view of a single iso9660, while a disk driver typically adopts the view of 2 partitions (although it's vaguely unhappy about the partitions being overlapping).

The fat32 partition is further marked as an EFI partition so that the disk view makes UEFI more happy because on "the surface" it looks like an ordinary UEFI setup.

BUT it also fools grub's intelligent install logic to make it install grub for UEFI regardless of which bios there is. Probably it just scans the disks to see if there is any EFI partition and from that jumps to the conclusion that the system has UEFI bios.

Therefore you need to exercise some manual hands-on towards the end to explicitly install the grub variant you need. This can be done either after or instead of the installer's grub installation. You where doing it right using the rescue mode.

Secondly, you cannot install linux onto a FAT32 partition because that filesystem type does not have symbolic links. You must format or reformat it into some filesystem type that can.

However wrong it is, the PC Speaker appears as an input device and is handled by the kbd module, or more specifically, Xorg looks for a keyboard device that handles bell. I think the idea is that the XBell event is actually like a KeyPress event and should be handled along the keyboard event handling path.

In any case, the kbd module is the only device handler for "bell" I've been able to find. You could also try the "evdev" module as driver. Xorg doesn't really care, but "libinput" doesn't recognise the "PC Speaker" device, so no driver gets installed.

I'm not sure how that could affect the "real" keyboard handling. The short of it is that Xorg has to install a driver for that device in order to use it.

The device, /dev/inputevent7 for you, is linked up by udev as /dev/input/by-path/platform-pcspkr-event-spkr (which you will find is a symbolic link to ../event7), and that's thus the same destination character device. But the missing link is for Xorg to install a (keyboard) driver that would have interest in the bell event(s).

EDIT: actually if you could share your Xorg.0.log with me, e.g. upload it to https://transfer.rrq.au so I could havea glance and maybe get some inspiration.... Xorg.0.log is found in either /var/log/ (if Xorg is run as root) or in ~/.local/share/xorg/ if Xorg is run by non-root user). Or email it to me.

Yes, you're right. The XkbBellNotify event is generated but nothing handles it to make the noise.

I think you need to "activate the volume group" first; doing so will set up the dm objects for the lvms, and the /dev/mapper (symbolic) links for them, to let you mount them "by name". I believe it'd be something like:

(bogus advice removed) 

EDIT: check the man pages; I don't use lvm regularly (being happy enough without that confusion layer) so may well be wrong on the detail.
EDIT2: I blanked my bogus advice --- see @rolfie's post.

Usually it would amount to chroot onto the target and then run update-grub though possibly the installation of grub got confused by something (e.g. a presence of an EFI partition on the host during the installation; the installer has one) and then installed the wrong package variant.

I guess you should have the grub-pc package installed, So make sure the chroot filesystem has the right package and then run grub-install for it (which probably does require mounting of /proc, /sys and /dev) before update-grub.

@rankett could you please copy your /etc/apt/sources.list into a code block here.

If you want to organise or reorganise your forum writings into a different style wiki presentation, then it is incumbent on you to go to such a wiki site and do that.

Interesting. the three dots matched 5 bytes... probably due to encoding. Now you can edit with, say, nano to add the missing "de" and save, then verify it with hexdump, and it should be ok.

EDIT: so, apparently it's libreoffice writer that adds those bytes. Thus, don't use that for editing text files. I suppose it seems that GUI tool developers nowadays don't really know what they are doing

Put the output of the folling into a "code" block:

hexdump -C /etc/apt/sources.list | head -n 5

... so we can look at the beginning of the file.