Boot Repair Tool
Boot Repair Tool
Hi Team,
This is a Ubuntu Boot Repair tool.
More info below
https://help.ubuntu.com/community/Boot-Repair
https://www.mediafire.com/file/s0e1bjdm ... i.xzm/file
This tool is for Advanced users only. Changes and alters the Grub and boot files (May cause your system unbootable) .
Only use if you messed up your Boot files or your system is not bootable.
I tested this, GUI is loading and so far most of features are working.
Dont use unless you know what you are doing.
This is a Ubuntu Boot Repair tool.
More info below
https://help.ubuntu.com/community/Boot-Repair
https://www.mediafire.com/file/s0e1bjdm ... i.xzm/file
This tool is for Advanced users only. Changes and alters the Grub and boot files (May cause your system unbootable) .
Only use if you messed up your Boot files or your system is not bootable.
I tested this, GUI is loading and so far most of features are working.
Dont use unless you know what you are doing.
Boot Repair Tool
Thanks Ed_P
Just curious about Linux and trying to learn.
Also always want to help others as far as I could.
Just curious about Linux and trying to learn.
Also always want to help others as far as I could.
- Rava
- Contributor
- Posts: 5416
- Joined: 11 Jan 2011, 02:46
- Distribution: XFCE 5.01 x86_64 + 4.0 i586
- Location: Forests of Germany
Boot Repair Tool
My system is bootable, but I need to load the kernel from an external device. When loading the kernel from the internal drive - even though the sha256 checksum of the kernel is correct, boot fails, or it randomly chooses a different kernel that would not work work my nvidia driver.
I already posted (without what Boot Repair tool could tell me) the info but sadly no one had an idea that would solve my issue.
Added in 1 hour 9 minutes 43 seconds:
Here is the thread about the issue: "Loading vmlinuz... failed. Bad file number"
Cheers!
Yours Rava
Yours Rava
Boot Repair Tool
Sorry Rava,
I was very busy with my work and life.
Is this issue still not resolved ?
I was very busy with my work and life.
Is this issue still not resolved ?
- Rava
- Contributor
- Posts: 5416
- Joined: 11 Jan 2011, 02:46
- Distribution: XFCE 5.01 x86_64 + 4.0 i586
- Location: Forests of Germany
Boot Repair Tool
no worries happens to most of us all the time. At least to me it does.
You mean the "Loading vmlinuz... failed. Bad file number" issue?
Sadly, same old same old. No chance in booting the wanted kernel from the internal harddisk, the boot loader will either load a wrong kernel (and then the NVidia driver would not load) or give the "Loading vmlinuz... failed. Bad file number" error and being unable to continue.
I have to load the kernel and initrd from some external USB device ever since. Good thing is that both are loaded into RAM, and when you load the rest of the system via UUID from an internal drive you can umount the boot device that holds the kernel and initrd. At least that's a good thing.
Why the issue is happening at all and why it's unsolved: I have no clue, nowhere on the intertubes I found a hint or solution.
Cheers!
Yours Rava
Yours Rava
Boot Repair Tool
Have you tried a different kernel or this is happening for all kernels?Rava wrote: ↑30 Oct 2021, 15:56Booting 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
sorry i dont remeber the whole conversation in the another thread,
Hope you checked the file hash
- Rava
- Contributor
- Posts: 5416
- Joined: 11 Jan 2011, 02:46
- Distribution: XFCE 5.01 x86_64 + 4.0 i586
- Location: Forests of Germany
Boot Repair Tool
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
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
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
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 ext4] - 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
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
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>
Last edited by Rava on 30 Sep 2022, 01:59, edited 1 time in total.
Reason: added futureme screenshot ^-^
Reason: added futureme screenshot ^-^
Cheers!
Yours Rava
Yours Rava
Boot Repair Tool
Happy to hear this worked for you.
Rava wrote: ↑30 Sep 2022, 01:56Added 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>
- Rava
- Contributor
- Posts: 5416
- Joined: 11 Jan 2011, 02:46
- Distribution: XFCE 5.01 x86_64 + 4.0 i586
- Location: Forests of Germany
Boot Repair Tool
I will see when I reboot, at the moment that happens when my system crashed during suspend.
Therefore these 2 emails to the future me to remind me if I started indeed booted completely internally (meaning, not only the modules, but the initrd and kernel as well).
That reminds me: I first have to check if the internal setup via porteus.cfg also reflects the change from 5.0rc3 to 5.0 (finale version) since I did not boot internally for many many moons.
*goes to check that right now*
Added in 7 minutes 26 seconds:
*Check done*
Indeed, it was not the finale version inserted there. Now I have that fixed and all I do is recall when booting, removing all USB thumbdrives and also removing the SD-Card in the USB-Reader. *knocks on wood*
Cheers!
Yours Rava
Yours Rava