yup totally sure that
calamares-git is broken in testing repo.
to confirm i uninstalled them on live boot then rebuilt using calamares-git pkgbuild abd it worked
and use manjaro-tools instead of manjaro-tools-git until the error is solved.
yup totally sure that
Please use unstable branch to test all changes made.
Made an unstable iso but still no UEFI boot just the same grub error, please fix.
Built an unstable iso but it still wont boot in UEFI mode fails with a grub error, same as testing.
use manjaro-tools-iso instead of manjaro-tools-iso-git
You can use manjaro-tools-git
If you go to lib/manjaro-tools/util-iso-boot.sh, as root, remove "(hd0)" the iso now boots
suspect hd0 isn't right for usb?
Yep, let me remove this addition tonight and rebuild the m-t tools.. I m thinking to try to add
search function to autodetect the right name..
(hd0) is what seemed to work to locate files when I manually tested
manjaro-gnome-18.1.0-pre2-testing-x86_64.iso from the rescue prompt. Ideally, you'd want to use something like
(hd0,msdos1), to explicitly set the partition where your GRUB boot data is located (and this is actually what I use in the
core.img I built for use with Rufus), but I'm pretty sure this will only work for BIOS/MBR and not UEFI/GPT drives, which we also need here, so that's why I was trying to go with something more generic.
Moreover, we have to account for the use of the
biosdisk module (which is what Manjaro in
dd mode appears to have been designed around), and I currently have no idea how that translates in terms of disk and partition identifiers for GRUB...
As to using
search, this is usually issued once
grub.cfg and the GRUB modules have been located... which of course means that, since we already have those and therefore identified the location we seek, it would become a bit superfluous.
search to be useful, it would have to be issued not in the main
grub.cfg but in
grub-mkimage... I think we might be able to do that by creating an early config through the
-c option, but then we'll probably need to embed a few more modules which
search might have dependencies on, as well as possibly chain link the config files.
All in all, it turns out that adding support for non dd FAT32 ISO extraction boot, that keeps all the existing modes happy, is turning to be a lot more complex than adding the handful a GRUB modules I originally thought it would boil down to. So if you guys can't come up with a solution you're happy with, note that I don't have a problem with the proposed patches being reverted, as I am planning to explore this issue in more details in a month or two (since right now I'm just dropping suggestions that I haven't had a chance to properly validate, due other matters taking precedence). But of course, I'll be happy to try to help, if you want to take a stab at it in the meantime.
Plug in as many grub bootable usb's - not necessary rufus usb, can be any other, like install usb's.
It should be hd0 at bios, right? (starting it up)
Let's test then.
At its grub prompt (install usb, type 'c') type
grub> echo $root
If hd0, output should be (hd0,msdosx) or (hd0, gptx)
Try it yourself.
Now boot that up, if it is not hd0, it will now be sda after booting up to OS.
Strange, isn't it?
I think you are confusing disks and partitions.
Again, I have yet to get a single report from someone where
(hd0) didn't map to the installation media (disk) where they booted from.
The problem we are facing here is that, unlike what I was hoping and what testing in grub rescue led me to believe, GRUB does not automatically resolve
(hd0) with an unqualified partition to
Yet, that doesn't invalidate the statement that, until someone demonstrates otherwise, the booted USB media will be seen as something else than
(hd0) by GRUB.
Not exactly, because a dd created media will have two partitions (ESP, with whatever label and main with label such as
MJR17112) whereas a FAT32 will have only one, and the GRUB files reside on the ESP.
So, in dd mode, you'll be looking for the ESP label, whereas in FAT32 mode, you'll be looking for the
Please be mindful that this issue might be a bit more complex to solve than it looks and that, indeed, unless you have validated a proposed fix, you may run into some unexpected surprises, which is what happened at each step of the way so far...
Yes, I heard you the first time.
You haven't tried my suggestion. I test grub often. I have rescue grub usb's made and I have a few internal drives. In my experience, when grub shows up, I sometimes verify with 'grub> echo $root' or 'grub> ls'. They are not always (hd0) (I won't type (hd0,msdosx) as this confuse you on partitions and drives). Why don't you try it yourself instead of repeating what is not tried. If you try it out 6 times and none of them verifies what I say, you should buy a lottery ticket or play russian roullette.
Yes, I'm aware of other variables that may cause non-boots. But this is specifically testing whether bios sees the usb as (hd0) and no other variables are involved. BTW, grub takes (hdx) as what the bios tells it to.
As said, I have no vested interest (I don't use rufus, etcher, unetbooting, pendrive, multidrive...).
To self: Strange.... I keep getting involved/petitioning/agitating in things that do not affect me or cause me trouble. intel-ucode, uefi in msdos, auto-menu-hide-grub, grub-customizer...
Must be silly. Or barking mad.
guys c`mon... theres no reason to argue, and thats exactly what MS wants... fragmentation
Because, as I said, I just don't have the time at the moment. I'm planning to look more closely at this in a month or two.
But, as I pointed out, in a application that is downloaded more than 3 million times a month, and provides custom GRUB core images with hardcoded
(hd0,msdos1) for BIOS drives, I have yet to see a single report from someone pointing to
(hd0) not being the booted disk (at least for BIOS).
If I expect that testing what you suggest will help with the problem at hand (which I don't -- it seems you just want to validate a point that is orthogonal to this discussion, and that, again, I should have heard about if it was relevant), I will of course do that when I take a proper look at the issue, and start creating and validating my own ISOs with GRUB changes...
Okay. Good luck.
And perhaps I have to thank you for making me question why I need to be involved/agitated in things that do not affect me. The Yemen war, Gaza mowing the lawn, Assange , Venezuela ..
But you have mentioned several times about users being simple newbies. And you expect those would report something only experts would realize, using grub prompt.
I still prefer aguslr/multiboot.
I suggest to everyone in question about ISO booting failures, to read Archwiki "How to create Hybrid multiboot USB disk". It explains "How many partitions are required" and "How to create them".
aguslr has created a script that does it automatically and you just need to copy ANY Iwo file onto USB drive.
while [ RTFM -eq 0 ]; do; debugging...; done
For now we will remove the hd0 hardcode
Please point to a single instance of me using "simple newbie" (which is something that I would find rather insulting as a term, therefore not something that I would tend to use, since there is well known stigma associated with "noob"), be it on this forum or the Rufus issue tracker.
If you can't do that, which I am pretty confident you can't, then, in case this is what you took objection with, you may want to be mindful about misinterpreting someone talking about "non tech-savvy" or "non technically proficient" users, which I do on occasion, in conversations where one legitimately needs to differentiate user proficiency (but not in a negative way), and especially, about deriving or implying that what was being said was an expression of contempt for (some) users.
Just to make this abundantly clear, I am rather puzzled at some of the occurrences that are being displayed in this thread, and that seem to serve very little purpose other than trying to reframe the current dialog as if I were coming here with a "bow to me, the great Rufus developer" attitude, instead of looking at my posts for what they are: an attempt at finding a working technical solution to an issue (that I did try to raise repeatedly for more than a year, on the old issue tracker) by trying to shed some light with regards to some of the elements that I am aware of and that I believe might be helpful to those who are genuinely interested in figuring that one out.
Now, to address your other assertion: Much to my daily chagrin, you may also want to be aware that I made sure that even non tech-savvy users can easily reach me by, for instance, providing a direct clickable e-mail link of my personal address in the about dialog of the Rufus application. So, and this is the part I will ask you to trust me on, I very much happen to hear from non technically proficient users on an exceedingly regular basis, even more so when they happen to find that the flash drive they just created doesn't boot.
Therefore, if you are trying to venture an alternate explanation as to why, again, with an application that is downloaded more than 3 million times every month (and that has been using hardcoded
(hd0,msdos1) with BIOS/GRUB for years), there does exist a major-enough problem with using
(hd0) that has managed to remain under the radar, you'll have to do a bit better to explain how statistically I wouldn't have heard about it by now, even from non tech-savvy users (knowing that non tech-savvy users don't usually have much trouble reporting the ISO they were using at the time and that, unless the issue is obvious, I try to download the ISO they were using to see if I can replicate the problem, in which case whether the reporter is an expert or not becomes irrelevant).
For what is worth, I have never found any shortage of Rufus users letting me know that Manjaro gets to grub-rescue when written in ISO mode, which is also why I have been trying to bring this issue to Manjaro's attention for more than a year now, so that we, collectively, could try to find a solution.
This being said, I think your suggestion to have a closer look at the Arch Wiki is indeed good advice.
you don't know my skills, I guess.
FWIW I have no problem with newbies being newbies, or whatever term anyone prefers to use to describe the same thing. I respect them more than non-newbies.
Actually I admire you for the good intention and I surely applaud.
Speaking for myself only, I find both Rufus and Manjaro ISO methods with flaws.
IMHO Manjaro team should have found another (different, as "better" is subjective) way to serve the ISOs. I guess they prefered to provide a demo Live session, instead of a pure flawless (to best possible extent) system installer. That's their right to decide and I fully respect and try to support existing failures (check my activity statistics). Now I see a Windows installer request to make changes to this model, which, if accepted, makes them review again all factors they had struggled from the beginning of this journey. I object about that, since there are very clear instructions on how to create a Live ISO. Then, you want to protect the so-called "newbies" from not even Reading The Fine Manual, which I find against my perspective of continuously educating newcomers (better term?...), which is highly essential to keeping their Manjaro systems out of troubles.
As for the "feedback" argue, it's my personal estimation/assessment out of my own experience as "newbie" and as "Helpdesk Support". Feel free to have your assessment, as it's only this, an "assessment".
I believe you have no intention to misinterpret my own intentions. Have in mind that my Enflish language skills are of the "Greek" type.
I have a UEFI32 (64 bit capable) device that until recently had been unsupported by most linux distros. I've used unetbootin to "burn" those ISOs to a USB formatted as FAT32. Then I add the bootia32.efi file to EFI/BOOT/ and the i386-efi/ module folder to /boot/grub/ to get a bootable liveUSB. I've used the technique with many distros, including Manjaro. The issue with being unable to boot the Manjaro liveUSB, is that the current Manjaro .efi files only support ISO9960 formatted USBs. Substituting the .efi file from another distro gets around that limitation. The replacement .efi is a lot larger than Manjaro's. All the .efi file has to accomplish is load the grub bootstrap and tell it where to find and how to read the file system containing /boot/grub/*. Adding enough modules to Manjaro's .efi files should solve the problem, since replacing the liveUSB .efi's solved the problem for me. BTW, my boot media has always been hd0 at the grub prompt!
I've had good luck with Rufus adding the bootia32.efi to its liveUSBs in the past, but I don't use windows much anymore.
BTW, Manjaro32 does support my device without hacking the liveUSB, as does MX-Linux, SparkyLinux and Linuxium. My hack works for the current Manjaro 64 bit ISO's, but my understanding is that UEFI32 support is being added
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.