Re: Trouble booting CF card in PCMCIA port from GRUB2

2009-04-21 Thread ebik 
On Mon, 20 Apr 2009 23:58:37 +0200
Stephan Henningsen  wrote:

>[...]
> no working USB flash or PCMCIA CF boot support from BIOS,
>[...]
> The PCMCIA slot or the card in it isn't shown!

This coincides, the PCMCIA slot can be shown only if BIOS has support
for it, because AFAIK grub2 does not (yet?) include PCMCIA drivers.

Maybe using linux+kexec as bootloader may help you.

-- 
 Tomáš 'ebík' Ebenlendr
 http://get.to/ebik
 PF 2009.30503599061



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Split #2: parser/reader separation

2009-04-21 Thread Bean 
Hi,

ping ?

On Sun, Apr 12, 2009 at 12:36 AM, Bean  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

Re: [PATCH] gptsync

2009-04-21 Thread Peter Cros 
On Wed, Apr 22, 2009 at 8:03 AM, Vladimir Serbinenko wrote:

> 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.
>
>>
That is exactly what I was referring to.

The ability to control the ordering of partitions was attractive, not a
problem.

I will leave it there thanks.


-- 
Cros (pxw)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] gptsync

2009-04-21 Thread Vladimir Serbinenko 
HFS autodetect added. With changelog this time. Should already be suitable
for inclusion

On Wed, Apr 22, 2009 at 12:03 AM, Vladimir Serbinenko wrote:

>
>
> 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 
+
+	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 
 
 	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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* 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] == '(' && args[0][grub_strlen (args[0]) - 1] == ')')
+{
+  args

Re: [PATCH] gptsync

2009-04-21 Thread Vladimir Serbinenko 
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] FreeBSD 64-bit kernel support

2009-04-21 Thread Vladimir Serbinenko 
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  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   Vladimir Serbinenko 
+
+	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 
 
 	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 point to it.
- */
-call

Re: [PATCH] gptsync

2009-04-21 Thread Isaac Dupree 
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] gptsync

2009-04-21 Thread Peter Cros 
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 wrote:

>
>
> On Tue, Apr 21, 2009 at 1:29 PM, Peter Cros  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: Framebuffer/vbe separation

2009-04-21 Thread Vesa Jääskeläinen 
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

2009-04-21 Thread Vladimir Serbinenko 
On Tue, Apr 21, 2009 at 1:29 PM, Peter Cros  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: Getting the silent=splash to work?

2009-04-21 Thread BandiPat 

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

2009-04-21 Thread Peter Cros 
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: [PATCH]: grub: Partitions can start at zero.

2009-04-21 Thread David Miller 
From: Vladimir Serbinenko 
Date: Mon, 20 Apr 2009 18:53:35 +0200

> On Mon, Apr 20, 2009 at 2:30 AM, David Miller  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