Activity for Amigo Ventero
-
Amigo Ventero modified a comment on ticket #11
I maked tests and result is base grub2 code passes the baton to core.img which is written after MBR. So is all clear and this is not bug and close this thread is possible. It also looks like the core.img code is variable and it probably defines the partition FS and other from which it loads modules, because after adding it to the USB-flash fat32 ignored the configuration on the USB-flash and loaded it from the ext4 HDD. This is probably handled by a script from grub-install. Thank for your time and...
-
I maked tests and result is base grub2 code passes the baton to core.img which is written after MBR. So is all clear and this is not bug and close this thread is possible. It also looks like the core.img code is variable and it probably defines the FS partition from which it loads modules, because after adding it to the USB-flash fat32 ignored the configuration on the USB-flash and loaded it from the ext4 HDD. This is probably handled by a script from grub-install. Thank for your time and best w...
-
I maked tests and result is base grub2 code passes the baton to core.img which is written after MBR. So is all clear and this is not bug and close this thread is possible. It also looks like the core.img code is variable and it probably defines the FS partition from which it loads modules, because after adding it to the USB-flash fat32 ignored the configuration to the USB-flash and loaded it from the ext4 HDD. This is probably handled by a script from grub-install. Thank for your time and best w...
-
I maked tests and result is base grub2 code passes the baton to core.img which is written after MBR. So is all clear and this is not bug and close this thread is possible. Thank for your time and best wishes.
-
Unless it takes it from that folder during installation - that would also explain core.img file in folder
-
I understand your arguments. Depending on what we've gathered together for the information, it's half and half, whether it's a missing next code or an error in the base code - why else would the core.img file be in the grub folder? So I'll try to ask PB how it is - he will probably be acquainted in more detail.
-
As far as I know, other boot loaders do so - for example, the Winloader or G4D does not distinguish whether FS is ntfs or fat and loads the appropriate module for further management. It is true, that in rufus grub2 installing is fixed choice for fat32 - then if you really needed something more beyond MBR for recognize FS, so this could be solved by an additional parameter to ms-sys. But then is need to find out how it really is , whether it is loaded from the location immediately after the MBR or...
-
It looks like it's going to load directly from the filesystem - grubfolder i386-pc include file core.img . In the end, I still think that the USB flash is evaluated the same as the HDD and that it may be an error. It is also possible that the code 0x80 may no longer be valid - I have experience that this parameter does not work with syslinux/isolinux chainloading to HDD, although it is set by default in the configurations of various Linux installers. Via Rufus is choice grub2-bootloader install fully...
-
On wiki GNU is written, if i think this good, that core is possible put at defined filesystem - then is necessary modified main mbr code. But with modern formating, with starting at 1MiB for alignment, this is redundant. Yes - you have right - this is probably for support request. Minimalist systems are often without grub tools and ms-sys is smaller, more univerzal and more simple for remmember with good manpage.
-
Thank you for vector and your time. By info from GNU GRUB you almost hit. The image files that make up grub2 have been reorganised; Stage 1, Stage 1.5, and Stage 2 are no more - now is image system - and grub2 mbr code search for "core.img", which is written in next at least 31KiB. From GNU wiki: This is the core image of GRUB. It is built dynamically from the kernel image and an arbitrary list of modules by the grub-mkimage program. Usually, it contains enough modules to access /boot/grub, and loads...
-
Thank you for vector. By info from GNU GRUB you almost hit. The image files that make up grub2 have been reorganised; Stage 1, Stage 1.5, and Stage 2 are no more - now is image system - and grub2 mbr code search for "core.img", which is written in next at least 31KiB. From GNU wiki: This is the core image of GRUB. It is built dynamically from the kernel image and an arbitrary list of modules by the grub-mkimage program. Usually, it contains enough modules to access /boot/grub, and loads everything...
-
Thank you for vector. By info from GNU GRUB you almost hit. The image files that make up grub2 have been reorganised; Stage 1, Stage 1.5, and Stage 2 are no more - now is image system - and grub2 mbr code search for "core.img", which is written in next at least 31KiB. From GNU wiki: This is the core image of GRUB. It is built dynamically from the kernel image and an arbitrary list of modules by the grub-mkimage program. Usually, it contains enough modules to access /boot/grub, and loads everything...
-
In Win via Rufus is this procedure fully functional.
-
In Win via Rufus this is fully functional.
-
grub2 boot record unfunctional
1
