Re: grub-probe detects ext4 wronly as ext2
From: JavierMartín [EMAIL PROTECTED] Sent: Monday, June 30, 2008 5:02 AM Phew, that was all (I hope) Cheers! Habbit Thank you for the patch. Just tried it out, it works fine ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Loading windows in macbook
Hi, Oh, actually a20 of macbook can be disabled with fast a20 port 92. However, the current a20 code do the keyboard controller test before trying port 92, which cause it to hang. To fix it, I only need to adjust the order of tests. -- Bean diff --git a/kern/i386/pc/startup.S b/kern/i386/pc/startup.S index 9542978..9752828 100644 --- a/kern/i386/pc/startup.S +++ b/kern/i386/pc/startup.S @@ -368,9 +368,32 @@ gate_a20_try_bios: popl %ebp call gate_a20_check_state cmpb %al, %dl - jnz gate_a20_try_keyboard_controller + jnz gate_a20_try_system_control_port_a ret +gate_a20_try_system_control_port_a: + /* + * In macbook, the keyboard test would hang the machine, so we move + * this forward. + */ + /* fourth, try the system control port A */ + inb $0x92 + andb $(~0x03), %al + testb %dl, %dl + jz 6f + orb $0x02, %al +6: outb $0x92 + + /* When turning off Gate A20, do not check the state strictly, + because a failure is not fatal usually, and Gate A20 is always + on some modern machines. */ + testb %dl, %dl + jz 7f + call gate_a20_check_state + cmpb %al, %dl + jnz gate_a20_try_keyboard_controller +7: ret + gate_a20_flush_keyboard_buffer: inb $0x64 andb $0x02, %al @@ -409,28 +432,9 @@ gate_a20_try_keyboard_controller: call gate_a20_check_state cmpb %al, %dl - jnz gate_a20_try_system_control_port_a - ret - -gate_a20_try_system_control_port_a: - /* fourth, try the system control port A */ - inb $0x92 - andb $(~0x03), %al - testb %dl, %dl - jz 6f - orb $0x02, %al -6: outb $0x92 - - /* When turning off Gate A20, do not check the state strictly, - because a failure is not fatal usually, and Gate A20 is always - on some modern machines. */ - testb %dl, %dl - jz 7f - call gate_a20_check_state - cmpb %al, %dl /* everything failed, so restart from the beginning */ jnz gate_a20_try_bios -7: ret + ret gate_a20_check_state: /* iterate the checking for a while */ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Patch for the open hackware
On Wed, Jun 18, 2008 at 1:45 AM, Bean [EMAIL PROTECTED] wrote:
On Wed, Jun 18, 2008 at 1:39 AM, Robert Millan [EMAIL PROTECTED] wrote:
On Tue, Jun 17, 2008 at 11:44:36PM +0800, Bean wrote:
+ if (grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_CANNOT_INTERPRET))
+{
+ grub_addr_t addr;
+ grub_uint32_t len;
+
+ addr = HEAP_MAX_ADDR - HEAP_MIN_SIZE;
+ len = HEAP_MIN_SIZE;
+
+ if (grub_claimmap (addr, len) 0)
+return grub_error (GRUB_ERR_OUT_OF_MEMORY,
+ Failed to claim heap at 0x%llx, len 0x%llx\n,
+ addr, len);
+
+ grub_mm_init_region ((void *) addr, len);
+}
+ else
+grub_available_iterate (heap_init);
}
This skips all the checks in heap_init(), which were intended for situations
that could also apply to Open Hackware. Would be better if you call
heap_init() with the desired parameters instead.
Hi,
You're right, this is the new patch.
btw, I also include the previous elf header patch. It's working in
linuxbios, olpc and ppc, I guess it should be all right.
Hi,
If no one objects, I'd like to commit this soon.
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe detects ext4 wronly as ext2
+#define EXT3_FEATURE_INCOMPAT_RECOVER 0x0004 /* Needs recovery */ +#define EXT2_DRIVER_SUPPORTED_INCOMPAT ( EXT2_FEATURE_INCOMPAT_FILETYPE ) I suspect this will mean that journalled ext3 when the system crashed (so the filesystem needs recovery from the journal) won't load. (Of course, properly speaking that would load grub's code to replay the journal...) But I think that (without other changes) that would make the system unbootable every time there was a power outage? (Of course it was not guaranteed to load correctly when ignoring the journal when it needed recovery, but it was likely to work, IIUC.) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe detects ext4 wronly as ext2
On Mon, Jun 30, 2008 at 8:12 PM, Javier Martín [EMAIL PROTECTED] wrote: El lun, 30-06-2008 a las 07:14 -0400, Isaac Dupree escribió: +#define EXT3_FEATURE_INCOMPAT_RECOVER 0x0004 /* Needs recovery */ +#define EXT2_DRIVER_SUPPORTED_INCOMPAT ( EXT2_FEATURE_INCOMPAT_FILETYPE ) I suspect this will mean that journalled ext3 when the system crashed (so the filesystem needs recovery from the journal) won't load. (Of course, properly speaking that would load grub's code to replay the journal...) But I think that (without other changes) that would make the system unbootable every time there was a power outage? (Of course it was not guaranteed to load correctly when ignoring the journal when it needed recovery, but it was likely to work, IIUC.) -Isaac As I said, I didn't add it because I didn't know whether recovery was supported or not. _Theoretically_ we should focus on correctness and refuse to read such a filesystem, but here goes a workaround for incompatible features that we do not support but still willingly want to ignore for the sake of compatibility. This new version of the patch adds another macro, EXT2_DRIVER_IGNORED_INCOMPAT where we can put features that we don't fully support, but still want a filesystem with them to be mounted, like the needs_recover flag. Of course, this is risky: INCOMPAT_* features are so for a reason, but it will allow dirty ext3 filesystems to be mounted until we have a working journal implementation. I had thought of adding some kind of warning, but since GRUB mounts and umounts filesystems constantly, it just cluttered the screen and I removed it. Hi, We must not quit if the journal flag is set, even if we don't handle it. grub-setup runs in a active system, the journal wouldn't be empty. If we just quit, we can't even install. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe detects ext4 wronly as ext2
Hi there, El lun, 30-06-2008 a las 20:27 +0800, Bean escribió: Hi, We must not quit if the journal flag is set, even if we don't handle it. grub-setup runs in a active system, the journal wouldn't be empty. If we just quit, we can't even install. If you mean the needs_recovery flag (EXT3_FEATURE_INCOMPAT_RECOVER), the last version of the patch does with it nicely, as it is added to the set of incompatible feature flags to be ignored in the check. It's not added to the list of supported incompatible features because true support for recovery and replay is not implemented right now, but dirty ext3 filesystems will still be mounted, even if it's risky without having journal replay functionality. Ext4 filesystems, on the other hand, will not, since the incompatible extents feature is neither in the supported nor the ignored list. signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Save/Load environment variable support
Hi,
This is the new patch, some changes:
1, envblk.h, remove GRUB_ENVBLK_RDIR and the like, they're not needed
in this patch.
2, util/envblk.c, use grub_* function for string manipulation.
3, commands/loadenv.c, use grub_disk_read/grub_disk_write to
read/write disk, the problem of lower level api is that they don't
update the cache.
If there is no problem, I'd like to commit this soon.
--
Bean
diff --git a/commands/loadenv.c b/commands/loadenv.c
new file mode 100755
index 000..7359683
--- /dev/null
+++ b/commands/loadenv.c
@@ -0,0 +1,257 @@
+/* loadenv.c - command to load/save environment variable. */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2008 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/normal.h
+#include grub/dl.h
+#include grub/mm.h
+#include grub/arg.h
+#include grub/file.h
+#include grub/disk.h
+#include grub/misc.h
+#include grub/env.h
+#include grub/envblk.h
+#include grub/partition.h
+
+static const struct grub_arg_option options[] =
+ {
+{file, 'f', 0, specify filename, 0, ARG_TYPE_PATHNAME},
+{0, 0, 0, 0, 0, 0}
+ };
+
+char buffer[GRUB_ENVBLK_MAXLEN];
+grub_envblk_t envblk;
+
+static grub_file_t
+read_envblk_file (char *filename, void NESTED_FUNC_ATTR read_hook (grub_disk_addr_t sector, unsigned offset, unsigned length))
+{
+ char *buf = 0;
+ grub_file_t file;
+
+ if (! filename)
+{
+ char *prefix;
+
+ prefix = grub_env_get (prefix);
+ if (prefix)
+{
+ int len;
+
+ len = grub_strlen (prefix);
+ buf = grub_malloc (len + 1 + sizeof (GRUB_ENVBLK_DEFCFG));
+ grub_strcpy (buf, prefix);
+ buf[len] = '/';
+ grub_strcpy (buf + len + 1, GRUB_ENVBLK_DEFCFG);
+ filename = buf;
+}
+ else
+{
+ grub_error (GRUB_ERR_FILE_NOT_FOUND, prefix is not found);
+ return 0;
+}
+}
+
+ file = grub_file_open (filename);
+ grub_free (buf);
+ if (! file)
+return 0;
+
+ if (read_hook)
+{
+ if (! file-device-disk)
+{
+ grub_file_close (file);
+ grub_error (GRUB_ERR_BAD_DEVICE,
+ this command is available only for disk devices.);
+ return 0;
+}
+ file-read_hook = read_hook;
+}
+
+ if (grub_file_read (file, buffer, GRUB_ENVBLK_MAXLEN) != GRUB_ENVBLK_MAXLEN)
+{
+ grub_file_close (file);
+ grub_error (GRUB_ERR_BAD_FILE_TYPE, file too short);
+ return 0;
+}
+
+ envblk = grub_envblk_find (buffer);
+ if (! envblk)
+{
+ grub_file_close (file);
+ grub_error (GRUB_ERR_BAD_FILE_TYPE, environment block not found);
+ return 0;
+}
+
+ return file;
+}
+
+static grub_err_t
+grub_cmd_load_env (struct grub_arg_list *state,
+ int argc __attribute__ ((unused)), char **args __attribute__ ((unused)))
+
+{
+ grub_file_t file;
+
+ auto int hook (char *name, char *value);
+ int hook (char *name, char *value)
+{
+ grub_env_set (name, value);
+
+ return 0;
+}
+
+ file = read_envblk_file ((state[0].set) ? state[0].arg : 0, 0);
+ if (! file)
+return grub_errno;
+
+ grub_file_close (file);
+
+ grub_envblk_iterate (envblk, hook);
+
+ return grub_errno;
+}
+
+static grub_err_t
+grub_cmd_list_env (struct grub_arg_list *state,
+ int argc __attribute__ ((unused)), char **args __attribute__ ((unused)))
+{
+ grub_file_t file;
+
+ auto int hook (char *name, char *value);
+ int hook (char *name, char *value)
+{
+ grub_printf (%s=%s\n, name, value);
+
+ return 0;
+}
+
+ file = read_envblk_file ((state[0].set) ? state[0].arg : 0, 0);
+ if (! file)
+return grub_errno;
+
+ grub_file_close (file);
+
+ grub_envblk_iterate (envblk, hook);
+
+ return grub_errno;
+}
+
+static grub_err_t
+grub_cmd_save_env (struct grub_arg_list *state, int argc, char **args)
+{
+ grub_file_t file;
+ grub_disk_t disk;
+ grub_disk_addr_t addr[GRUB_ENVBLK_MAXLEN GRUB_DISK_SECTOR_BITS];
+ char buf[GRUB_DISK_SECTOR_SIZE];
+ grub_disk_addr_t part_start = 0;
+ int num = 0;
+
+ auto void NESTED_FUNC_ATTR hook (grub_disk_addr_t sector, unsigned offset,
+ unsigned length);
+
+ void NESTED_FUNC_ATTR hook (grub_disk_addr_t sector,
+ unsigned offset, unsigned length)
+{
Re: [PATCH] Patch for the open hackware
On Mon, 2008-06-30 at 18:08 +0800, Bean wrote: If no one objects, I'd like to commit this soon. No objection from me. I was about to ask you to commit it. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] add a counter in grub_dprintf
On Sun, 2008-06-29 at 13:22 +0200, Robert Millan wrote: On Thu, Jun 26, 2008 at 05:20:51PM +0200, Javier Martín wrote: Whoops, sorry, I meant that grub_mkimage would create two core.img images, one per kernel.img version, and then grub_install would copy them as usual. Then grub_setup would embed/set up the normal core.img or the debug version based on a switch. What I propose is basically modifying grub_mkimage to allow choosing the kernel.img file used and then adding some lines to grub_install so that the two versions of core.img are generated (but only the selected is embedded). Ah; then it sounds fine, I guess. Sorry for entering this discussion so late. I can tell from my experience that most debug code is only useful to debug once specific problem. Once the problem is fixed, the debug code is not needed. If another problem is found, then some new debug code should be written to debug that problem. Generic debug code may be useful to get information from users if only they can reproduce the problem. But even then, if may be better to add a few lines to test certain assumptions rather than try to glean useful pieces of information from a long generic log. Adding a complicated mechanism for having debug and non-debug images looks like an overkill to me. It could create more problems than it would fix. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix chainloding + Chainloading into logical partitions
2008/6/30 Lucas Gadani [EMAIL PROTECTED]: Hello, This is my first patch for GRUB, and I haven't found any coding styles/formatting, nor developer documentation, so, if there's something wrong, please, forgive me and point me to the right direction. Current implementation of the chainloading code does not work, cause it reads the partition table from the first sector of the root device, and the root device does not contain partition information. I've changed the way partition table are loaded, keeping a copy of the partition entry in grub_partition_t structs data field, and just loading this information in the correct address when chainloading. I've also changed the logical partitions start address to point to the actual disk sector, instead of pointing to the sector relative to the beginning of the extended partition, so we can now boot into logical partitions (for example, syslinux doesn't boot if the partition table doesn't map to the correct disk sector). Any comments are appreciated. -- Lucas Thank you so much for this. I've been having problem for weeks trying to boot some syslinux-bootable partitions on a usb stick. I knew of the problem but lacked the necessary knowledge to contribute myself. I've just begun to try the patched grub, but until now performs as expected. Something that might be related: I've created a stick with a GPT label, and I get partitions to boot using syslinux, or rather, they all boot until the fourth. The fifth and the following ones don't, even when I clone the contents of another partition which does boot. I suspect a similar problem to the one you've addressed. Thanks again for the effort. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Small fix in grub-setup
On Mon, 2008-06-30 at 03:58 +0200, Javier Martín wrote: Here goes a small fix to a grub-setup error that has driven /me crazy for the last 4 hours: in the recent split between core_path and core_path_dev, one occurrence of the former that should have been turned into the latter was not, thus making grub-setup spit lots of nonsensical (to me) error: file not found messages. I spent a big deal of time trying to debug the wrong piece of code, since I stubbornly thought that the error was in the read-and-check loop, while it really was later in the file... Sigh I understand you were trying to install GRUB to a non-default root. I'm sorry for not testing that. The fix is so simple that I post it directly here. If a ChangeLog entry is necessary, I'd propose complete core_path variable split or something along that lines. Actually, it's a real bug, so ChangeLog shouldn't be worded like it's another cosmetic change like the original patch was meant to be. I've applied your patch. Thank you! -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH] Sector 2 of non-embedded core.img: write early or patch later?
On Sat, 2008-06-28 at 12:58 +0800, Bean wrote: On Sat, Jun 28, 2008 at 5:24 AM, Pavel Roskin [EMAIL PROTECTED] wrote: I tend to prefer the later (write early) approach, but I'd like to see some feedback before I commit it. Hi, The problem of write early is that it changes the target image before verification is made, so if verification fails, the change remains. This is generally not a good practice, we should not touch core.img if it can't be embedded successfully. OK, that's a good argument. Actually, if grub-install is used, core.img would have been rewritten already. Anyway, core.img is a file we want to touch as little as possible, considering that it can already be used. I'm applying the patch-later patch with some simplifications and warning fixes. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: New developer available :)
On Tue, Jul 1, 2008 at 5:59 AM, walt [EMAIL PROTECTED] wrote: Bean wrote: On Mon, Jun 30, 2008 at 4:43 AM, walt[EMAIL PROTECTED] wrote: ...I'm using grub4dos because grub2 won't (yet) boot a floppy image or chainload Vista's bootmgr. Hi, Well, you can actually achieve these function with some external tools. Using memdisk, you can emulate a floppy/harddisk image, and with loadbin, you can chainload ntldr/bootmgr/grldr/stage2, etc. Hi Bean, Have you tried booting a dos floppy image with memdisk lately? I just tried memdisk-3.52 on two different machines using both legacy and grub2, and nothing worked. After printing several lines of info and some hex numbers it prints this: Loading boot sector...booting... Starting... and then the machine hangs forever, needing a hard reset to reboot. My test image was made from a fresh and tested floppy which I made using WinXP. Can anyone duplicate this? Or not? Hi, Perhaps you can try some older version as well, like 3.11 or so. Also, you can add raw or bigraw parameter to memdisk, it instructs memdisk to access memory directly instead of relying on int 15, which can be buggy in some machine. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
