"Loading vmlinuz... failed. Bad file number"

[Ed_P]

Since I not plan on installing a Windoze on that machine ever again, why should I leave the sdfa1 as NTFS?

I'm talking about defraging the vmlinuz file that is causing your boot problem not what format the drive is.

You not answered my question about ext4 being supported by the Porteus bootloader creation script or not.

I have no idea. It is not something that I have experience with.

[Rava]

I'm talking about defraging the vmlinuz file that is causing your boot problem not what format the drive is.

Copied the vmlinuz_Porteus_5.4.30_x86_64 file to an external HD's ext3 partition, removed it from sda1 and copied it back from the ext3 drive.
Now I must look into porteus.cfg and see if it needs adjustment and then when I have no urgent emails or such to write or receive I can reboot any try booting that kernel from sda1.

[Ed_P]

Copied the vmlinuz_Porteus_5.4.30_x86_64 file to an external HD's ext3 partition, removed it from sda1 and copied it back from the ext3 drive.

Not what I suggested. By removing it you opened up the same broken cluster chains for it to be copied back into. Thus it may be fragmented again.

[Rava]

Not what I suggested. By removing it you opened up the same broken cluster chains for it to be copied back into. Thus it may be fragmented again.

No, a file gets copied to randomly chosen areas on a disk. The change a file gets the very same areas as previously is very slim.

Or you could use the GParted approach to defrag it.

I think a much quicker way is this:

● Start Porteus using an external approach - and not sda1 even when there are only symlinks to another sdaN partition on it - e.g. start from an USB thumbdrive or from an external USB harddrive.

then

● Copy everything on sda1 to a different drive.
● wipe all data on sda1
● First create all folders and subfolders in sda1
● Move the most important files not to be fragmented back first, e.g. all kernel and initrd files
● Move back all the rest of the files.

Still no 100% guarantee that no files are fragmented, but it is a high chance at least the kernel files are not.

Your thoughts?

The

Use Gparted to defrag your file system

approach is not possible because of this

You also have to have more unused space available than used space for this to work

[Ed_P]

Your thoughts?

If you feel more comfort with your slower approach to verify my suggested cause of the problem do it.

[Rava]

If you feel more comfort with your slower approach to verify my suggested cause of the problem do it.

Your approach means:

a filesystem which has most likely small areas scattered around all over it
where you copy a file onto, most likely getting that file fragmented as well due to the above.

What is quicker with that approach?

[Ed_P]

Your approach means:

a filesystem which has most likely small areas scattered around all over it
where you copy a file onto, most likely getting that file fragmented as well due to the above.

May be, or may be not. But it doesn't take long to find out. Will the problem be resolved with your approach? May be, or may be not.

Consider the number of installs of vmlinuz over the years, and relate that to the number of reports of "Bad file number" related to it. None of the installs of vmlinuz on all the various types of drives and formats were not fragmented except for yours! May be or may be not.

Choose whatever approach you will feel most comfortable with to prove the cause/solution to the problem. Then implement the best solution.

[Rava]

Choose whatever approach you will feel most comfortable with to prove the cause/solution to the problem. Then implement the best solution.

I wrote ncmprhnsbl a PM about " Can the Porteus installer handle ext4 as internal boot partition? " I wait till he replied.

[Rava]

Formatted sda1 from NTFS to ext4.
When using a newer initrd now the fsck cheatcode also works on that ext4 partition and reports no issue. (The older initrd complained about some unknown feature of the ext4 partition and would do no fsck and told me to update my fsck … as if updating initrd is that trivial.)

Even when fsck on boot reports no issues on sda1 - sda1 is still unable to boot the kernel from that device. I presume it is the same error message as the screenshot above, still not able to read it myself - most probably I have to record the screen again to see what the boot screen tells me.

It is quite annoying to have to use an external USB stick to be able to boot my correct kernel when loading all of base/ from sda1.

[raja]

Since, all my Hard Disks failed over a period of time I was using only USB disks for the past few years.

Last month I got a 160GB Hard Disk and installed Grub as boot loader.

I made four partitions, three formatted in EXT4 and one in NTFS.

No OS in SDA1. Ubuntu Budgie ISO and APorteus ISO are there in this partition. I rarely boot them.

SDA2 has few versions of Porteus, and Nemisis .

I have no problem at all in booting any of them.

So Hard Disk or EXT4 have no issues at all.

MY grub menu:

Code: Select all

set timeout=30

loadfont unicode

set menu_color_normal=white/black
set menu_color_highlight=black/light-gray

menuentry "Nemisis-New" {
set gfxpayload=keep
#search --set=root --fs-uuid 46d2baf8-5a05-4013-9593-128a4c07e592
linux (hd0,msdos1)/boot/vmlinuz-5.12.18
initrd (hd0,msdos1)/boot/initrd-new.xz
}

menuentry "Porteus-5.0" {
set gfxpayload=keep
search --set=root --fs-uuid 46d2baf8-5a05-4013-9593-128a4c07e592
linux (hd0,msdos1)/boot/vmlinuz-5.15.11
initrd (hd0,msdos1)/boot/initrd-5.0-rc3.xz
}

I have many more entries, but irrelevant here.

In one I have commented out set root(SDA2)

Grub finds both and boots. The machine also have a couple of USB disks plugged in.

Note that vmlinuz and initrd for all of them are placed in boot folder ,SDA1(hd0,msdos1)

[Rava]

Note that vmlinuz and initrd for all of them are placed in boot folder ,SDA1(hd0,msdos1)

By that you mean sda1 is VFAT or NTFS?

And I started with the default 1.5GB sda1 boot partition of SM-Witless-OS 7 (in the meantime SM-W-7 terminated itself, I booted it maybe once a year for a few hours only, never went online with it and never updated anything.) and then the error with the kernel occurred.

Therefore I used fdisk and mkfs.ext4 to reformat sda1 from ntfs to ext4.

Sadly no one seems to know what the reason for the "Loading vmlinuz... failed. Bad file number" is, and a DDG search also gave no helpful info.

Added in 3 minutes :
Just once again I DDG'd "Loading vmlinuz... failed. Bad file number" and guess what? The first hit is page two of this very thread.

[raja]

SDA1 , as informed, is EXT4.

Porteus and nemisis have no problem with ext4 formatted HDD.