Page 1 of 2
"Loading vmlinuz... failed. Bad file number"
Posted: 30 Oct 2021, 15:56
by Rava
Booting my default kernel vmlinuz_Porteus_5.4.30_x86_64 from the internal harddisc fails. To see the error message I had to record the boot screen since it switches back to the boot selection in a split second:
Code: Select all
Loading vmlinuz_Porteus.5.4.30_x86_64... failed. Bad file number
See screenshot, the end is hard to read:
The md5sums of the vmlinux 5.4.30_x86_64 kernel from the USB thumbdrive that boots okay is the same than the version on the internal hard drive ( f5df3c96f73367689085585bd438b6e7 ) that gives this error.
So what does this "Bad file number" mean? file reads the vmlinuz_Porteus_5.4.30_x86_64 file okay:
Code: Select all
root@porteus:/1/boot# file vmlinuz
vmlinuz: symbolic link to vmlinuz_Porteus_5.4.30_x86_64
root@porteus:/1/boot# file vmlinuz_Porteus_5.4.30_x86_64
vmlinuz_Porteus_5.4.30_x86_64: Linux kernel x86 boot executable bzImage, version
5.4.30-porteus (root@porteus) #1 SMP Sat Apr 4 20:11:00 UTC 2020, RO-rootFS, swap_dev 0x4, Normal VGA
The two used initrd's from the USB thumbdrive and internal harddrive also have the same md5sum: ee8fd5662737b8385d51592982075645
I also removed the kernel file and copied it anew, again the md5sum is still the same, and again, the same error at boot time "Loading vmlinuz_Porteus.5.4.30_x86_64... failed. Bad file number" or "Loading vmlinuz... failed. Bad file number"
So for now, I can load the modules from the internal drive okay via from=UUID:What-EvEr/Porteus_5.0rc3e … but I would like to be able to boot just from the internal hard drive (initrd and
kernel), still the need to load the initrd and kernel from USB thumbdrive persists.
"Loading vmlinuz... failed. Bad file number"
Posted: 30 Oct 2021, 16:49
by beny
hi maybe the vmlinuz is corrupt,but if you have a backup you can restore it.
"Loading vmlinuz... failed. Bad file number"
Posted: 30 Oct 2021, 17:51
by raja
rename kernel as vmlinuz-5.4.30 with corresponding change in porteus.cfg.
run fsck.ext4 /dev/sdax
If the hdd partition is clean, there shouldn't be any problem
"Loading vmlinuz... failed. Bad file number"
Posted: 31 Oct 2021, 06:47
by Rava
beny wrote: ↑30 Oct 2021, 16:49
hi maybe the vmlinuz is corrupt,but if you have a backup you can restore it.
Like I wrote - md5sum is identical
I already copied the working vmlinuz to sda1 - once as vmlinuz and once as vmlinuz_Porteus.5.4.30_x86_64, with corresponding change in porteus.cfg, all resulting in the same error.
I presume for fsck I have to load my system completely from external USB thumbdrive or external harddisk…
Is there a newer fsck.ntfs available than the one shipped with Port 5.0rc3 x86-64?
In i586 Port 4.0 that I am currently on only has these
Code: Select all
root@porteus:~# fsck.
fsck.aufs fsck.ext3 fsck.f2fs fsck.msdos fsck.tmpfs
fsck.cramfs fsck.ext4 fsck.fat fsck.reiserfs fsck.vfat
fsck.ext2 fsck.ext4dev fsck.minix fsck.rootfs fsck.xfs
root@porteus:~# ntfs
ntfs-3g ntfsclone ntfscp ntfslabel ntfsundelete
ntfs-3g.probe ntfscluster ntfsfix ntfsls
ntfscat ntfscmp ntfsinfo ntfsresize
(I used [tab] to let bash show me what's available)
"Loading vmlinuz... failed. Bad file number"
Posted: 31 Oct 2021, 19:58
by ncmprhnsbl
Rava wrote: ↑31 Oct 2021, 06:47
Is there a newer fsck.ntfs available than the one shipped with Port 5.0rc3 x86-64?
there is no such thing..
https://wiki.archlinux.org/title/NTFS-3 ... ilesystems
for others, try the
fsck cheatcode, which uses fsck* that is in initrd.xz
"Loading vmlinuz... failed. Bad file number"
Posted: 31 Oct 2021, 20:20
by beny
hi rava this one in slackware current:/mnt/sdb1/root/slackware/slackware64-current/slackware64/a/ntfs-3g-2021.8.22-x86_64-1.txz but the ntfs3 of paragon are merged into the 5.15 kernel and are listed into the neko's configure
"Loading vmlinuz... failed. Bad file number"
Posted: 31 Oct 2021, 22:08
by Rava
beny wrote: ↑31 Oct 2021, 20:20
hi rava this one in slackware current:/mnt/sdb1/root/slackware/slackware64-current/slackware64/a/ntfs-3g-2021.8.22-x86_64-1.txz
beny… what a weird … URL
found
https://slackware.uk/slackware/slackwar ... 6_64-1.txz
viA
https://slackware.pkgs.org/
downloaded, now transferring to the correct machine and setting up USB only boot.
beny wrote: ↑31 Oct 2021, 20:20
but the ntfs3 of paragon are merged into the 5.15 kernel and are listed into the neko's configure
I can use other kernel? Since my nvidia driver only compiled for 5.4.30 as newest kernel…
Porteus 5.0rc1 and rc2 NVidia 340.108 driver for older hardware for kernel 5.4.30 - works also for 5.0rc3.
"Loading vmlinuz... failed. Bad file number"
Posted: 31 Oct 2021, 22:33
by beny
hi isn't a url sorry, just for the record i know you have build the old nvidia driver is ok
"Loading vmlinuz... failed. Bad file number"
Posted: 01 Nov 2021, 07:13
by Rava
ntfsfix found no error, ntfsinfo is less helpful; while it prints info at the end it persists of failing to open the device it just printed info about.
Code: Select all
root@porteus:/1/Boot# ntfsfix --version|head -n 1
ntfsfix v2021.8.22
root@porteus:~# ntfsfix /dev/sda1
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... FIXED
NTFS volume version is 3.1.
NTFS partition /dev/sda1 was processed successfully.
root@porteus:~# ntfsinfo -m /dev/sda1
Volume is scheduled for check.
Please boot into Windows TWICE, or use the 'force' option.
NOTE: If you had not scheduled check and last time accessed this volume
using ntfsmount and shutdown system properly, then init scripts in your
distribution are broken. Please report to your distribution developers
(NOT to us!) that init scripts kill ntfsmount or mount.ntfs-fuse during
shutdown instead of proper umount.
Failed to open '/dev/sda1'.
Here all my vmlinuz of my internal first partition and their md5sum
Code: Select all
root@porteus:/1/Boot# ls -o vmlinuz*
-rwxrwxrwx 1 root 4322688 2020-04-04 20:23 vmlinuz
-rwxrwxrwx 1 root 3576672 2015-05-30 13:30 vmlinuz64
-rwxrwxrwx 1 root 0 2017-11-12 04:36 vmlinuz64_is_TinyCorePure64-6.3
-rwxrwxrwx 1 root 3855120 2018-04-22 20:25 vmlinuz_Porteus_4.0_x86_64
-rwxrwxrwx 1 root 4384128 2019-05-26 00:00 vmlinuz_Porteus_5.0rc1_x86_64
-rwxrwxrwx 1 root 3978112 2019-02-24 00:00 vmlinuz_Porteus_5.0rc1d_x86_64
-rwxrwxrwx 1 root 4330880 2020-08-09 00:00 vmlinuz_Porteus_5.0rc2_x86_64
-rwxrwxrwx 1 root 4318592 2020-02-12 02:24 vmlinuz_Porteus_5.4.19_x86_64
-rwxrwxrwx 1 root 4322688 2020-04-04 20:23 vmlinuz_Porteus_5.4.30_x86_64
-rwxrwxrwx 1 root 2248032 2010-07-14 14:43 vmlinuz_quirkyNOP120
root@porteus:/1/Boot# md5sum vmlinuz*
f5df3c96f73367689085585bd438b6e7 vmlinuz
c4f46b5cd826d7a765a3e85439309cfc vmlinuz64
d41d8cd98f00b204e9800998ecf8427e vmlinuz64_is_TinyCorePure64-6.3
1c642ff455d89ba59ebbd93222712bfc vmlinuz_Porteus_4.0_x86_64
bceeb13f2e102d59af577d3e40f54bfa vmlinuz_Porteus_5.0rc1_x86_64
fff901330ceb38ef836137ee8cd50a6d vmlinuz_Porteus_5.0rc1d_x86_64
4309801d9bc0e7d575812ed23a92bf9d vmlinuz_Porteus_5.0rc2_x86_64
e2197abb9d338d66690068ad5e3c1503 vmlinuz_Porteus_5.4.19_x86_64
f5df3c96f73367689085585bd438b6e7 vmlinuz_Porteus_5.4.30_x86_64
a32329edbcfb9c0717a7c5e98ea6a032 vmlinuz_quirkyNOP120
same for initrd
Code: Select all
root@porteus:/1/Boot# ls -o initrd*
-rwxrwxrwx 1 root 821660 2020-04-11 00:00 initrd.xz
-rwxrwxrwx 1 root 824160 2018-04-22 20:25 initrd.xz_Porteus_4.0_x86_64
-rwxrwxrwx 1 root 822732 2019-02-24 00:00 initrd.xz_Porteus_5.0rc1d_x86_64
-rwxrwxrwx 1 root 821660 2020-04-11 00:00 initrd.xz_Porteus_5.0rc2_x86_64
-rwxrwxrwx 1 root 1808240 2010-07-14 14:43 initrd_quirkyNOP120.gz
root@porteus:/1/Boot# md5sum initrd*
ee8fd5662737b8385d51592982075645 initrd.xz
2934a6c4b46bc2ab99cddcb4647e6e5c initrd.xz_Porteus_4.0_x86_64
19bd879c9e3b502f67cbcb9baf4422f4 initrd.xz_Porteus_5.0rc1d_x86_64
ee8fd5662737b8385d51592982075645 initrd.xz_Porteus_5.0rc2_x86_64
9a5623b6dbe806ed6d757ef5210af483 initrd_quirkyNOP120.gz
Now the probably strangest part. As you can see above, vmlinuz and vmlinuz_Porteus_5.4.30_x86_64 have the same size and same md5sum.
Still when configuring vmlinuz_Porteus_5.4.30_x86_64 in porteus.cfg I get the error from the screenshot from the initial post.
BUT when I configure vmlinuz instead...
strangely is loads this kernel
Code: Select all
root@porteus:~# uname -a
Linux porteus.example.net 5.4.57-porteus #1 SMP Sun Aug 9 09:03:28 UTC 2020 x86_
64 Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz GenuineIntel GNU/Linux
which is vmlinuz_Porteus_5.0rc2_x86_64. Of course I cannot start X since this kernel not works with my 010-nvidia-340.108-k.5.4.30-porteus-v5.0-x86_64_rava.xzm .
Code: Select all
root@porteus:/1/Boot# file vmlinuz_Porteus_5.0rc2_x86_64
vmlinuz_Porteus_5.0rc2_x86_64: Linux kernel x86 boot executable bzImage, version 5.4.57-porteus (root@porteus) #1 SMP Sun Aug 9 09:03:28 UTC 2020, RO-rootFS, swap_dev 0x4, Normal VGA
root@porteus:/1/Boot# file vmlinuz
vmlinuz: Linux kernel x86 boot executable bzImage, version 5.4.30-porteus (root@porteus) #1 SMP Sat Apr 4 20:11:00 UTC 2020, RO-rootFS, swap_dev 0x4, Normal VGA
I honestly do not get what is going on.
How can loading vmlinuz - which is 5.4.30_x86_64 kernel - load vmlinuz_Porteus_5.0rc2_x86_64 instead?
How can it be that my porteus.cfg seems to do other stuff than what it is configured and told to do?
To make it all complete, here the relevant entry of the internal partition porteus.cfg:
Code: Select all
LABEL xfceRava5.0rc3f
MENU LABEL 5.0rc3f baseV2021-??-?? INTERN XFCE fsck Text mode, RavaStyle
KERNEL vmlinuz
APPEND initrd=initrd.xz from=UUID:Bla-BluBB/Porteus_5.0rc3f ramsize=10% zram=20% timezone=Europe/Berlin volume=75% kmap=de lang=de fsck 3
TEXT HELP
Run Porteus the Rava way:
always fresh - telinit 3 (or
"without starting X")
ENDTEXT
the f in Porteus_5.0rc3
f is my personal numbering and has no reflection on how the 5.0rc3 version is officially named.
"Loading vmlinuz... failed. Bad file number"
Posted: 04 Nov 2021, 23:31
by Rava
^
Still no one with any hints or clues on how to research the issue further?
"Loading vmlinuz... failed. Bad file number"
Posted: 22 Nov 2021, 15:27
by Ed_P
Is it possible your vmlinuz file needs to be defragged?
"Loading vmlinuz... failed. Bad file number"
Posted: 22 Nov 2021, 16:45
by raja
You have not given the correct entries in porteus.cfg and base folder.
I too have many versions of vmlinuz and never ever faced your 'man made' problem.
e.g-i586
My base kernel module is named as '000-kernel-4.4.272.xzm'
My syslinux menuentry is 'KERNEL /boot/syslinux/vmlinuz-4.4.272'
syslinux folder has four more different vmlinuz files, which i use to boot x86_64 os, using the same usb disk.
No problem at all as long as "cfg" or "sgn" files in FOLDER is named different. I edit initrd for different "FOLDER" names and 'sgn',cfg' names.
"Loading vmlinuz... failed. Bad file number"
Posted: 22 Nov 2021, 16:56
by Rava
Ed_P wrote: ↑22 Nov 2021, 15:27
Is it possible your vmlinuz file needs to be defragged?
Could be, but since I have no longer a windoze… I cannot defrag it. All I could do is boot completely from USB without touching any internal drive and format the sda1 from ntfs into e.g.
ext4. After I copied all files and folders on it elsewhere, of course.
It is not a large partition anyway, only 1.5 GB since it is the original Windoze-7 boot partition.
Can the Porteus installer handle ext4 as internal boot partition?
Added in 7 minutes 3 seconds:
raja wrote: ↑22 Nov 2021, 16:45
You have not given the correct entries in porteus.cfg and base folder.
Yes I have. I can boot all other systems e.g. the TinyCore or the Puppy one, and all Porteus ones but the one with the named kernel. I can boot all these systems as well, just with the wrong kernel that would not work with my NVidia driver since I choose the kernel because it is the very last version the NVidia driver could be compiled for. NVidia now simply dropped support for older hardware.
Most likely Ed_P has the reason mentioned above - a fragmented vmlinuz.
Unlike what you presume, how else would all my Porteus variants work flawlessly when I load initrd and vmlinuz from the external USB drive but then use the folders and all in base/ using the UUID cheatcode?
Please do explain: how could booting up the system like that work okay when your assumption I messed up the "correct entries in porteus.cfg and base folder" would be true?
"Loading vmlinuz... failed. Bad file number"
Posted: 22 Nov 2021, 19:10
by Ed_P
Rava wrote: ↑22 Nov 2021, 17:03
your assumption I messed up the "correct entries in porteus.cfg and base folder" would be true?
Typo, error when copy&pasting cfg.
Rava wrote: ↑22 Nov 2021, 17:03
I cannot defrag it.
Copy file to another drive, rename the original file on the boot drive, copy the file on the other drive back to the boot drive.
Or you could use the GParted approach to defrag it.
"Loading vmlinuz... failed. Bad file number"
Posted: 23 Nov 2021, 20:04
by Rava
Ed_P wrote: ↑22 Nov 2021, 19:10
Copy file to another drive, rename the original file on the boot drive, copy the file on the other drive back to the boot drive.
Or you could use the GParted approach to defrag it.
Since I not plan on installing a Windoze on that machine ever again, why should I leave the sdfa1 as NTFS?
You not answered my question about ext4 being supported by the Porteus bootloader creation script or not.