Devuan Daedalus: /i386-pc/normal.mod not found

Altoid · 2025-01-10 09:06:47

Hello:

I dd'd devuan_daedalus_5.0.1_amd64_netinstall.iso to an 4.0Gb SD card.
Then installed it on an 8.0Gb USB stick.
The usual precautions taken:

- checked SHA256 of the downloaded *.iso
- installer check of the installation media before anything else

This is how the USB is partitioned:

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

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sdg1  *        2048  4190207  4188160    2G 83 Linux
/dev/sdg2        4192254 15151103 10958850  5.2G  5 Extended
/dev/sdg5        4192256 14741503 10549248    5G 83 Linux
/dev/sdg6       14743552 15151103   407552  199M 82 Linux swap / Solaris
#

On booting the USB, I get this:

GRUB loading.
Welcome to GRUB!

error: file ` /boot/grub/i386-pc/normal.mod not found.
grub rescue>

The installation was run on my Sun Ultra 24 which is not hampered by att the UEFI whatever crap.
Just plain BIOS boot, thank you.

It is as bare as could be (still needs a good clean-up) as I want to use it to run Clonezilla-Live.
Just the defaults, no desktop enviroment.cd.

When I mount the drive, CD to /boot, I get this:

$ /boot/grub$ ls
grub.cfg  splash.png  unicode.pf2
$

Seems that grub is pointing to my system drive UUID ...

search --no-floppy --fs-uuid --set=root d6841f29-e39b-4c87-9c52-3a9c3bafe2d3

... instead of pointing to the USB UUID:

# blkid
--- snip ---
/dev/sdb1: LABEL="devuan" UUID="d6841f29-e39b-4c87-9c52-3a9c3bafe2d3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0004a8f4-01"
--- snip ---
/dev/sdg1: UUID="68f8d933-a2a1-40eb-916f-eba5582c8968" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="db4d27ce-01"
--- snip ---
#

No idea how that happened, but it did.

Question:
Manually changing all instances of the system UUID for the correct one will do?
If not, which is the easiest/fastest way to fix this?

Thanks.

Best,

A.

ralph.ronnquist · 2025-01-10 10:13:00

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.

Altoid · 2025-01-16 23:24:19

Hello:

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

ralph.ronnquist wrote:

... it would amount to chroot onto the target and then run update-grub ...

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.

RedGreen925 · 2025-01-17 00:57:02

[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

I find it hard to believe you could have file system errors on first boot of the operating system. That to me suggest corruption during the install. Have you created a memtest86+ boot disk and let it run a few passes to confirm the memory is still in good shape. Also where does the 6.10 kernel come from? That is not the stock kernel on that install disk.

Altoid · 2025-01-17 05:05:59

Hello:

RedGreen925 wrote:

... hard to believe you could have file system errors on first boot ...

It is all in the screen printout.

RedGreen925 wrote:

... suggest corruption during the install.

Could be, no idea what it is.

RedGreen925 wrote:

... memtest86+ boot disk and let it run a few passes ...

Have not done that in a while but then have not had any motive to suspect memory corruption at any point.

This box runs many hours a day every day of the year.
If there were any sort of memory corruption, I would have had memory errors before now.
And they would have shown up in the usual places. eg: dmesg ECC error printout

... where does the 6.10 kernel come from? ...

This is devuan_daedalus_5.0.1_amd64_netinstall.iso | 15-Apr-2024 22:38 | 478M

Comes from the same place every other Daedalus

It is the same kernel my box runs on:

$ uname -a
Linux devuan 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux
$

Thanks for your input.

Best,

A.

RedGreen925 · 2025-01-17 05:13:26

Loading Linux 6.10.0-10-AMD64 ...

Is from the output you post so it is not the same kernel. That is why I asked that question. If you do not try a memtest the only other thing I can suggest is junk USB controller/driver for the controller. There is no way a fresh install should have a corrupted file system unless something causes that corruption while booting. That comes down to memory, controller or device used to boot with. It seems unlikely a new stick would be useless, one way to test that is use it on another device and see if it boot there.

ralph.ronnquist · 2025-01-17 06:04:07

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.

Altoid · 2025-01-17 10:32:33

Hello:

... installation ISOs are set up as "Hybrid ISOs". This means that the ISO is a union of two ...
... like this (in beautiful ascii art):

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.

... fools grub's intelligent install logic ...

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

... need to exercise some manual hands-on ...
... where doing it right using the rescue mode.

Good to know.
Buy still no joy.

... cannot install linux onto a FAT32 partition ...

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.

Altoid · 2025-01-17 11:10:59

Hello:

... try a memtest ...

Yes, there's also memtester which I am putting to work now.

# memtester 4096 5
memtester version 4.6.0 (64-bit)
Copyright (C) 2001-2020 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).
--- snip ---

Between the OS and memtester 78% of available RAM is being used.

... only other thing I can suggest is junk USB controller/driver for the controller.

The on board USB2.0 controller has always worked perfectly well.
As for the driver(?), it is the one from this distribution.

... no way a fresh install should have a corrupted file system ...

I'll take your word for that but then, the installer should have written GRUB to the USB stick and it did not.

... unlikely a new stick would be useless ...

Agreed.

... use it on another device and see if it boot there.

The only amd64 box I have is this one.
My other one is an Asus 1000HE. (32 bit)

I will see about running a test to do an intensive write from one USB drive to another.
Data corruption in the controller (if that is the case) should show up there.

Thanks for your input.

Best,

A.

Last edited by Altoid (2025-01-17 11:11:45)

ralph.ronnquist · 2025-01-17 11:30:34

Sometime in life I have met USB sticks that refuse to change the first 440 bytes which is where the leagcy bios boot loader gets written. You should check that your sticks don't have that problem: e.g. write some certain data to there, take the USB out, eat an apple, plug in the USB ideally in a different port, then verify that data.

Do that twice with different data, to confirm that your data gets written and is preserved.

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

Next, use the rescue approach to chroot to the target file system and install grub-pc as well as to run a manual grub-install /dev/sdg . (You might need to mount /dev and /proc for the latter; I'm not sure if the rescue entry has done chroot and those mounts)

Altoid · 2025-01-17 12:45:50

Hello:

... met USB sticks that refuse to change the first 440 bytes ...

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.

... check that your sticks don't have that problem: e.g. write some certain data to there, take the USB out, eat an apple, plug in the USB ideally in a different port, then verify that data.

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

... twice with different data, to confirm that your data gets written and is preserved.

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.

... use the rescue approach to chroot to the target file system and install grub-pc as well as to run a manual grub-install /dev/sdg.

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.

Altoid · 2025-01-17 16:02:49

Hello:

Update:

Altoid wrote:

... memtester which I am putting to work now.

# memtester 4096 5
memtester version 4.6.0 (64-bit)
Copyright (C) 2001-2020 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).
--- snip ---

Memtester ran 5 loops for ~360 minutes and all of them came up with no failures, like this one:

--- snip ---
Loop 1/5:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok         
  Block Sequential    : ok         
  Checkerboard        : ok         
  Bit Spread          : ok         
  Bit Flip            : ok         
  Walking Ones        : ok         
  Walking Zeroes      : ok         
  8-bit Writes        : ok
  16-bit Writes       : ok

Loop 2/5:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
--- snip ---

I think that can most probably rule out any memory corruption issues.
The testing continues.

Best,

A.

Altoid · 2025-01-17 23:27:25

Hello:

Altoid wrote:

... testing continues.

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.

RedGreen925 · 2025-01-18 00:39:53

At this point looks like it is the installer itself then with it passing all those tests. An idea since you have grub installed on the disk just clone your install to the stick either while booted into it or booted from an install disk. The install disk is simplest way to do it as it is a straight up rsync command from the mounted install partition to the USB stick partition. As root or with sudo in front of the commands.

mkdir /tmp/oldroot
mkdir /tmp/newroot
mount /dev/sd?? /tmp/oldroot
mount /dev/sd?? /tmp/newroot
rsync -avP /tmp/oldroot/* /tmp/newroot/
blkid                <---- use to get old and newroot drive UUIDs
sed -i "s/oldroot_UUID/newroot_UUID/g" /tmp/newroot/boot/grub/grub.cfg
sed -i "s/oldroot_UUID/newroot_UUID/g" /tmp/newroot/etc/fstab

Now when I do this on EFI system never having done a MBR I have to change the UUID to the new root in the /boot/efi/EFI/debian/grub.cfg. Once that is done I have identical copy of the drive in the machine ready to boot on the drive it was cloned to. It works without fail so many times I have lost count of the times I have used that script I wrote to do this. If there are no other files that grub uses in booting a MBR drive other than those I show it should just boot your present install that was cloned onto the USB disk when put into your SUN machine. If wanting to do it from running machine then the rsync becomes this from my script. If logged into a graphical session with the /home directory in use then there are many other things that need to be excluded in that situation.

rsync -ahPHAXx --delete --exclude={/boot/efi/*,/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/swapfile,/lost+found} / /tmp/root/

This excludes everything that should not be copied from a running system as it is recreated on every boot unique to that boot. In my script the target for the copy is the /tmp/root/ that gets created by it. Something to try if it turns out the install disk is the problem as a way to get an OS on the USB stick. Now I look over it again if you have any other partitions being used you need to change them UUIDs as well on the USB stick fstab to those new UUIDs as well as copy them over.

Altoid · 2025-01-18 12:19:05

Hello:

... looks like it is the installer itself then with it passing all those tests.

Yes, that was my thought from the start.
And unless anyone can come up with a better/more reasonable explanation to what is going on, it would seem that that is what we are seeing.

Not a good sign.

BTW:
Installing GRUB as described in my previous post was not followed through with the needed grub-update so I was left with a grub rescue > prompt on my screen ('grub_file_filters' not found) and the USB drive behaving as before.

I recovered my system drive this morning (the easy way) with a Super Grub2 image Super Grub2 for non-UEFI systems.
I was not feeling lucky and did not want to risk screwing up any further.

---
I should learn to do it the old way / manually ie: via grub rescue >.
One day I may not have anything else at hand and then, what?

I have always thought that the day will come when the only way to get anything done properly, securely and without any restraints/controls will be by being proficient in command line at the terminal. Seems it may be sooner than later.

But I digress ...
---

The purpose behind my wanting to install a very small footprint Devuan on small capacity SD/MicroSD cards was to 1. make use of a few I had and 2. put together a Devuan based Clonezilla-Live (it is Debian based) to always have at hand or to boot into from an on-board USB socket my system MB has.

That went awry when I was not able to install Devuan on any card or USB stick (old or brand new), the results being those reported in my OP and others.

It would be great if anyone with non-UEFI hardware could run a test to see if they get the same / similar result.

Thanks in advance.

Best,

A.

ralph.ronnquist · 2025-01-18 13:26:24

Yes, I thought I told you that it appears grub gets confused upon seeing the EFI partition of the installer, making it jump to the conclusion that the system has UEFI bios.

Probably that logic is in the grub udeb that gets installed into the installer (for the grub installation step and dialog). Though afaik it's not a forked package, but it would be good to have someone making a focussed effort on isolating the problem in detail for lodging a bug report about it.

RedGreen925 · 2025-01-18 14:20:13

The purpose behind my wanting to install a very small footprint Devuan on small capacity SD/MicroSD cards was to

As they say around here " there is more than one way to skin a cat" no clue why they pick a cat but the gist of it is there is always more than one option. Go to the source Debian, get the netinstall .iso do a minimal install then convert it to Devuan. That is how I got it on the box the Devuan installer will not boot on my machine, actually I just cloned my machine's Debian install and did the conversion. You get to test if the changes made by Devuan are the problem or if the Debian installers are the problem. Or do the cloning I have suggested before.

Altoid · 2025-01-18 15:53:15

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?

... afaik it's not a forked package ...
... good to have someone making a focussed effort ...
... lodging a bug report ...

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

bugs.debian.org wrote:

Hi,
Since sysvinit is not enabled by default in Debian, I do not consider this
bug as release-critical. Downgrading the bug severity to "normal".

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

bugs.debian.org wrote:

Hi,
Since UEFI boot is the default configuration for Debian, I do not consider this
bug as release-critical. Downgrading the bug severity to "normal".

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.

Altoid · 2025-01-18 16:10:40

Hello:

... get the netinstall .iso do a minimal install ...

See my previous post.
The problem also crops up with a Debian *.iso.

... test if the changes made by Devuan ...

Apparently, the Debian installer has not been forked by Devuan, so it is the same one save for some branding and such things.

Or do the cloning ...

Could be.
But I need something more straightforward than that.

Thanks for your input.

Best,

A.

RedGreen925 · 2025-01-18 16:22:19

The problem also crops up with a Debian *.iso.

It appears you have solved the grub problem and as you mention good luck getting Debian people to do anything about it. Their "we care about our users" is nothing but words written down to make them feel better about themselves while doing exactly the opposite. They will ship known broken packages and do nothing to fix them because their policy says not to, unless of course they want to do the opposite then the fix gets made policy be damned. I have seen this hypocrisy in action for decades now.

Altoid · 2025-01-18 17:46:18

Hello:

... solved the grub problem ...

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.

greenjeans · 2025-01-18 18:29:15

@Altoid, THANK YOU!! I'm sorry I don't have a good answer to your problem, but you just helped me solve one of mine that's been bugging me for a few weeks now with this portion of your post:

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.

This is the same problem i've had with Mintstick, it's super-fast and does a nice job in a hurry, but it also creates that ISO9660 fs that takes up the whole stick when in fact the iso is only 1.2 gigs, and i've been wanting a second partition just for data, not persistence, just data so when I rescue files from older PC's I have a place to store them easily.

Installed the gnome-disk-utility you mentioned, and it showed me the installed system was on it's own partition and the rest was literally empty space, just freakin empty space.

In it's menu if offered me the option of creating a new partition using that empty space, I did so and named it "DATA" and it worked perfectly and really fast, posting now from a liveUSB session using that very stick.

So again, big-time thank you and I hope you get your issue worked out!

Altoid · 2025-01-18 19:31:00

Hello:

greenjeans wrote:

... but you just helped me solve one of mine ...

You're welcome, but all merit belongs ralph.ronnquist.

Not being at all familiar with all this UEFI crap, I just asked the question because it seemed odd that gparted showed me one thing and disks another.
Maybe it is time for gparted to make the necessary adjustments.

Ralph's explanation as to how it works (+the ascii art) is what set you on the right track.

Best,

A.

Last edited by Altoid (2025-01-18 19:32:30)

RedGreen925 · 2025-01-18 23:34:40

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

As you have figured out their broken installer will not let you do that, you are stuck with the work around you have used. Just like I finally figured out last year why the damn thing does not respect your choice for the /boot/efi partition you get to set when using manual partitioning as I always do. The damn thing per-selects every efi partition in the system for use as an efi system partition. Unless you go to every single one of them and de-select your choice is ignored depending on its position in the drive listing on that page. If your drive is third in the list then you damn well better make certain that one and two is not selected or those will be used before your choice. If last in list with more drives then every other partition needs to be de-selected before your choice will be used.

ralph.ronnquist · 2025-01-18 23:50:31

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.

The officially official Devuan Forum!

#1 2025-01-10 09:06:47

Devuan Daedalus: /i386-pc/normal.mod not found

#2 2025-01-10 10:13:00

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#3 2025-01-16 23:24:19

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#4 2025-01-17 00:57:02

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#5 2025-01-17 05:05:59

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#6 2025-01-17 05:13:26

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#7 2025-01-17 06:04:07

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#8 2025-01-17 10:32:33

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#9 2025-01-17 11:10:59

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#10 2025-01-17 11:30:34

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#11 2025-01-17 12:45:50

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#12 2025-01-17 16:02:49

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#13 2025-01-17 23:27:25

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#14 2025-01-18 00:39:53

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#15 2025-01-18 12:19:05

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#16 2025-01-18 13:26:24

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#17 2025-01-18 14:20:13

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#18 2025-01-18 15:53:15

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#19 2025-01-18 16:10:40

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#20 2025-01-18 16:22:19

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#21 2025-01-18 17:46:18

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#22 2025-01-18 18:29:15

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#23 2025-01-18 19:31:00

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#24 2025-01-18 23:34:40

Re: Devuan Daedalus: /i386-pc/normal.mod not found

#25 2025-01-18 23:50:31

Re: Devuan Daedalus: /i386-pc/normal.mod not found

Board footer