Testuser wrote: ↑29 Sep 2022, 20:35
Have you tried a different kernel or this is happening for all kernels?
[…]
Hope you checked the file hash
This happens only with the one kernel I need for my NVidia driver and I sure did check the hash, even using a better hash than md5sum:
On my internal boot device
Code: Select all
root@porteus:/mnt/sda1/boot# sha256sum vmlinuz_Porteus_5.4.30_x86_64
6a1f68308ce54b68149b266709f20c533235cdd495da69004408adb49cd132fd vmlinuz_Porteus_5.4.30_x86_64
root@porteus:/mnt/sda1/boot# l vmlinuz_Porteus_5.4.30_x86_64
-rw-r--r-- 1 root 4322688 2020-04-04 20:23 vmlinuz_Porteus_5.4.30_x86_64
and on my external 2GB SD-card via USB reader:
Code: Select all
root@porteus:/mnt/sdc1/boot/syslinux# sha256sum vmlinuz
6a1f68308ce54b68149b266709f20c533235cdd495da69004408adb49cd132fd vmlinuz
root@porteus:/mnt/sdc1/boot/syslinux# l vmlinuz
-rw-r--r-- 1 root 4322688 2020-04-04 21:23 vmlinuz
Even sha256sum reports the two kernels as being identically.
And it is not because of the differing path of the kernel (/mnt/sda1/
boot vs /mnt/sdc1/
boot/syslinux) that it fails. Other kernels are loading just fine that sit in the same path than the vmlinuz_Porteus_5.4.30_x86_64 one:
Code: Select all
root@porteus:/mnt/sda1/boot# l vmlinuz*Porteus*
-rw-r--r-- 1 root 3855120 2018-04-22 20:25 vmlinuz_Porteus_4.0_x86_64
-rw-r--r-- 1 root 4318592 2020-02-12 02:24 vmlinuz_Porteus_5.4.19_x86_64
-rw-r--r-- 1 root 4322688 2020-04-04 20:23 vmlinuz_Porteus_5.4.30_x86_64
It's an unsolved mystery for now.
I even reformatted the sda1 from NTFS (it was the broken SM-Witless-7 1.5 GB boot partition) into ext4 [realizing the initrd used back then is unable to perform fsck on ext
4] - all to no avail.
EDIT1
Doing the above checks I realized something.
While my system should be set up in using the kernels from /mnt/sda1/boot - I happen to also have a 2nd version of vmlinuz_Porteus_5.4.30_x86_64 sitting in /mnt/sda1/boot/syslinux and up to now unbeknownst to me this very one differs in its hash indeed:
Code: Select all
root@porteus:/mnt/sda1/boot/syslinux# sha256sum vmlinuz_Porteus_5.4.30_x86_64
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 vmlinuz_Porteus_5.4.30_x86_64
So it was simply a corrupted file all along, and the porteus initrd seems to first look in [device]/boot/syslinux and after that it looks into [device]/boot/ - but when being instructed in loading vmlinuz_Porteus_5.4.30_x86_64 it uses the one in [device]/boot/syslinux - and when loading others it discards the vmlinuz_Porteus_5.4.30_x86_64 one in [device]/boot/ but loads one of the others in there.
Finally mystery solved. I look like a dumdum now
but me not cares, better having to admit I did overlook one single thing - still
finally having solved the mystery (success is only guaranteed when booting from sda1 finally succeeds...)
I now will overwrite /mnt/sda1/boot/syslinux/vmlinuz_Porteus_5.4.30_x86_64 with /mnt/sda1/boot/vmlinuz_Porteus_5.4.30_x86_64 - check it via sha256sum and then try once again booting from sda1.
EDIT2
Prior copying:
Code: Select all
root@porteus:/mnt/sda1/boot/syslinux# sha256sum vmlinuz_Porteus_5.4.30_x86_64 ../vmlinuz_Porteus_5.4.30_x86_64
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 vmlinuz_Porteus_5.4.30_x86_64
6a1f68308ce54b68149b266709f20c533235cdd495da69004408adb49cd132fd ../vmlinuz_Porteus_5.4.30_x86_64
copying and new sha256sum check
Code: Select all
root@porteus:/mnt/sda1/boot/syslinux# cp ../vmlinuz_Porteus_5.4.30_x86_64 .
/bin/cp: overwrite './vmlinuz_Porteus_5.4.30_x86_64'? y
root@porteus:/mnt/sda1/boot/syslinux# sha256sum vmlinuz_Porteus_5.4.30_x86_64 ../vmlinuz_Porteus_5.4.30_x86_64
6a1f68308ce54b68149b266709f20c533235cdd495da69004408adb49cd132fd vmlinuz_Porteus_5.4.30_x86_64
6a1f68308ce54b68149b266709f20c533235cdd495da69004408adb49cd132fd ../vmlinuz_Porteus_5.4.30_x86_64
When I next reboot I try remembering doing it from the internal device - and then we will see. By all logic now it should boot fine and the "Bad file number" should be finally an issue of the past.
Added in 36 minutes 31 seconds:
I even used
https://www.futureme.org to send two letters to the future me - one to be delivered in one week and the other in two weeks - asking future me if I did indeed boot internally when booting for the next time:
</geek>