-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In MBR mode on 64-bit system, $grub_cpu is i386 not x84_64 #3
Comments
I agree that it is useful to have a variable that captures whether the cpu is 64-bit capable, since it is impossible in GRUB to check both command output and variables in one
I have already defined a variable However, I am not sure whether the other variables are actually beneficial or if they only confuse and use up variable space that might be needed better for advanced scripting in your include files. First of all, your 4 variables EFI32 EFI64 MBR32 MBR64 suggest that there are actually only four environments somebody writing scripts may care about. But actually there are five. Among Windows 10 tablets and Chromebooks there are many devices with 64-bit capable Atom CPUs which ship with a 32-bit EFI environment. On those environments, it is possible to boot Windows 64-bit (if you use 32-bit bootmgr.efi), and it is also possible to boot recent 64-bit Linux kernels (if you use Second, GRUB's scripting does not really support boolean values. In your example,
will also be entered on 32-bit system, since "false" as a string is considered to be true (only empty string is false). You'd have to write
which makes me try to avoid having variables that have string values that look like boolean values That being said, you can of course define your own variables in your scripts and use them afterwards. And if you believe there are stronger arguments for including those variables that I missed, feel free to comment again :) |
sorry about the bad code of -a - I should have tested it first!.. With my variables, BIT64=true means a 64-bit capable CPU. EFI64 means it booted using a 64-bit UEFI BIOS.
in my code for menuentries which works and makes it really easy. For instance, enclosing a menuentry with if $BIT32 is useful so that it does not display 64-bit ISOs in the menu on a 32-bit CPU system. I don't know what the environment space is in your grub2 build, so it is up to you what variables you define. These are just suggestions which I have found very useful when making menuentries and where I want to limit the number of entries in a grub menu. I think if you used .inc files for some of your other modules, e.g. netboot, grml, etc. with a nice menuentry title and relevant 'if' statements, then you could just include all modules in a single download and the user would see only the menu entries in the main menu if the payload file was present. Also, it might be helpful to include a sample_menu.ini file and a sample_menu.module.inc file which demonstrated to the user how to add menus and also could list what pre-defined environment variables were available to use? These are just suggestions I am throwing at you to make it easier to use and more user friendly, please feel free to ignore them if you wish, I am just trying to be helpful :-) P.S. It would be nice to have sub-menus, e.g. 'addfolder xxxx', in menu.ini to add a new menu entry in the first menu which would take you to a xxxx menu which lists all modules in the \usb-modboot\xxxx folder ? |
No problem - it was just a good way to me to illustrate that it is a bad idea to have boolean variables in GRUB.
Yes, but EFI64 refers to the "bitness" of the firmware, while MBR64 refers to the "bitness" of the CPU. For consistency, it should be MBR16 only (since MBR firmware is always 16-bit) :-)
Yes, that form works, since it will call the "true" and "false" commands. But since GRUB does not support
But
However, in case of an ISO that supports both MBR and EFI32 boot I would not test for
I would want to have both listed when booting on a 64-bit cpu, since when my machine has only 2 GB or less of RAM, I'd often prefer booting the 32-bit version over the 64-bit one.
Out of curiosity: Did you ever encounter an ISO (or other boot image) that works in MBR mode on a 32-bit CPU but not on a 64-bit CPU? The only reason I could think of is licensing, since 64-bit CPUs are supposed to be 100% backwards compatible (even down to the 16-bit 8086 CPU).
Then I could also include the logic for all "modules" into the main config file. It would be equally slow, but with less cluttered files on the filesystem. Or I could have stayed with the predecessor of usb-modboot (which is still on GitHub and used such a static system). Or I could have used any of the other static systems made by other people (like you :D) where I can also add scripts myself, but should be aware that whenever I try to upgrade the main system, some of my scripts will break. In other words, my modules should only be examples, not in any way exhaustive (they are just what I needed for my own needs). On the other hand, the defined variables and functions should (barring fixed bugs in GRUB itself) be backwards compatible so if you write your own modules, you should be able to extract a newer version of USB-ModBoot on top of them and everything still works. (There are also two modules that are dynamic on the name of the module file, so you can add them more than once for multiple "payload" ISOs).
Yes, documentation can surely be improved :-)
Yeah, I understand that. But I want to understand the rationale of some of those suggestions, too, so I tend to ask back. (Feel free to ignore my questions if you don't think that your answers might change my opinion :D)
Yes, submenus is a good idea. I'd rather make it automatic, i.e. if a directory contains no I'll have to refactor my script a bit to do that (in particular, pass a path to the menuentries as third parameter). |
Directories that contain neither `grub.cfg` nor `grub.inc` are automatically converted to submenus. Subdirectories can also be used in `addmodule` command in menu.ini to add submenus to favourites. Also add SUPPORTS_64_BIT variable to test whether the processor supports 64-bit (long mode). See #3.
Documentation improvements still pending. |
grub_cpu returns "i386" on a 64-bit system, I suggest setting up some variables for the user to use in his .cfg or .inc files to make it easier, e.g.
ISO files can be placed in a sub-folder and then .inc menus can be added such as
The text was updated successfully, but these errors were encountered: