Hello:

I was writing my previous one when your post came in.

Hmm ....
This is what I get:

# fdisk -l devuan_daedalus_5.0.0_i386_desktop-live.iso
Disk devuan_daedalus_5.0.0_i386_desktop-live.iso: 1.29 GiB, 1385709568 bytes, 2706464 sectors
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: 0x6bae8a95

Device                                       Boot Start     End Sectors  Size Id Type
devuan_daedalus_5.0.0_i386_desktop-live.iso *       64 2706463 2706400  1.3G 17 Hidden HPFS/NTFS
# 

The file was downloaded here.

I checked the file against its SHA256SUM.
ie: a8d354cbf8bc7137dad4734d508a2f3dcfe9d87132f01d4ae14955b6e770d86a

# sha256sum devuan_daedalus_5.0.0_i386_desktop-live.iso
a8d354cbf8bc7137dad4734d508a2f3dcfe9d87132f01d4ae14955b6e770d86a devuan_daedalus_5.0.0_i386_desktop-live.iso
#

The downloaded *.iso comes from the usual place and has the correct hash sequence.

I think your *.iso and my *.iso are identical:

mine -  Disk devuan_daedalus_5.0.0_i386_desktop-live.iso: 1.29 GiB, 1385709568 bytes, 2706464 sectors
yours - Disk devuan_daedalus_5.0.0_i386_desktop-live.iso: 1.29 GiB, 1385709568 bytes, 2706464 sectors

mine -  devuan_daedalus_5.0.0_i386_desktop-live.iso *       64 2706463 2706400  1.3G 17 Hidden HPFS/NTFS
yours - devuan_daedalus_5.0.0_i386_desktop-live.iso1 *     64 2706463 2706400  1.3G 17 Hidd

The printout truncation is confusing things ...

Quite so, but good to know.

Thanks for your input.
Best,

A.

Hello:

@ralph.ronnquist

No.
The stanza used was:
dd if=home/groucho/Downloads/devuan_daedalus_5.0.0_i386_desktop-live.iso of=/dev/sdg1 bs=4M status=progress oflag=direct

I obviously do no touch the USB drive till I see the dd printout reporting the result of the operation.
ie: records in / records out + command prompt.

Just the same, to check:

# dd if=/home/groucho/Downloads/devuan_daedalus_5.0.0_i386_desktop-live.iso of=/dev/sdg1 bs=4M status=progress conv=fsync
1385709568 bytes (1.4 GB, 1.3 GiB) copied, 32 s, 43.0 MB/s
330+1 records in
330+1 records out
1385709568 bytes (1.4 GB, 1.3 GiB) copied, 217.089 s, 6.4 MB/s
#

And then as suggested:

# cmp /home/groucho/Downloads/devuan_daedalus_5.0.0_i386_desktop-live.iso /dev/sdg1
cmp: EOF on /home/groucho/Downloads/devuan_daedalus_5.0.0_i386_desktop-live.iso after byte 1385709568, in line 5389724
#

The problem persists.

Thinking that the size (64Gb) of the USB drive could be an issue, I formatted it with a single 7.8Gb partition to which I dd'd the *.iso file.
But, no, no cigar.

I have no problems with any these USB drives in my main box (Sun Ultra 24), they are all detected at boot time and will boot an *.iso file.

I have three identical Kingston Technology DataTraveler 100 G3/G4/SE9 G2/50 and the Asus 1000HE netbook refused to boot with two of them, be they empty / unformatted, formated to full size or to 7.8Gb. The BIOS does not detect them.

The third one, with the Ventoy system on it, boots without any issues.

So (unless I am missing something) it comes down to the BIOS having issues with either the USB standard (3.2 not 3.0) or their capacity.
I say it is the BIOS because if I insert them once Chimaera is up and running, the system detects them and can mount, read and write to them without any issues. ie: the BIOS lacks the proper drivers. (?)

Seeing that the Ventoy USB works and the dd'd USB does not, I set out to compare them with fdisk.

Ventoy

# fdisk -l /dev/sdg
Disk /dev/sdg: 57.73 GiB, 61991813632 bytes, 121077761 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: 0x4a2d7551

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdg1  *         2048 121012223 121010176 57.7G  7 HPFS/NTFS/exFAT
/dev/sdg2       121012224 121077759     65536   32M ef EFI (FAT-12/16/32)
# 

Daedalus_i386_desktop-live.iso

# fdisk -l /dev/sdg
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: 0x0ccbfdf1

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdg1  *     2048 120844287 120842240 57.6G  b W95 FAT32
# 

With my untrained eyes, besides Ventoy having a 32mb EFI partition, what I see is this:

- both drives have boot partitions starting at 2048
- Ventoy's boot partition is Id 7, type HPFS/NTFS/exFAT 
- Devuan's boot partition is Id b, type W95 FAT32

On a whim, I cleared the USB drive and formatted as Id 7, type HPFS/NTFS/exFAT:

# fdisk -l /dev/sdg
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: 0x0ccbfdf1

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdg1        2048 120844287 120842240 57.6G  7 HPFS/NTFS/exFAT
# 

I then dd'd the same devuan_daedalus_5.0.0_i386_desktop-live.iso:

# dd if=/home/groucho/Downloads/devuan_daedalus_5.0.0_i386_desktop-live.iso of=/dev/sdg1 bs=4M status=progress conv=fsync
1385709568 bytes (1.4 GB, 1.3 GiB) copied, 11 s, 123 MB/s
330+1 records in
330+1 records out
1385709568 bytes (1.4 GB, 1.3 GiB) copied, 155.279 s, 8.9 MB/s

Checked:

# cmp /home/groucho/Downloads/devuan_daedalus_5.0.0_i386_desktop-live.iso /dev/sdg1
cmp: EOF on /home/groucho/Downloads/devuan_daedalus_5.0.0_i386_desktop-live.iso after byte 1385709568, in line 5389724
# 

Unfortunately, that did not work.
What is probably missing is the EFI crap in the 32Mb partition but I have no idea how to deal with that.

TL;DR
It would seem that the *.iso files generated these days will not play nice with older ie: BIOS boot hardware such as the Asus 1000HE.
This is a problem, apparently solved (for now) via Ventoy.

As I mentioned in another thread involving a USB drive:

Best,

A.

Hello:

A closer look at the non-detectable USB drive with fdisk showed me this:

# fdisk -l /dev/sdg
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: 0xbb37ef5f

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdg1        2048 120844287 120842240 57.6G  b W95 FAT32     # no boot flag
#

So I added the boot flag with gparted:

# fdisk -l /dev/sdg
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: 0xbb37ef5f

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdg1  *     2048 120844287 120842240 57.6G  b W95 FAT32
# 

No difference, the USB stick is not seen by the netbook's BIOS (Asus 1000HE).

Best,

A.

Hello:

Let's see ...

Registered:
2025-01-27
Posted:
2025-01-28

Received answers:
2025-01-28 x1
2025-01-30 x1
---
A long awkward silence ensues ...
eg: crickets
---
20250504 x 2  <- valiant effort from Devarch and Rolfie ...

When I see this sort of attitude from members (most if not all, new ones) seeking help, it really makes me wonder ...

.
A.

Hello:

Please open a terminal, do this and post the result:

$ cd /usr/share/images/desktop-base

Translation:

Best,

A.

Hello:

Yes.
That is what it says.

One would tend to think so.

So ...
Why is it being reported (also by dmesg) as loaded?

The clue to my post is that (apparently) blacklsting the IPv6 module is not working.
ie: it is being loaded in spite of being blacklisted with the usual *.conf file in /etc/sudoers.d.

Very sorry for not being clear enough, English not being my mother tongue and all that.

Best,

A.

Hello:

I beg to differ: I was on the right page.
The one belonging to lists.cups.org, now inaccessible.

Great find ...  8^D

But that is a Wayback Machine snapshot, unsearchable (?). 

Thanks for your input.

Best,

A.

Hello:

Check here: https://discussion.fedoraproject.org/t/ … own/124911

TL;DR
Disable the “Wake on LAN” option in the BIOS.

If that does not work, check this link where you will find many hits with posts by people having the same issue.

Sometimes, Google can be a friend. 8^°

Best,

A.

Hello:

As you have seen, the difference in perfomance is huge.

And there is basically one main motive for this being so.

Best,

A.

Hello:

Indeed.
As it should be.

This provided that the package installed (like the printout you posted shows) actually comes from the Devuan repository.

Like I pointed out, the problem* posted by kapqa (not related to the original post) would seem to indicate that the package installed may not be from the Devuan repository.    * printout points to a typical error in Linux systems using systemd.

That said, note that the link posted leads to a Debian open-iscsi wiki page. 

@kapqa
You may want to consider opening a separate thread with your problem and start by posting the terminal printout from this:

$ uname -a

$ cat /etc/apt/sources.list

$ apt list | grep -i installed | grep -i open-iscsi

Best,

A.

Hello:

Crikey !... 
Seems espresso had not kicked in yet.

But not a proper excuse though.

The thing is that I'm just lowly hack who most always finds the answers to difficult stuff under the same two names.
ie: fsmithred / ralph.ronnquist

Yes, that's the best (true one) I can come up with.  8^D

Best,

A.