Hello:

Yes, and with the same fdisk version.

Yes ... 8^°

It got remounted when I unmounted, ejected and inserted it again.
Did not notice.

But then, I think the only partition mounted was Partition 2.
As seen by disks:   <- gparted does not reveal it

---
Partition 2
Size: 23 MB (22507520 bytes)
Contents: FAT (16-bit version) — Not Mounted
Device: /dev/sdg2
UUID: FAE4-C64A
Partition Type: EFI (FAT-12/16/32)
---

The partition we were editing was not mounted. (IIRC)
I think that if it had been mounted fdisk would have printed out a warning.

Indeed, fdisk says so.
But then it also says 'probably'.

Of course.
I saw the error right after posting so I rewrote the *.iso file and reedited the partition like before.

The end result was the same.

---

# blkid /dev/sdg
/dev/sdg: PTUUID="3488f3e0" PTTYPE="dos"
# 
# blkid /dev/sdg1
/dev/sdg1: PTUUID="3488f3e0" PTTYPE="dos" PARTUUID="3488f3e0-01"
# 
# blkid /dev/sdg2
/dev/sdg2: SEC_TYPE="msdos" UUID="FAE4-C64A" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3488f3e0-02"
# 
# blkid /dev/sdg3
/dev/sdg3: PARTUUID="3488f3e0-03"
# 

What could / would prevent fdisk to make good on its warning?

Thanks for your input.

Best,

A.

Hello:

While I agree, it is not the solution.

What failed here was management.

-> Big -> Time -> Fail

Uncanny.

Coming from where it came from, I think this was a test to see what would happen if ...
The response must be swift and ruthless.

ie:
The 'unfortunate individual' should be banned from the Linux team.
Permanently.

There is far too much at risk to do anything else.

Of course, YMMV.

Best,

A.

Hello:

Worth trying.

Seems fdisk knows what's going on.

# fdisk /dev/sdg

Welcome to fdisk (util-linux 2.38.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

The device contains 'iso9660' signature and it will be removed by a write command. See fdisk(8) man page and --wipe
option for more details.
--- snip ---

I did not try it with fdisk yet but disks let me do it without affecting the rest of the layout.
ie: I can still see the ISOIMAGE in PC-Man as well as its full contents.

I then renamed the efi directory and edited the extensions of /efi/boot/bootx64.efi and /efi/boot/bootia32.efi.

The installer should not see any hint of anything EFI.

# fdisk -l /dev/sdg
Disk /dev/sdg: 3.64 GiB, 3904897024 bytes, 7626752 sectors
Disk model: Storage Device  
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: 0x0291be20

Device     Boot Start     End Sectors  Size Id Type
/dev/sdg1  *       64 2842463 2842400  1.4G  0 Empty
/dev/sdg2         556    3435    2880  1.4M  c W95 FAT32 (LBA)
# 

Edit:
One side effect this may/will have is a fail when using the installer to check the installation media.

I'll try this later today or tomorrow and report back.

Thanks for your input.

Best,

A.

Hello:

No, I haven't.
Not if I want to install Devuan to a USB stick to use with non-UEFI hardware.

I still have to try installing from a Devuan-Live *.iso.
Maybe this week-end if I have time.

Best,

A.

Hello:

... told you that it appears grub gets confused upon seeing the EFI partition of the installer ...

Indeed, you did.

You also took the time to write up an explanation along with some neat ascii art.
Forgot to thank you for that, my apologies.

I'd say it is a bug in the installer.
Or maybe it is a feature in the installer?

If not forked it is a bug report to bugs.debian.org

That being the case, then it would not matter how focused the effort.
ie: I have already seen where that ends.

See this bug report and the reply from the dev/maintainer.

TL;DR

In all probability, filing a well documented bug report would get you a reply akin to this one:

And that will be it.

Maybe someone with non-UEFI hardware can confirm this and then (maybe) someone here at Devuan can have a look.
If it can be fixed and fixing it deemed worthwhile, the package would then have to be forked.

The one thing I can confirm is that when I tried to install debian-10.13.0-amd64-netinst.iso to a USB stick, I got the same result.

Unfortunately, I have no other amd64 hardware to test on.

Best,

A.

Hello:

Right, here we go:

Test 1

# dd if=/home/groucho/Desktop/data1.txt of=/dev/sdg bs=440 count=1
1+0 records in
1+0 records out
440 bytes copied, 8.4841e-05 s, 5.2 MB/s
#

Half hour later ...

# dd if=/dev/sdg of=/home/groucho/Desktop/data1bis.txt bs=440 count=1
1+0 records in
1+0 records out
440 bytes copied, 0.000129402 s, 3.4 MB/s
#

Check the file integrity:

~$ diff /home/groucho/Desktop/data1.txt /home/groucho/Desktop/data1bis.txt
~$

---------------

Test 2

# dd if=/home/groucho/Desktop/data2.txt of=/dev/sdg bs=440 count=1
1+0 records in
1+0 records out
440 bytes copied, 7.8027e-05 s, 5.6 MB/s
#

Another half hour later ...

# dd if=/dev/sdg of=/home/groucho/Desktop/data2bis.txt bs=440 count=1
1+0 records in
1+0 records out
440 bytes copied, 0.00010365 s, 4.2 MB/s
#

Check the file integrity:

~$ diff /home/groucho/Desktop/data2.txt /home/groucho/Desktop/data2bis.txt
~$

---------------

That one passed: no problem with the first 440 bytes in the USB drive.
Now to install GRUB on the USB stick via command line.

1. check I won't screw up

# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
--- snip ---
sdg      8:96   1  14.4G  0 disk
`-sdg1   8:97   1  14.4G  0 part /media/groucho/testusb
#

2. install GRUB

# grub-install /dev/sdg
Installing for i386-pc platform.
Installation finished. No error reported.   ### <-
#

I then booted my box from the USB stick and was greeted by GRUB and was able to boot my system.

That one also passed: GRUB can be installed with no issues to the USB stick.

So:
1. not a system memory issue
2. not a problem with the first USB stick's 440 bytes
3. no problem installing GRUB manually, worked as expected.

At this point, it may be worthwhile to try installing from Devuan-Live and see if it fails or not.

Will report later or this week-end.

Best,

A.

Hello:

I see.

The first two USB sticks I used were 8.0Gb/16.0Gb USB2.0 Kingston Data Traveler SE9s, have had them for a while now and always worked without any fuss.
The new ones are USB3.2 64Gb Kingston Data Traveler Exodia M, new/unused up to yesterday.

They surely have different chips / controllers yet they suffer the same issue, at least in my box.

I was looking around to see how to do something like that.

Right.

# dd if=data1 of=/dev/sdg bs=440 count=1

Will it do if data1 / data2 each are a few different SHA256SUMS strings?
I understand that a byte is more or less the equivalent of 440 letters and seven strings would sum up 448 bytes or so.

I see.

That would be (while in rescue mode) executing a shell in the installed system ie: /dev/sdX.
Right? I have seen there is an option for that.

I was just wondering if there was any installer which did not have all this UEFI crap.
Maybe one of the first Devuan installers. (?)

Thanks a lot for your input.

Best,

A.

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.