memory allocator enhancements...
Hi All, I have been thinking on how to improve memory allocator (thou hasn't got too much time lately to play with it) so it could aid in following scenarios: 1. Move VBE BIOS thunks or other code from kernel to actual driver - specially named segment that gets allocated to lowmem in order to call VBE BIOS extensions - These should be located right after kernel in lowmem - Seems to be a bit tricky to patch relocation info properly (at least this is what I was last debugging). Ideas are welcome. Perhaps my code was not just modified properly... 2. Allocate memory for BIOS extensions in order to support BIOS drive mapping and El Torito or what ever someone needs. - Probably need to make hole to memory map that is passed to OS so allocated memory needs to be at end of lowmem so no holes within low memory are present - Perhaps this should be only done at last step of boot process. Eg allocate first memory to high mem and then when boot decision has been made, then allocate to low mem and make necessary hooks 3. Load OS image at start of highmem. I do not remember which OS needed this thou... 4. Allocate memory for GRUB code/modules/data. This can be at end of highmem. Are there any other needs? So what does people feel about these changes. I am afraid if too much freedom is given it will make it complex... Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: memory allocator enhancements...
Hello, one additional consideration is to let grub2 stay in memory even after OS loads. This way it would be possibly to expose any file/partition accessible through grub2 system as a virtual int13h disk. For this to be a it's very desirable to put all modules that may need to stay, the kernel and corresponding memory at the end of lowmem/uppermem. For OS loading memory at fixed address may be allocated by functions like grub_claimmap on ieee1275 (I have some code in this direction in my patch "multiboot on EFI") Another idea is to allocate invalidatable blocks like disk cache in the middle of the memory. It would decrease the memory fragmentation and if it conflicts with any other allocation it can be easily invalidated Vesa Jääskeläinen wrote: - Seems to be a bit tricky to patch relocation info properly (at least this is what I was last debugging). Ideas are welcome. Perhaps my code was not just modified properly... In my efiemu patch I needed to do some similar things (virtual addressing code vs physical addressing code). You may look at my efiemu patch 2. Allocate memory for BIOS extensions in order to support BIOS drive mapping and El Torito or what ever someone needs. - Probably need to make hole to memory map that is passed to OS so allocated memory needs to be at end of lowmem so no holes within low memory are present I propose to integrate this with grub_machine_mmap_iterate. It would be like grub_mmap_iterate - similar to grub_machine_mmap_iterate but with holes created by grub itself grub_mmap_register (start,length, type) - create a memory block of type TYPE. This way all loaders will pass "perforated" map to their kernels. As for kernels using BIOS I would code int15 handler. - Perhaps this should be only done at last step of boot process. Eg allocate first memory to high mem and then when boot decision has been made, then allocate to low mem and make necessary hooks The patch to do this "preboot hooks" is pending since september Are there any other needs? For xnu resume to work fine I need to allocate a huge chunk of memory for hibernate image (whole memory minus few MB). It can be anywhere but must be contiguous. So what does people feel about these changes. I am afraid if too much freedom is given it will make it complex... Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 svn2059
BandiPat schrieb: Thanks Andreas, I just figured that out as well when testing on another machine just now. If you still have the file I sent you for svn2059, would you mind testing it on your machine as well. I'm tempted to send you the svn2059 or 2065 to compile on your current machine, to see if it behaves differently than the one I built. Be prepared though, as I'm sure you'll need to re-install svn2031 back after 2059 fails to boot. Keep your LiveCD available to reboot! :-) I tested the svn2059-60.1 build on my current Zenwalk installation. It would boot here, but I have it installed to superblock of my ext3 partition, so that might be the difference. Therefore I installed grub2 to the MBR, but like that it would work too. But I noticed two other problems: * If I drop to console with 'c' from the menu and then reload the menu with 'configfile (hd0,3)/boot/grub/grub.cfg', 'prefix' is unset and I can't boot. If I drop then back to console I can set 'prefix' properly to '(hd0,3)/boot/grub' and boot from console, but configfile won't work. * With the 'linux' loader as opposed to the 'linux16' loader, I would always get a verbose splash, although I force a silent one with 'splash=silent'. My assumption was that the kernel parameters are ignored at all, but passing a wrong root resulted in a error. So either only 'splash=silent' is ignored or its something completely different. I think the problem is related to the one described in "New linux loader doesn't like vga=1". Andreas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of normal mode (version 2)
On Saturday 04 April 2009 08:02:40 Colin D Bennett wrote: > What if you switch back and forth between normal and rescue mode > many times in a row? The stack will grow with each call and eventually > the stack will overflow and Bad Things will happen. Yes. > Now you could also return function pointers instead of using > switch/case with enum constants, but it's the same concept. Then > setjmp is another similar way to do it without implementing a central > dispatcher like grub_main above. Exactly. For those who know the concept of continuation, setjmp/longjmp is very handy. This makes some kind of programs to be written easily and simply. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of normal mode (version 2)
On Saturday 04 April 2009 14:06:18 Bean wrote: > One of the problem for normal.mod dependency is its side effect. For > example, currently ls.mod depend on normal.mod just for > grub_normal_print_device_info. If we want to embed ls.mod in core.img, > we must embedded normal.mod as well, along with a lot of > initialization actions that we may not want. Right, if we can completely merge the ls on rescue mode and that on normal mode. For now, I am not sure if this is feasible, so I prefer to keep a poor version of ls for rescue mode, which does not require functions in normal.mod, until you prove that that is feasible. > We can generate a handler.lst by scanning source for > grub_parser_register, etc, just like commands.lst: > > parser.sh: sh > reader.normal: normal > menu.textmenu: textmenu > terminal_outout.gfxterm: gfxterm > > We can then read it in normal.mod and set the hooks for all handler > classes. I like if you can merge all kinds of handlers this way, thus eliminating the command.lst and the fs.lst. But I still think that having commands for parsers and menus, since you can do: grub> sh /boot/grub/foo.sh grub> textmenu grub> gfxmenu They won't be very useful for most people, but could be useful for development. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] FAT, UFS and mtime
On Saturday 04 April 2009 18:21:40 phcoder wrote: > Can someone review this patch? Looks good to me. Thanks, Okuji > phcoder wrote: > > mtime part > > 2009-03-15 Vladimir Serbinenko > > > > Support for mtime and further expandability of dir command > > > > * include/grub/lib/datetime.h: moved to ... > > * include/grub/datetime.h: ... moved here and added > > declaration of grub_unixtime2datetime. All users updated > > * include/grub/fs.h: new syntax for dir and mtime functionin > > struct grub_fs > > * include/grub/fshelp.h: new declarations of GRUB_FSHELP_TYPE_MASK > > and GRUB_FSHELP_FLAGS_MASK > > * commands/ls.c (grub_ls_list_files): Write mtime in long format > > * fs/ext2.c (grub_ext2_dir): use new dir syntax and supply mtime > > (grub_ext2_mtime): new function > > * fs/hfsplus.c (grub_hfsplus_dir): use new dir syntax and supply > > mtime (grub_hfsplus_mtime): new function > > * fs/ufs.c (GRUB_UFS_ATTR_TYPE): new definition > > (GRUB_UFS_ATTR_FILE): likewise > > (GRUB_UFS_ATTR_LNK): likewise > > (struct grub_ufs_sblock): new fields mtime > > (grub_ufs_read_inode): new parameter to read inode to a separate > > buffer all users updated > > (grub_ufs_dir): mtime support > > (grub_ufs_mtime): new function > > * fs/affs.c (grub_affs_dir): use new dir syntax > > * fs/afs.c (grub_afs_dir): likewise > > * fs/cpio.c (grub_cpio_dir): likewise > > * fs/fat.c (grub_fat_find_dir): likewise > > * fs/hfs.c (grub_hfs_dir): likewise > > * fs/iso9660.c (grub_iso9660_dir): likewise > > * fs/jfs.c (grub_jfs_dir): likewise > > * fs/minix.c (grub_minix_dir): likewise > > * fs/ntfs.c (grub_ntfs_dir): likewise > > * fs/reiserfs.c (grub_reiserfs_dir): likewise > > * fs/sfs.c (grub_sfs_dir): likewise > > * fs/xfs.c (grub_xfs_dir): likewise > > * util/hostfs.c (grub_hostfs_dir): likewise > > * lib/datetime.c: moved to ... > > * normal/datetime.c: ... moved here > > (grub_unixtime2datetime): new function > > * kern/rescue.c (grub_rescue_print_files): use new dir syntax > > * normal/completition.c (iterate_dir): use new dir syntax > > * normal/misc.c (grub_normal_print_device_info): tell the > > last modification time of a volume > > * kern/fs.c (grub_fs_probe): updated dummy function to use new syntax > > * conf/i386-coreboot.rmk: added normal/datetime.c to grub-emu > > and normal.mod. Removed lib/datetime.c from datetime.mod > > * conf/i386-efi.rmk: likewise > > * conf/i386-ieee1275.rmk: likewise > > * conf/i386-pc.rmk: likewise > > * conf/powerpc-ieee1275.rmk: likewise > > * conf/sparc64-ieee1275.rmk: likewise > > * conf/x86_64-efi.rmk: likewise > > > > Robert Millan wrote: > >> On Sun, Mar 01, 2009 at 05:25:10PM +0100, phcoder wrote: > >>> Hello all. It seems that gcc has trouble with -m32 when structure is > >>> passed as argument. So I replaced that part by a pointer. Also I > >>> made some improvements to ufs code to support solaris branch of ufs. > >>> I tested it also with freebsd and netbsd's branch and it works fine > >>> on it too. > >>> As my 3 FS patches: mtime, FAT and UFS are interdependent I submit a > >>> patch with all 3 features. If it's really necessary I can split them > >>> but it requires a lot of unnecessary work > >> > >> Please do. It is definitely confusing to review patches that merge > >> unrelated things. > >> > >> Also, please don't include the changelog entry in your patch, since > >> those break too easily. Just paste it at the top of your mail. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] parttool
On Saturday 04 April 2009 18:22:39 phcoder wrote: > Can someone review this patch? Only some style should be corrected. For example: +#ifndef GRUB_UTIL + if (!parts) +grub_dl_unref (mymod); +#endif Our convention is to put a space between "!" and "parts", so this should be: +#ifndef GRUB_UTIL + if (! parts) +grub_dl_unref (mymod); +#endif Also, the ChangeLog should state what variables are affected explicitly. For example: * conf/common.rmk: Added parttool.mod and pcpart.mod Instead, you should say: * conf/common.rmk (parttool_mod_SOURCES): New variable. (parttool_mod_CFLAGS): Likewise. (parttool_mod_LDFLAGS): Likewise. ...and so on... The code itself looks good, so you can check it in, once you correct the styles. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of normal mode (version 2)
On Sun, Apr 5, 2009 at 10:33 PM, Yoshinori K. Okuji wrote: > On Saturday 04 April 2009 14:06:18 Bean wrote: >> One of the problem for normal.mod dependency is its side effect. For >> example, currently ls.mod depend on normal.mod just for >> grub_normal_print_device_info. If we want to embed ls.mod in core.img, >> we must embedded normal.mod as well, along with a lot of >> initialization actions that we may not want. > > Right, if we can completely merge the ls on rescue mode and that on normal > mode. For now, I am not sure if this is feasible, so I prefer to keep a poor > version of ls for rescue mode, which does not require functions in > normal.mod, until you prove that that is feasible. > Hi, Currently, this is implemented using priority list. The commands has a field that indicate its priority. For normal command, the value is 0, for extended command, it's 1. So if two version of ls is loaded, the extended ls would be used. All commands are in a unify set, so you can run normal commads/extended commands in either rescue or normal mode. >> We can generate a handler.lst by scanning source for >> grub_parser_register, etc, just like commands.lst: >> >> parser.sh: sh >> reader.normal: normal >> menu.textmenu: textmenu >> terminal_outout.gfxterm: gfxterm >> >> We can then read it in normal.mod and set the hooks for all handler >> classes. > > I like if you can merge all kinds of handlers this way, thus eliminating the > command.lst and the fs.lst. > > But I still think that having commands for parsers and menus, since you can > do: > > grub> sh /boot/grub/foo.sh > grub> textmenu > grub> gfxmenu > > They won't be very useful for most people, but could be useful for > development. Yeah, that's possible. We can register a generic command to do the task. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Move loader.c out of the kernel
On the IRC Yoshinori K. Okuji agreed that this move can be useful in cases like lvm+raid and luks. Any further oppositions? phcoder wrote: I was thinking about something more finished like the possibility of handling multiple preboot and to undo the operations in case of failed or returned boot. Potentially it could be moved to a separate module but it results in a reverse dependency and somewhat ugly code Vesa Jääskeläinen wrote: phcoder wrote: This usage case isn't the main target case. If you embed the loader (which tend to be quite big) then you already have an overhead from loader module. Why are you so concerned with overhead of boot.mod? But on the other hand this forces all the people in other cases to have boot code in core.img. I want to add preboot hooks and don't want increment size of kernel. multiboot.mod currently increases the size by around 11KB. And my patch doesn't restrict you from putting loader in core.img in any way Even if you add the preboot hooks there, it should only cause size affect in couple of bytes for uncompressed image. Like in following "sketch": ... preboot_handler_address: dd 0 ... cmp [preboot_handler_address], 0 je no_preboot_handler call [preboot_handler_address] no_preboot_handler: ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] mtools-like FAT-label behaviour
Commited phcoder wrote: Bean already said on IRC that this patch is fine with him. If I don't recieve any oppositions in 1 week I consider this patch ok for committment phcoder wrote: Applies fine to last SVN phcoder wrote: With this patch fat became case-sensitive which is probably wrong. Corrected version of patch attached Sorry Vladimir 'phcoder' Serbinenko phcoder wrote: Hello. Now the handling of FAT-labels keeps the trailing spaces and ignores VFAT label generated by mlabel tool. Here is the patch to correct this. Unfortunately m$ when user set a mixed case label only uppercase one is saved to FS, moreover m$ keeps the mixed case label in the registry fooling the user. So no way to read these. To test mixed case labels be sure that mlabel reports it as mixed case. Thanks Vladimir 'phcoder' Serbinenko -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of normal mode (version 2)
On Monday 06 April 2009 00:02:59 Bean wrote: > On Sun, Apr 5, 2009 at 10:33 PM, Yoshinori K. Okuji wrote: > > On Saturday 04 April 2009 14:06:18 Bean wrote: > >> One of the problem for normal.mod dependency is its side effect. For > >> example, currently ls.mod depend on normal.mod just for > >> grub_normal_print_device_info. If we want to embed ls.mod in core.img, > >> we must embedded normal.mod as well, along with a lot of > >> initialization actions that we may not want. > > > > Right, if we can completely merge the ls on rescue mode and that on > > normal mode. For now, I am not sure if this is feasible, so I prefer to > > keep a poor version of ls for rescue mode, which does not require > > functions in normal.mod, until you prove that that is feasible. > > Hi, > > Currently, this is implemented using priority list. The commands has a > field that indicate its priority. For normal command, the value is 0, > for extended command, it's 1. So if two version of ls is loaded, the > extended ls would be used. All commands are in a unify set, so you can > run normal commads/extended commands in either rescue or normal mode. Great. As long as we can use a smaller (so more stupid) version of ls, I have no objection. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
on splitting modules
Hello, I have written an article on the wiki right now: http://grub.enbug.org/OnSplittingModules This article is based on our discussion on the IRC. I think the disagreement between Bean and me derived from that I didn't know his ultimate goal, and actually I investigated the same idea as him a long time ago. Now, I am very excited with his work, and I hope he will succeed. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
crypto space considerations (Re: Current state of grub2 encryption support)
As I already stated on the IRC libgcrypt modules are optimized for speed and not the performance (e.g. main loop of sha1 is repeated multiple times with minor modifications to avoid if's). Generally it's ok to optimize for speed but in context of embedding size is more important. On the other hand some OSes require grub to load big files (e.g. solaris requires 70 MB). On powerful CPUs speed optimization doesn't play any role since bottleneck is the I/O. However in the case of low-powered CPUs it may make a difference. One possibility is to have 2 modules: one size and one speed optimized and to dynamically switch between them. In this case size-optimized versions can be even written in asm since space isn't an issue on supported non-i386 platforms (but it may change in the future). In any case I think we should keep speed-optimized versions of ciphers for which we have no size-optimized variant phcoder wrote: Michael Gorven wrote: On Tuesday 31 March 2009 10:50:57 phcoder wrote: How big is your core.img? With the following modules (untested), 61K. configfile sha1 biosdisk pc linux ext2 minicmd crypto aes luks sha256 You don't need to embed linux.mod to the kernel, it can very weel be loaded from encrypted partition. configfile and luks depend on normal.mod. It shouldn't be the case. configfile shouldn't be needed in this context at all. minicmd isn't needed either luks should be able to retrieve the password without using normal mode. Using grub_cmdline_get for retrieving password is IMO wrong. It has features like kill and yank which nobody needs when entering password. Also it adds the password to the history When I commented out the line in luks.c to retrieve the password (to remove normal.mod dependency), apply my bootmove patch with following modules: biosdisk pc ext2 crypto aes sha256 luks sha1 I get a core.img of the size 40992 bytes. While still 9248 bytes bigger then the mbr gap (31744) it's already nearer to the goal Alternatively it's possible to embed grub in the space reserved for future AF stripes of unused key slot. The disadvantage is the need to reinstall after key change. IMO this way shouldn't be taken. But we can contact LUKS people and ask them to add embeding space for grub2. It's enough to just shift everything by 1 MiB on devices bgger then 256 MiB, and by 256 Kib on devices bigger then 64 MiB (can be overriden at format time), then make luks code look for the header at 0, 256KiB and 1 MiB ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2
These issues still remain phcoder wrote: Hello I was looking into multiboot2 specifications and have some suggestions: 1) double the size of flags. 8 features per category seems to be few. it could even be made completely expandable by the following format: ... 2) "All undefined flags *should* be set to zero for future use. " IMO in this place all OSes should be required to follow this rule in current terminology it would be "must" 3) "The physical address to which the boot loader should jump in order to start running the operating system." In current terminology should make no real sense here 4) "This tag should contain a string that enables operating systems to distinguish between different bootloaders and different versions of the same bootloader." Parsing strings may be difficult. Perhaps we could include a version tag with a format dependent on bootloader and optionally a requirement that higher numbers are newer versions? 5)memory map: "The order of memory maps is not guaranteed but a boot loader should sort the items based on the starting addresses. " I don't like the optionality of this rule if it's included in specifications it should be either required or dropped altogether. Otherwise we risk to have OSes which rely on sorting and bootloaders which doesn't sort. I'm personally for making it mandatory for reasons similar to next entry 6) memory map. " Tags of this type should be omitted on architectures where the OS is able to retrieve this information from firmware. (Doing do will encourage OS portability across bootloaders, and simplify GRUB development and maintenance.) " This contradicts the goal of easier OS developement and may result in semi-compatible OS and bootloaders. Additionally I think that eliminating the necessity of use of firmware from OS is a good thing and allows easier porting between architectures differing only by firmware 7) Command line tag. I propose to reserve the identifier 0x0005 for command line and make it the same format as "Boot Loader Name" but arguments shouldn't include kernel image name. This way we would prevent OSes from trying to access this file by bootloader-specific name. In addition in both "Boot Loader Name" and "Command-line" we should specify the encoding to be utf-8 -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 svn2059
Andreas Born wrote: BandiPat schrieb: Thanks Andreas, I just figured that out as well when testing on another machine just now. If you still have the file I sent you for svn2059, would you mind testing it on your machine as well. I'm tempted to send you the svn2059 or 2065 to compile on your current machine, to see if it behaves differently than the one I built. Be prepared though, as I'm sure you'll need to re-install svn2031 back after 2059 fails to boot. Keep your LiveCD available to reboot! :-) I tested the svn2059-60.1 build on my current Zenwalk installation. It would boot here, but I have it installed to superblock of my ext3 partition, so that might be the difference. Therefore I installed grub2 to the MBR, but like that it would work too. But I noticed two other problems: * If I drop to console with 'c' from the menu and then reload the menu with 'configfile (hd0,3)/boot/grub/grub.cfg', 'prefix' is unset and I can't boot. If I drop then back to console I can set 'prefix' properly to '(hd0,3)/boot/grub' and boot from console, but configfile won't work. * With the 'linux' loader as opposed to the 'linux16' loader, I would always get a verbose splash, although I force a silent one with 'splash=silent'. My assumption was that the kernel parameters are ignored at all, but passing a wrong root resulted in a error. So either only 'splash=silent' is ignored or its something completely different. I think the problem is related to the one described in "New linux loader doesn't like vga=1". Andreas = Ok, I'm not sure I understand what all of this means, except the part that you mentioned it worked for you. That at least tells me the build is not bad. Since I don't presently have a current 6.0 setup, I can't test that right now, but will do a new install so I can. I've never installed to the superblock, just the mbr, but I'll assume that's not the problem, since you seem to have gotten both to work. As I mentioned, I have tried this on two snapshot systems, where both have failed using 2059 or above. Since you haven't tried it on your snapshot, and this file will work there as well because the only difference is I compiled one as 686 the other 486. I would be interested to know your results there as well. I've got an idea I'm going to try, but not sure it will make a difference. Thus far, I've been using the previous grub.cfg created by 2031, so I think I'll try to let 2059 create a new one. Again not sure it would make a difference because it appears the loader is not getting to the grub.cfg before it fails. Thanks, Pat ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
grub2 and network boot
Hello All, Forgive me for asking a newb question, but could someone please tell me how to configure grub2 to do either a TFTP or NFS boot? I am assuming this functionality exists in grub2. I'm working with a 686 processor and a Realtek 8169 PHY. Any pointers would be greatly appreciated. Thanks, Dallas Clement ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 and network boot
On Sun, 2009-04-05 at 22:47 -0500, Dallas Clement wrote: > Hello All, > > Forgive me for asking a newb question, but could someone please tell > me how to configure grub2 to do either a TFTP or NFS boot? I am > assuming this functionality exists in grub2. > > I'm working with a 686 processor and a Realtek 8169 PHY. GRUB2 has no networking support yet. It is planned, but the current status is "looking for members": http://grub.enbug.org/Subprojects -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 and network boot
Okay, Thank you for the speedy reply! On Sun, Apr 5, 2009 at 10:52 PM, Pavel Roskin wrote: > On Sun, 2009-04-05 at 22:47 -0500, Dallas Clement wrote: >> Hello All, >> >> Forgive me for asking a newb question, but could someone please tell >> me how to configure grub2 to do either a TFTP or NFS boot? I am >> assuming this functionality exists in grub2. >> >> I'm working with a 686 processor and a Realtek 8169 PHY. > > GRUB2 has no networking support yet. It is planned, but the current > status is "looking for members": http://grub.enbug.org/Subprojects > > -- > Regards, > Pavel Roskin > > > ___ > 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
