{"action":"created","issue":{"url":"https://api.github.com/repos/schierlm/usb-modboot/issues/3","repository_url":"https://api.github.com/repos/schierlm/usb-modboot","labels_url":"https://api.github.com/repos/schierlm/usb-modboot/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/schierlm/usb-modboot/issues/3/comments","events_url":"https://api.github.com/repos/schierlm/usb-modboot/issues/3/events","html_url":"https://github.com/schierlm/usb-modboot/issues/3","id":362939061,"node_id":"MDU6SXNzdWUzNjI5MzkwNjE=","number":3,"title":"In MBR mode on 64-bit system, $grub_cpu is i386 not x84_64","user":{"login":"steve6375","id":1469350,"node_id":"MDQ6VXNlcjE0NjkzNTA=","avatar_url":"https://avatars2.githubusercontent.com/u/1469350?v=4","gravatar_id":"","url":"https://api.github.com/users/steve6375","html_url":"https://github.com/steve6375","followers_url":"https://api.github.com/users/steve6375/followers","following_url":"https://api.github.com/users/steve6375/following{/other_user}","gists_url":"https://api.github.com/users/steve6375/gists{/gist_id}","starred_url":"https://api.github.com/users/steve6375/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/steve6375/subscriptions","organizations_url":"https://api.github.com/users/steve6375/orgs","repos_url":"https://api.github.com/users/steve6375/repos","events_url":"https://api.github.com/users/steve6375/events{/privacy}","received_events_url":"https://api.github.com/users/steve6375/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-09-23T12:33:19Z","updated_at":"2018-09-24T16:13:10Z","closed_at":null,"author_association":"NONE","body":"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.\r\n```\r\n# DEFINE VARIABLES FOR MBR\\EFI and 32/64-bit\r\nset BIT64=false; set BIT32=false; set MBR=false; set EFI=false; set EFI64=false; set EFI32=false; set MBR32=false; set MBR64=false\r\nif cpuid -l; then set BIT64=true; else set BIT32=true; fi\r\nif [ \"${grub_platform}\" == \"pc\" ]; then set MBR=true; fi\r\nif [ \"${grub_platform}\" == \"efi\" ]; then set EFI=true; fi\r\nif [ \"${grub_cpu}\" == \"x86_64\" and $EFI = true ]; then set EFI64=true; fi\r\nif [ \"${grub_cpu}\" == \"i386\" and $EFI = true ]; then set EFI32=true; fi\r\nif [ $BIT64 = true and $MBR = true ]; then set MBR64=true; fi\r\nif [ $BIT32 = true and $MBR = true ]; then set MBR32=true; fi\r\nexport MBR EFI MBR32 MBR64 EFI32 EFI64 BIT32 BIT64\r\n#Examples\r\n#if [ $BIT64 = true and $MBR = true ] ; then echo 64-bit MBR ; fi\r\n#if [ $BIT64 = true and $EFI = true ] ; then echo 64-bit EFI ; fi\r\n#if $BIT64 ; then echo 64-bit ; fi\r\n#if $BIT32 ; then echo 32-bit ; fi\r\n```\r\n\r\n\r\nISO files can be placed in a sub-folder and then .inc menus can be added such as\r\n\r\n```\r\n\tif [ -f \"/usb-modboot/ISO/ubuntu-18.04-desktop-amd64.iso\" -a $BIT64 ]; then\r\n\t\t\tmenuentry \"Ubuntu amd64\" \"ubuntu.iso\" {\r\n\t\t\t\tset iso_path=\"/usb-modboot/ISO/ubuntu-18.04-desktop-amd64.iso\"\r\n\t\t\t\texport iso_path\r\n\t\t\t\tloopback loopdev_cfg \"${iso_path}\"\r\n\t\t\t\tset orig_root=\"$root\"\r\n\t\t\t\tset root=(loopdev_cfg)\r\n\t\t\t\tconfigfile /boot/grub/loopback.cfg\r\n\t\t\t\tloopback -d loopdev_cfg\r\n\t\t\t\tset root=\"$orig_root\"\r\n\t\t\t\tterminal_output $terminal\r\n\t\t\t}\r\n\tfi\r\n\r\n\r\n\r\n```\r\n"},"comment":{"url":"https://api.github.com/repos/schierlm/usb-modboot/issues/comments/424032797","html_url":"https://github.com/schierlm/usb-modboot/issues/3#issuecomment-424032797","issue_url":"https://api.github.com/repos/schierlm/usb-modboot/issues/3","id":424032797,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNDAzMjc5Nw==","user":{"login":"schierlm","id":1568931,"node_id":"MDQ6VXNlcjE1Njg5MzE=","avatar_url":"https://avatars1.githubusercontent.com/u/1568931?v=4","gravatar_id":"","url":"https://api.github.com/users/schierlm","html_url":"https://github.com/schierlm","followers_url":"https://api.github.com/users/schierlm/followers","following_url":"https://api.github.com/users/schierlm/following{/other_user}","gists_url":"https://api.github.com/users/schierlm/gists{/gist_id}","starred_url":"https://api.github.com/users/schierlm/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/schierlm/subscriptions","organizations_url":"https://api.github.com/users/schierlm/orgs","repos_url":"https://api.github.com/users/schierlm/repos","events_url":"https://api.github.com/users/schierlm/events{/privacy}","received_events_url":"https://api.github.com/users/schierlm/received_events","type":"User","site_admin":false},"created_at":"2018-09-24T16:13:10Z","updated_at":"2018-09-24T16:13:10Z","author_association":"OWNER","body":"> sorry about the bad code of -a - I should have tested it first!..\r\n\r\nNo problem - it was just a good way to me to illustrate that it is a bad idea to have boolean variables in GRUB.\r\n\r\n> With my variables, BIT64=true means a 64-bit capable CPU. EFI64 means it booted using a 64-bit UEFI BIOS.\r\n\r\nYes, 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) :-)\r\n\r\n> I actually use, e.g.\r\n> \r\n> ```\r\n> if $BIT64; then \r\n> \r\n> (menuentry here)\r\n> \r\n> fi\r\n> ```\r\n> in my code for menuentries which works and makes it really easy.\r\n\r\nYes, that form works, since it will call the \"true\" and \"false\" commands. But since GRUB does not support `&&` or `||` in commands, any attempt to combine two such variables will fail.\r\n\r\n> 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.\r\n\r\nBut `if ! cpuid -l` works equally well...\r\n\r\n> In the case of a 64-bit Atom CPU which has a UEFI32 BIOS, it can run a 32-bit ISO if $EFI64 is false (or $MBR and $EFI32 is true), so **32-bit ISOs** which can MBR and UEFI-boot should test for **if ! $EFI64**. So both $BIT64 and $EFI64 are useful.\r\n\r\nHowever, in case of an ISO that supports both MBR and EFI32 boot I would not test for `! $EFI64`, since that (again) assumes that the list of options is exhaustive. If later I add support for 64-bit Coreboot (for example) to USB-ModBoot, the module would break (assuming it cannot boot on coreboot either). Therefore, I'd rather use something like `if [\"$MBR\" = \"true\" -o \"$EFI32\" = \"true\" ]` instead of using a variable that just happens to work correctly \"by accident\".\r\n\r\n> Some ISOs do not support UEFI, so $MBR32 and $MBR64 are useful (you could have both a 64-bit linux ISO and the same linux version in 32-bit form but only want to have one listed in the menu depending on your CPU type).\r\n\r\nI 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.\r\n\r\n> ISOs which do not support UEFI-booting but do support booting on 32-bit and 64-bit CPUs can use $MBR. Same for $MBR64 or $MBR32 where the ISO only support that type of system.\r\n\r\nOut 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).\r\n\r\n> 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.\r\n\r\nThen 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.\r\n\r\nIn 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.\r\n\r\n(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).\r\n\r\n> 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?\r\n\r\nYes, documentation can surely be improved :-)\r\n \r\n> 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 :-)\r\n\r\nYeah, 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)\r\n\r\n> 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 ?\r\n\r\nYes, submenus is a good idea. I'd rather make it automatic, i.e. if a directory contains no `grub.cfg` and no `grub.inc`, it becomes a submenu with its contents. You can still use `addmodule` to add such a directory to the menu manually, but you can also just have a directory structure and menus will come to life automatically.\r\n\r\nI'll have to refactor my script a bit to do that (in particular, pass a path to the menuentries as third parameter).\r\n"}}
{"actor":{"display_login":"schierlm"}}