Re: subversion repository structure
On Thu, 17 Jul 2008 11:20:47 +0800 Bean <[EMAIL PROTECTED]> wrote: > On Wed, Jul 16, 2008 at 6:23 AM, Pavel Roskin <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-07-15 at 23:02 +0200, Yoshinori K. Okuji wrote: > > > >> I don't agree on this. GRUB Legacy and GRUB 2 are developed fully > >> independently (if any). If we follow your way, the repository > >> would look like this: > >> > >> branches/ > >> grub-legacy/ > >> prepare_0_97/ > >> prepare_0_98/ > >> prepare_1_98/ > >> prepare_1_99/ > >> ... > >> > >> I feel that this has no logical structure. When we make a branch > >> for GRUB 2, we put it under branches, when we modify the "trunk" > >> of GRUB Legacy, we do under branches, when we make a branch for > >> GRUB Legacy, we use branches... > > > > Yes, that's my suggestion. I understand that you may feel uneasy > > about it, but I don't think we are going to do many releases from > > the legacy branch, maybe one or none at all. > > > > It's OK to have stable and development branches. grub-legacy is > > essentially our stable branch, even though it didn't start as a > > branch. > > > > CVS is inherently asymmetric. Certain things just don't work on > > branches the way they work on trunk. That's why it was reasonable > > to avoid branches with CVS for anything but release preparation. > > > > Subversion is (more) symmetric. It's possible to develop on any > > branch, check the entire history of files, merge changes from other > > branches. Separating trunk from other branches in the standard > > Subversion repository layout is primarily to give comfort to CVS > > users, who are used to having one trunk with a special status. > > > > We could have GRUB 2 under branches too and have no trunk. But > > having GRUB 2 as the trunk gives us the standard layout, which is a > > good thing. In any case, I think it's better than any of the > > "two-headed" solutions. > > Hi, > > If we're using branches, I suggest the following layout: > > branches >grub-legacy > trunk > tags > grub-0.97 > grub-1.96 > ... > > trunk is grub2, the current develop branch, and grub-legacy is under > branches. This layout makes perfect sense if we are treating GRUB legacy and GRUB 2 as the same project, but where GRUB 2 is now the development mainline and GRUB legacy is a past release codeline. On the other hand, if GRUB legacy and GRUB 2 are considered separate projects, then having completely separate sub-trees like: grub-legacy/ trunk/ - 0.9x mainline tags/ grub-0.97- tagged release branches/ grub/ trunk/ - GRUB 2 mainline tags/ grub-1.96- GRUB v1.96 release branches/ makes more sense. I think we could actually go either way. It's not as if there is going to be much activity on grub-legacy anyway, right? Regards, Colin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Idea: elimination of the normal mode (revised version)
On Mon, Jul 7, 2008 at 8:29 AM, Bean <[EMAIL PROTECTED]> wrote:
> Hi,
>
> First of all, we can still keep rescue and normal command. But instead
> of depending on normal.mod, normal command depends on module arg,
> which is an option parser. Also, these two type of commands are of the
> same command set. In fact, module arg is implemented as a pre parser,
> which goes through the list of arguments and extract the options. In
> the case of rescue command, the pre parser field is null, which means
> it wants to parse options itself.
>
> Then, I think of a new structure to represent all configurable
> handlers of grub. Different types of handler have different fields,
> but they all share a command header:
>
> struct grub_handler
> {
> .next,
> .name,
> .init,
> .fini
> };
>
> Same type of handlers are linked together. We first define an enum to
> list all types. For example:
>
> enum {
> GRUB_HANDLER_INPUT,
> GRUB_HANDLER_OUTPUT,
> GRUB_HANDLER_CONSOLE,
> GRUB_HANDLER_MENU,
> GRUB_HANDLER_SCRIPT,
> GRUB_HANDLER_NUM
> };
>
> Then, we define an array to point to the head of handler linked list:
> grub_handler[GRUB_HANDLER_NUM];
>
> Head is the default selection. When we insert a new handler module, it
> would automatically become the new default, although we can switch
> back to old handler using a command.
>
> Here are more details about different handlers:
>
> input:
> This is the input component of terminal:
>
> struct grub_handler_input
> {
> .next,
> .name,
> .init,
> .fini,
> .checkkey,
> .getkey
> .flags,
> };
>
> output:
> This is the output component of terminal:
>
> struct grub_handler_output
> {
> .next,
> .name,
> .init,
> .fini,
> .putchar,
> .getcharwidth,
> .getxy,
> .gotoxy,
> .cls,
> .setcolorstate,
> .setcursor,
> .flags,
> };
>
> console interface:
> It represent the grub console, users type commands and execute them
> line by line.
>
> struct grub_handler_console
> {
> .next,
> .name,
> .init,
> .fini,
> .run
> };
>
> menu interface:
> It represent the menu, users select a menu item and execute it.
>
> struct grub_handler_menu
> {
> .next,
> .name,
> .init,
> .fini,
> .run
> };
>
> script engine:
> It's responsible for parsing config file to get the menu list, and
> execution of commands.
>
> struct grub_handler_script
> {
> .next,
> .name,
> .init,
> .fini,
> .readconfig
> .getmenu
> .execute
> };
>
> The handlers are independent of each other. When they need something,
> they called specific function of the default handler. For example, to
> read a key from the console, we can use
> grub_handler[GRUB_HANDLER_INPUT]->getkey. Also, to get the list of
> items to be displayed on screen, the menu handler can call
> grub_handler[GRUB_HANDLER_SCRIPT]->getmenu.
Any comment for this idea ?
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Loading windows in macbook
On Fri, Jul 4, 2008 at 2:59 AM, Marco Gerards <[EMAIL PROTECTED]> wrote: > Bean <[EMAIL PROTECTED]> writes: > >> On Fri, Jul 4, 2008 at 2:40 AM, Marco Gerards <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> Bean <[EMAIL PROTECTED]> writes: >>> 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. >>> >>> What is the order you propose? I wouldn't mind such a fix since the >>> Intel Mac is quite popular, although changing this might break GRUB on >>> other systems... >> >> Hi, >> >> Currently, the order is >> >> bios >> keyboard controller >> fast a20 port >> >> The second test would hang macbook, so I suggest >> bios >> fast a20 port >> keyboard controller >> >> I don't know if it will break other system. The fast a20 port code is >> simple enough, it reads from port 92, modify and write it back, system >> that don't support it shouldn't be affected, unless they use port 92 >> for other purpose. > > This seems to be a sane order. I would favor your solution to this > problem. Please wait a while before you commit this, so Okuji can > comment on this in case he disagrees. Hi, If no one objects, I'd commit this soon. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: subversion repository structure
On Wed, Jul 16, 2008 at 6:23 AM, Pavel Roskin <[EMAIL PROTECTED]> wrote: > On Tue, 2008-07-15 at 23:02 +0200, Yoshinori K. Okuji wrote: > >> I don't agree on this. GRUB Legacy and GRUB 2 are developed fully >> independently (if any). If we follow your way, the repository would look like >> this: >> >> branches/ >> grub-legacy/ >> prepare_0_97/ >> prepare_0_98/ >> prepare_1_98/ >> prepare_1_99/ >> ... >> >> I feel that this has no logical structure. When we make a branch for GRUB 2, >> we put it under branches, when we modify the "trunk" of GRUB Legacy, we do >> under branches, when we make a branch for GRUB Legacy, we use branches... > > Yes, that's my suggestion. I understand that you may feel uneasy about > it, but I don't think we are going to do many releases from the legacy > branch, maybe one or none at all. > > It's OK to have stable and development branches. grub-legacy is > essentially our stable branch, even though it didn't start as a branch. > > CVS is inherently asymmetric. Certain things just don't work on > branches the way they work on trunk. That's why it was reasonable to > avoid branches with CVS for anything but release preparation. > > Subversion is (more) symmetric. It's possible to develop on any branch, > check the entire history of files, merge changes from other branches. > Separating trunk from other branches in the standard Subversion > repository layout is primarily to give comfort to CVS users, who are > used to having one trunk with a special status. > > We could have GRUB 2 under branches too and have no trunk. But having > GRUB 2 as the trunk gives us the standard layout, which is a good thing. > In any case, I think it's better than any of the "two-headed" solutions. Hi, If we're using branches, I suggest the following layout: branches grub-legacy trunk tags grub-0.97 grub-1.96 ... trunk is grub2, the current develop branch, and grub-legacy is under branches. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: subversion repository structure
On Wed, Jul 16, 2008 at 8:52 AM, walt <[EMAIL PROTECTED]> wrote: > I was quite confused when I checked out the new svn sources because I got > more code than I want or need. I want only the grub2 sources and not the > legacy grub, but I get them both anyway. > > For example: > > # ls -l ~/src/grub2 > drwxr-xr-x 8 wa1ter users 4096 2008-07-15 17:33 grub <--- I don't need > this > drwxr-xr-x 24 wa1ter users 4096 2008-07-15 16:56 grub2 > > # grep savannah ~/src/grub2/.svn/entries > svn://svn.savannah.gnu.org/grub/trunk <--- No mention of grub2? > svn://svn.savannah.gnu.org/grub > > I got to this point after several attempts to fetch the grub2 sources, > and now I can't remember what I did to get this far. I'm still confused! > > At least there should be clear instructions somewhere telling me how to > get sources for grub2 *only*, yes/no? Hi, Well, you can checkout grub2 source with: svn checkout svn://svn.savannah.gnu.org/grub/trunk/grub2 -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 cannot mount correct NTFS-partition
On Thu, Jul 17, 2008 at 10:00 AM, Bean <[EMAIL PROTECTED]> wrote: > On Wed, Jul 16, 2008 at 10:07 PM, Oleg Strikov <[EMAIL PROTECTED]> wrote: >> Hi! >> I get strange problem, using grub2-current (and last releases as well) >> - ntfs partition cannot be mounted due to incorrect MFT size. After >> grub_printf() debug i collect some data: >> MFT_SIZE = 1968 (too big!) = cluster_per_mft (246) * spc (8) >> It looks like incorrect value :( but i get the same result on number >> of my ntfs partitions. >> Partitions can be mounted in linux/windows without any problems. >> >> What data should i collect to fully describe my problem? >> Thanks! > > Hi, > > cluster_per_mft is a signed number, 246 = -10, so size of mft is > actually 2^10 = 1024, which is the default value. Your problem should > be caused by something else. Hi, BTW, you can use fstest.exe to dump some useful information about ntfs file system, download it at: http://grub4dos.sourceforge.net/grub4dos/fstest.exe Run the following commands: fstest.exe info C:\ fstest.exe list C:\ fstest.exe inode C:\$MFT -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 cannot mount correct NTFS-partition
On Wed, Jul 16, 2008 at 10:07 PM, Oleg Strikov <[EMAIL PROTECTED]> wrote: > Hi! > I get strange problem, using grub2-current (and last releases as well) > - ntfs partition cannot be mounted due to incorrect MFT size. After > grub_printf() debug i collect some data: > MFT_SIZE = 1968 (too big!) = cluster_per_mft (246) * spc (8) > It looks like incorrect value :( but i get the same result on number > of my ntfs partitions. > Partitions can be mounted in linux/windows without any problems. > > What data should i collect to fully describe my problem? > Thanks! Hi, cluster_per_mft is a signed number, 246 = -10, so size of mft is actually 2^10 = 1024, which is the default value. Your problem should be caused by something else. -- 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
From: "JavierMartín" <[EMAIL PROTECTED]> Sent: Wednesday, July 16, 2008 9:07 PM To: "The development of GRUB 2" Subject: Re: grub-probe detects ext4 wronly as ext2 OK, so this is what I get from your 3 posts, and my proposals for the driver future: * meta_bg is a deprecated feature and is incompatible with resize_inode, which is used by default in ext4 and can be used by all other extN filesystems. We cannot safely ignore it since it signals an incompatible change in one of the fs descriptors, so the reading code might not be able to locate (meta)data on disk. I advocate _rejecting_ volumes with it (given that it's no longer being generated by any "standard" tool) until someone writes a patch to support it. resize_inode is not just enabled for ext4 but for every extN by mke2fs.conf Either check your own /etc/mke2fs.conf or see [0] which is the newest and so has all the ext4 features in it :) I can't remember ever seeing that meta_bg but I do remember that resize_inode wasn't just added now in the newest e2fsprogs The release-notes unfortunatly don't say when it was added or at least I didn't found that with searching for resize_inode * flex_bg seemingly allows certain metadata structures to be located at places other than their default positions. However, given that it is only used on volumes quite filled with bad blocks, I think we can (at least temporarily) _ignore_ it, but truly supporting it would be a Good Thing (tm) For me currently it works but that's why I added that others should test that. At least on this list only I and Bean tested this and I think Bean just tested this with my 30 MB image I gave him, where grub-fstest failed to read the Linux Kernel I don't know what this comment on mke2fs(8) about flex_bg means (use with -G option to group meta-data in order to create a large virtual block group). Oh, I now saw in that mail I forgot to copy the text from that -G option and the raw sourcecode of the manpage I linked there isn't really easy to read -G " number-of-groups" Specify the number of block goups that will be packed together to create one large virtual block group on an ext4 filesystem. This improves meta-data locality and performance on meta-data heavy workloads. The number of goups must be a power of 2 and may only be specified if the flex_bg filesystem feature is enabled. But because this grouping needs flex_bg enabled, and flex_bg is INCOMPAT, there's maybe a reason grub needs to support it. Maybe I'll try it out if grub fails to boot with that -G option used * uninit_bg might already be supported (we should check, though, with bigger partitions) and is not an incompat flag, so my patch does not affect its handling. I've one 8 GB ext4 where ~ 3 GB are used and another 8 GB ext4 where just ~700 MB are used Both have uninit_bg and flex_bg and grub works with them But because I don't use them much, proberbly grub doestn't even reach the uninitialized blockgroups/inode tables [0] http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=misc/mke2fs.conf;hb=HEAD ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe detects ext4 wronly as ext2
El mié, 16-07-2008 a las 19:44 +0200, Felix Zielcke escribió: > > Oh well I should have used grep with -i > > meta_bg and META_BG does make a difference > > > > Anyway in release-notes I now found this: > > > > Add support for the an alternative block group descriptor layout which > > allows for on-line resizing without needing to prepare the filesystem > > in advance. (This is the incomat feature flag meta_bg.) > > > > So it seems you'll have sooner or later to worry about that. > > But I still think it's currently not that important to implement it, > > because it's currently not compatible with resize_inode > > > > I should really take me more time for such things, but I think it's at least > better then sending the same mail twice :) > (Robert Millan knows why I say this) > > Anyway I thought that the release-notes are just for the current release not > complete list for every like NEWS or even the changelog > This entry is from version 1.30 dated October 31, 2002 > So I think resize_inode has completly replaced meta_bg > It's at least not mentioned anymore in the mke2fs(8) man page or even set by > mke2fs.conf > But probably the question remains, if grub should ignore it or reject it if > it's set OK, so this is what I get from your 3 posts, and my proposals for the driver future: * meta_bg is a deprecated feature and is incompatible with resize_inode, which is used by default in ext4 and can be used by all other extN filesystems. We cannot safely ignore it since it signals an incompatible change in one of the fs descriptors, so the reading code might not be able to locate (meta)data on disk. I advocate _rejecting_ volumes with it (given that it's no longer being generated by any "standard" tool) until someone writes a patch to support it. * flex_bg seemingly allows certain metadata structures to be located at places other than their default positions. However, given that it is only used on volumes quite filled with bad blocks, I think we can (at least temporarily) _ignore_ it, but truly supporting it would be a Good Thing (tm) * uninit_bg might already be supported (we should check, though, with bigger partitions) and is not an incompat flag, so my patch does not affect its handling. 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: grub-probe detects ext4 wronly as ext2
Oh well I should have used grep with -i meta_bg and META_BG does make a difference Anyway in release-notes I now found this: Add support for the an alternative block group descriptor layout which allows for on-line resizing without needing to prepare the filesystem in advance. (This is the incomat feature flag meta_bg.) So it seems you'll have sooner or later to worry about that. But I still think it's currently not that important to implement it, because it's currently not compatible with resize_inode I should really take me more time for such things, but I think it's at least better then sending the same mail twice :) (Robert Millan knows why I say this) Anyway I thought that the release-notes are just for the current release not complete list for every like NEWS or even the changelog This entry is from version 1.30 dated October 31, 2002 So I think resize_inode has completly replaced meta_bg It's at least not mentioned anymore in the mke2fs(8) man page or even set by mke2fs.conf But probably the question remains, if grub should ignore it or reject it if it's set ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe detects ext4 wronly as ext2
Oh well I should have used grep with -i meta_bg and META_BG does make a difference Anyway in release-notes I now found this: Add support for the an alternative block group descriptor layout which allows for on-line resizing without needing to prepare the filesystem in advance. (This is the incomat feature flag meta_bg.) So it seems you'll have sooner or later to worry about that. But I still think it's currently not that important to implement it, because it's currently not compatible with resize_inode ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe detects ext4 wronly as ext2
From: "JavierMartín" <[EMAIL PROTECTED]> Sent: Wednesday, July 16, 2008 6:38 PM To: "The development of GRUB 2" Subject: Re: grub-probe detects ext4 wronly as ext2 Er... of course, the Linux extN implementation is the de-facto reference implementation. Some incompat features are only used in newer versions like ext3 and ext4, while others are added to ext2 too. I was talking about the GRUB extN driver, which recently got patched by Bean. I thought you thought that META_BG is ext4 specific, but even ext2 supports it Anyway I just grepped for META_BG in the e2fsprogs 1.41 source and mke2fs.c says that resize_inode and meta_bg are not compatible resize_inode is by default enabled. I have it disabled on my ext4, because I just don't need it but I don't think this means meta_bg is enabled. So for me it looks like there's no need to worry about meta_bg Maybe I'll find something about that Uninit_bg is signaled (iIrc) in the superblock by a ROCOMPAT flag, GDT_CSUM, and then in the block groups by whatever-it-is (head spinning even faster). Oh well, I gave you a link to ext4.h and I even didn't notice there's really no UNINIT flag in the 3 lists of compat,incompat and rocompat I grepped e2fsprogs source for it You're right it is uninit_bg "is" the ROCOMPAT flag GDT_CSUM AFAIK, uninit_bg should work if the (readonly) GRUB reader respects the spec and skips "invalid" block groups/inodes/whatever (those that haven't been initialized). As I don't know what the f*** do META_BG and FLEX_BG do, I can't tell you whether they truly work or it's just a matter of luck: it's Bean who can tell us whether or not he implemented support for them - Yeah, Bean has to tell you. I only looked a few secons at the differences between his 2 patches which made my ext4 working and even if I would have read it longer, I didn't think I would fully understand it :) At [0] there's a mail from me on this list, with 2 quotes from Documentation/ext4.txt and what mke2fs(8) says about it and a quote of Bean what he found about flex_bg I only added the "extents" flag to the supported list on my patch, but including more is a matter of seconds. Yeah, I just wanted to make sure that uninit_bg and flex_bg don't get forgot, and then I forget this, install the debian package and then end up on a unbootable system :) But even if that happens, it's not a big problem for me now. Currently I only use ext4 in VMware [0] http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00157.html ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe detects ext4 wronly as ext2
El mié, 16-07-2008 a las 17:27 +0200, Felix Zielcke escribió: > From: "JavierMartín" <[EMAIL PROTECTED]> > Sent: Wednesday, July 16, 2008 5:09 PM > To: "The development of GRUB 2" > Subject: Re: grub-probe detects ext4 wronly as ext2 > > > I see the ext4 patch was checked in recently. Can the "forbid-incompat" > > patch with the new, specific error messages be committed too then? I'm > > submitting an updated version (i.e. against the current HEAD) because > > new lines were added. > > > > PS: does the ext4 patch add support for META_BG? it should be added to > > the list of supported incompat features then. > > I don't know what this META_BG is but even the ext2 kernel driver supports > it [0] Er... of course, the Linux extN implementation is the de-facto reference implementation. Some incompat features are only used in newer versions like ext3 and ext4, while others are added to ext2 too. I was talking about the GRUB extN driver, which recently got patched by Bean. > Maybe the list of flags have a bit changed so I'm so nice and give you even > a git link to the current ext4.h in Linus' official git tree [1] > You'll probably mean FLEX_BG :) All those flags make my head spin so fast I'll create a dark hole through gravitomagnetic effects. I no longer know what the hell does each one do T_T > > I didn't take a deep look at the changes between the first patch from Bean > and the last one which he commited. > But for me it's now working fine with whole / on ext4 made with the final > e2fsprogs 1.41 in Debian unstable, > with flex_bg,extents and uninit_bg from the INCOMPAT list, so flex_bg and > uninit_bg should be added to your list which are ignored/supported Uninit_bg is signaled (iIrc) in the superblock by a ROCOMPAT flag, GDT_CSUM, and then in the block groups by whatever-it-is (head spinning even faster). > > Maybe it's just luck for me that it works now with uninit_bg and flex_bg, > the best would be if other people would test it AFAIK, uninit_bg should work if the (readonly) GRUB reader respects the spec and skips "invalid" block groups/inodes/whatever (those that haven't been initialized). As I don't know what the f*** do META_BG and FLEX_BG do, I can't tell you whether they truly work or it's just a matter of luck: it's Bean who can tell us whether or not he implemented support for them - I only added the "extents" flag to the supported list on my patch, but including more is a matter of seconds. 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: Next release?
El mié, 16-07-2008 a las 12:17 -0400, Pavel Roskin escribió: > On Wed, 2008-07-16 at 16:17 +0200, Javier Martín wrote: > > > Same for me: I have the BIOS set up to boot from the second hard drive, > > which then becomes (hd0) for GRUB through the BIOS (kinda like what my > > proposed drivemap module does), but my /boot partition was on the first > > hard drive, which is now (hd1). Took me a bit to realise things, and I > > finally had to move around the whole partitioning scheme on the second > > hard drive to put /boot in there. > > I'm not sure I understand why you had to move /boot to the second drive. > But I think if GRUB refused to do cross-drive installs by default, it > would help you consider a single drive install right away. In any case, > it's a good thing. Now you can remove the first drive, and GRUB would > load all the way to the menu. > Remove it? o_O No I can't, because Windows XP and some of my Linux partitions (swap and /tmp) are there. 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: Next release?
On Wed, 2008-07-16 at 16:17 +0200, Javier Martín wrote: > Same for me: I have the BIOS set up to boot from the second hard drive, > which then becomes (hd0) for GRUB through the BIOS (kinda like what my > proposed drivemap module does), but my /boot partition was on the first > hard drive, which is now (hd1). Took me a bit to realise things, and I > finally had to move around the whole partitioning scheme on the second > hard drive to put /boot in there. I'm not sure I understand why you had to move /boot to the second drive. But I think if GRUB refused to do cross-drive installs by default, it would help you consider a single drive install right away. In any case, it's a good thing. Now you can remove the first drive, and GRUB would load all the way to the menu. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Next release?
On Wed, 2008-07-16 at 07:11 -0700, Colin D Bennett wrote: > > That's a very advanced setup. I actually cannot imagine why anyone > > would use different boot and root drives. Well, maybe the boot drive > > has no partitions that GRUB or the host OS can access? > > I have used machines that have multiple Linux versions spread across > two drives, but one common /boot partition so they can all be booted > from GRUB. This doesn't seem unusual to me. As I understand it, there are two cases where we have to hardcode the drive number. 1) MBR and core.img (embedded or not) are on different drives. 2) core.img and /boot/grub are on different drives. The second case can be mitigated because core.img can search all available drives. We can even tell it whether to search only hard drives or only floppies. After switching to lzma, we have some space in core.img we can use for that logic. I'm not sure that you are using either of those configurations. If yes, I'm not sure you need it, considering that you have Linux partitions on both drives. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Drivemap module
El sáb, 05-07-2008 a las 13:04 +0200, Marco Gerards escribió: > Javier Martín <[EMAIL PROTECTED]> writes: > > > Just an updated version of the patch that adds support for device-like > > names instead of raw BIOS disk numbers, i.e. this is now supported: > > grub> drivemap (hd0) (hd1) > > In addition to the already supported: > > grub> drivemap (hd0) 0x81 > > The effect is the same: the second BIOS hard drive will map to (hd0) > > through the installed int13h routine. The new syntax does not require > > the target device name to exist (hd1 need not exist in my example), and > > the parsing is very simple: it accepts names like (fdN) and (hdN) with > > and without parenthesis, and with N ranging from 0 to 127, thus allowing > > the full 0x00-0xFF range even though most BIOS-probing OSes don't bother > > going any further than fd7 and hd7 respectively. > > Great! Can you please send in a changelog entry? > > -- > Marco What about this: * commands/i386/pc/drivemap.c : New file, main part of the new drivemap module allowing BIOS drive remapping not unlike the legacy "map" command. This allows to boot OSes with boot-time dependencies on the particular ordering of BIOS drives or trusting their own to be 0x80, like Windows XP, with non-standard boot configurations. * commands/i386/pc/drivemap_int13h.S : New file, INT 13h handler for the drivemap module. Installed as a TSR routine by drivemap.c, performs the actual redirection of BIOS drives. * conf/i386-pc.rmk : Added the new module * include/grub/loader.h : Added a "just-before-boot" callback infrastructure used by drivemap.mod to install the INT13 handler only when the "boot" command has been issued. * kern/loader.c : Implement the preboot-hook described By the way, I sent the data to the "assign" mail as you instructed me to, and I've been told I'll receive some GNU copyright assignment documents to sign-and-return in a few days. 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: grub-probe detects ext4 wronly as ext2
From: "JavierMartín" <[EMAIL PROTECTED]> Sent: Wednesday, July 16, 2008 5:09 PM To: "The development of GRUB 2" Subject: Re: grub-probe detects ext4 wronly as ext2 I see the ext4 patch was checked in recently. Can the "forbid-incompat" patch with the new, specific error messages be committed too then? I'm submitting an updated version (i.e. against the current HEAD) because new lines were added. PS: does the ext4 patch add support for META_BG? it should be added to the list of supported incompat features then. I don't know what this META_BG is but even the ext2 kernel driver supports it [0] Maybe the list of flags have a bit changed so I'm so nice and give you even a git link to the current ext4.h in Linus' official git tree [1] You'll probably mean FLEX_BG :) I didn't take a deep look at the changes between the first patch from Bean and the last one which he commited. But for me it's now working fine with whole / on ext4 made with the final e2fsprogs 1.41 in Debian unstable, with flex_bg,extents and uninit_bg from the INCOMPAT list, so flex_bg and uninit_bg should be added to your list which are ignored/supported Maybe it's just luck for me that it works now with uninit_bg and flex_bg, the best would be if other people would test it [0] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/ext2_fs.h;hb=HEAD [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/ext4/ext4.h;hb=HEAD ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe detects ext4 wronly as ext2
I see the ext4 patch was checked in recently. Can the "forbid-incompat" patch with the new, specific error messages be committed too then? I'm submitting an updated version (i.e. against the current HEAD) because new lines were added. PS: does the ext4 patch add support for META_BG? it should be added to the list of supported incompat features then. 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: GRUB2 cannot mount correct NTFS-partition
El mié, 16-07-2008 a las 14:07 +, Oleg Strikov escribió: > MFT_SIZE = 1968 (too big!) = cluster_per_mft (246) * spc (8) Was that written by GRUB? I could not find that string, nor parts of it, in the source code. WRT your problem, the closest match I could find is in fs/ntfs.c, around line 819: if ((data->mft_size > MAX_MFT) || (data->idx_size > MAX_IDX)) goto fail; Where MAX_MFT is (1024 >> BLK_SHR) = (1024 >> 9) = 2 (???) 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: Next release?
El mié, 16-07-2008 a las 07:11 -0700, Colin D Bennett escribió: > On Tue, 15 Jul 2008 19:52:15 -0400 > Pavel Roskin <[EMAIL PROTECTED]> wrote: > > > On Wed, 2008-07-16 at 01:32 +0200, Yoshinori K. Okuji wrote: > > > > > If a boot drive is the same as a root drive, you are right. > > > Otherwise we need to do so. > > > > > > I think we have seen tons of examples with GRUB Legacy which may > > > not be solved automatically in all cases. If one digs into the > > > archive of bug-grub, I guess several cases would be found easily. > > > With GRUB 2, we can avoid embedding BIOS drive numbers in many > > > cases, using UUIDs or labels or files. But this does not always > > > work, so I am afraid that we need to support device.map, even if it > > > is an evil necessity. > > > > That's a very advanced setup. I actually cannot imagine why anyone > > would use different boot and root drives. Well, maybe the boot drive > > has no partitions that GRUB or the host OS can access? > > I have used machines that have multiple Linux versions spread across > two drives, but one common /boot partition so they can all be booted > from GRUB. This doesn't seem unusual to me. Same for me: I have the BIOS set up to boot from the second hard drive, which then becomes (hd0) for GRUB through the BIOS (kinda like what my proposed drivemap module does), but my /boot partition was on the first hard drive, which is now (hd1). Took me a bit to realise things, and I finally had to move around the whole partitioning scheme on the second hard drive to put /boot in there. > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel 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: Next release?
On Tue, 15 Jul 2008 19:52:15 -0400 Pavel Roskin <[EMAIL PROTECTED]> wrote: > On Wed, 2008-07-16 at 01:32 +0200, Yoshinori K. Okuji wrote: > > > If a boot drive is the same as a root drive, you are right. > > Otherwise we need to do so. > > > > I think we have seen tons of examples with GRUB Legacy which may > > not be solved automatically in all cases. If one digs into the > > archive of bug-grub, I guess several cases would be found easily. > > With GRUB 2, we can avoid embedding BIOS drive numbers in many > > cases, using UUIDs or labels or files. But this does not always > > work, so I am afraid that we need to support device.map, even if it > > is an evil necessity. > > That's a very advanced setup. I actually cannot imagine why anyone > would use different boot and root drives. Well, maybe the boot drive > has no partitions that GRUB or the host OS can access? I have used machines that have multiple Linux versions spread across two drives, but one common /boot partition so they can all be booted from GRUB. This doesn't seem unusual to me. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
GRUB2 cannot mount correct NTFS-partition
Hi! I get strange problem, using grub2-current (and last releases as well) - ntfs partition cannot be mounted due to incorrect MFT size. After grub_printf() debug i collect some data: MFT_SIZE = 1968 (too big!) = cluster_per_mft (246) * spc (8) It looks like incorrect value :( but i get the same result on number of my ntfs partitions. Partitions can be mounted in linux/windows without any problems. What data should i collect to fully describe my problem? Thanks! ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
