Boot Repair Tool

Post links to your 64bit module repos here. Repo maintainers are responsible for resolving any issues caused by their xzm's.
Testuser
Samurai
Samurai
Posts: 137
Joined: 26 May 2021, 15:11
Distribution: Porteus-v5.0-64-LXDE

Boot Repair Tool

Post#1 by Testuser » 15 Apr 2022, 11:32

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.

:)

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Boot Repair Tool

Post#2 by Ed_P » 15 Apr 2022, 17:36

You definitely have an interesting talent Testuser. :D
Ed

Testuser
Samurai
Samurai
Posts: 137
Joined: 26 May 2021, 15:11
Distribution: Porteus-v5.0-64-LXDE

Boot Repair Tool

Post#3 by Testuser » 16 Apr 2022, 11:40

Thanks Ed_P :)

Just curious about Linux and trying to learn.

Also always want to help others as far as I could.
:)

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Boot Repair Tool

Post#4 by Rava » 21 Aug 2022, 18:02

Testuser wrote:
15 Apr 2022, 11:32
Only use if you messed up your Boot files or your system is not bootable.
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

Testuser
Samurai
Samurai
Posts: 137
Joined: 26 May 2021, 15:11
Distribution: Porteus-v5.0-64-LXDE

Boot Repair Tool

Post#5 by Testuser » 29 Sep 2022, 19:09

Sorry Rava,

I was very busy with my work and life. :) :crazy:

Is this issue still not resolved ? :%)

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Boot Repair Tool

Post#6 by Rava » 29 Sep 2022, 19:18

Testuser wrote:
29 Sep 2022, 19:09
I was very busy with my work and life. :) :crazy:
no worries happens to most of us all the time. At least to me it does. :)
Testuser wrote:
29 Sep 2022, 19:09
Is this issue still not resolved ? :%)
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. Image
Cheers!
Yours Rava

Testuser
Samurai
Samurai
Posts: 137
Joined: 26 May 2021, 15:11
Distribution: Porteus-v5.0-64-LXDE

Boot Repair Tool

Post#7 by Testuser » 29 Sep 2022, 20:35

Rava wrote:
30 Oct 2021, 15:56
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
Have you tried a different kernel or this is happening for all kernels?

sorry i dont remeber the whole conversation in the another thread,

Hope you checked the file hash :)

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Boot Repair Tool

Post#8 by Rava » 30 Sep 2022, 01:20

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 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

ImageImage
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
Image
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:
Image
</geek>
Last edited by Rava on 30 Sep 2022, 01:59, edited 1 time in total.
Reason: added futureme screenshot ^-^
Cheers!
Yours Rava

Testuser
Samurai
Samurai
Posts: 137
Joined: 26 May 2021, 15:11
Distribution: Porteus-v5.0-64-LXDE

Boot Repair Tool

Post#9 by Testuser » 30 Sep 2022, 18:49

Happy to hear this worked for you.
Rava wrote:
30 Sep 2022, 01:56
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:
Image
</geek>
:D :D

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Boot Repair Tool

Post#10 by Rava » 30 Sep 2022, 19:16

Testuser wrote:
30 Sep 2022, 18:49
Happy to hear this worked for you.
I will see when I reboot, at the moment that happens when my system crashed during suspend. :cry:
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

Post Reply