Re: ATA update
Hello, Am Freitag, den 08.08.2008, 01:46 +0200 schrieb Marco Gerards: > Hi, > > One minute ago I committed a patch to improve ATA support. > Probable better if I just send you know a mail instead of telling on IRC: This is shown for device 4,0 and 4,1 PCI Dev (0,8,0) compat=1 rega=0x9e0=regb=0xbe0 My first SATA RAID Disk is fully recognized i.e. it shows the ST3808110AS name and Firmware 2AAA which I can find in dmesg. For device 4,1 it only shows "ATA detected" but nothing more, it goes then to device 5,0. ls (ata8) shows partition table ls (ata8,1) or (ata8,2) unknown filesystem But that's probable right, if your ata.mod works more then Linux instead of the biosdisk.mod which works more then yeah BIOS ;) I just tried to mount /dev/sda1 which is NTFS and syslog shows $MFT corrupted (ntfs-3g). So I hope that GRUB will still have the biosdisk.mod for guys like me on a dmraid (in Linux terms) or fake hardware motherboard RAID ;) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Windows boot
- Original Message
From: Bean <[EMAIL PROTECTED]>
To: The development of GRUB 2
Sent: Friday, 8 August, 2008 12:10:24 PM
Subject: Re: Windows boot
On Fri, Aug 8, 2008 at 2:22 PM, Viswesh S <[EMAIL PROTECTED]> wrote:
>
>
> - Original Message
> From: Bean <[EMAIL PROTECTED]>
> To: The development of GRUB 2
> Sent: Friday, 8 August, 2008 9:13:09 AM
> Subject: Re: Windows boot
>
> On Fri, Aug 8, 2008 at 9:58 AM, Viswesh S <[EMAIL PROTECTED]> wrote:
>>
>>
>> - Original Message
>> From: Javier Martín <[EMAIL PROTECTED]>
>> To: The development of GRUB 2
>> Sent: Friday, 8 August, 2008 3:56:35 AM
>> Subject: Re: Windows boot
>>
>> Hi again,
>>
>> 2008/8/7 Viswesh S <[EMAIL PROTECTED]>:
>>> Hi,
>>>
>>> I installed ubuntu in the same harddisk(hda) as windows.
>>>
>>> After installing ubuntu, using grub legacy, I was able to log in to
>>> windows,
>>> using the entries, rootnoverify and chainloader +1.
>>>
>>> But when I install grub2 and then modify the grub.cfg with the following,
>>> statements, it is not working, says ...A disk read error occurred ,Press
>>> Ctrl+Alt+Del .
>>>
>>> This is my grub.cfg
>>>
>>> menuentry "Windows" {
>>> set root=(hd0,3)
>>> chainloader +1
>>>
>>> }
>>>
>>> My windows file sytem is in NTFS and not vfat
>>>
>>> One more thing to check with is, the need of ntfs mod present as part of
>>> grub2.So where exactly that is getting used,though I have tried to load
>>> the
>>> module ntfs and ntfscomp in grub using insmod in grub menu,...but no
>>> positive results.
>> The FS only matters if you try to access files on the volume, but
>> chainloader just reads raw sectors from disk, so the FS module does
>> not matter: you could have an SFS partition for the sake of it and it
>> would work if the superblock was executable.
>>>
>>> What might be in grub2, which prevents windows to boot.
>> Hmm... you could try booting (hd1) instead of (hd1,1), i.e. Windows'
>> MBR instead of its boot sector directly. I'll be back in town tomorrow
>> night and then I'll be able to look at my own GRUB config file, but
>> Windows has always been a wild beast to master. For the record, my
>> tests were with Windows XP Home in an Athlon X2 and with Windows XP
>> x64 on an Athlon 64. Thus, I don't know if Intel CPUs triple-fault on
>> my code (improbable, because it runs on QEMU) or if Windows Vista
>> (which has a changed boot process) works with it.
>>
>>
>> Hi,
>>
>> Windows I am trying to boot is Windows Server 2003, but anyway that doesnt
>> matter, as from legacy grub,I am able to boot.This makes it more
>> interesting, as I feel we are missing some small intricacy in grub2 in
>> this
>> case.
>>
>> Let me also have a look.
>
> Hi,
>
> What's the command you use in grub legacy ?
>
> BTW, you should know that device number of grub2 is not the same as
> grub legacy, the first partition is (hd0,1) instead of (hd0,0).
> Anyway, you can use ls to list the current devices.
>
> --
> Bean
> Hi,
>
> The partition number difference I am aware of.That difference was taken into
> account.
>
> In the case of grub legacy,the grub.cfg was in this way.
>
> menuentry "Windows" {
>
> rootnoverify
> chainloader +1
> }
>
> As windows is in the 3 partition, using ls (hd0,3) I could see windows
> files.
>
> so the grub.cfg
>
> menuentry "Win" {
>
> chainloader (hd0,3)+1
> }
>
> (or)
>
> menuentry "Win" {
> set root=(hd0,3)
> chainloader +1
> }
>
> Tried both the combinations.But not working, getting the message ." A disk
> read Error occurred
>
> Press Ctrl+Alt+Del to restart.
>
> I am not sure whether this is a filesystem issue (ntfs) which grub2 is not
> able to identify as such (or) Grub2 is not able to read the boot sector
> correctly.( As legacy grub was able to boot quite easily the same thing)
>
> I am badly stuck and I dont want to go back to legacy grub also.
Hi,
I think it's not related to ntfs, chainloader command read the first
sector, it doesn't matter what file system is used.
But I do remember a small issue with chainloader command of grub2, the
partition entry pointed to by %esi is not correct, I wonder if this
have something to do with your problem.
Hi,
Thanks,let me have a look at the chainloader command in grub2 and in legacy
grub.
Could you let me know the issue which you faced in the chainloader command.
Viswesh
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Unlimited freedom, unlimited storage. Get it now, on
http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
bug: cygwin support breaks cross compiles on cygwin
Hi, I used cygwin to build grub2/i386-coreboot using an i386-elf cross compiler. unfortunately the test in configure only looks for the host platform and enables pe2elf in that case, even though my compiler emits ELF already. my workaround is to just change that test (there's no OS cyg_win), but of course that's no permanent solution. Bean proposed on IRC to look if the target compiler emits PE, and enable pe2elf based on that. Regards, Patrick Georgi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ATA update
Hi Felix, Felix Zielcke <[EMAIL PROTECTED]> writes: >> One minute ago I committed a patch to improve ATA support. >> > Probable better if I just send you know a mail instead of telling on > IRC: > > This is shown for device 4,0 and 4,1 > PCI Dev (0,8,0) compat=1 rega=0x9e0=regb=0xbe0 > > My first SATA RAID Disk is fully recognized i.e. it shows the > ST3808110AS name and Firmware 2AAA which I can find in dmesg. > > For device 4,1 it only shows "ATA detected" but nothing more, it goes > then to device 5,0. Most likely something failed in grub_ata_identify. you might want to add more debugging information there. > ls (ata8) shows partition table > ls (ata8,1) or (ata8,2) unknown filesystem Can grub-emu deal with these filesystems? > But that's probable right, if your ata.mod works more then Linux instead > of the biosdisk.mod which works more then yeah BIOS ;) Hm? > I just tried to mount /dev/sda1 which is NTFS and syslog shows $MFT > corrupted (ntfs-3g). Also on biosdisk. > So I hope that GRUB will still have the biosdisk.mod for guys like me on > a dmraid (in Linux terms) or fake hardware motherboard RAID ;) Yes. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ATA update
Hello Marco, Am Freitag, den 08.08.2008, 11:17 +0200 schrieb Marco Gerards: > Hi Felix, > > Most likely something failed in grub_ata_identify. you might want to > add more debugging information there. Ok I try. > > ls (ata8) shows partition table > > ls (ata8,1) or (ata8,2) unknown filesystem > > Can grub-emu deal with these filesystems? No it says unknown fs, too. > > But that's probable right, if your ata.mod works more then Linux instead > > of the biosdisk.mod which works more then yeah BIOS ;) > > Hm? > > > I just tried to mount /dev/sda1 which is NTFS and syslog shows $MFT > > corrupted (ntfs-3g). > > Also on biosdisk. I currently always boot directly from my Raid 0 GRUB + Vista bootmgr + Vista \Windows\ is on Raid 0 my Linux / and so /boot is on my PATA disk. This works totally fine for booting Vista and Linux. With biosdisk.mod there's just (hd0) wich are both harddisks for the raid0 ls (hd0,1)/ shows everything from my NTFS raid0 (hd1) is then my IDE disk. There's no (hd2) The BIOS itself can handle the RAID 0 for booting fine. But as soon as you're in Linux or Windows the OS needs to care about it. Linux still shows sda and sdb, but that doestn't work right. I need dmraid so I have one /dev/mapper/nvidia_cediideh1 which I can mount fine. This is RAID 0 with chunksize 256 KB, so the first 256 KB of the combined disks is on disk 0 But NTFS hasn't it's $MFT just on the first 256 KB The second partition of it is a small ext3, but maybe it just begins on the second disk. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ATA update
> > I currently always boot directly from my Raid 0 > GRUB + Vista bootmgr + Vista \Windows\ is on Raid 0 > my Linux / and so /boot is on my PATA disk. > This works totally fine for booting Vista and Linux. > Oh and I forgot the Vista bootmgr file is 326 KB big, so even with my (probable big) chunksize of 256 KB this file lies on both disks. So for booting Vista it's essential to handle the RAID 0. I can try to copy my /boot to the ext3 partition I already have there. Maybe with biosdisk this even works with GRUB + Linux :) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ATA update
Am Freitag, den 08.08.2008, 11:55 +0200 schrieb Marco Gerards: > > Can't raid.mod be used for this, somehow? I had this talk already with Bean on IRC. At least the Nvidia nForce chipsets RAIDs have stored their 512 byte superblock in (end of disks) - 1024 bytes. The last 512 Bytes of both disks just contain zeroes. dmraid searches all disks for these superblocks it supports. So it is possible to implement this. Althoguh i don't know if raid.mod should be renamed to mdraid.mod and there should be a new dmraid.mod But that probable confuses people The raid.mod needs an overhaul anyway if the super 1.x format should be implemented, because the 1.x ones store there superblock at different positions of the disks not always at the same position where the current default 0.90 stores it. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ATA update
Felix Zielcke <[EMAIL PROTECTED]> writes: >> I currently always boot directly from my Raid 0 >> GRUB + Vista bootmgr + Vista \Windows\ is on Raid 0 >> my Linux / and so /boot is on my PATA disk. >> This works totally fine for booting Vista and Linux. > > Oh and I forgot the Vista bootmgr file is 326 KB big, > so even with my (probable big) chunksize of 256 KB this file lies on > both disks. Can't raid.mod be used for this, somehow? -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: bug: cygwin support breaks cross compiles on cygwin
On Fri, Aug 8, 2008 at 5:03 PM, Patrick Georgi <[EMAIL PROTECTED]> wrote: > Hi, > > I used cygwin to build grub2/i386-coreboot using an i386-elf cross compiler. > unfortunately the test in configure only looks for the host platform and > enables pe2elf in that case, even though my compiler emits ELF already. > > my workaround is to just change that test (there's no OS cyg_win), but of > course that's no permanent solution. > Bean proposed on IRC to look if the target compiler emits PE, and enable > pe2elf based on that. Hi, Yes, we can solve this with script. Another way is to do some test in grub-pe2elf. If the image is already elf, it does nothing and return true. This should fix the problem as well. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Windows boot
On Fri, Aug 8, 2008 at 2:50 PM, Viswesh S <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Thanks,let me have a look at the chainloader command in grub2 and in legacy
> grub.
>
> Could you let me know the issue which you faced in the chainloader command.
Hi,
The problem is in loader/i386/pc/chainloader.c (grub_chainloader_cmd):
/* Obtain the partition table from the root device. */
dev = grub_device_open (0);
if (dev)
{
grub_disk_t disk = dev->disk;
if (disk)
{
grub_partition_t p = disk->partition;
/* In i386-pc, the id is equal to the BIOS drive number. */
drive = (int) disk->id;
if (p)
{
grub_disk_read (disk, p->offset, 446, 64,
(char *) GRUB_MEMORY_MACHINE_PART_TABLE_ADDR);
part_addr = (void *) (GRUB_MEMORY_MACHINE_PART_TABLE_ADDR
+ (p->index << 4));
}
}
grub_device_close (dev);
}
p->offset is the offset of the start of the partition, but actually,
we need to read the sector that contain the partition table, which is
the mbr for primary. But replace p->offset with 0 doesn't fix this, as
grub_disk_read is related to the beginning of partition, not the disk.
You need to use the low level api:
disk->dev->read (disk, 0, 1, (char *) GRUB_MEMORY_MACHINE_PART_TABLE_ADDR);
But this fix only apply to primary partition, for logical partition,
the partition table is not in mbr, and this quick patch doesn't work.
But I remember someone send a patch to allow for loading of syslinux
in logical partition, you can search the list if you're interested.
BTW, if this doesn't work, you can try loadbin. It can be used to
chainload ntldr/bootmgr directly.
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: bug: cygwin support breaks cross compiles on cygwin
Patrick Georgi wrote:
Hi,
I used cygwin to build grub2/i386-coreboot using an i386-elf cross
compiler. unfortunately the test in configure only looks for the host
platform and enables pe2elf in that case, even though my compiler
emits ELF already.
my workaround is to just change that test (there's no OS cyg_win), but
of course that's no permanent solution.
Bean proposed on IRC to look if the target compiler emits PE, and
enable pe2elf based on that.
Thanks for the info.
A simple fix is probably a test for target_os also, please try attached
patch (and re-run autoconf).
Christian
diff --git a/configure.ac b/configure.ac
index 7a5938a..41e08f1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -206,9 +206,10 @@ AC_MSG_RESULT([$TARGET_IMG_LDFLAGS_AC])
# For platforms where ELF is not the default link format.
AC_MSG_CHECKING([for command to convert module to ELF format])
-if test "$host_os" = cygwin; then
- TARGET_OBJ2ELF='grub-pe2elf.exe'
-fi
+case "${host_os}:${target_os}" in
+ cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf.exe' ;;
+ *) ;;
+esac
AC_SUBST(TARGET_OBJ2ELF)
AC_MSG_RESULT([$TARGET_OBJ2ELF])
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: bug: cygwin support breaks cross compiles on cygwin
On Fri, Aug 08, 2008 at 11:03:49AM +0200, Patrick Georgi wrote: > Hi, > > I used cygwin to build grub2/i386-coreboot using an i386-elf cross > compiler. unfortunately the test in configure only looks for the host > platform and enables pe2elf in that case, even though my compiler emits > ELF already. > > my workaround is to just change that test (there's no OS cyg_win), but > of course that's no permanent solution. > Bean proposed on IRC to look if the target compiler emits PE, and enable > pe2elf based on that. I have observed that grub-pe2elf is included even in native builds for ELF platforms. Perhaps this is caused by the same bug? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: bug: cygwin support breaks cross compiles on cygwin
Robert Millan wrote: On Fri, Aug 08, 2008 at 11:03:49AM +0200, Patrick Georgi wrote: Hi, I used cygwin to build grub2/i386-coreboot using an i386-elf cross compiler. unfortunately the test in configure only looks for the host platform and enables pe2elf in that case, even though my compiler emits ELF already. my workaround is to just change that test (there's no OS cyg_win), but of course that's no permanent solution. Bean proposed on IRC to look if the target compiler emits PE, and enable pe2elf based on that. I have observed that grub-pe2elf is included even in native builds for ELF platforms. Perhaps this is caused by the same bug? No, grub-pe2elf is build and installed even if is not necessary for the build process. This should be no problem. Christian ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Drivemap module
Am Mittwoch, den 06.08.2008, 19:31 +0200 schrieb Javier Martín: > This will work on Windows, because no matter where it tries to boot from > it will find the same disk: both the first and second BIOS disks point > to hd1 now. > ... > This is the setup I have > extensively tested in QEMU, while the Windows boot has been tested in > both QEMU (with ReactOS) and some random computers including mine (with > Windows XP Home and Windows XP Pro x64). > Even though I don't need your drivemap at all (see one of my replies to Marco's ATA topic) I was so kind to try this out with my Vista x64 SP1 ;) I haven't remembered exactly the 2 menuentrys you wrote in your mail so I used a mixture of both :) drivemap (hd1) (hd0) set root=(hd0) chainloader (hd1,1)+1 This booted fine for me, GRUB loaded from IDE disk and Vista chainloaded from my SATA RAID 0. I really hope that you get this commited, then there's one feature less missing from grub-legacy ;) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: bug: cygwin support breaks cross compiles on cygwin
Hello, Am Freitag, den 08.08.2008, 14:59 +0200 schrieb Christian Franke: > > No, grub-pe2elf is build and installed even if is not necessary for the > build process. This should be no problem. > Well it's the same as with that --enable-debug thingy ;) In our Debian trunk SVN I already commited a change to remove grub.d/10_windows because Debian/Ubuntu users just don't have a need for this. It would be better if Robert and me don't need to do such changes. We could just remove grub-pe2elf, too. But why should it be build for everybody if only Cygwin users have a use for it? Then clearly the whole build process needs a change so that grub-pe2elf is only build on Cygwin. I doubt GRUB 2 is/will be used that much on Cygwin as with native Linux. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Drivemap module
- Original Message From: Felix Zielcke <[EMAIL PROTECTED]> To: The development of GRUB 2 Sent: Friday, 8 August, 2008 6:50:12 PM Subject: Re: [PATCH] Drivemap module Am Mittwoch, den 06.08.2008, 19:31 +0200 schrieb Javier Martín: > This will work on Windows, because no matter where it tries to boot from > it will find the same disk: both the first and second BIOS disks point > to hd1 now. > ... > This is the setup I have > extensively tested in QEMU, while the Windows boot has been tested in > both QEMU (with ReactOS) and some random computers including mine (with > Windows XP Home and Windows XP Pro x64). > Even though I don't need your drivemap at all (see one of my replies to Marco's ATA topic) I was so kind to try this out with my Vista x64 SP1 ;) I haven't remembered exactly the 2 menuentrys you wrote in your mail so I used a mixture of both :) drivemap (hd1) (hd0) set root=(hd0) chainloader (hd1,1)+1 This booted fine for me, GRUB loaded from IDE disk and Vista chainloaded from my SATA RAID 0. I really hope that you get this commited, then there's one feature less missing from grub-legacy ;) Hi, Nice to know that the patch is working..for others also.meanwhile I am not too much sure,why the same is not happening to me. The only difference in this case is that , my linux is in sata and my windows is in IDE. Viswesh ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Problem booting grub2: can't find fd1
Hello, I have a brand new server: A Dell PowerEdge T105 Quad Core AMD64. I installed it with Debian Lenny, which installed Lilo as a bootloader. I installed grub2 manually: grub-install /dev/sda update-grub When I boot I get dropped into a rescue shell because grub can't find fd1. The output of `ls`: (linuxvg-boot) (linuxvg-root) (linuxvg-swap) (hd0) (hd0,1) (hd0,2) (hd0,3) (fd0) (fd1) Thing is, my server has no floppy drive. It has one had disk containing two small Dell partitions and a big partition that is the PV for my LVM volume group "linuxvg". And it contains a DVD-ROM drive. No floppy drive. I even disabled the floppy controller in the BIOS. I am able to boot Debian by entering the boot commands manually: > insmod linux > linux (linuxvg-boot)/vmlinuz-2.6.25-2-amd64 root=/dev/mapper/linuxvg-root ro > initrd (linuxvg-boot)/initrd.img-2-6-25-2-amd64 > boot What can I do to fix this issue? Yesterday on #grub marco_g suggested that I try grub-legacy to see it it has the same fd1 problem. I can't install grub-legacy because it does not support having /boot on LVM, so I will need to test grub-legacy with a rescue image. Unfortunately I don't have a floppy drive so I can't try the grub legacy disk image supplied by the grub-disk package. I do have grub-rescue-cd but that's grub2, not grub-legacy. Does anyone have a grub-legacy rescue CD iso I can use to see if grub-legacy has the same problem as grub2? Kind regards, -- Sander Marechal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: bug: cygwin support breaks cross compiles on cygwin
Felix Zielcke wrote: Hello, Am Freitag, den 08.08.2008, 14:59 +0200 schrieb Christian Franke: No, grub-pe2elf is build and installed even if is not necessary for the build process. This should be no problem. Well it's the same as with that --enable-debug thingy ;) In our Debian trunk SVN I already commited a change to remove grub.d/10_windows because Debian/Ubuntu users just don't have a need for this. It would be better if Robert and me don't need to do such changes. We could just remove grub-pe2elf, too. But why should it be build for everybody if only Cygwin users have a use for it? Then clearly the whole build process needs a change so that grub-pe2elf is only build on Cygwin. I agree. I posted a patch which handles both grub.d/10_windows and grub-pe2elf. Christian ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Don't install Cygwin specific files elsewhere
This patch prevents the install of grub.d/10_windows on other OS.
grub-pe2elf is only installed if requested by --enable-grub-pe2elf. Even
on Cygwin, grub-pe2elf is only required during build.
Christian
2008-08-08 Christian Franke <[EMAIL PROTECTED]>
* Makefile.in: Add `target_os' and `enable_grub_pe2elf'.
* conf/common.rmk: Install `grub-pe2elf' only if requested.
Install `grub.d/10_windows' only on Cygwin.
* configure.ac: Add subst of `target_os'.
Check `target_os' also before setting TARGET_OBJ2ELF.
Add `--enable-grub-pe2elf'.
diff --git a/Makefile.in b/Makefile.in
index 2121431..6137974 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -48,6 +48,7 @@ PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
target_cpu = @target_cpu@
+target_os = @target_os@
platform = @platform@
INSTALL = @INSTALL@
@@ -92,6 +93,7 @@ UNIFONT_HEX = @UNIFONT_HEX@
# Options.
enable_grub_emu = @enable_grub_emu@
enable_grub_fstest = @enable_grub_fstest@
+enable_grub_pe2elf = @enable_grub_pe2elf@
enable_lzo = @enable_lzo@
### General variables.
diff --git a/conf/common.rmk b/conf/common.rmk
index 3d674a6..95859f7 100644
--- a/conf/common.rmk
+++ b/conf/common.rmk
@@ -100,7 +100,10 @@ grub_editenv_SOURCES = util/grub-editenv.c lib/envblk.c util/misc.c kern/misc.c
CLEANFILES += grub-editenv
# for grub-pe2elf
+ifeq ($(enable_grub_pe2elf), yes)
bin_UTILITIES += grub-pe2elf
+endif
+
grub_pe2elf_SOURCES = util/grub-pe2elf.c util/misc.c
CLEANFILES += grub-pe2elf
@@ -120,7 +123,11 @@ CLEANFILES += update-grub_lib
%: util/grub.d/%.in config.status
./config.status --file=$@:$<
chmod +x $@
-update-grub_SCRIPTS = 00_header 10_linux 10_hurd 10_windows 30_os-prober 40_custom
+update-grub_SCRIPTS = 00_header 10_linux 10_hurd 30_os-prober 40_custom
+ifeq ($(target_os), cygwin)
+update-grub_SCRIPTS += 10_windows
+endif
+
CLEANFILES += $(update-grub_SCRIPTS)
update-grub_DATA += util/grub.d/README
diff --git a/configure.ac b/configure.ac
index 7a5938a..f561b8b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -100,6 +100,7 @@ case "$target_cpu" in
esac
AC_SUBST(target_cpu)
+AC_SUBST(target_os)
AC_SUBST(platform)
#
@@ -206,9 +207,10 @@ AC_MSG_RESULT([$TARGET_IMG_LDFLAGS_AC])
# For platforms where ELF is not the default link format.
AC_MSG_CHECKING([for command to convert module to ELF format])
-if test "$host_os" = cygwin; then
- TARGET_OBJ2ELF='grub-pe2elf.exe'
-fi
+case "${host_os}:${target_os}" in
+ cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+ *) ;;
+esac
AC_SUBST(TARGET_OBJ2ELF)
AC_MSG_RESULT([$TARGET_OBJ2ELF])
@@ -385,6 +387,11 @@ AC_ARG_ENABLE([grub-fstest],
[build and install the `grub-fstest' debugging utility])])
AC_SUBST([enable_grub_fstest])
+AC_ARG_ENABLE([grub-pe2elf],
+ [AS_HELP_STRING([--enable-grub-pe2elf],
+ [build and install the `grub-pe2elf' conversion utility])])
+AC_SUBST([enable_grub_pe2elf])
+
# Output files.
AC_CONFIG_LINKS([include/grub/cpu:include/grub/$target_cpu
include/grub/machine:include/grub/$target_cpu/$platform])
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New command checktime
On Fri, Aug 8, 2008 at 3:12 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > On Thu, Aug 07, 2008 at 11:17:14AM -0700, Colin D Bennett wrote: >> I just have a couple of suggestions: >> >> On Fri, 8 Aug 2008 01:52:07 +0800 >> Bean <[EMAIL PROTECTED]> wrote: >> >> > On Thu, Aug 7, 2008 at 7:19 PM, Bean <[EMAIL PROTECTED]> wrote: >> > 1. date [MMDDhhmm[[CC]YY][.ss]] >> > >> > Set/Display current datetime, to set date, The format is the same as >> > the date command, you can also use - or : to seperate the numbers. For >> > example: >> > >> > date 0902 >> > Sep, 2. >> > >> > date 10-05-13-15 >> > Oct 5, 13:15 >> >> I know the reason for using that format is to be compatible with the >> Unix 'date' command, but I find it impossible to remember the arcane >> format it accepts. > > We could have its --help include this "[MMDDhhmm[[CC]YY][.ss]]" boilerplate, > like with gnu date. > > IMHO it's an advantage that the input for changing the date is defined > simple instead of accepting lots of different layouts. This means less code > size, less complexity and also makes the commands more usable in scripts and > such. > I agree with Colin the datetime representation should be more intuitive, but we should stick to one layout. I use the following format now: date [[year-]month-day] [hour:minute[:second]] date is separated by `-' , and time `:', year and second part can be omitted. >> > 2. crontab min hour day_of_month month day_of_week >> >> This really doesn't allow you to edit a crontab, does it? If not, is >> there a more appropriate name we could use instead of 'crontab'? >> Perhaps 'testdate' or something? > > I think it's good that it mentions crontab, since it basicaly works with > that format, but I agree that it isn't consistent with the crontab command. > > How about something that contains 'crontab' but isn't 'crontab'? Like > 'test_crontab', 'crontab_check' or something like this? test_crontab looks good to me. This is the new patch, if no one objects, I'd commit it soon. 2008-08-09 Bean <[EMAIL PROTECTED]> * conf/i386-pc.rmk (pkglib_MODULES): Add datetime.mod, date.mod and crontab.mod. (datetime_mod_SOURCES): New macro. (datetime_mod_CFLAGS): Likewise. (datetime_mod_LDFLAGS): Likewise. (date_mod_SOURCES): Likewise. (date_mod_CFLAGS): Likewise. (date_mod_LDFLAGS): Likewise. (crontab_mod_SOURCES): Likewise. (crontab_mod_CFLAGS): Likewise. (crontab_mod_LDFLAGS): Likewise. * conf/i386-coreboot.rmk (pkglib_MODULES): Add datetime.mod, date.mod and crontab.mod. (datetime_mod_SOURCES): New macro. (datetime_mod_CFLAGS): Likewise. (datetime_mod_LDFLAGS): Likewise. (date_mod_SOURCES): Likewise. (date_mod_CFLAGS): Likewise. (date_mod_LDFLAGS): Likewise. (crontab_mod_SOURCES): Likewise. (crontab_mod_CFLAGS): Likewise. (crontab_mod_LDFLAGS): Likewise. * conf/i386-ieee1275.rmk (pkglib_MODULES): Add datetime.mod, date.mod and crontab.mod. (datetime_mod_SOURCES): New macro. (datetime_mod_CFLAGS): Likewise. (datetime_mod_LDFLAGS): Likewise. (date_mod_SOURCES): Likewise. (date_mod_CFLAGS): Likewise. (date_mod_LDFLAGS): Likewise. (crontab_mod_SOURCES): Likewise. (crontab_mod_CFLAGS): Likewise. (crontab_mod_LDFLAGS): Likewise. * conf/i386-efi.rmk (pkglib_MODULES): Add datetime.mod, date.mod and crontab.mod. (datetime_mod_SOURCES): New macro. (datetime_mod_CFLAGS): Likewise. (datetime_mod_LDFLAGS): Likewise. (date_mod_SOURCES): Likewise. (date_mod_CFLAGS): Likewise. (date_mod_LDFLAGS): Likewise. (crontab_mod_SOURCES): Likewise. (crontab_mod_CFLAGS): Likewise. (crontab_mod_LDFLAGS): Likewise. * conf/x86_64-efi.rmk (pkglib_MODULES): Add datetime.mod, date.mod and crontab.mod. (datetime_mod_SOURCES): New macro. (datetime_mod_CFLAGS): Likewise. (datetime_mod_LDFLAGS): Likewise. (date_mod_SOURCES): Likewise. (date_mod_CFLAGS): Likewise. (date_mod_LDFLAGS): Likewise. (crontab_mod_SOURCES): Likewise. (crontab_mod_CFLAGS): Likewise. (crontab_mod_LDFLAGS): Likewise. * commands/date.c: New file. * commands/crontab.c: Likewise. * include/grub/datetime.h: Likewise. * include/grub/i386/cmos.h: Likewise. * kern/generic/get_dow.c: Likewise. * kern/i386/datetime.c: Likewise. * kern/efi/datetime.c: Likewise. -- Bean diff --git a/commands/crontab.c b/commands/crontab.c new file mode 100644 index 000..2a7b061 --- /dev/null +++ b/commands/crontab.c @@ -0,0 +1,127 @@ +/* crontab.c - command to test current date/time. */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 2008 Free Software Foundation, Inc. + * + * GRUB
