Posts by Altoid

Altoid · Hardware & System Configuration

Hello:

hunter0one wrote:

... ported the zramen script from Void Linux ...
... comes with a working init script for Daedulus.

Thanks for doing that for the team Dev1.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Still working on my Asus 1000HE. 8^°

My netbook runs on Devuan Chimaera and the lightest file manager ever I found (besides mc) was xfe 1.43.1-1 i386.
Worked great and never looked back.

This morning I got a notification from the author about a request I made (back in ascii days) for an automount feature which has been incorporated to lhe latest version (2.1).

Rolad Baudin wrote:

**[feature-requests:#237] Automount devices in Xfe**
**Status:** open
**Group:** v1.0_(example)
**Labels:** automount
**Created:** Tue Dec 03, 2019 12:48 PM UTC
**Last Updated:** Sun Mar 14, 2021 05:28 PM UTC
**Owner:** nobody
Xfe now has an (optional, Linux only) automounter. You can configure it in Xfe / Edit / Preferences / Settings.

The thing is that I don't see any i386 version in the Devuan repositories but I can find version 2.0.1-2 in the Debian repositories (Trixie) so I expect that the latest version ie: xfe 2.1 i386 will eventually (?) be available there also.

There are also i386 versions available for Buster, Bullseye and Bookworm, all of them ideal for undepowered i386 hardware such as the 1000HE.

I doubt xfe2.0.1-2 i386 would install without issues in my Devuan Chimaera netbook.
Or maybe not ...

Q: Is there a way to get that done?

Best,

A.

Altoid · Hardware & System Configuration

Hello:

EDX-0 wrote:

... my https://github.com/eylles/zram-service script ...

Yes, I saw it.

But this is for an undepowered (Intel Atom N280/2Gb) ca. 2009 netbook for which I need a simple/easy solution.
The zramctl command can set up all the parameters I need in a jiffy in case the default ones are not suitable or I want to experiment.

Thanks for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello.

I wrote:

... troubleshoot this further?

No need.

In true (and time proven) Linux fashion I found a way out.
ie: by doing it in a different manner.

For those interested, the whole explanation is here.

TL;DR
For whatever reason, it seems the problem of getting the/a zram script to start in /etc/init.d has been doing the rounds for a while.
I could not find out why.

The solution is to start zram, setting the parameters and the zramswap file directly from rc.local.
And Bob's your uncle.

To test, I just dropped in the lines posted but (just to be neat) I'll write up a short script as a replacement for that.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Still working on my Asus 1000HE. 8^°

I have set up zram / zramswap with this script which I found referenced here.

Just in case, I added both the shebang (#!/bin/sh) and the usual PATH= variable as I saw it was missing.
I then named it zramswap, copied it to /etc/init.d, made it executable and did update-rc.d zramswap defaults.

The problem I have is that it does not start at boot and I can't figure out why.

But I can start it from a terminal:

$ sudo zramswap start
Setting up swapspace version 1, size = 1002.6 MiB (1051303936 bytes)
no label, UUID=05decff9-d90e-4db3-ae9d-a65484a3462c
$

$ sudo swapon -s
Filename				Type		Size	Used	Priority
/dev/sda5                              	partition	12595196	0	1
/dev/zram0                             	partition	1026664	0	20
~$

$ cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/sda5                               partition	12595196	0		1
/dev/zram0                              partition	1026664		0		20
$

$ sudo zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle    1002.6M   4K   74B    4K       2 [SWAP]
$

I can't get anything from running the script in a terminal either:

# /etc/init.d/zramswap start > /tmp/zramswap.log 2>&1
#
# cat /tmp/zramswap.log
#                           <- nothing to see here ...

Just in case ...

#!/bin/sh
#!/usr/bin/env /lib/init/init-d-script

### BEGIN INIT INFO
# Provides:          zramswap
# Required-Start:    $syslog $time $remote_fs
# Required-Stop:     $syslog $time $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Linux zramswap setup
# Description:       Debian init script for zramswap
### END INIT INFO

PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON=/usr/sbin/zramswap
PIDFILE=none

_is_active() {
	$DAEMON status >/dev/null 2>&1
	return $?
}

do_start_prepare() {
	if _is_active; then
		log_warning_msg "$NAME is already active"
		exit 3
	fi
}

do_start_cmd_override() {
	$DAEMON start
}

do_stop_prepare() {
	if ! _is_active; then
		log_warning_msg "$NAME is not active"
		exit 3
	fi
}

do_stop_cmd_override() {
	$DAEMON stop
}

do_status_override() {
	$DAEMON status
}

do_restart_override() {
	if _is_active; then
		$DAEMON restart
	else
		$DAEMON start
	fi
}

How to troubleshoot this further?

Thanks in advance.

Best,

A.

Altoid · Installation

Hello:

mweishaar wrote:

... @Altoid is quoting and replying to his own posts ...

Yes.
Instead of editing the previous post, I posted again.
Makes more sense when you are following the thread.
Granted, I neglected to add Update at the beginning of the post the quote to myself.
Sorry about that ...

But I digress ...

Running apt clean or apt autoclean requires root or sudo.
Depending on how your system is configured.

# apt clean
#

# apt autoclean
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
#

Likewise, to run apt-get clean or apt-get autoclean also requires root or sudo.

# apt-get clean
# 
# apt-get autoclean
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
#

With respect to apt-cache ...
You are quite right: clean and autoclean are not valid options.
What has happened is most probably a typo on behalf of one of our (most active) admins: fsmithred.

Strange ...
I have been a member of Dev1 for eight years now and it is the first time I see such a thing.
No big deal, just this week I have made more than a half dozen typos myself.
Happens.

So, no.
My guess is that you are not losing it, whatever it may be.
I keep my own it in a small box under the kitchen sink so it does not get lost. 8^°

Hope that clears up things for you.

Best,

A.

Altoid · Installation

Hello:

I wrote:

I use apt autoclean and apt autoremove along with apt install -f all the time.

Yes.

apt autoclean will remove obsolete packages but to clear the /var/cache/apt/archives and /var/cache/apt/archives/partial directories you have to use apt clean.

Just checked in my netbook's Chimaera system and I came across a dozen or so packages from over three years ago.

Makes sense.
They were there because I never use apt clean, just apt autoclean and apt autoremove.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

mtbvfr wrote:

Which Trackball device do you use ...

I have been using a ERGO M575, I think also from Logitech.
It was the least expensive (wireless) one I could find locally.

It is quite evident that it is not made to last.

Not crazy about it, lint builds up inside the ball cavity, especially around the contact points.
But then I have seen that happen in every other one of these things I have used, I guess it is part of the deal.

One pet peeve I have is that the rubber pads that keep them from sliding on the desktop are (usually) absolute crap.
They are stuck on with some sort of rubber cement and eventually they will come off.

And to clean the thing thoroughly (under the buttons, around the wheel), you have to take it apart.
This means that (besides the necessary patience and care) the pads must come off to have access to the tiny screws.
Lose them (a pad and/or screw) and you are in a jam.

You may want to consider trying possible options out before purchasing one.
My only recommendation is to avoid any brand/model with rechargeable batteries.
Common AA's are available anytime / anywhere.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

ralph.ronnquist wrote:

Maybe having lz4 in /etc/initramfs-tools/modules ...

Indeed ...
That would have done it.

Except that, for some reason, I decided to add an (obviously unneeded) underscore.
Hence it not working as expected.

ralph.ronnquist wrote:

What's lz_4 ?

Hmm ...
Direct consequence of not taking my 20:00 pill?
Or maybe taking it twice. 8^°

Now it works. 8^)

--- snip ---
[     4.473334] zswap: loaded using pool lz4/z3fold
--- snip ---

There's nothing like paying attention to what you are typing.
While you are typing it.

Thanks so much for you input.
Have a good week-end.

Best,

A.

Altoid · Installation

greenjeans wrote:

... Bleachbit do the heavy lifting ...

My favourite was fslint but it's now long gone on account of python 2.7.x being deprecated.

Best,

A.

Altoid · Installation

Hello:

mweishaar wrote:

... see my Edit: comment.

Yes, I saw it.
I use apt autoclean and apt autoremove along with apt install -f all the time.

But I have read that they do not take care of what has accumulated in /var/cache/apt/archives and /var/cache/apt/archives/partial.
Sorry, cannot find the link ... 8^°

Thanks for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Wanting to get the last possible bit of ooompf from my Asus 1000HE, I installed zswap.
Chimaera+Openbox do a good job.
But the 2.0Gb RAM is rather limiting, especially when using my coffee roasting software.

The system is up to date and the kernel command line has all the needed bits:
zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=40 zswap.zpool=z3fold.

/etc/initramfs-tools/modules also has the needed bits:

lz_4
lz4_compress
z3fold

Yet the dmesg printout reads:

--- snip ---
[     4.495646] zswap: compressor lz4 not available, using default lzo
--- snip ---

Interestingly enough, opening a terminal and doing modprobe lz4 will actually load it and it will show up with lsmod.
Maybe it is the order in which these are loaded?

I'd appreciate some input on this.

Best,

A.

Altoid · Installation

Hello:

fsmithred wrote:

... run apt-cache autoclean to get rid of old deb packages

Was passing by, had a read and tried it.
Had never used it before.

# uname -a
Linux devuan 6.1.0-34-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.135-1 (2025-04-25) x86_64 GNU/Linux
#

# apt-cache autoclean
E: Invalid operation autoclean
#
# apt-cache clean
E: Invalid operation clean
#

System is up to date.

What am I missing?

Thanks in advance.

Best,

A.

Altoid · Hardware & System Configuration

Update:

I wrote:

... still have to contact Asus to ask about that.

After filling out an online form asking for the netbook's serial number and other data, I managed to get a reply from Asus.
I also sent them a photo of the barcoded label on the original packaging which clearly read:

---
Model: 1000HE
Customer number, P/N, Serial Number, EAN, UPC, Check Number.

EEEPC 1000HE, BLACK,XP,1g DDR2
INTEL ATOM280, 160G(D)/ZD,802.11B/G/N,BT
1.3M CAMERA,6CELL LI-ION,SLEEVE
---

So, after having inequivocally established what hardware I was referring to, I asked:

I wrote:

I am asking here because I have not been able to find this
information anywhere (manual, on-line, FAQ, etc.)
Q: What is the highest capacity USB drive I can use when booting from
the F2/BBS Popup menu?

The reply started by saying that they queried the serial number and other data in their system but found no information.
ie: no information about what (at that point in time) was arguably Asus' most successful product ever.

ASUS Service wrote:

If it is an ASUS Eee PC it is a long discontinued product.

If ...?

And then this:

ASUS Service wrote:

Generally for hardware of that generation it would be a 8Gb USB drive with a Fat32 format, preferably done with Rufus.
This reply is based on my technical experience.
I am sorry but I cannot recognise the model with the S/N given.

No further comments needed.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

greenjeans wrote:

... same iso you linked to.
Works perfectly ...

Yes, it was the first thing I checked.
First SHA256 and then cmp (thanks to Ralph.R for that)
So no problem with the *.iso.

greenjeans wrote:

... USB 3 stick in an interface for USB 2 ...

Like I mentioned earlier on, the USB 3.x drive works perfectly well once the system is up.
So there's no issue with backwards compatibility.
ie: USB 2.0 / 3.x

That said, your nature always sides with the hidden flaw is a gem. 8^)

greenjeans wrote:

dd is not ...

... for everyone, agreed.
But if I do not practise I'll never learn to do it properly.
I will always regret not having stated with / studying command line DOS earlier.

We are heading towards the day when only those who can proficiently work with a terminal may have a chance ...
But I digress.

greenjeans wrote:

... not doing something magical ...

Of course it is not, I was using a metaphor of sorts.

What it does. thanks to very clever / creative coding is make a 64Gb (or more, cannot say) USB 3.x drive detectable by the BIOS of a netbook that would seem to have a limit* to that, I still have to contact Asus to ask about that.
* see link to the Ventoy page posted by rolfie.

Many years ago, Linux was the go-to OS if you had hardware that would struggle with newer versions of mainstream OSs like MS, etc.
Bloat, bling and all kinds of BS in Linux distributions has put a stop to that.

Now, you have to find a lightweight distribution, such as the ones you roll.

Like I mentioned previously , it would be a great thing to be able to dd a standard *.iso and have it do what Ventoy does.
ie: just that, overcome the BIOS USB size limit in older laptops / netbooks. Nothing else needed.

Unfortunately, I do not see that happening, ever.
The tide is clearly flowing in the opposite direction.

Thanks for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

rolfie wrote:

... stumbled across this topic ...

Yes, one of the hypothesis I shuffled about was a hardware limitation, USB 3.x, size or both.
Evidently limited to the BIOS as, once up, the system has no problems with the (64Gb USB 3.x) USB drive the BIOS does not detect.

But, as I noted in my last post, that same USB drive with a Ventoy system does not have any problems.
I wonder if *.iso files could not be made to do the same.
ie. dd the *.iso files and it will boot, no BIOS limit problems.

rolfie wrote:

... solved it by using a 32G stick.

A quick workaround, for now.
Soon you will not be able to purchase small capacity USB drives.
The smallest I can find locally are 32Gb.

rolfie wrote:

... in legacy mode this limitation comes into play.

Like the link you posted indicates, it depends on the BIOS.
My Sun MS Ultra 24 box can boot from the 64Gb drive with no issues.

Thank you for the link.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

fsmithred wrote:

dd to the whole device, /dev/sdg, not to the partition.

Ooops ... 8^°

Right.

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

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

# fdisk -l /dev/sdg
Disk /dev/sdg: 1.89 GiB, 2032664576 bytes, 3970048 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: 0x6bae8a95

Device     Boot Start     End Sectors  Size Id Type
/dev/sdg1  *       64 2706463 2706400  1.3G 17 Hidden HPFS/NTFS

Good news: that fixed it for the 2.0Gb SD card in the USB adapter.
The 1000HE detects it and boots as expected.

I then dd'd the 64Gb USB 3.2 drive in the same manner:

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

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

# 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: 0x6bae8a95

Device     Boot Start     End Sectors  Size Id Type
/dev/sdg1  *       64 2706463 2706400  1.3G 17 Hidden HPFS/NTFS
#

Unfortunately, it did not respond in the same manner.
ie: the drive is not detected by the netbook's BIOS

@fsmithred
Thank you for the heads up.
My screw-up was confusing things for me.

At this point, it looked like it was a hardware issue.
ie: the 1000HE's BIOS / USB controller and USB 3.2 vs. USB 2.0

To confirm this, I dd'd the same file to the last USB 2.0 drive I have.
One of those slim, metal clad Kingston SE9s of which I am very fond of and hesitated to do anything with it.
I had already lost the 16Gb one.

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

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

# fdisk -l /dev/sdg
Disk /dev/sdg: 7.22 GiB, 7757398016 bytes, 15151168 sectors
Disk model: DataTraveler 2.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: 0x6bae8a95

Device     Boot Start     End Sectors  Size Id Type
/dev/sdg1  *       64 2706463 2706400  1.3G 17 Hidden HPFS/NTFS
#

It worked. 8^)

Q: does it still look like this is hardware issue?
ie: the USB controller in the Asus 1000HE BIOS (945GM Express chipset) has no problems booting from a Kingston SE9 USB 2.0 drive but does not even detect the Kingston USB 3.2 DataTraveler 100 drive, which in turn is detected and can be mounted, read and written to once the system is up.

A: I do not think so.
The reason being that the exact same USB 3.2 drive with a Ventoy system is detected by the BIOS and can be used to boot any *.iso file (provided it is i386, obviously).

So, unless I am missing something (?), the remaining questions would be:

1. Just what is the netbook's BIOS looking for in the USB 3.2 drive but cannot find?
2. Why does it find it in the USB 2.0 drive but not in the USB 3.2 drive? => They both have been dd'd with the same *.iso file.

Whatever the missing bit is, it is quite evidently present in the USB 3.2 Ventoy USB drive, allowing the netbook's BIOS to detect the drive.
And then, it is also possible that there is something in the *.iso file (bug?) that prevents the BIOS from detecting the USB 3.2 drive.

Unfortunately, I don't have a 64Gb USB 2.0 drive to test this further.

This is all well over my head so I will leave it to those who know more about the matter.
As you have seen, I am still in the process of learning how to use dd properly. 8^°

Edit:
The people at Ventoy have a webpage describing their disk layout.
Maybe the answer is there?

Thank you all for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

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

ralph.ronnquist wrote:

... something is off with your iso.

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 ...

ralph.ronnquist wrote:

... UEFI installers of chimaera and daedalus are two different technologies.
... irrelevant to here, which wouldn't be an EFI boot.

Quite so, but good to know.

Thanks for your input.
Best,

A.

Altoid · Hardware & System Configuration

Hello:

I wrote:

... *.iso files generated these days will not play nice with older ie: BIOS boot hardware ...

Forgot to point out that, to rule out any USB stick issues, I also dd'd the daedalus_5.0.0_i386_desktop-live.iso to a 2.0Gb SD card:

# 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, 64 s, 21.7 MB/s
330+1 records in
330+1 records out
1385709568 bytes (1.4 GB, 1.3 GiB) copied, 320.048 s, 4.3 MB/s
#

And checked:

# cmp /home/groucho/Downloads/devuan_daedalus_5.0.0_i386_desktop-live.iso /dev/sdg1
/home/groucho/Downloads/devuan_daedalus_5.0.0_i386_desktop-live.iso /dev/sdg1 differ: char 1000046593, line 3882924
#

Again, for some reason the partition does not get written with a boot flag:

# fdisk -l /dev/sdg
Disk /dev/sdg: 1.89 GiB, 2032664576 bytes, 3970048 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: 0x60b198df

Device     Boot Start     End Sectors  Size Id Type
/dev/sdg1        2048 3969023 3966976  1.9G  b W95 FAT32
#

Fixed that:

# fdisk -l /dev/sdg
Disk /dev/sdg: 1.89 GiB, 2032664576 bytes, 3970048 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: 0x60b198df

Device     Boot Start     End Sectors  Size Id Type
/dev/sdg1  *     2048 3969023 3966976  1.9G  b W95 FAT32
#

The SD card slot in the netbook is faulty so I use a USB 2.0 SD card adapter.
Curiously enough, the BIOS sees it and I can select to boot from the USB mass storage device but it will not boot.
ie: all I get on the screen is a blinking underscore cursor.

So yes, it would seem that there is something going on with how the *.iso files are assembled / rolled.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

@ralph.ronnquist

... dd with conv=fsync so that the program does not exit ...

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:

Altoid wrote:

Devuan Chimaera netinstall *.iso: 372.00 MB - UEFI installer: 00.754 MB
Devuan Daedalus netinstall *.iso: 477.80 MB - UEFI installer: 23.00 MB
30X more code has been added to the UEFI partition on the road between Chimaera and Daedalus.
Does anyone really know exactly what all that added code does?

Best,

A.

Altoid · Hardware & System Configuration

Hello:

fsmithred wrote:

... ok on 1101HA, bios version 0317

This is a 1000HE, bios version 1104 (last) with the Intel 945GM Express chipset.
The 1101HA uses the Intel US15W chipset but I cannot say if it is relevant or not.

fsmithred wrote:

... no-name giveaway usb stick ...

Is it a 2.0 or 3.0 USB stick?

I am booting devuan_daedalus_5.0.0_i386_desktop-live.iso and, like I mentioned, boots correctly with the Ventoy USB.
ie: the USB stick is detected by the Asus 1000HE bios.

I'll check and see what happens with the devuan_chimaera_4.0.2_i386_desktop-live.iso.

Thanks for you input.

Best,

A.

Altoid · Hardware & System Configuration

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.

Altoid · Hardware & System Configuration

Hello:

Just to see what it would look like, I dd'd the i386 live Daedalus *.iso to a new USB stick but, to my surprise, it was not detected by my Asus 1000HE netbook.
ie: press Esc to get the boot device selection screen and see only the internal HDD available, no USB stick detected.

The *.iso file was SHA256 checked and was visible/accessible to the file manager.
This which ruled out both a bad dd and a USB hardware issue.

To check, I then tried another Debian based i386 live *.iso (#!++), with exactly the same result.

All this happens independently of the boot device order (removable device, atapi CD-ROM or HDD) is established in the BIOS.

I then copied both *.iso files to a Ventoy USB and had no problems booting them from there.

It seems that these days *.iso files cannot be seen properly by BIOS boot rigs which apparently need whatever magic Ventoy does.
ie: no backwards compatibility.

Short of being forced to use Ventoy from now on, is there a work around?

Does not look good to me.
As always, YMMV.

I'd appreciate comments from members who know more about this.

Best,

A.

Altoid · Off-topic

Hello:

Interesting article @The Register:
---
37signals is completing its on-prem move, deleting its AWS account to save millions
by Simon Sharwood
---

Simon Sharwood @TheRegister wrote:

... but the industry pulled a fast one convincing everyone it's the only way,” he concluded.
“No wonder you see cloud vendors and ads and PR everywhere. There's so much money in convincing
everyone that owning your own hardware is impossible or that operating Linux servers is too hard!”

Best,

A.

Altoid · Devuan

Hello:

rolfie wrote:

... missed the original post ...

That is not (and should not be) a problem for anyone taking the time to reply to as request for support here at Dev1.

ie: You do what you can, when you can and if you can.

My apologies if my text sounded like anything else.

Time is, indisputably, the most valuable thing anyone has.
And to dedicate a part of it, however small, to help someone is the right thing to do.

It is part of what I refer to as the 'pay it forward system'.
It goes around and (eventually) will come back to you.

Best,

A.

The officially official Devuan Forum!

#51 Re: Hardware & System Configuration » [SOLVED] zramswap script won't start » 2025-05-19 19:39:04

#52 Hardware & System Configuration » xfe i386 file manager » 2025-05-19 13:41:09

#53 Re: Hardware & System Configuration » [SOLVED] zramswap script won't start » 2025-05-19 01:15:51

#54 Re: Hardware & System Configuration » [SOLVED] zramswap script won't start » 2025-05-18 23:20:23

#55 Hardware & System Configuration » [SOLVED] zramswap script won't start » 2025-05-18 15:57:46

#56 Re: Installation » [SOLVED] Problem with Failed to execute login command - Daedalus » 2025-05-17 13:44:51

#57 Re: Installation » [SOLVED] Problem with Failed to execute login command - Daedalus » 2025-05-17 09:13:40

#58 Re: Hardware & System Configuration » Which Trackball device? » 2025-05-17 02:07:42

#59 Re: Hardware & System Configuration » [SOLVED] Compressor lz4 not available » 2025-05-17 00:42:16

#60 Re: Installation » [SOLVED] Problem with Failed to execute login command - Daedalus » 2025-05-16 22:18:37

#61 Re: Installation » [SOLVED] Problem with Failed to execute login command - Daedalus » 2025-05-16 20:55:45

#62 Hardware & System Configuration » [SOLVED] Compressor lz4 not available » 2025-05-16 20:36:39

#63 Re: Installation » [SOLVED] Problem with Failed to execute login command - Daedalus » 2025-05-16 16:31:27

#64 Re: Hardware & System Configuration » [SOLVED] USB with *.iso image not detected in BIOS boot netbook » 2025-05-15 13:00:27

#65 Re: Hardware & System Configuration » [SOLVED] USB with *.iso image not detected in BIOS boot netbook » 2025-05-14 12:27:19

#66 Re: Hardware & System Configuration » [SOLVED] USB with *.iso image not detected in BIOS boot netbook » 2025-05-13 21:42:22

#67 Re: Hardware & System Configuration » [SOLVED] USB with *.iso image not detected in BIOS boot netbook » 2025-05-13 12:18:20

#68 Re: Hardware & System Configuration » [SOLVED] USB with *.iso image not detected in BIOS boot netbook » 2025-05-13 00:14:23

#69 Re: Hardware & System Configuration » [SOLVED] USB with *.iso image not detected in BIOS boot netbook » 2025-05-12 23:37:56

#70 Re: Hardware & System Configuration » [SOLVED] USB with *.iso image not detected in BIOS boot netbook » 2025-05-12 19:21:58

#71 Re: Hardware & System Configuration » [SOLVED] USB with *.iso image not detected in BIOS boot netbook » 2025-05-12 14:28:50

#72 Re: Hardware & System Configuration » [SOLVED] USB with *.iso image not detected in BIOS boot netbook » 2025-05-12 11:49:44

#73 Hardware & System Configuration » [SOLVED] USB with *.iso image not detected in BIOS boot netbook » 2025-05-11 22:47:59

#74 Off-topic » The tide is turning » 2025-05-09 07:18:47

#75 Re: Devuan » Update of Devuan causes VirtualBox shared folder corruption » 2025-05-05 12:27:36

Board footer