2014-11-18 23:49:29 +00:00
|
|
|
This directory contains the Grub 2.0 boot records that are used by Rufus
|
2014-11-17 23:41:46 +00:00
|
|
|
|
2020-09-16 12:59:06 +00:00
|
|
|
* boot.img and core.img were created from:
|
|
|
|
|
https://ftp.gnu.org/gnu/grub/grub-2.04.tar.xz
|
[grub] add yet another frigging patch to GRUB "2.04"
* GRUB 2.0 maintainer think they're doing a fine job, even when there are
CRITICAL SECURITY FIXES that should warrant an immediate out of bound
release, and instead consider that waiting MONTHS or YEARS to release
anything is not a big deal at all.
* Ergo, distros, such as Ubuntu, start to pick whatever security patches
they see fit, since they can simply not RELY on the upstream project to
produce security releases in a timely manner. One such patch is:
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00012.html
* But since there is no new GRUB release per se, they still call their GRUB
version, onto which they applied patches that have come into existence
more than 2 years after the actual 2.04 release, "GRUB 2.04".
* Obviously, since GRUB 2.04 + literally hundreds of cherry picked patches
does deviate a lot from the last release, THINGS BREAK IN SPECTACULAR
FASHION, such as the recently released Ubuntu 21.04 failing to boot with
the error: grub_register_command_lockdown not found.
* Oh, and of course, regardless of all the above, if you ask anyone, they'll
tell you that there's nothing fundamentally wrong with the GRUB release
process (even if they should long have released 2.05, 2.05-1 and 2.05-2,
were their maintainer ready to acknowledge that delaying releases DOES
CREATES MAJOR ISSUES DOWSTREAM, as many people REPEATEDLY pointed to them
on the GRUB mailing list) or with the Ubuntu GRUB versioning process (that
really shouldn't be calling their version of GRUB "grub-2.04" but instead
something like "grub-2.04_ubuntu"). Oh no siree! Instead, the problem must
all be with Rufus and its maintainer, who should either spend their lives
pre-emptively figuring which breaking patch every other distro applied out
there, or limit media creation to DD mode, like any "sensible" person
would do, since DD mode is the ultimate panacea (Narrator: "It wasn't").
* So, once again, a massive thanks to all the people who have been involved
in the current GRUB 2.0 shit show, whose DIRECT result is to make end
users' lives miserable, while GRUB maintainers are hell bent on continuing
to pretend that everything's just peachy and are busy patting themselves
on the back on account that "Fedora recently dropped more than 100 of the
custom patches they had to apply to their GRUB fork" (sic). Nothing to see
here, it's just GRUB maintainer's Jedi business as usual. Besides, who the
hell cares about Windows users trying to transition to Linux in a friendly
manner anyway. I mean, as long as something doesn't affect existing Linux
users, it isn't a REAL problem, right?...
2021-04-22 22:59:17 +00:00
|
|
|
with the following 3 extra patches applied:
|
2020-09-16 12:59:06 +00:00
|
|
|
- https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00016.html
|
|
|
|
|
- https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00017.html
|
[grub] add yet another frigging patch to GRUB "2.04"
* GRUB 2.0 maintainer think they're doing a fine job, even when there are
CRITICAL SECURITY FIXES that should warrant an immediate out of bound
release, and instead consider that waiting MONTHS or YEARS to release
anything is not a big deal at all.
* Ergo, distros, such as Ubuntu, start to pick whatever security patches
they see fit, since they can simply not RELY on the upstream project to
produce security releases in a timely manner. One such patch is:
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00012.html
* But since there is no new GRUB release per se, they still call their GRUB
version, onto which they applied patches that have come into existence
more than 2 years after the actual 2.04 release, "GRUB 2.04".
* Obviously, since GRUB 2.04 + literally hundreds of cherry picked patches
does deviate a lot from the last release, THINGS BREAK IN SPECTACULAR
FASHION, such as the recently released Ubuntu 21.04 failing to boot with
the error: grub_register_command_lockdown not found.
* Oh, and of course, regardless of all the above, if you ask anyone, they'll
tell you that there's nothing fundamentally wrong with the GRUB release
process (even if they should long have released 2.05, 2.05-1 and 2.05-2,
were their maintainer ready to acknowledge that delaying releases DOES
CREATES MAJOR ISSUES DOWSTREAM, as many people REPEATEDLY pointed to them
on the GRUB mailing list) or with the Ubuntu GRUB versioning process (that
really shouldn't be calling their version of GRUB "grub-2.04" but instead
something like "grub-2.04_ubuntu"). Oh no siree! Instead, the problem must
all be with Rufus and its maintainer, who should either spend their lives
pre-emptively figuring which breaking patch every other distro applied out
there, or limit media creation to DD mode, like any "sensible" person
would do, since DD mode is the ultimate panacea (Narrator: "It wasn't").
* So, once again, a massive thanks to all the people who have been involved
in the current GRUB 2.0 shit show, whose DIRECT result is to make end
users' lives miserable, while GRUB maintainers are hell bent on continuing
to pretend that everything's just peachy and are busy patting themselves
on the back on account that "Fedora recently dropped more than 100 of the
custom patches they had to apply to their GRUB fork" (sic). Nothing to see
here, it's just GRUB maintainer's Jedi business as usual. Besides, who the
hell cares about Windows users trying to transition to Linux in a friendly
manner anyway. I mean, as long as something doesn't affect existing Linux
users, it isn't a REAL problem, right?...
2021-04-22 22:59:17 +00:00
|
|
|
- https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00012.html
|
2020-09-16 12:59:06 +00:00
|
|
|
on a Debian 10.x x64 system using the commands:
|
|
|
|
|
./autogen.sh
|
|
|
|
|
./configure --disable-nls --enable-boot-time
|
|
|
|
|
make -j6
|
|
|
|
|
cd grub-core
|
|
|
|
|
../grub-mkimage -v -O i386-pc -d. -p\(hd0,msdos1\)/boot/grub biosdisk part_msdos fat ntfs exfat -o core.img
|
2014-11-18 23:49:29 +00:00
|
|
|
|
|
|
|
|
* boot.img has been modified to nop the jump @ 0x66 as per grub2's setup.c comments:
|
|
|
|
|
/* If DEST_DRIVE is a hard disk, enable the workaround, which is
|
|
|
|
|
for buggy BIOSes which don't pass boot drive correctly. Instead,
|
|
|
|
|
they pass 0x00 or 0x01 even when booted from 0x80. */
|
|
|
|
|
|
|
|
|
|
* Note that, for convenience reasons, the content of boot.img is *not* the one that
|
|
|
|
|
Rufus processes when writing the MBR.
|
|
|
|
|
Instead, the byte array from src/ms-sys/inc/mbr_grub2.h (whose content is identical)
|
|
|
|
|
is what Rufus uses. If you modify these files, be mindful that you may also need
|
|
|
|
|
to update the array in mbr_grub2.h.
|
|
|
|
|
|
|
|
|
|
* For details, see src/format.c, src/msys/br.c and src/msys/inc/mbr_grub2.h.
|