Re: Bad shim signature on kernel loading with patchset from 25.05.2023 and up
On Thu, Jun 22, 2023 at 3:00 PM Tobias Powalowski via Grub-devel wrote: > > Hi, > just curious since the patchset from 25.05.2023, I cannot use Secure Boot on > my project anymore. The kernel hash cannot be validated anymore and shim > bails out with bad shim signature. > Any help would be appreciated. > greetings > tpowa According to shim documentation the shim lock protocol should use SysV abi instead of MS abi. So could you try if it solves your issue if you remove "__grub_efi_api" from the verify function of grub_efi_shim_lock_protocol in include/grub/efi/api.h in around line 1780 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v4 3/5] efi: Drop all uses of efi_call_XX wrappers
On Wed, Jun 14, 2023 at 5:17 PM Daniel Kiper wrote: > > On Mon, Jun 12, 2023 at 10:53:09PM +0200, Robin Candau wrote: > > Le 12/06/2023 à 21:05, Daniel Kiper a écrit : > > > On Mon, Jun 12, 2023 at 07:19:53PM +0200, Christian Hesse wrote: > > > > Ard Biesheuvel on Tue, 2023/05/23 17:31: > > > > > Now that GCC can generate function calls using the correct calling > > > > > convention for us, we can stop using the efi_call_XX () wrappers, and > > > > > just dereference the function pointers directly. > > > > > > > > > > This avoids the untyped variadic wrapper routines, which means better > > > > > type checking for the method calls. > > > > Building an Arch package from current git master makes the system > > > > unbootable > > > > with just a black screen. We did biscect this and found this commit > > > > (bb4aa6e06ee3877110a1dc0eb0d766ffac978993 in master) to be the first > > > > bad one. > > > > > > > > As gcc is mentioned in the commit message... We are building with gcc > > > > 13.1.1-1. Any idea what is going on here? > > > Could you provide us more details? On which architecture/target do > > > you run tests? Does GRUB start? If yes which kernel version do you > > > try to boot? Could you send us a link to the GRUB and kernel packages > > > and sources? Etc... > > > > > > Daniel > > > > Hi, > > > > Tests have been ran on a x86_64 laptop (but the issue has been reproduced on > > several other x86_64 machines). GRUB does not start, we don't even reach the > > GRUB menu, nothing more than a black screen at boot. > > The kernel we're trying to boot is `linux 6.3.7-arch1-1` [1] (package [2]), > > but I doubt the kernel itself is in cause as we're able to boot it with a > > GRUB package built without the bb4aa6e06ee3877110a1dc0eb0d766ffac978993 > > commit. Here's a working GRUB package [3] and a faulty one [4]. > > Sources are taken from https://git.savannah.gnu.org/git/grub.git [5]. > > > > I remain available if you need specific tests or additional information. > > > > [1] https://archlinux.org/packages/core/x86_64/linux/ > > [2] > > http://www.gtlib.gatech.edu/pub/archlinux/core/os/x86_64/linux-6.3.7.arch1-1-x86_64.pkg.tar.zst > > [3] > > https://pkgbuild.com/~eworm/grub/grub-2:2.06.r535.g6a080b9cd-2-x86_64.pkg.tar.zst > > [4] > > https://pkgbuild.com/~eworm/grub/grub-2:2.06.r554.gc016a969d-2-x86_64.pkg.tar.zst > > [5] > > https://gitlab.archlinux.org/archlinux/packaging/packages/grub/-/blob/main/PKGBUILD#L60 > > It looks I was able to reproduce this problem. I will be checking what > is going on in following days... > > Daniel After looking at the patch, I would assume that the __grub_efi_api calling convention annotiation is missing in the protocol definitions of include/grub/efi/console_control.h include/grub/efi/graphics_output.h include/grub/efi/uga_draw.h > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] kern/misc: Move grub_printf_fmt_check to gfxmenu
On Sat, Mar 20, 2021 at 1:22 AM Colin Watson wrote: > > This function is only used by gfxmenu. Moving it there is unfortunately > a bit messy, but it frees up a fairly substantial amount (in relative > terms) of precious core image space on i386-pc. > > DOWN: obj/i386-pc/grub-core/kernel.img (31740 > 31528) - change: -212 > UP: obj/i386-pc/grub-core/gfxmenu.mod (39816 < 40216) - change: 400 > DOWN: i386-pc core image (biosdisk ext2 part_msdos) (27453 > 27351) - > change: -102 > DOWN: i386-pc core image (biosdisk ext2 part_msdos diskfilter mdraid09) > (32367 > 32259) - change: -108 Thank you for the size analysis. Size constraints on i386-pc was something I had not considered when I wrote the original patch. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Add chainloaded image as shim's verifiable object
On Mon, Mar 8, 2021 at 5:59 AM Michael Chang via Grub-devel wrote: > > On Fri, Mar 05, 2021 at 01:49:00PM +, Dimitri John Ledkov wrote: > > On Fri, Mar 5, 2021 at 1:34 PM Michael Chang wrote: > > > > > > On Fri, Mar 05, 2021 at 12:21:49PM +, Dimitri John Ledkov wrote: > > > > This is not an oversight but intentional. > > > > > > > > Currently there is no chainloader support with SBAT as further > > > > development is required to ensure policy is applied correctly. Once > > > > SBAT support for chainloading is defined, it will be introduced. > > > > > > Hm. What I heard is that shim wouldn't enfore SBAT validation for the > > > "indirect" image loaded by grub for now. So we should still able to > > > boot, eg, kernel and other efi image loaded by grub which is still in > > > lacking of SBAT support. > > > > > > > There is a difference between chainloading a new bootloader, or > > booting a linux kernel. > > When chainloading a different grub that is verified by the vendor-db > > in shim, sbat should be enforced, if the current grub has sbat. > > When chainloading windows bootmgr, which is signed by things in db, > > sbat need not be enforced. > > Can't this be done in shim and shim_lock itself ? It should be able to > discern that the .sbat is missing and therefore skip vendor-db. For the > linux distribution they should only take care rotating out their signing > keys for this boothole2 update and use shim_lock to reject degrarded > pre-boothole2 grub release. > > Or did I miss anything here ? As far as I understand it there is one thing to keep in mind when using chainloader with the upcoming shim: If a new vulnerability is discovered in Grub any time in the future, then the SBAT revocation has to be done for the Shim, not Grub. Then a new Shim would need to blacklist all vulnerable Grub versions that were signed with the embedded key. This is because a new, fixed Grub would still load the vulnerable Grub through chainloader and Shim would accept it because it does not check the SBAT section on that verification path. Of course the revocation can be handled on a per distribution / product basis. But this is probably something to discuss on the shim review board. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Add chainloaded image as shim's verifiable object
On Fri, Mar 5, 2021 at 1:12 PM Michael Chang via Grub-devel wrote: > > While attempting to dual boot Microsoft Windows with efi chainloader, it > failed with below error when secure boot was enabled. > > error ../../grub-core/kern/verifiers.c:119:verification requested but > nobody cares: /EFI/Microsoft/Boot/bootmgfw.efi. > > It is a regression, as previously it worked without problem. > > It turns out chainloading image has been locked down introduced by > > 578c95298 kern: Add lockdown support > > However we should consider it as verifiable object to shim to allow > booting in secure boot enabled mode. The chainloaded image could also > have trusted signature signed by vendor with their pubkey cert in db. > For that matters it's usage should not be locked down in secure boot, > and instead use shim to validate it's signature before running it. > > Signed-off-by: Michael Chang [cut out] >/* Fall through. */ > diff --git a/grub-core/kern/lockdown.c b/grub-core/kern/lockdown.c > index 0bc70fd42..e1fd1c1e2 100644 > --- a/grub-core/kern/lockdown.c > +++ b/grub-core/kern/lockdown.c > @@ -48,7 +48,6 @@ lockdown_verifier_init (grub_file_t io __attribute__ > ((unused)), > case GRUB_FILE_TYPE_PXECHAINLOADER: > case GRUB_FILE_TYPE_PCCHAINLOADER: > case GRUB_FILE_TYPE_COREBOOT_CHAINLOADER: > -case GRUB_FILE_TYPE_EFI_CHAINLOADED_IMAGE: > case GRUB_FILE_TYPE_ACPI_TABLE: > case GRUB_FILE_TYPE_DEVICE_TREE_IMAGE: >*flags = GRUB_VERIFY_FLAGS_DEFER_AUTH; > -- > 2.26.2 The lockdown verifier makes sure that at least one verifer has validated the image. So removing GRUB_FILE_TYPE_EFI_CHAINLOADED_IMAGE from it is a very bad idea. > ___ > Grub-devel mailing list > Grub-devel@gnu.orgthe > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: announcing XHCI support (USB 3.0)
Hi Jan, I noticed that the code will not handle XHCI controllers with multiple USB 3 port ranges. This is no problem with USB 3.0 controllers, but the USB 3.1 and USB 3.2 specs brought additional speeds. At my workplace we have a Ryzen mainboard with an XHCI controller where 2 ports support up to Gen2 speed and 2 ports support Gen 1 (USB 3.0) speed. The code in xhci.c will not handle that correctly, as it only supports one USB 3 configuration and it does not check if it already found any USB 3 ports. The BIOS handoff code also looks sketchy. XHCI handles BIOS handoff through an extended attribute in the mmio space. The code tries to do the handoff through the pci space. That code looks like it has been copied over from EHCI where the BIOS handoff fields are located in the PCI space. I also don't see any adjustments to handle USB3 hubs, but I did not look very hard. USB3 hubs use different hub descriptors and a different port status field so they need some special handling. The USB2 part of the hubs on a XHCI controller should be fine. If you have any questions feel free to ask. Greetings, Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/4] efinet: UEFI IPv6 PXE support
On Fri, Jun 5, 2020 at 4:16 AM Michael Chang wrote:
>
> You're probably right if the data type for `station_ip` is
> `grub_efi_pxe_ip_address_t`, but here it is `grub_efi_ip_address_t` declared
> as:
>
> typedef grub_uint8_t grub_efi_ip_address_t[8] __attribute__ ((aligned(4)));
>
> So the compiler would have been taking care of the alignment already ...
Oh, right.
I only ran into an alignment problem wenn I combined your patches to use the
UEFI Managed Network Protocol together with a patch to handle proxy dhcp.
Sorry for the noise
> By the way, I found the mentioned hunk is different to what was posted on the
> list[1], which had relevant fields like this:
>
> grub_uint8_t using_ipv6;
> grub_uint8_t unused[16];
> grub_efi_pxe_ip_address_t station_ip;
> grub_efi_pxe_ip_address_t subnet_mask;
>
> Maybe Javier could help to shed some light on why the change was made ? Though
> I'm not against it, I'm still interested to know about it if they have any
> other concern or in case anything could be missing here. :)
>
> [1] https://lists.gnu.org/archive/html/grub-devel/2016-08/msg3.html
>
> Thanks,
> Michael
>
> >
> > On Thu, Jun 4, 2020 at 9:34 AM Javier Martinez Canillas
> > wrote:
> > >
> >
> > > typedef struct grub_efi_pxe_mode
> > > {
> > > - grub_uint8_t unused[52];
> > > + grub_efi_boolean_t started;
> > > + grub_efi_boolean_t ipv6_available;
> > > + grub_efi_boolean_t ipv6_supported;
> > > + grub_efi_boolean_t using_ipv6;
> > > + grub_efi_boolean_t bis_supported;
> > > + grub_efi_boolean_t bis_detected;
> > > + grub_efi_boolean_t auto_arp;
> > > + grub_efi_boolean_t send_guid;
> > > + grub_efi_boolean_t dhcp_discover_valid;
> > > + grub_efi_boolean_t dhcp_ack_received;
> > > + grub_efi_boolean_t proxy_offer_received;
> > > + grub_efi_boolean_t pxe_discover_valid;
> > > + grub_efi_boolean_t pxe_reply_received;
> > > + grub_efi_boolean_t pxe_bis_reply_received;
> > > + grub_efi_boolean_t icmp_error_received;
> > > + grub_efi_boolean_t tftp_error_received;
> > > + grub_efi_boolean_t make_callbacks;
> > > + grub_efi_uint8_t ttl;
> > > + grub_efi_uint8_t tos;
> > > + grub_efi_ip_address_t station_ip;
> > > + grub_efi_ip_address_t subnet_mask;
> > >grub_efi_pxe_packet_t dhcp_discover;
> > >grub_efi_pxe_packet_t dhcp_ack;
> > >grub_efi_pxe_packet_t proxy_offer;
> > >grub_efi_pxe_packet_t pxe_discover;
> > >grub_efi_pxe_packet_t pxe_reply;
> > > + grub_efi_pxe_packet_t pxe_bis_reply;
> > > + grub_efi_pxe_ip_filter_t ip_filter;
> > > + grub_efi_uint32_t arp_cache_entries;
> > > + grub_efi_pxe_arp_entry_t
> > > arp_cache[GRUB_EFI_PXE_BASE_CODE_MAX_ARP_ENTRIES];
> > > + grub_efi_uint32_t route_table_entries;
> > > + grub_efi_pxe_route_entry_t
> > > route_table[GRUB_EFI_PXE_BASE_CODE_MAX_ROUTE_ENTRIES];
> > > + grub_efi_pxe_icmp_error_t icmp_error;
> > > + grub_efi_pxe_tftp_error_t tftp_error;
> > > } grub_efi_pxe_mode_t;
> > >
> > > typedef struct grub_efi_pxe
Those changes look like the api.h changes in a patch from Joseph
Mroczek to support proxy dhcp
https://lists.gnu.org/archive/html/grub-devel/2014-05/msg2.html
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/4] efinet: UEFI IPv6 PXE support
Hi,
You replace the 'unused[52]' field before dhcp_discover with 51 bytes.
While the UEFI spec also defines the EFI_PXE_BASE_CODE_MODE struct in
this way it also specifies that an EFI_IP_ADDRESS is 16-byte buffer
aligned on a 4-byte boundary.
So there should probably be a grub_efi_uint8_t between tos and
station_ip to ensure the correct alignment
On Thu, Jun 4, 2020 at 9:34 AM Javier Martinez Canillas
wrote:
>
> typedef struct grub_efi_pxe_mode
> {
> - grub_uint8_t unused[52];
> + grub_efi_boolean_t started;
> + grub_efi_boolean_t ipv6_available;
> + grub_efi_boolean_t ipv6_supported;
> + grub_efi_boolean_t using_ipv6;
> + grub_efi_boolean_t bis_supported;
> + grub_efi_boolean_t bis_detected;
> + grub_efi_boolean_t auto_arp;
> + grub_efi_boolean_t send_guid;
> + grub_efi_boolean_t dhcp_discover_valid;
> + grub_efi_boolean_t dhcp_ack_received;
> + grub_efi_boolean_t proxy_offer_received;
> + grub_efi_boolean_t pxe_discover_valid;
> + grub_efi_boolean_t pxe_reply_received;
> + grub_efi_boolean_t pxe_bis_reply_received;
> + grub_efi_boolean_t icmp_error_received;
> + grub_efi_boolean_t tftp_error_received;
> + grub_efi_boolean_t make_callbacks;
> + grub_efi_uint8_t ttl;
> + grub_efi_uint8_t tos;
> + grub_efi_ip_address_t station_ip;
> + grub_efi_ip_address_t subnet_mask;
>grub_efi_pxe_packet_t dhcp_discover;
>grub_efi_pxe_packet_t dhcp_ack;
>grub_efi_pxe_packet_t proxy_offer;
>grub_efi_pxe_packet_t pxe_discover;
>grub_efi_pxe_packet_t pxe_reply;
> + grub_efi_pxe_packet_t pxe_bis_reply;
> + grub_efi_pxe_ip_filter_t ip_filter;
> + grub_efi_uint32_t arp_cache_entries;
> + grub_efi_pxe_arp_entry_t arp_cache[GRUB_EFI_PXE_BASE_CODE_MAX_ARP_ENTRIES];
> + grub_efi_uint32_t route_table_entries;
> + grub_efi_pxe_route_entry_t
> route_table[GRUB_EFI_PXE_BASE_CODE_MAX_ROUTE_ENTRIES];
> + grub_efi_pxe_icmp_error_t icmp_error;
> + grub_efi_pxe_tftp_error_t tftp_error;
> } grub_efi_pxe_mode_t;
>
> typedef struct grub_efi_pxe
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: does grub2 support proxy dhcp?
On Thu, Apr 2, 2020 at 7:39 PM Daniel Kiper wrote: > > On Wed, Apr 01, 2020 at 11:08:07PM +0200, Thomas Frauendorfer wrote: > > Hi Olaf, > > > > Current Grub does not handle proxy DHCP correctly. > > There is a patch to add support for proxy DHCP in the mailing list > > archives, but it was never merged. > > I did some adjustments to make it apply to 2.04 for work which I could > > share if you are interested. > > Yes, please share it... Hi, I pushed the current state to https://github.com/MiraySoftware/grub2/commits/sysload_2_4_pxe but the patches are not cleaned up to a state that would allow the merge them to Grub. Also, the patches apply to 2.04 but won't apply to Grub trunk because of the most recent changes there, The updated patch based on the on this mailing list is here: https://github.com/MiraySoftware/grub2/commit/9f2092f4bb3ab462e07bc80969e60234fc191b5b Then some adjustments to make it work in our test setup: https://github.com/MiraySoftware/grub2/commit/5a50f39e7172540bf8c4d5c77a3ccf2263857db5 Then a patch to prefer proxy dhcp as default server: https://github.com/MiraySoftware/grub2/commit/01ffd8b28e8bccae25d9851d4bc53c3c0a4c4d8c And a patch to add a environment variable to get the tftp server because I wasn't sure if the grub_net_default_server variable should refer to the dhcp or the tftp server and I did not want to change too much in the current default behavior. https://github.com/MiraySoftware/grub2/commit/ef33547863b2261a433ed23ce18c2772766ee51f I don't know if those patches are of any use to anybody. But if you have any questions please feel free to ask. Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: does grub2 support proxy dhcp?
Hi Olaf, Current Grub does not handle proxy DHCP correctly. There is a patch to add support for proxy DHCP in the mailing list archives, but it was never merged. I did some adjustments to make it apply to 2.04 for work which I could share if you are interested. On Mon, Mar 30, 2020 at 1:55 PM Olaf Hering wrote: > > According to dnsmasq(8) one host can act as a plain DHCP server, while > another one supplies TFTP. Apparently this is called "proxy-DHCP", and > happens to work just fine with the ordinary 'pxelinux.0' bootfile from > syslinux. > > With grub2 it fails because all the relevant variables for TFTP point to the > IP address of the DHCP server. > > Is this just a regression in grub.git#master, or does/did this work for > anyone? > > > Olaf > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bug fix for ntfs
On Wed, Apr 25, 2012 at 5:01 AM, Bean bean12...@gmail.com wrote: Thanks for the info, I don't have any 4K drive to test. You can check if ntfs fs driver is working properly since I don't remember if I have made the 1024 MFT assumption elsewhere. I don't know yet when I will have the time to test it because the 4k drives are test hardware at work. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bug fix for ntfs
On Mon, Apr 23, 2012 at 6:03 PM, Bean bean12...@gmail.com wrote: Hi, 2, Previous version doesn't return blocklist information for small files embed in MFT, this patch fixes it. For example, create a 512-byte file test in ntfs and try this command: grub-fstest /ntfs.img blocklist /test It looks like this part of patch has issues. Like that it doesn't handle the case when the read is split across 2 sectors or if MFT entry is at offset =1024. Or that it adds some checks (like invalid mft offset) which weren't there previously and which would make GRUB bail out on weird FS even if user doesn't want blocklists. MFT in ntfs is only 1024 bytes, and it must be sector aligned, so if this test fails, there is serious problem with the fs (or the driver). Is it true for 4K sector NTFS? Yeah, I've tried 64K block size and MFT is still 1024 bytes, it just pack multiple MFT in a single allocation unit. When I formated a disk with 4K sectors in Windows it used a complete sector for each MFT record. The block size is not relevant for the MFT record size, but the sector size of the disk is. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Workaround for usb boot failure on some mainboards
Hi,
On some boards, like the AsRock K7S41GX, Grub fails to boot from
superfloppy fat32 formated usb sticks.
The reason for the boot failure is that the bios of the mentioned
board replaces byte 0x24 of the bpb with the value 0x00 when it's read
through the bios function.
In fat16 this byte contains the Disc unit number, so this causes no real
harm there.
In fat32 this byte is part of the sectors per FAT information, so by
modifying this value the bios makes Grub unable to read the fat system.
The attached workaround reads the backup bpb information on fat32
filesystems and uses the sectors per fat information stored there.
PS: I'm sorry if this mail is a duplicate, but I sent it before but I
wasn't subscribed so it might have been blocked/dropped before
--- ../grub2-upstream/grub2-upstream/grub-core/fs/fat.c 2010-09-21
12:13:17.154835710 +0200
+++ grub2-merge/grub-core/fs/fat.c 2010-09-22 10:23:27.935482451 +0200
@@ -214,6 +214,29 @@ grub_fat_mount (grub_disk_t disk)
? grub_le_to_cpu16 (bpb.sectors_per_fat_16)
: grub_le_to_cpu32
(bpb.version_specific.fat32.sectors_per_fat_32))
data-logical_sector_bits);
+ if (bpb.sectors_per_fat_16)
+data-sectors_per_fat = grub_le_to_cpu16 (bpb.sectors_per_fat_16)
data-logical_sector_bits;
+ else
+{
+ /* Workaround for buggy BIOSes which replace offset 0x24 in the bpb
+ with the drive number. This offset is part of sectors_per_fat_32 in
+ the fat32 structure.
+ We read the backup bpb (if available) and use the value there */
+ struct grub_fat_bpb backup_bpb;
+ grub_uint32_t backup_bpb_address = grub_le_to_cpu16
(bpb.version_specific.fat32.backup_boot_sector) data-logical_sector_bits;
+ if (bpb.version_specific.fat32.backup_boot_sector
+ (! grub_disk_read (disk,
+backup_bpb_address,
+0,
+sizeof (backup_bpb),
+backup_bpb)))
+ data-sectors_per_fat = grub_le_to_cpu32
(backup_bpb.version_specific.fat32.sectors_per_fat_32)
data-logical_sector_bits;
+
+ if (data-sectors_per_fat == 0)
+ data-sectors_per_fat = grub_le_to_cpu32
(bpb.version_specific.fat32.sectors_per_fat_32) data-logical_sector_bits;
+}
+
+
if (data-sectors_per_fat == 0)
goto fail;
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Workaround for usb boot failure on some mainboards
On Wed, Sep 22, 2010 at 6:14 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: Wouldn't that be a bug in the BIOS? Don't go writing to a drive you don't know what contains. It could be something other tahn fat16 after all (what if it was a linux kernel with a bootheader on it and not a filesystem at all?) Sounds like the BIOS needs fixing badly. Nothing wrong with making grub more robust against corrupt filesystems, but it doesn't actually fix the bug in the BIOS. Well, I think I didn't state the problem clearly enough: The bios doesn't write to the disk, it just changes the value on the fly when the bootloader is reading the bpb through a bios method. The workaroud also doesn't change the disk, it only reads the necessary information from a region the bios doesn't mess up on the fly... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Workaround for usb boot failure on some mainboards
On Wed, Sep 22, 2010 at 7:45 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Wed, Sep 22, 2010 at 06:52:46PM +0200, Thomas Frauendorfer wrote: Well, I think I didn't state the problem clearly enough: The bios doesn't write to the disk, it just changes the value on the fly when the bootloader is reading the bpb through a bios method. The workaroud also doesn't change the disk, it only reads the necessary information from a region the bios doesn't mess up on the fly... Still a bug. It can NOT assume things about what is being booted. Don't assume FAT16 unless you checked explicitly that it is FAT16. I know, that a bios must not assume anything about a file system it hasn't checked. But it does and I can't change that and because of that bug booting from an usb-stick fails on that mainboard (and most likely a few others at well). ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
