I'm trying to make rEFInd detect Nobara linux (which is fedora based) but the problem is nobara created a "fedora" folder in the EFI partition when it was installed, so everytime I see a fedora icon in the boot menu which I don't want, what I did was I just copied "fedora" and renamed it to "nobara" to add an entry for nobara. But the problem is i'll have to sync nobara with "fedora" everytime. Is there a way to make rEFInd detect it as nobara ? Thank you
Why would Refind be trying to write to anything on boot? It doesn't (apart from logging but this is not related to that). I took a closer look at things and it looks more like there might be an issue with your setup. rEFInd tries to open misc dirs with the DirIterOpen function while scanning for loaders. This is done with the EFI_FILE_MODE_READ attribute but for some reason, this appears to be denied on your setup and an EFI_WRITE_PROTECTED error returned. It's not like it is trying EFI_FILE_MODE_WRITE...
You could try setting the log_level config option in rEFInd to 0to disable logging. However, it could be that in the backend and unseen by users, the logging is actually always started (some items need logging before the config file is read) and that such logging is subsequently discarded if the log_level is found to be 0 when the config file is processed. If that is the case and the issue is related to logging, you might still get the issue. You could try the REL version of RefindPlus as it does...
You could try setting the log_level config option in rEFInd to 0to disable logging. However, it could be that in the backend and unseen by users, the logging is actually always started (some items need logging before the config file is read) and that such logging is subsequently discarded if the log_level is found to be 0 when the config file is processed. If that is the case and the issue is related to logging, you might still get the issue. You could try the REL version of RefindPlus as it does...
You could try setting the log_level config option in rEFInd to 0to disable logging. However, I it could be that in the backend and unseen by users, the logging is actually always started (some items need logging before the config file is read) and that such logging is subsequently discarded if the log_level is found to be 0 when the config file is processed. If that is the case and the issue is related to logging, you might still get the issue. You could try the REL version of RefindPlus as it does...
You could try setting the log_level config option in rEFInd to 0to disable logging. However, I think that in the backend and unseen by users, the logging is actually always started (some items need logging before the config file is read) and such logging is discarded if log_level is found to be 0 after the config file is processed. If that is the case and the issue is related to logging, you might still get the issue. You could try the REL version of RefindPlus as it does not create a log file at...
You could try setting the log_level config option in rEFInd to 0to disable logging. However, I think that in the backend and unseen by users, the logging is actually always started (some items need logging before the config files is read) and discarded if log_level is found to be 0 after the config file is processed. If that is the case and the issue is related to logging, you might still get the issue. You could try the REL version of RefindPlus as it does not create a log file at all.
Okay, I replaced the bootx64.efi file with your fork. The error still occurs. It would not be able to write a log to a filesystem as it's running from a read only filesystem. Unfortunately this machine doesn't have working serial output and it doesn't look like Refind's logging is particularly flexible - although I could be wrong.
My request was to replace the rEFInd efi with one from RefindPlus in whatever setup you used with the rEFInd efi to see whether you get the same result. Do you mean to say you since have found the issue you reported is actually because you tried to run without an ISO that that such an ISO is required or is it that the rEFInd setup is packaged in an ISO and you cannot change the efi without creating a new ISO?
My request was to replace the rEFInd efi with one from RefindPlus in whatever setup you used with the rEFInd efi to see whether you get the same result. Do you mean to say you since have found the issue you reported is actually because you tried to run without an ISO that that such an ISO is required?
My request was to replace the rEFInd efi with one from Refindplus in whatever setup you tested with the rEFInd efi to see whether you get the same issue. Do you mean to say you since have found the issue you reported is actually because you tried to run without an ISO that that such an ISO is required?
My request was to replace the rEFInd efi with one from Refindplus in whatever setup you tested with the rEFInd efi to see whether you get the same issue. Do you mean to say you since have found the issue you reported is because you tried to run without an ISO that that such an ISO is required?
My request was to replace the rEFInd efi with one from Refindplus in whatever setup you tested to see whether you get the same issue. Do you mean to say you since have found the issue you reported is because you tried to run without an ISO that that such an ISO is required?
@dakanji wrote: Can you temporarily try RefindPlus and let me know whether you get the same outcome? See here for HowTo: https://sourceforge.net/p/refind/discussion/general/thread/4d2754f090/#5d5f The iodd requires an ISO file - I'll build one at some point if you haven't got a script or something for it. --Adam
Can you temporarily try RefindPlus and let me know whether you get the same outcome? See here for HowTo: https://sourceforge.net/p/refind/discussion/general/thread/4d2754f090/#5d5f Thanks
i tried playing around with the default_selection parameter, but my system still alwaysboots into windows. (i have a linux , windows and hackintosh multi boot system)
The attached (?) screenshot is the closest I could get in a VM, but on a real machine, I get an error Error: Write Protected while scanning the \ directory on ElTorito * Hit any key to continue * Error: Write Protected while scanning the EFI directory on ElTorito * Hit any key to continue * Error: Write Protected while scanning the boot directory on ElTorito (errors appear to start from ./refind/driver_support.c line 565) Why would Refind be trying to write to anything on boot? iodd presents as a...
Can confirm that refit_call3_wrapper(gBS->SetMem, ...) fixes the duplicate tools bug. I've closed my original merge request and opened a simpler one.
Wrap SetMem when built with GNU-EFI to fix the "duplicate tools" bug
Iteratively zero out GlobalConfig.ShowTools after processing showtools tokens
I can confirm that refit_call3_wrapper(gBS->SetMem, ...) fixes the issue. I will close this merge request and open another with a simpler fix.
Note that rEFInd requires .VolumeIcon files to be in the volume root. Anyway, easiest would probably be to name your wished icon as os_BOOT.png and save this under the \EFI\Microsoft\Boot folder.
Note that .VolumeIcon files need to be in the volume root. I think the easiest would probably be to name your wished icon as os_BOOT.png and save this under the \EFI\Microsoft\Boot folder.
Hello dakanji. Sorry for the late response. I tried every option you mentioned, but nothing worked. I deleted the os_win8.png and at the same time put the icons in the corresponded volume directories, but both win 10 and 7 had the icon with 3 circles (the picture that is shown when it doesn't know what os it is). That means it doesn't detect the files "bootmgfw.png " and ".VolumeIcon.png", even when os_win8.png is missing. Also, the default scanfor includes the manual entry. I think I will give up....
This is a triple-boot PC. Drive 1: EFI, Fedora, Windows 10 Drive 2: Fedora-Rawhide (No EFI on this disk. I deleted it.) I have a custom banner. No custom stanzas. All operating systems auto-detect just fine. It's a small but annoying problem. The banner loads three times before the icons appear. Thoughts?
OK, finally had time to time to try the stanza and that worked - the kaos icon is displayed now
im guessing the post needs confirimination.
(Posting this prior to seeing joevt's post, which is right now "awaiting moderation".) My latest thought for this icon issue is to create a stanza to handle the kaos distro, I need to research how to do this, but unfortunately I won't be able to get to that right away ...
With respect to renaming the icon, I thought better than a rename would be to symlink os_linux.png to os_kaos.png. That would make it more obvious what was going on. However ln -s requires a full path as a target, which again brings up the symlink question - what is the mount point of the efi partition when rEFInd is running?
Yep, I could rename the icon. It would work fine (unless I ever installed another distro that mounted the efi partition on /boot). As an alternate idea, I noticed that Rod, in 2023, added an option to follow symlinks. So I could theoretically symlinks the kernels in the efi partition to the KaOS XFS partition . So rEFInd would see the kernels there and be able to read /etc/os-release there. I think there's also an option to STOP rEFInd from looking for kernels in the efi partition (to avoid seeing...
I guess I'm stuck with the penguin You could always rename your os_kaos file as os_linux
Duh - slaps forehead. It's NOT the XFS partition that needs the filesystem name trick. I'd need to name the efi filesystem "kaos" because that's where the kaos kernels are. That just seems like a wrong thing to do, so I guess I'm stuck with the penguin...
Found nothing on the xfs_admin errors. Found that KDE partition manager will deal with XFS partitions, so tried using that, running on my KDE Neon distro, to change the filesystem name of the KaOS partition. It reported success, but yet the label is still empty!
For the KaOS distro, the refind log shows: Trying to locate an icon based on hints 'boot,EFI,System,Partition,linux' So it's not looking for "kaos". So I decided a refind trick is really necessary, and therefore installed xfsprogs in one of the other distros. I ran xfs_admin there to change the filesystem name of the (unmounted) Kaos partition to "kaos" (wiithout the quotes of course) but got a whole raft of errors and the name remains empty, so no joy there. I'll need to research why xfs_admin ...
Wow, I hadn't realized there was the ability to enable a log file. Thanks! The refind documentation is very thorough, but its a bit difficult to find the information one needs. Anyway, in refind.conf, I uncommented log_level and set it to 4. I rebooted to create the log. At first, the file looked mysterious until I discovered it was using UTF-16. So I converted the file to UTF-8 to inspect it, using this command while in sudo bash: iconv -f UTF-16 -t UTF-8 refind.log -o refind-utf-8.log I can see...
Some patches to fix refind-install
Well, output a log file, check what is happening on icons for that item and make adjustments. Otherwise, a Linux icon being shown for a Linux instance is not the end of the world. Good luck!
Well, output a log file, check what is happening on icons for that item and make adjustments. Otherwise, a Linux icon being shown for a Linux instance is not really an issue. Good luck!
Thanks! I downloaded xfs_x64.efi from Pete Batard's https://efi.akeo.ie/downloads/efifs-1.10/x64/ and put it into the refind/drivers_x64 directory. But - it's still the penguin showing instead of the KaOS icon ... On Rod's "Using EFI Drivers'" webpage, he says "When you reboot after installing drivers, rEFInd should automatically detect and use the drivers you install." I guess that means that tho XFS was probably a component of this (minor) problem, but there's still something else going on.
Thanks! I downloaded xfs_x64.efi from Pete Batard's https://efi.akeo.ie/downloads/efifs-1.10/x64/ and put it into the refind/drivers_x64 directory. But - it's still the penguin showin instead of the KaOS icon ... On Rod's "Using EFI Drivers'" webpage, he says "When you reboot after installing drivers, rEFInd should automatically detect and use the drivers you install." I guess that means that tho XFS was probably a component of this (minor) problem, but there's still something else going on.
Get an XFS driver from the Pete Batard link here and add it to your drivers folder: https://sourceforge.net/p/refind/discussion/general/thread/d1ef8ae6/#cd8c
Just got an idea. /etc/os-release is in the KaOS partition, which they require to use an XFS filesystem. So I think rEFInd can't read that file ...
Rod may be ignoring this one, or on vacation, but I realized I should also have mentioned the following: * KaOS was the last distro I installed * prior to that I was using rEFInd with the other two distros only * during the KaOS install (from a usb stick ISO) it asked if I wanted to use rEFInd. I said yes, but later I realized that this might have caused a re-install But again - the oddly missing icon is the only problem.
Nice. Why not just use refit_call3_wrapper gBS->SetMem and drop the specific GNUEFI macros in lib.h? Also extend to cover refit_call3_wrapper gBS->CopyMem as well. Other toolkits will also happily work with these. I note though, that you tried to follow the same way things were previously done.
The MR works around the issue but does not fix the root cause. From my original comment, it is: Basically, the SetMem item is not taking ... Luckily, it seems someone else with an unrelated issue has stumbled on the root issue of SetMem being broken on recent GNUEFI builds and come up with a fix. SetMem basically needs to be refit_call3_wrapper(gBS->SetMem, ...) to work with recent GNUEFI builds. I posted a comment on the MR pointing to the thread with the fix.
While this might work around the problem, it does not address the root issue. Note that workarounds are fine when the root problem is not clear but in this case, it seems some other memory management related issue fix proposed here does address the real problem of SetMem being broken: https://sourceforge.net/p/refind/discussion/general/thread/56a4a60843/
Nice. Why not just use refit_call3_wrapper gBS->SetMem and drop the specific GNUEFI macros in lib.h? Also extend to cover refit_call3_wrapper gBS->CopyMem as well. Other toolkits will also happily work with these.
I found the issue, I'm attaching a patch.
I just installed this today. how do i start it? i check the conf file nothing in yet. so i geuss that means ineed to start it somehow. im on legion go via storm os gnome arch linux.
It looks like vendors such as Dell and SuperMicro are ignoring the DriverXXXX and DriverOrder options, regardless of settings such as Secure Boot. Am I doing something wrong, or is this feature not really usable? It works fine with Tiano & QEMU. I understand that efi root kits are a big risk, so I guess it makes sense that this wouldn't be possible, but it would sure be convenient sometimes. Thanks
Just asking because I don't get why the 1 icon is shown incorrectly. 3 different distros, each in its own partition, and separate efi and home partitions. All boot properly, so no problem there,. Only the one icon is a problem, so basically just an annoyance. The icon replaced by the penguin is for the KaOS distro. - the value of ID in os-release is "kaos". - the icon, in the folder with all the others, is os_kaos.png - the icon is viewable (i.e. not defective) - its file permissions are the same...
Thanks for the awesome rEFInd that I use on many PCs. On Raspberry Pi5 with RPi5 UEFI v0.3 it fails in same way as OP with "Synchronous Exception at 0x000000003E628F38" (v0.13.3.5) or "Synchronous Exception at 0x000000003E628F40" (v0.14.2). I have tried to enable log_level 4 but rEFInd never writes a log (it's installed alt name as /EFI/BOOT/BOOTAA64.EFI); incidentally Ventoy ARM64 does work. I tried renaming tools_arch and drivers_arch folders and prefix with hide_ to reduce files pulled in but...
Thanks for the awesome rEFInd that I use on many PCs. On Raspberry Pi5 with UEFI v0.3 it fails in same way as OP with "Synchronous Exception at 0x000000003E628F38" (v0.13.3.5) or "Synchronous Exception at 0x000000003E628F40" (v0.14.2). I have tried to enable log_level 4 but rEFInd never writes a log (it's installed alt name as /EFI/BOOT/BOOTAA64.EFI); incidentally Ventoy ARM64 does work. I tried renaming tools_arch and drivers_arch folders and prefix with hide_ to reduce files pulled in but nothing...
Thanks for the awesome rEFInd that I use on many PCs. On Raspberry Pi5 with UEFI v0.3 it fails in same way as OP with "Synchronous Exception at 0x000000003E628F38" (v0.13.3.5) or "Synchronous Exception at 0x000000003E628F40" (v0.14.2). I have tried to enable log_level 4 but rEFInd never writes a log (it's installed alt name as /EFI/BOOT/BOOTAA64.EFI); incidentally Ventoy ARM64 does work. I tried renaming tools_arch and drivers_arch folders and prefix with hide_ to reduce files pulled in but nothing...
rEFInd relies upon the EFI to read the kernel file. If the EFI cannot read a device natively, it requires a driver, such as the ext4fs and other Linux filesystem drivers provided with rEFInd. AFAIK, there's no EFI driver to read LUKS devices, so AFAIK, at present, rEFInd doesn't support reading kernels from them. In theory, this limitation could be fixed by writing an EFI LUKS driver. A more practical workaround at the moment is to store your kernel and initramfs on a partition that rEFInd can read....
I encrypted the root partition to a luks device. the kernel (vmlinuz and initrd) is also encrypted.(i nearly used up the spare space in efi partition) I wonder if refind supports or will support boot from this device since i didnt find anything about it in the docs.
Saw the issue you raised on GitHub. Will get back there presently.
Saw the issue you raised on GitHub. Thanks. Will get back there presently.
Hello, also with refindPlus same problem. Here the log.
Would it be fine to do the test by using an USB pen ? I would not block my work PC. Also: do I need to use config.conf or it would alse read the refind.conf I already have ? Thanks
Would it be fine to do the test by using an USB pen ? I would not block my work PC.
Looks like a memory conflict caused it to hang. Can you try temporarily replacing the rEFInd efi with one from RefindPlus to see if it does the same? See: https://github.com/dakanji/RefindPlus/releases Just change the rEFInd file extension to .efix, give the RefindPlus file the same name as rEFInd had and reboot as normal. Use the RefindPlus DBG file (for debugging) to generate a log file. The REL file (for normal use) does not produce logs. You can share the log here. Thanks.
Refind 0.14.2 can boot if compiled with gnu-efi 3.0.18, but if I use a jpeg banner it is all garbled. If compiled with gnu-efi 3.0.17, the jpeg looks good. I tried to use libeg/nanojpeg.c from 0.14.0 with the same result (still garbled).
Hello all, I have just got a new laptop ( ( HP Elitebook 655 G10 ) and as usual I've installed refing ( latest ), repartitioned my hard drive to shrink the windows partition, recreated all other partitions and extracted the dump for my linux installation. At boot I got an empty refind screen without any choice available. I've tried everything I've read around, removing unused drivers and son on, and also the Microsoft directory from the ESP thinkging it could lead to problems due to secureboot stuff,...
Nevermind, I think I figured it out. In case anyone comes to this thread from a google search, I had to disable fastboot and now the Windows entry reliably shows.
I'm dual booting Arch linux and Windows 11 on 2 separate drives in a UEFI system with rEFInd installed on the Arch side. The issue is rEFInd does not always detect Windows 11. Specifically, it never detects it, unless I go into the UEFI interface first and then reboot into rEFInd, and then it detects it. However, any subsequent reboot, it will not detect Windows. I've tried pretty much anything I can think of, including repairing the EFI partition in Windows. For now, I'm getting around the issue...
I'm curious as to how the kernel manages to load the initrd image once execution is handed off to the kernel after rEFInd loads it. My understanding is that rEFInd loads the kernel into memory, and executes it just like any other EFI application, passing it the kernel command line parameters (including 'initrd=xxx' parameters). But how does the kernel then load the initrd image? My understanding is that the kernel has no filesystem drivers (isn't this the whole point of initial ramdisks?), and in...
reproducible builds: don't leak the build timestamp
@Felipe I have submitted a merge request to fix the issue, hopefully the author accepts it.
Hi, I just registered at sourceforge to say this bug is a very sad thing. Please help.
Gentlemen: Thanks for rEFInd, it looks like liberation from the GRUB monster. I had a few issues installing it, if there's interest I'd be happy to go into it in depth.
The boot restore process is doing legacy/BIOS boot restore, so its not going to affect the EFI boot settings. You have to change EFI boot settings to make it boot legacy BIOS boot by default (select the Windows startup option in Startup Disk preferences panel or hold option key at boot to enter the Startup Manager EFI app, select the Windows option, hold control key and press enter, or use the bless command). Doing any of those three will set the EFI boot nvram variable to the Boot Camp EFI program...
I tried it again by burning the ISO to a DVD instead of USB. This succeeded, notwithstanding various errors and warnings that suggested it wouldn't boot. The iMac now boots in legacy mode and suspends/recovers without a pink screen, so job done, It does still use rEFInd, which surprises me. Is that expected? I thought the boot-restore process would use just legacy GRUB. Attached are the xxd dumps and the new Boot Info generated after booting in legacy mode. On waking from suspend the wired network...
I'm using 10.4.11 on a PowerPC Mac but it should be the same as an Intel Mac. Here's the output when I paste the text (I removed the tabs to be safe): JoeG5:~ joevt$ echo $BASH_VERSION 2.05b.0(1)-release JoeG5:~ joevt$ testit () { > if perl -ne 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption"; then > echo match > else > echo nomatch > fi > } JoeG5:~ joevt$ FirstCmdlineOption=vmlinuz ; testit match JoeG5:~ joevt$ FirstCmdlineOption=bzImage ; testit match JoeG5:~ joevt$ FirstCmdlineOption=kernel...
I'm using 10.4.11 on a PowerPC Mac but it should be the same as an Intel Mac. Here's the output when I paste the text (I removed the tabs to be safe): JoeG5:~ joevt$ echo $BASH_VERSION 2.05b.0(1)-release JoeG5:~ joevt$ testit () { > if perl -ne 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption"; then > echo match > else > echo nomatch > fi > } JoeG5:~ joevt$ FirstCmdlineOption=vmlinuz ; testit match JoeG5:~ joevt$ FirstCmdlineOption=bzImage ; testit match JoeG5:~ joevt$ FirstCmdlineOption=kernel...
The fdisk output in your Boot Info says the EFI partition is marked as the active partition. That seems strange but it might work. xxd the PBR of sda1 to see if it has boot code (before and after you repair boot to see how things get modified). From the output of od, it looks like it does have boot code. xxd output will make it more clear. Also do xxd for the mbr as well. dd if=/dev/sda count=1 | xxd dd if=/dev/sda1 count=1 | xxd dd if=/dev/sda3 count=1 | xxd Normally I would expect the boot code...
Yes, that's exactly what I do. Copy and paste then press enter to execute. Regards, Paul Jurkonis Sent from Proton Mail mobile -------- Original Message -------- On May 19, 2024, 7:58 PM, joevt wrote: Maybe you can show me how you are running it through bash. In my tests, I just copy and paste the text into a Terminal.app window. Error installing on MacBook 1,1 Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/refind/discussion/general/ To unsubscribe from further...
Maybe you can show me how you are running it through bash. In my tests, I just copy and paste the text into a Terminal.app window.
I don't know if you can boot legacy BIOS using USB on a 2008 Mac. I would stick with a CD to be sure. Legacy BIOS boot for old Macs is usually limited to internal disks and built-in CD/DVD. BootCamp Assistant.app from a version of macOS that supports your Mac will instruct you to make a CD or USB or something, depending on what that Mac supports.
Iteratively zero out GlobalConfig.ShowTools after processing showtools tokens
@joevt I made the change, -nE to -ne. I ran it through bash this is the error; /Users/myName/Desktop/new.bash: line 1: syntax error near unexpected token'`{ 'Users/myName/Desktop/new.bash: line 1: `testit () {
Hmm, seems like I need help to repair the boot-repair image :-( I burned boot-repair to a good USB stick and tried booting by holding Alt and the power button on the iMac. This gave me two options 'Windows' (which refers to the internal HD) and EFI boot. The latter is the USB boot-recovery. I booted from the latter and after a short period it said something like Error: '/boot' not found Looking at the USB, it does have a boot directory. Any suggestions?
Thanks, I'll try that. I tried the boot-repair tool under the running system and it looks easy, right at my level :-) It wouldn't do the job from the running system so I'll put it on a USB and see if it works. I've added the boot info generated by boot-repair before taking any action, just for reference. @joevt thanks. Yes I should have given sda, not sda1.
Thank you for the answer! But my system recognise 2 type of preboot: one is from MacOs and the other one is from OpenCore. Whaty type of command do I need to write near default_selection? Thanks
You can set any unique part of the description as the default_selection to have rEFInd use that; for instance: default_selection = preboot Assuming there's only one preboot option, this example should cause it to be used as the default selection on every boot.
To boot in BIOS/CSM/legacy mode, you must install a BIOS-mode boot loader on the disk. This is normally the BIOS version of GRUB; and to install that, you'll need to boot a Linux recovery tool or OS installer and then issue appropriate commands to do the installation. The easiest way to do this is likely to be to use the Boot Repair tool: https://help.ubuntu.com/community/Boot-Repair That said, in this case your ultimate end state will be to use BIOS-mode GRUB 2 to boot a single OS (Linux Mint),...
Isn't sda1 partition 1? I think sda is the entire disk which has the MBR? I would use xxd instead of od to view hex. All those control character names are distracting. parted says sda1 has the boot flag. Does that mean it's the MBR's active partition? The fdisk command should be able to show the partition table of the MBR including which partition is active. sda3 doesn't seem to have any boot code since it's all nul characters. What is the contents of sda1 (list of files)? I think it's just the EFI...
And for sda3, the linux partition: od -Ax -a /dev/sda3 000000 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul * 000400 nul nul k nul nul | - soh L del nak nul etb e stx soh 000410 D etx c nul nul nul nul nul stx nul nul nul stx nul nul nul 000420 nul nul nul nul nul nul nul nul nul sp nul nul H v H f 000430 G v H f bs nul del del S o soh nul soh nul nul nul 000440 ~ v D f nul nul nul nul nul nul nul nul soh nul nul nul 000450 nul nul nul nul vt nul nul nul nul soh nul nul < nul nul...
Here's the MBR sudo od -Ax -a /dev/sda1 000000 k X dle m k f s . f a t nul stx bs sp nul 000010 stx nul nul nul nul x nul nul ? nul del nul nul bs nul nul 000020 h _ ht nul X stx nul nul nul nul nul nul stx nul nul nul 000030 soh nul ack nul nul nul nul nul nul nul nul nul nul nul nul nul 000040 nul soh ) J g j ] B O O T sp sp sp sp sp 000050 sp sp F A T 3 2 sp sp sp so us > w | , 000060 " @ t vt V 4 so ; bel nul M dle ^ k p 2 000070 d M syn M em k ~ T h i s sp i s sp n 000080 o t sp a sp b o o t...
Does the MBR have boot code? This is block 0 of the disk. Is the Linux partition marked as active in the MBR? Does the PBR have boot code? This is block 0 of the partition that is marked active in the MBR. You may need to use the Linux CD to setup legacy boot. Basically, the PBR needs boot code that knows how to load and run legacy GRUB.
I have a 2008 iMac on which I've installed Linux Mint Debian Edition. There's a problem when exiting from Suspend that leaves the screen pink and stripey. This is a known issue that is apparently fixed by booting in legacy mode. When I boot, rEFInd shows me three options: EFI\debian\grubx64.efi from BOOT boot\vmlinuz-6.1.0-12-amd64 from 107 GiB ext4 volume Legacy OS from whole disk volume Each of these is from the disk (each has a little disk icon) The first two work well and appear the same when...
Correction: To work in Mac OS X 10.4.11 or 10.5.8, replace -nE with -ne. I have no idea how you got those errors. It's a bash script that uses perl so no reason to try it in perl. Just copy and paste it into Terminal.app. In Mac OS X 10.4.11, perl -v says I have v5.8.6
@joevt this is what happens when I run in Bash and Perl **Bash:** PALMACPRO:~ myName$ /Users/ myName /Desktop/new 'Users/ myName /Desktop/new: line 1: syntax error near unexpected token `{ 'Users/ myName /Desktop/new: line 1: `testit () { PALMACPRO:~ myName $ **Perl:** PALMACPRO:~/desktop myName $ perl -w new Unquoted string "perl" may clash with future reserved word at new line 2. String found where operator expected at new line 2, near "nE 'exit !(/vmlinuz|bzImage|kernel/)'" (Do you need to predeclare...
I haven't looked at the script, but I suspect you want to replace line 1397 with the line I provided. Then you may wish to search for any other occurrances of =~ to see if they also need to be changed. But before doing that, test the replacement to make sure it works with your shell version. testit () { if perl -nE 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption"; then echo match else echo nomatch fi } FirstCmdlineOption=vmlinuz ; testit FirstCmdlineOption=bzImage ; testit FirstCmdlineOption=kernel...
@jovet I'm not new to programming, but I'm not fluent in any specific programming language. With that said, I would need more detailed instructions where to make edits in the original script. Regards, Paul Jurkonis Sent from Proton Mail mobile Regards, Paul Jurkonis Sent from Proton Mail mobile -------- Original Message -------- On May 16, 2024, 8:09 AM, joevt wrote: Maybe use perl? if perl - nE 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption" ; then Error installing on MacBook 1,1 Sent...
Maybe use perl? if perl -nE 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption"; then
Maybe use perl? if perl -nE 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption"; then
I think bash in Mac OS X 10.4.11 doesn't like =~ (vmlinuz|bzImage|kernel) You'll need a different comparison method there.
@joevt Thanks for the reply Productname: Max OS X Productversion: 10.4.11 $SHELL /bin/bash
What OS and OS version and shell version are you using? $SHELL --version