Re: [PATCH]: grub: Partitions can start at zero.
From: Vladimir Serbinenko phco...@gmail.com
Date: Mon, 20 Apr 2009 18:53:35 +0200
On Mon, Apr 20, 2009 at 2:30 AM, David Miller da...@davemloft.net wrote:
With Sun partitions, individual partitions can start at disk
address zero. That's right, zero.
This works because UFS and EXT{2,3,4} superblocks are offset
far enough into the partition that it won't overwrite the
disk label nor the boot block.
I added an, arguably hackish, heuristic to handle this properly.
Basically if the OS device name does not end in a digit we'll believe
that a zero hdg.start value can be a partition.
If anyone has a better way to handle this, let me know :-)
What about the way I proposed in thread on implementing nested partitions?
Thanks for your feedback, I'll take a look at this.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
Hi, I have been playing with grub gptsync, on apple intel mac with GUID partitioned 8 GB usb stick, 8 partitions. #1 is the standard fat32 EFI system part for macs. I am comparing with the gptsync utility from linux, or rEFIt gptsync, currently used for macs booting pc-bios bootloader. It is working to allow selection of GPT partions for MBR 2, 3, 4 but some of the numbers look wrong. I have not tried setting flags. grub gptsync is not handling MBR partition table 1 the same way as current linux or refit gptsync, which puts GPT partition 1 (EFI system FAT32) in MBR part1. GPT Partions are (512 byte sectors) Current GPT partition table: # Start LBA End LBA Type 1 40 409639 EFI System (FAT) 2 409640 2395367 Mac OS X HFS+ 32395368 4573255 Mac OS X HFS+ 44835400 7141399 Mac OS X HFS+ 57403544 9965767 Mac OS X HFS+ 6 10227912 13046359 Mac OS X HFS+ 7 13308504 15642623 Mac OS X HFS+ 8 15904768 15949783 Mac OS X HFS+ There seems to be agreement about start and end on MBR table partitions 2 3 4, using grub gptsync (hd0) 2 3 4. Other bytes differ (type, flags). This is after grub gptsync (hd0) 2 3 4 (MBR part1 was initially set by linux gptsync) p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb [sudo] password for pxw: 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 01c0 02 00 ee 7f 0e 19 01 00 00 00 27 40 06 00 00 7f |..'@| 01d0 0f 19 83 1a 2d 95 28 40 06 00 c0 4c 1e 00 00 1a |-.(@...L| 01e0 2e 95 83 ab 57 1c e8 8c 24 00 60 3b 21 00 00 fc |W...$.`;!...| 01f0 59 2c 83 87 63 bc 48 c8 49 00 d0 2f 23 00 55 aa |Y,..c.H.I../#.U.| 0200 Then as seen in linux gptsync, Current MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 409640 2395367 83 Linux 32395368 4573255 83 Linux 44835400 7141399 83 Linux Status: MBR table must be updated. Proposed new MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 * 409640 2395367 af Mac OS X HFS+ 32395368 4573255 af Mac OS X HFS+ 44835400 7141399 af Mac OS X HFS+ May I update the MBR as printed above? [y/N] y Yes p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe || 01c0 ff ff ee fe ff ff 01 00 00 00 27 40 06 00 80 fe |..'@| 01d0 ff ff af fe ff ff 28 40 06 00 c0 4c 1e 00 00 fe |..(@...L| 01e0 ff ff af fe ff ff e8 8c 24 00 60 3b 21 00 00 fe |$.`;!...| 01f0 ff ff af fe ff ff 48 c8 49 00 d0 2f 23 00 55 aa |..H.I../#.U.| 0200 -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Getting the silent=splash to work?
Felix Zielcke wrote: Am Montag, den 20.04.2009, 16:53 -0400 schrieb BandiPat: Ok, grub2 devs, I can't figure this out. The splash screen that covers the scrolling text when booting up, no longer works! I've tried several different things, but have not run across a solution yet. What's the trick? Another user mentioned I should use linux16 rather than linux, but that gives me an error when I try it. Grub2 tells me I need to load a kernel first. I am running a 32-bit Linux on a 64-bit machine. When I tried to run the memory test, it gave me an error that I had to use linux16 for it, which indeed did work! If you want to use the old linux loader with linux16 then you need to use initrd16 too for the initrd. Thanks Felix, this fix does work. I guess I don't fully understand what is going on, but certainly some changes have occurred with the two, linux16 linux. Will linux work again in the future or is that reserved for 64 bit or above? I mean linux works, but just blocks the splash screen. Is it a matter of the splash screen setup needing a change? See, I think I'm confusing things because I don't understand what's going on with all that. Anyway thanks, Pat ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
On Tue, Apr 21, 2009 at 1:29 PM, Peter Cros pxwp...@gmail.com wrote: Hi, I have been playing with grub gptsync, on apple intel mac with GUID partitioned 8 GB usb stick, 8 partitions. #1 is the standard fat32 EFI system part for macs. I am comparing with the gptsync utility from linux, or rEFIt gptsync, currently used for macs booting pc-bios bootloader. It is working to allow selection of GPT partions for MBR 2, 3, 4 but some of the numbers look wrong. I have not tried setting flags. grub gptsync is not handling MBR partition table 1 the same way as current linux or refit gptsync, which puts GPT partition 1 (EFI system FAT32) in MBR part1. I don't understand what you mean. I will not do any special treatment for EFI system partition. As far as I'm concerned it's just a partition. I don't think it's a problem since user can ask which partitions to put in MBR GPT Partions are (512 byte sectors) Current GPT partition table: # Start LBA End LBA Type 1 40 409639 EFI System (FAT) 2 409640 2395367 Mac OS X HFS+ 32395368 4573255 Mac OS X HFS+ 44835400 7141399 Mac OS X HFS+ 57403544 9965767 Mac OS X HFS+ 6 10227912 13046359 Mac OS X HFS+ 7 13308504 15642623 Mac OS X HFS+ 8 15904768 15949783 Mac OS X HFS+ There seems to be agreement about start and end on MBR table partitions 2 3 4, using grub gptsync (hd0) 2 3 4. Other bytes differ (type, flags). This is after grub gptsync (hd0) 2 3 4 (MBR part1 was initially set by linux gptsync) p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb [sudo] password for pxw: 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 01c0 02 00 ee 7f 0e 19 01 00 00 00 27 40 06 00 00 7f |..'@| 01d0 0f 19 83 1a 2d 95 28 40 06 00 c0 4c 1e 00 00 1a |-.(@...L| 01e0 2e 95 83 ab 57 1c e8 8c 24 00 60 3b 21 00 00 fc |W...$.`;!...| 01f0 59 2c 83 87 63 bc 48 c8 49 00 d0 2f 23 00 55 aa |Y,..c.H.I../#.U.| 0200 Then as seen in linux gptsync, Current MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 409640 2395367 83 Linux 32395368 4573255 83 Linux 44835400 7141399 83 Linux Status: MBR table must be updated. Proposed new MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 * 409640 2395367 af Mac OS X HFS+ 32395368 4573255 af Mac OS X HFS+ 44835400 7141399 af Mac OS X HFS+ May I update the MBR as printed above? [y/N] y Yes Here there are 2 differences. First partition type for hfs+ isn't autodetected, I will fix this, just I thought it ws unnecessary AFAIK every OS which understands HFS+ understands GPT. The second thing is that none of partiion is active. Here you have just to tell which partition is active. You can have the same behavior as OSX gptsync with command gptsync hd0 2+0xaf 3-0xaf 4-0xaf Once I add hfs+ autodetect it will be enough to do gptsync hd0 2+ 3 4 p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe || 01c0 ff ff ee fe ff ff 01 00 00 00 27 40 06 00 80 fe |..'@| 01d0 ff ff af fe ff ff 28 40 06 00 c0 4c 1e 00 00 fe |..(@...L| 01e0 ff ff af fe ff ff e8 8c 24 00 60 3b 21 00 00 fe |$.`;!...| 01f0 ff ff af fe ff ff 48 c8 49 00 d0 2f 23 00 55 aa |..H.I../#.U.| 0200 -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Framebuffer/vbe separation
Vladimir Serbinenko wrote: Hello, currently vbe module contains all the framebuffer functions which are actually adapter-independent and I think more adapters can be implementing by providing a function which sets mode and framebuffer. Additionally it provides an interface to retrieve framebuffer address for loaders: check that current mode is framebuffer based and if it is, take the address. May I do it that way? Yes. I have nothing against making frame buffer code as common code as possible because other systems would also benefit from it. Just keep in mind that other video drivers will also need to use it and do not call directly VBE driver itself, provide proper interface over Video Subsystem. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
There appears to be a small bug there. For example - gptsync (hd0) 4 2 3 will write data for GPT partition 4 2 3 to MBR partition table 2 3 4 but also GPT partition 1 to MBR partition 1 (which is actually what happens now for intel mac.) And similarly for other selections will write the next lower gpt partition number to MBR partition 1 slot. I don't think it is compatible with current MBR/GPT hybrid partitioning on intel macs for grub-pc booting. On Wed, Apr 22, 2009 at 1:10 AM, Vladimir Serbinenko phco...@gmail.comwrote: On Tue, Apr 21, 2009 at 1:29 PM, Peter Cros pxwp...@gmail.com wrote: Hi, I have been playing with grub gptsync, on apple intel mac with GUID partitioned 8 GB usb stick, 8 partitions. #1 is the standard fat32 EFI system part for macs. I am comparing with the gptsync utility from linux, or rEFIt gptsync, currently used for macs booting pc-bios bootloader. It is working to allow selection of GPT partions for MBR 2, 3, 4 but some of the numbers look wrong. I have not tried setting flags. grub gptsync is not handling MBR partition table 1 the same way as current linux or refit gptsync, which puts GPT partition 1 (EFI system FAT32) in MBR part1. I don't understand what you mean. I will not do any special treatment for EFI system partition. As far as I'm concerned it's just a partition. I don't think it's a problem since user can ask which partitions to put in MBR GPT Partions are (512 byte sectors) Current GPT partition table: # Start LBA End LBA Type 1 40 409639 EFI System (FAT) 2 409640 2395367 Mac OS X HFS+ 32395368 4573255 Mac OS X HFS+ 44835400 7141399 Mac OS X HFS+ 57403544 9965767 Mac OS X HFS+ 6 10227912 13046359 Mac OS X HFS+ 7 13308504 15642623 Mac OS X HFS+ 8 15904768 15949783 Mac OS X HFS+ There seems to be agreement about start and end on MBR table partitions 2 3 4, using grub gptsync (hd0) 2 3 4. Other bytes differ (type, flags). This is after grub gptsync (hd0) 2 3 4 (MBR part1 was initially set by linux gptsync) p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb [sudo] password for pxw: 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 01c0 02 00 ee 7f 0e 19 01 00 00 00 27 40 06 00 00 7f |..'@| 01d0 0f 19 83 1a 2d 95 28 40 06 00 c0 4c 1e 00 00 1a |-.(@...L| 01e0 2e 95 83 ab 57 1c e8 8c 24 00 60 3b 21 00 00 fc |W...$.`;!...| 01f0 59 2c 83 87 63 bc 48 c8 49 00 d0 2f 23 00 55 aa |Y,..c.H.I../#.U.| 0200 Then as seen in linux gptsync, Current MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 409640 2395367 83 Linux 32395368 4573255 83 Linux 44835400 7141399 83 Linux Status: MBR table must be updated. Proposed new MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 * 409640 2395367 af Mac OS X HFS+ 32395368 4573255 af Mac OS X HFS+ 44835400 7141399 af Mac OS X HFS+ May I update the MBR as printed above? [y/N] y Yes Here there are 2 differences. First partition type for hfs+ isn't autodetected, I will fix this, just I thought it ws unnecessary AFAIK every OS which understands HFS+ understands GPT. The second thing is that none of partiion is active. Here you have just to tell which partition is active. You can have the same behavior as OSX gptsync with command gptsync hd0 2+0xaf 3-0xaf 4-0xaf Once I add hfs+ autodetect it will be enough to do gptsync hd0 2+ 3 4 p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe || 01c0 ff ff ee fe ff ff 01 00 00 00 27 40 06 00 80 fe |..'@| 01d0 ff ff af fe ff ff 28 40 06 00 c0 4c 1e 00 00 fe |..(@...L| 01e0 ff ff af fe ff ff e8 8c 24 00 60 3b 21 00 00 fe |$.`;!...| 01f0 ff ff af fe ff ff 48 c8 49 00 d0 2f 23 00 55 aa |..H.I../#.U.| 0200 -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
Peter Cros wrote: I don't think it is compatible with current MBR/GPT hybrid ?partitioning on intel macs for grub-pc booting. well, it doesn't necessarily order the partitions in the same way as e.g. rEFIt gptsync does, but that's because this GRUB implementation gives you more control! You can even pick different MBR-partition-configurations, before booting different OSes. Vladimir Serbinenko wrote: Here there are 2 differences. First partition type for hfs+ isn't autodetected, I will fix this, just I thought it ws unnecessary AFAIK every OS which understands HFS+ understands GPT. At least Mac OS X 10.3 and earlier don't understand GPT, and it actually makes a difference with Apple's target disk mode! And there may be a few other combinations. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] FreeBSD 64-bit kernel support
Hello, here is the version with changelog, fix for freebsd_module and licencing corrections. If nobody objects I'll commit it soon Enjoy On Sun, Apr 12, 2009 at 9:19 PM, Bean bean12...@gmail.com wrote: Hi, This patch allows you to load amd64 freebsd kernel directly, here is an example: set root=(hd0,1,a) freebsd /boot/kernel/kernel freebsd_loadenv /boot/device.hints set FreeBSD.vfs.root.mountfrom=ufs:/dev/ad0s1a boot Test successfully on FreeBSD 7.1 amd64. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel diff --git a/ChangeLog b/ChangeLog index ca0ab43..bd1776b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,40 @@ +2009-04-21 Bean bean12...@gmail.com Vladimir Serbinenko phco...@gmail.com + + FreeBSD 64-bit support + + * conf/i386-pc.rmk (bsd_mod_SOURCES): add loader/i386/bsd_helper.S + and loader/i386/bsd_trampoline.S + (bsd_mod_ASFLAGS): new variable + * include/grub/i386/bsd.h (FREEBSD_MODINFOMD_SMAP): new definition + (FREEBSD_MODTYPE_KERNEL64): likewise + (grub_bsd64_trampoline_start): likewise + (grub_bsd64_trampoline_end): likewise + (grub_bsd64_trampoline_selfjump): likewise + (grub_bsd64_trampoline_gdt): likewise + * include/grub/i386/loader.h (grub_unix_real_boot): moved from here ... + * include/grub/i386/bsd.h (grub_unix_real_boot): ... moved here + * kern/i386/loader.S (grub_unix_real_boot): moved from here ... + * loader/i386/bsd_helper.S (grub_unix_real_boot): moved here + * include/grub/gpt_partition.h (grub_gpt_partentry): Corrected the type + of attrib member + * loader/i386/bsd_pagetable.c: new file + * loader/i386/bsd_trampoline.S: likewise + * loader/i386/bsd.c (ALIGN_QWORD): new macro + (ALIGN_VAR): likewise + (entry_hi): new variable + (kern_end_mdofs): likewise + (is_64bit): likewise + (grub_freebsd_add_meta): use ALIGN_VAR + (grub_e820_mmap): new declaration + (grub_freebsd_add_mmap): new function + (grub_freebsd_add_meta_module): support 64 bit kernels + (grub_freebsd_list_modules): use ALIGN_VAR + (gdt_descriptor): new declaration + (grub_freebsd_boot): support 64 bit kernels + (grub_bsd_elf64_hook): new function + (grub_bsd_load_elf): support elf64 + + 2009-04-19 Vladimir Serbinenko phco...@gmail.com Correct GPT definition diff --git a/conf/i386-pc.rmk b/conf/i386-pc.rmk index 265b250..bf2516d 100644 --- a/conf/i386-pc.rmk +++ b/conf/i386-pc.rmk @@ -301,9 +301,10 @@ aout_mod_CFLAGS = $(COMMON_CFLAGS) aout_mod_LDFLAGS = $(COMMON_LDFLAGS) # For bsd.mod -bsd_mod_SOURCES = loader/i386/bsd.c +bsd_mod_SOURCES = loader/i386/bsd.c loader/i386/bsd_helper.S loader/i386/bsd_trampoline.S bsd_mod_CFLAGS = $(COMMON_CFLAGS) bsd_mod_LDFLAGS = $(COMMON_LDFLAGS) +bsd_mod_ASFLAGS = $(COMMON_ASFLAGS) # For usb.mod usb_mod_SOURCES = bus/usb/usb.c bus/usb/usbtrans.c bus/usb/usbhub.c diff --git a/include/grub/i386/bsd.h b/include/grub/i386/bsd.h index f50f18e..3706f4d 100644 --- a/include/grub/i386/bsd.h +++ b/include/grub/i386/bsd.h @@ -80,9 +80,12 @@ #define FREEBSD_MODINFOMD_SHDR 0x0009 /* section header table */ #define FREEBSD_MODINFOMD_NOCOPY 0x8000 /* don't copy this metadata to the kernel */ +#define FREEBSD_MODINFOMD_SMAP 0x1001 + #define FREEBSD_MODINFOMD_DEPLIST (0x4001 | FREEBSD_MODINFOMD_NOCOPY) /* depends on */ #define FREEBSD_MODTYPE_KERNEL elf kernel +#define FREEBSD_MODTYPE_KERNEL64 elf64 kernel #define FREEBSD_MODTYPE_MODULE elf module #define FREEBSD_MODTYPE_RAW raw @@ -222,4 +225,11 @@ struct grub_netbsd_btinfo_bootdisk int partition; }; +void grub_unix_real_boot (grub_addr_t entry, ...) + __attribute__ ((cdecl,noreturn)); + +extern grub_uint8_t grub_bsd64_trampoline_start, grub_bsd64_trampoline_end; +extern grub_uint32_t grub_bsd64_trampoline_selfjump; +extern grub_uint32_t grub_bsd64_trampoline_gdt; + #endif /* ! GRUB_BSD_CPU_HEADER */ diff --git a/include/grub/i386/loader.h b/include/grub/i386/loader.h index afd3eb9..72a44d0 100644 --- a/include/grub/i386/loader.h +++ b/include/grub/i386/loader.h @@ -32,7 +32,4 @@ extern grub_size_t EXPORT_VAR(grub_os_area_size); grub_err_t EXPORT_FUNC(grub_linux16_boot) (void); -void EXPORT_FUNC(grub_unix_real_boot) (grub_addr_t entry, ...) - __attribute__ ((cdecl,noreturn)); - #endif /* ! GRUB_LOADER_CPU_HEADER */ diff --git a/kern/i386/loader.S b/kern/i386/loader.S index bbd2187..3e9c713 100644 --- a/kern/i386/loader.S +++ b/kern/i386/loader.S @@ -118,25 +118,3 @@ linux_setup_seg: .word 0 .code32 -/* - * Use cdecl calling convention for *BSD kernels. - */ - -FUNCTION(grub_unix_real_boot) - -callEXT_C(grub_dl_unload_all) - - /* Interrupts should be disabled. */ -cli - - /* Discard `grub_unix_real_boot' return address. */ -popl%eax - -/* Fetch `entry' address ... */ -popl %eax - -/* - * ... and put our return address in its place. The kernel will - * ignore it, but it expects %esp to
Re: [PATCH] gptsync
On Tue, Apr 21, 2009 at 9:49 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: Peter Cros wrote: I don't think it is compatible with current MBR/GPT hybrid ?partitioning on intel macs for grub-pc booting. well, it doesn't necessarily order the partitions in the same way as e.g. rEFIt gptsync does, but that's because this GRUB implementation gives you more control! You can even pick different MBR-partition-configurations, before booting different OSes. Yes it was written with such possibility in mind. I don't see why grub2 will enforce mbr partitions to be sorted since mbr doesn't require such thing. If you ask grub2 to put partitions in reverse order it does it. As to partition in zeroth slot it spans across the space before the first MBR partition and is so called protective partition and is required for some tools including grub2 itself to recognise gpt disk as such. About compatibiliy: hybrid MBR is against specifications - it's a trick to boot legacy OS. So the only compatibility you can speak about is the ability to boot a legacy OS of your choice. Vladimir Serbinenko wrote: Here there are 2 differences. First partition type for hfs+ isn't autodetected, I will fix this, just I thought it ws unnecessary AFAIK every OS which understands HFS+ understands GPT. At least Mac OS X 10.3 and earlier don't understand GPT, and it actually makes a difference with Apple's target disk mode! And there may be a few other combinations. Ok -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
HFS autodetect added. With changelog this time. Should already be suitable
for inclusion
On Wed, Apr 22, 2009 at 12:03 AM, Vladimir Serbinenko phco...@gmail.comwrote:
On Tue, Apr 21, 2009 at 9:49 PM, Isaac Dupree
m...@isaac.cedarswampstudios.org wrote:
Peter Cros wrote:
I don't think it is compatible with current MBR/GPT hybrid ?partitioning
on
intel macs for grub-pc booting.
well, it doesn't necessarily order the partitions in the same way as e.g.
rEFIt gptsync does, but that's because this GRUB implementation gives you
more
control! You can even pick different MBR-partition-configurations, before
booting different OSes.
Yes it was written with such possibility in mind. I don't see why grub2
will enforce mbr partitions to be sorted since mbr doesn't require such
thing. If you ask grub2 to put partitions in reverse order it does it. As to
partition in zeroth slot it spans across the space before the first MBR
partition and is so called protective partition and is required for some
tools including grub2 itself to recognise gpt disk as such.
About compatibiliy: hybrid MBR is against specifications - it's a trick to
boot legacy OS. So the only compatibility you can speak about is the ability
to boot a legacy OS of your choice.
Vladimir Serbinenko wrote:
Here there are 2 differences. First partition type for hfs+ isn't
autodetected, I will fix this, just I thought it ws unnecessary AFAIK
every
OS which understands HFS+ understands GPT.
At least Mac OS X 10.3 and earlier don't understand GPT, and it actually
makes
a difference with Apple's target disk mode! And there may be a few
other
combinations.
Ok
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
diff --git a/ChangeLog b/ChangeLog
index ca0ab43..2a2ba20 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,21 @@
+2009-04-21 Vladimir Serbinenko phco...@gmail.com
+
+ gptsync
+
+ * commands/gptsync.c: new file
+ * conf/common.rmk (pkglib_MODULES): add gptsync.mod
+ (gptsync_mod_SOURCES): new variable
+ (gptsync_mod_CFLAGS): likewise
+ (gptsync_mod_LDFLAGS): likewise
+ * include/grub/pc_partition.h (GRUB_PC_PARTITION_TYPE_NTFS):
+ new definition
+ (GRUB_PC_PARTITION_TYPE_HFS): likewise
+ * conf/i386-coreboot.rmk (grub_emu_SOURCES): add commands/gptsync.c
+ * conf/i386-ieee1275.rmk: likewise
+ * conf/i386-pc.rmk: likewise
+ * conf/powerpc-ieee1275.rmk: likewise
+
+
2009-04-19 Vladimir Serbinenko phco...@gmail.com
Correct GPT definition
diff --git a/commands/gptsync.c b/commands/gptsync.c
new file mode 100644
index 000..cbedf45
--- /dev/null
+++ b/commands/gptsync.c
@@ -0,0 +1,255 @@
+/* gptsync.c - fill the mbr based on gpt entries */
+/* XXX: I don't know what to do if sector size isn't 512 bytes */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2009 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include grub/command.h
+#include grub/dl.h
+#include grub/device.h
+#include grub/disk.h
+#include grub/pc_partition.h
+#include grub/partition.h
+#include grub/misc.h
+#include grub/mm.h
+#include grub/fs.h
+
+/* Convert a LBA address to a CHS address in the INT 13 format. */
+/* Taken from grub1. */
+/* XXX: use hardcoded geometry of C = 1024, H = 255, S = 63.
+ Is it a problem?
+*/
+static void
+lba_to_chs (int lba, grub_uint8_t *cl, grub_uint8_t *ch,
+ grub_uint8_t *dh)
+{
+ int cylinder, head, sector;
+ int sectors = 63, heads = 255, cylinders = 1024;
+
+ sector = lba % sectors + 1;
+ head = (lba / sectors) % heads;
+ cylinder = lba / (sectors * heads);
+
+ if (cylinder = cylinders)
+{
+ *cl = *ch = *dh = 0xff;
+ return;
+}
+
+ *cl = sector | ((cylinder 0x300) 2);
+ *ch = cylinder 0xFF;
+ *dh = head;
+}
+
+static grub_err_t
+grub_cmd_gptsync (grub_command_t cmd __attribute__ ((unused)),
+ int argc, char **args)
+{
+ grub_device_t dev;
+ struct grub_pc_partition_mbr mbr;
+ struct grub_partition *partition;
+ grub_disk_addr_t first_sector;
+ int numactive = 0;
+
+ if (argc 1)
+return grub_error (GRUB_ERR_BAD_ARGUMENT, device name required);
+ if (argc 4)
+return grub_error (GRUB_ERR_BAD_ARGUMENT, only 3 partitions can be
+ in hybrid MBR);
+
+ if (args[0][0] == '('
Re: [PATCH] Split #2: parser/reader separation
Hi, ping ? On Sun, Apr 12, 2009 at 12:36 AM, Bean bean12...@gmail.com wrote: Hi, This patch moves the parser from normal.mod to script/sh, it also split rescue mode to rescue_reader and rescue_parser. dynamic command support and auto fs loader is moved to standalone source file normal/dyncmd.c and normal/autofs.c. -- Bean -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
