I'm talking about defraging the vmlinuz file that is causing your boot problem not what format the drive is.
I have no idea. It is not something that I have experience with.
I'm talking about defraging the vmlinuz file that is causing your boot problem not what format the drive is.
I have no idea. It is not something that I have experience with.
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.
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.
I think a much quicker way is this:
approach is not possible because of this
You also have to have more unused space available than used space for this to work
If you feel more comfort with your slower approach to verify my suggested cause of the problem do it.
Your approach means:
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.
I wrote ncmprhnsbl a PM about " Can the Porteus installer handle ext4 as internal boot partition? " I wait till he replied.
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
}
By that you mean sda1 is VFAT or NTFS?