From nobody@FreeBSD.org Tue Dec 9 17:10:26 2008 Return-Path: Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD9EF1065672 for ; Tue, 9 Dec 2008 17:10:26 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id BD5E68FC1D for ; Tue, 9 Dec 2008 17:10:26 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mB9HAQJ3067016 for ; Tue, 9 Dec 2008 17:10:26 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id mB9HAQqK067015; Tue, 9 Dec 2008 17:10:26 GMT (envelope-from nobody) Message-Id: <200812091710.mB9HAQqK067015@www.freebsd.org> Date: Tue, 9 Dec 2008 17:10:26 GMT From: Hiroharu Tamaru To: freebsd-gnats-submit@FreeBSD.org Subject: pxeboot fails to load kernel / modules X-Send-Pr-Version: www-3.1 X-GNATS-Notify: >Number: 129526 >Category: kern >Synopsis: pxeboot(8) fails to load kernel / modules >Confidential: no >Severity: serious >Priority: low >Responsible: jhb >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Dec 09 17:20:01 UTC 2008 >Closed-Date: Fri Mar 20 15:36:50 UTC 2009 >Last-Modified: Fri Mar 20 15:36:50 UTC 2009 >Originator: Hiroharu Tamaru >Release: 7.1-RC1-i386 >Organization: The University of Tokyo >Environment: Pentium 4 (pre EM64T), Supermicro M/B, Award BIOS, onborad em NIC >Description: PXE booting the 7.1-RC1-i386 installer fails to boot the kernel. The setup is 7.1-RC1-i386-disc1.iso extracted on an ftp server, and boot/pxeboot included in this image served by a tftp server. The DHCP server instructs the target machine to pick this pxeboot and mount the ftp exported iso image as root. With older releases like 6.x, breaking out into loader prompt at the beastie menu, and typing: set vfs.root.mountfrom="ufs:/dev/md0c" followed by 'boot' would start the kernel and invoke the installer. However, with 7.1-RC, at the time the loader tries to load mfsroot, it fails and says that root filesystem is not found. lsdev or ls at this point locks the system up. It turns out that replacing the pxeboot binary served by tftp to pxeboot in 6.4-RELEASE-i386-bootonly.iso allows the installer to boot properly, but pxeboot from 7.0-RELEASE also fails. It then turned out that by unzipping the /boot/mfsroot.gz image on the ftp server allows the kernel to boot, for any of the pxeboot's mentioned above. Thus it seems likely that the unzipping routines in pxeboot, or more precisely, the loader included in the pxeboot, is corrupting some part of the device table or such. This could be system BIOS / PXE BIOS dependent issue, but I have not investigated any further at this moment. Further details / tests / trials available on request. >How-To-Repeat: Setup a PXE boot environment described as above, and try to boot into the installer. >Fix: Workarounds are to gunzip the boot/mfsroot.gz file, or to use pxeboot from 6.4-RELEASE. >Release-Note: >Audit-Trail: From: Hiroharu Tamaru To: John Baldwin Cc: sobomax@freebsd.org, pjd@freebsd.org Subject: Re: kern/129526: pxeboot fails to load kernel / modules Date: Wed, 10 Dec 2008 18:20:31 +0900 Thank you, John. At Tue, 9 Dec 2008 16:21:47 -0500, John Baldwin wrote: > > On Tuesday 09 December 2008 12:54:06 pm Hiroharu Tamaru wrote: (snip) > > It turns out that replacing the pxeboot binary served by tftp > > to pxeboot in 6.4-RELEASE-i386-bootonly.iso allows the installer > > to boot properly, but pxeboot from 7.0-RELEASE also fails. > > > > It then turned out that by unzipping the /boot/mfsroot.gz image > > on the ftp server, it allows the kernel to boot, for any of the pxeboot's > > mentioned above. > > > > Thus, it seems likely that the unzipping routines in pxeboot, > > or more precisely, the loader included in the pxeboot, > > is corrupting some part of the device table or such. (snip) > I think loader has just grown and the stack is growing into the heap. There > is a loader option to move the heap up above 1 MB that you should try. Indeed, it was. (for the record:) Enabling the code in sys/boot/i386/loader/main.c that is activated by putting either of: LOADER_BZIP2_SUPPORT=yes LOADER_FIREWIRE_SUPPORT=yes LOADER_ZFS_SUPPORT=yes (8.0-current only ATM) into /etc/make.conf has solved the problem. Current pxeboot build pulls the loader binary built for the (non-pxe-)loader verbatim. Is there a possibility that putting the heap above 1MB might become the default in the near future? say, whenever LOAD_NO_GZIP_SUPPORT is not set. Alternatively, do you think it is worth a trouble to modifiy the build system so that the default pxeboot has this high heap support? Or, would you think whoever setting up an pxeboot installer should know the corners, and either unzip the mfsroot.gz or rebuild his own pxeboot? Thanks. Hiroharu From: John Baldwin To: Hiroharu Tamaru Cc: sobomax@freebsd.org, pjd@freebsd.org, FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/129526: pxeboot fails to load kernel / modules Date: Wed, 10 Dec 2008 14:51:48 -0500 On Wednesday 10 December 2008 04:20:31 am Hiroharu Tamaru wrote: > Thank you, John. > > At Tue, 9 Dec 2008 16:21:47 -0500, John Baldwin wrote: > > > > On Tuesday 09 December 2008 12:54:06 pm Hiroharu Tamaru wrote: > (snip) > > > It turns out that replacing the pxeboot binary served by tftp > > > to pxeboot in 6.4-RELEASE-i386-bootonly.iso allows the installer > > > to boot properly, but pxeboot from 7.0-RELEASE also fails. > > > > > > It then turned out that by unzipping the /boot/mfsroot.gz image > > > on the ftp server, it allows the kernel to boot, for any of the pxeboot's > > > mentioned above. > > > > > > Thus, it seems likely that the unzipping routines in pxeboot, > > > or more precisely, the loader included in the pxeboot, > > > is corrupting some part of the device table or such. > (snip) > > I think loader has just grown and the stack is growing into the heap. There > > is a loader option to move the heap up above 1 MB that you should try. > > Indeed, it was. > > (for the record:) > Enabling the code in sys/boot/i386/loader/main.c > that is activated by putting either of: > LOADER_BZIP2_SUPPORT=yes > LOADER_FIREWIRE_SUPPORT=yes > LOADER_ZFS_SUPPORT=yes (8.0-current only ATM) > into /etc/make.conf has solved the problem. > > > Current pxeboot build pulls the loader binary built for > the (non-pxe-)loader verbatim. > > Is there a possibility that putting the heap above 1MB > might become the default in the near future? say, whenever > LOAD_NO_GZIP_SUPPORT is not set. > > Alternatively, do you think it is worth a trouble to modifiy > the build system so that the default pxeboot has this high > heap support? > > Or, would you think whoever setting up an pxeboot installer > should know the corners, and either unzip the mfsroot.gz or > rebuild his own pxeboot? I think adding GPT support (which I did) probably caused the loader to grow enough in size. Probably I should make the GPT stuff optional and enable the higher memory usage if it is enabled (but make it on by default perhaps?) -- John Baldwin From: Hiroharu Tamaru To: John Baldwin Cc: sobomax@freebsd.org, pjd@freebsd.org, FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/129526: pxeboot fails to load kernel / modules Date: Sat, 13 Dec 2008 17:08:51 +0900 At Wed, 10 Dec 2008 14:51:48 -0500, John Baldwin wrote: > > On Wednesday 10 December 2008 04:20:31 am Hiroharu Tamaru wrote: > > Thank you, John. > > > > At Tue, 9 Dec 2008 16:21:47 -0500, John Baldwin wrote: > > > > > > On Tuesday 09 December 2008 12:54:06 pm Hiroharu Tamaru wrote: > > (snip) > > > > It turns out that replacing the pxeboot binary served by tftp > > > > to pxeboot in 6.4-RELEASE-i386-bootonly.iso allows the installer > > > > to boot properly, but pxeboot from 7.0-RELEASE also fails. > > > > > > > > It then turned out that by unzipping the /boot/mfsroot.gz image > > > > on the ftp server, it allows the kernel to boot, for any of the > pxeboot's > > > > mentioned above. > > > > > > > > Thus, it seems likely that the unzipping routines in pxeboot, > > > > or more precisely, the loader included in the pxeboot, > > > > is corrupting some part of the device table or such. > > (snip) > > > I think loader has just grown and the stack is growing into the heap. > There > > > is a loader option to move the heap up above 1 MB that you should try. > > > > Indeed, it was. > > > > (for the record:) > > Enabling the code in sys/boot/i386/loader/main.c > > that is activated by putting either of: > > LOADER_BZIP2_SUPPORT=yes > > LOADER_FIREWIRE_SUPPORT=yes > > LOADER_ZFS_SUPPORT=yes (8.0-current only ATM) > > into /etc/make.conf has solved the problem. > > > > > > Current pxeboot build pulls the loader binary built for > > the (non-pxe-)loader verbatim. > > > > Is there a possibility that putting the heap above 1MB > > might become the default in the near future? say, whenever > > LOAD_NO_GZIP_SUPPORT is not set. > > > > Alternatively, do you think it is worth a trouble to modifiy > > the build system so that the default pxeboot has this high > > heap support? > > > > Or, would you think whoever setting up an pxeboot installer > > should know the corners, and either unzip the mfsroot.gz or > > rebuild his own pxeboot? > > I think adding GPT support (which I did) probably caused the loader to grow > enough in size. Probably I should make the GPT stuff optional and enable the > higher memory usage if it is enabled (but make it on by default perhaps?) I agree that's quite reasonable (wrapping around GPT, and default it to on). I looked into the sources, but to me, wrapping all the bits on GPT with #ifdef LOADER_GPT_SUPPORT was not too trivial. How trivial or non-trivial is it if I asked you for it? I'll look into it again when I get another time slot if you are too busy until then. Thanks. Hiroharu From: John Baldwin To: Hiroharu Tamaru Cc: sobomax@freebsd.org, pjd@freebsd.org, FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/129526: pxeboot fails to load kernel / modules Date: Mon, 2 Mar 2009 13:53:21 -0500 On Saturday 13 December 2008 3:08:51 am Hiroharu Tamaru wrote: > At Wed, 10 Dec 2008 14:51:48 -0500, > John Baldwin wrote: > > > > On Wednesday 10 December 2008 04:20:31 am Hiroharu Tamaru wrote: > > > Thank you, John. > > > > > > At Tue, 9 Dec 2008 16:21:47 -0500, John Baldwin wrote: > > > > > > > > On Tuesday 09 December 2008 12:54:06 pm Hiroharu Tamaru wrote: > > > (snip) > > > > > It turns out that replacing the pxeboot binary served by tftp > > > > > to pxeboot in 6.4-RELEASE-i386-bootonly.iso allows the installer > > > > > to boot properly, but pxeboot from 7.0-RELEASE also fails. > > > > > > > > > > It then turned out that by unzipping the /boot/mfsroot.gz image > > > > > on the ftp server, it allows the kernel to boot, for any of the > > pxeboot's > > > > > mentioned above. > > > > > > > > > > Thus, it seems likely that the unzipping routines in pxeboot, > > > > > or more precisely, the loader included in the pxeboot, > > > > > is corrupting some part of the device table or such. > > > (snip) > > > > I think loader has just grown and the stack is growing into the heap. > > There > > > > is a loader option to move the heap up above 1 MB that you should try. > > > > > > Indeed, it was. > > > > > > (for the record:) > > > Enabling the code in sys/boot/i386/loader/main.c > > > that is activated by putting either of: > > > LOADER_BZIP2_SUPPORT=yes > > > LOADER_FIREWIRE_SUPPORT=yes > > > LOADER_ZFS_SUPPORT=yes (8.0-current only ATM) > > > into /etc/make.conf has solved the problem. > > > > > > > > > Current pxeboot build pulls the loader binary built for > > > the (non-pxe-)loader verbatim. > > > > > > Is there a possibility that putting the heap above 1MB > > > might become the default in the near future? say, whenever > > > LOAD_NO_GZIP_SUPPORT is not set. > > > > > > Alternatively, do you think it is worth a trouble to modifiy > > > the build system so that the default pxeboot has this high > > > heap support? > > > > > > Or, would you think whoever setting up an pxeboot installer > > > should know the corners, and either unzip the mfsroot.gz or > > > rebuild his own pxeboot? > > > > I think adding GPT support (which I did) probably caused the loader to grow > > enough in size. Probably I should make the GPT stuff optional and enable the > > higher memory usage if it is enabled (but make it on by default perhaps?) > > I agree that's quite reasonable (wrapping around GPT, and default it to on). > > I looked into the sources, but to me, wrapping all the bits on GPT with > #ifdef LOADER_GPT_SUPPORT was not too trivial. > How trivial or non-trivial is it if I asked you for it? > I'll look into it again when I get another time slot if > you are too busy until then. I finally did this today. You can try http://www.freebsd.org/~jhb/patches/boot_gpt.patch If you can verify it works for you I will commit it. -- John Baldwin From: Hiroharu Tamaru To: John Baldwin Cc: sobomax@freebsd.org, pjd@freebsd.org, FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/129526: pxeboot fails to load kernel / modules Date: Sun, 08 Mar 2009 03:01:05 +0900 Thanks, John, for taking your time for this. At Mon, 2 Mar 2009 13:53:21 -0500, John Baldwin wrote: > > On Saturday 13 December 2008 3:08:51 am Hiroharu Tamaru wrote: > > At Wed, 10 Dec 2008 14:51:48 -0500, > > John Baldwin wrote: > > > > > > On Wednesday 10 December 2008 04:20:31 am Hiroharu Tamaru wrote: > > > > Thank you, John. > > > > > > > > At Tue, 9 Dec 2008 16:21:47 -0500, John Baldwin wrote: > > > > > > > > > > On Tuesday 09 December 2008 12:54:06 pm Hiroharu Tamaru wrote: > > > > (snip) > > > > > > It turns out that replacing the pxeboot binary served by tftp > > > > > > to pxeboot in 6.4-RELEASE-i386-bootonly.iso allows the installer > > > > > > to boot properly, but pxeboot from 7.0-RELEASE also fails. > > > > > > > > > > > > It then turned out that by unzipping the /boot/mfsroot.gz image > > > > > > on the ftp server, it allows the kernel to boot, for any of the > > > pxeboot's > > > > > > mentioned above. > > > > > > > > > > > > Thus, it seems likely that the unzipping routines in pxeboot, > > > > > > or more precisely, the loader included in the pxeboot, > > > > > > is corrupting some part of the device table or such. > > > > (snip) > > > > > I think loader has just grown and the stack is growing into the heap. > > > There > > > > > is a loader option to move the heap up above 1 MB that you should try. > > > > > > > > Indeed, it was. > > > > > > > > (for the record:) > > > > Enabling the code in sys/boot/i386/loader/main.c > > > > that is activated by putting either of: > > > > LOADER_BZIP2_SUPPORT=yes > > > > LOADER_FIREWIRE_SUPPORT=yes > > > > LOADER_ZFS_SUPPORT=yes (8.0-current only ATM) > > > > into /etc/make.conf has solved the problem. > > > > > > > > > > > > Current pxeboot build pulls the loader binary built for > > > > the (non-pxe-)loader verbatim. > > > > > > > > Is there a possibility that putting the heap above 1MB > > > > might become the default in the near future? say, whenever > > > > LOAD_NO_GZIP_SUPPORT is not set. > > > > > > > > Alternatively, do you think it is worth a trouble to modifiy > > > > the build system so that the default pxeboot has this high > > > > heap support? > > > > > > > > Or, would you think whoever setting up an pxeboot installer > > > > should know the corners, and either unzip the mfsroot.gz or > > > > rebuild his own pxeboot? > > > > > > I think adding GPT support (which I did) probably caused the loader to > grow > > > enough in size. Probably I should make the GPT stuff optional and enable > the > > > higher memory usage if it is enabled (but make it on by default perhaps?) > > > > I agree that's quite reasonable (wrapping around GPT, and default it to on). > > > > I looked into the sources, but to me, wrapping all the bits on GPT with > > #ifdef LOADER_GPT_SUPPORT was not too trivial. > > How trivial or non-trivial is it if I asked you for it? > > I'll look into it again when I get another time slot if > > you are too busy until then. > > I finally did this today. You can try > http://www.freebsd.org/~jhb/patches/boot_gpt.patch > > If you can verify it works for you I will commit it. OK. I tried it, but not very good, unfortunately. First off, the sources for 7.0 is different from those for 8-current, and the diff did not apply cleanly for 7.0. Although the rejected bits were trivial to hand-apply, I decided to have a try with 8-current pxeboot. I worked with 8-current sources as of couple of weeks ago, and this time, the patch applied cleanly. Now the results: 1) The original pxeboot did not even stop by saying it cannot find the root filesystem (as I reported for 7.0RC1 pxeboot), but it silently blanked the screen out and hung the system up. --- I suppose the 8-current loader has grown even more? By the way, if mfsroot.gz is unzip'ped to mfsroot, the boot proceeds, as was so for the original 7.0RC1 pxeboot. 2) The patched pxeboot worked! -- this is good, but was quite expected, right? 3) The patched pxeboot with LOADER_NO_GPT_SUPPORT="yes" in /etc/make.conf gave the same symptom as the 7.0RC1 pxeboot: it fails for gzip'ed mfsroot.gz saying the root filesystem is not found, but succeeds for unzip'ped mfsroot . --- so, just removing the GPT parts are not enough, at least for the pxeboot in current. and finally, FWIW, 4) 7.0RC pxeboot hand-patched, and with LOADER_NO_GPT_SUPPORT="yes" also failed, just like 3). It sure helps the default pxeboot, so for me it is much better if this is commited, but what would you say? Hiroharu Tamaru State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Mon Mar 9 17:19:08 UTC 2009 State-Changed-Why: A fix (of sorts) has been committed to HEAD. Responsible-Changed-From-To: freebsd-bugs->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Mon Mar 9 17:19:08 UTC 2009 Responsible-Changed-Why: A fix (of sorts) has been committed to HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=129526 From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/129526: commit references a PR Date: Mon, 9 Mar 2009 17:19:30 +0000 (UTC) Author: jhb Date: Mon Mar 9 17:16:29 2009 New Revision: 189588 URL: http://svn.freebsd.org/changeset/base/189588 Log: - Make it possible to disable GPT support by setting LOADER_NO_GPT_SUPPORT in make.conf or src.conf. - When GPT is enabled (which it is by default), use memory above 1 MB and leave the memory from the end of the bss to the end of the 640k window purely for the stack. The loader has grown and now it is much more common for the heap and stack to grow into each other when both are located in the 640k window. PR: kern/129526 MFC after: 1 week Modified: head/sys/boot/i386/libi386/Makefile head/sys/boot/i386/libi386/biosdisk.c head/sys/boot/i386/libi386/devicename.c head/sys/boot/i386/loader/Makefile head/sys/boot/i386/loader/main.c Modified: head/sys/boot/i386/libi386/Makefile ============================================================================== --- head/sys/boot/i386/libi386/Makefile Mon Mar 9 17:09:46 2009 (r189587) +++ head/sys/boot/i386/libi386/Makefile Mon Mar 9 17:16:29 2009 (r189588) @@ -33,6 +33,10 @@ CFLAGS+= -DDISK_DEBUG CFLAGS+= -DSMBIOS_SERIAL_NUMBERS .endif +.if !defined(LOADER_NO_GPT_SUPPORT) +CFLAGS+= -DLOADER_GPT_SUPPORT +.endif + # Include simple terminal emulation (cons25-compatible) CFLAGS+= -DTERM_EMU Modified: head/sys/boot/i386/libi386/biosdisk.c ============================================================================== --- head/sys/boot/i386/libi386/biosdisk.c Mon Mar 9 17:09:46 2009 (r189587) +++ head/sys/boot/i386/libi386/biosdisk.c Mon Mar 9 17:16:29 2009 (r189588) @@ -68,12 +68,14 @@ __FBSDID("$FreeBSD$"); # define DEBUG(fmt, args...) #endif +#ifdef LOADER_GPT_SUPPORT struct gpt_part { int gp_index; uuid_t gp_type; uint64_t gp_start; uint64_t gp_end; }; +#endif struct open_disk { int od_dkunit; /* disk unit number */ @@ -90,25 +92,31 @@ struct open_disk { #define BD_FLOPPY 0x0004 #define BD_LABELOK 0x0008 #define BD_PARTTABOK 0x0010 +#ifdef LOADER_GPT_SUPPORT #define BD_GPTOK 0x0020 +#endif union { struct { struct disklabel mbr_disklabel; int mbr_nslices; /* slice count */ struct dos_partition mbr_slicetab[NEXTDOSPART]; } _mbr; +#ifdef LOADER_GPT_SUPPORT struct { int gpt_nparts; struct gpt_part *gpt_partitions; } _gpt; +#endif } _data; }; #define od_disklabel _data._mbr.mbr_disklabel #define od_nslices _data._mbr.mbr_nslices #define od_slicetab _data._mbr.mbr_slicetab +#ifdef LOADER_GPT_SUPPORT #define od_nparts _data._gpt.gpt_nparts #define od_partitions _data._gpt.gpt_partitions +#endif /* * List of BIOS devices, translation from disk unit number to @@ -130,8 +138,10 @@ static int bd_write(struct open_disk *od static int bd_int13probe(struct bdinfo *bd); +#ifdef LOADER_GPT_SUPPORT static void bd_printgptpart(struct open_disk *od, struct gpt_part *gp, char *prefix, int verbose); +#endif static void bd_printslice(struct open_disk *od, struct dos_partition *dp, char *prefix, int verbose); static void bd_printbsdslice(struct open_disk *od, daddr_t offset, @@ -163,8 +173,10 @@ static void bd_closedisk(struct open_dis static int bd_open_mbr(struct open_disk *od, struct i386_devdesc *dev); static int bd_bestslice(struct open_disk *od); static void bd_checkextended(struct open_disk *od, int slicenum); +#ifdef LOADER_GPT_SUPPORT static int bd_open_gpt(struct open_disk *od, struct i386_devdesc *dev); static struct gpt_part *bd_best_gptpart(struct open_disk *od); +#endif /* * Translate between BIOS device numbers and our private unit numbers. @@ -286,6 +298,7 @@ bd_print(int verbose) if (!bd_opendisk(&od, &dev)) { +#ifdef LOADER_GPT_SUPPORT /* Do we have a GPT table? */ if (od->od_flags & BD_GPTOK) { for (j = 0; j < od->od_nparts; j++) { @@ -293,9 +306,10 @@ bd_print(int verbose) od->od_partitions[j].gp_index); bd_printgptpart(od, &od->od_partitions[j], line, verbose); } - + } else +#endif /* Do we have a partition table? */ - } else if (od->od_flags & BD_PARTTABOK) { + if (od->od_flags & BD_PARTTABOK) { dptr = &od->od_slicetab[0]; /* Check for a "dedicated" disk */ @@ -339,6 +353,7 @@ display_size(uint64_t size) return (buf); } +#ifdef LOADER_GPT_SUPPORT static uuid_t efi = GPT_ENT_TYPE_EFI; static uuid_t freebsd_boot = GPT_ENT_TYPE_FREEBSD_BOOT; static uuid_t freebsd_ufs = GPT_ENT_TYPE_FREEBSD_UFS; @@ -380,6 +395,7 @@ bd_printgptpart(struct open_disk *od, st stats); pager_output(line); } +#endif /* * Print information about slices on a disk. For the size calculations we @@ -561,8 +577,10 @@ bd_opendisk(struct open_disk **odp, stru } /* Determine disk layout. */ +#ifdef LOADER_GPT_SUPPORT error = bd_open_gpt(od, dev); if (error) +#endif error = bd_open_mbr(od, dev); out: @@ -826,6 +844,7 @@ bd_bestslice(struct open_disk *od) return (prefslice); } +#ifdef LOADER_GPT_SUPPORT static int bd_open_gpt(struct open_disk *od, struct i386_devdesc *dev) { @@ -1003,6 +1022,7 @@ bd_best_gptpart(struct open_disk *od) } return (prefpart); } +#endif static int bd_close(struct open_file *f) @@ -1022,8 +1042,10 @@ bd_closedisk(struct open_disk *od) if (od->od_flags & BD_FLOPPY) delay(3000000); #endif +#ifdef LOADER_GPT_SUPPORT if (od->od_flags & BD_GPTOK) free(od->od_partitions); +#endif free(od); } Modified: head/sys/boot/i386/libi386/devicename.c ============================================================================== --- head/sys/boot/i386/libi386/devicename.c Mon Mar 9 17:09:46 2009 (r189587) +++ head/sys/boot/i386/libi386/devicename.c Mon Mar 9 17:16:29 2009 (r189588) @@ -120,6 +120,7 @@ i386_parsedev(struct i386_devdesc **dev, err = EUNIT; goto fail; } +#ifdef LOADER_GPT_SUPPORT if (*cp == 'p') { /* got a GPT partition */ np = cp + 1; slice = strtol(np, &cp, 10); @@ -133,6 +134,7 @@ i386_parsedev(struct i386_devdesc **dev, } partition = 0xff; } else { +#endif if (*cp == 's') { /* got a slice number */ np = cp + 1; slice = strtol(np, &cp, 10); @@ -149,7 +151,9 @@ i386_parsedev(struct i386_devdesc **dev, } cp++; } +#ifdef LOADER_GPT_SUPPORT } +#endif } else { cp = np; } @@ -227,14 +231,18 @@ i386_fmtdev(void *vdev) case DEVT_DISK: cp = buf; cp += sprintf(cp, "%s%d", dev->d_dev->dv_name, dev->d_unit); +#ifdef LOADER_GPT_SUPPORT if (dev->d_kind.biosdisk.partition == 0xff) { cp += sprintf(cp, "p%d", dev->d_kind.biosdisk.slice); } else { +#endif if (dev->d_kind.biosdisk.slice > 0) cp += sprintf(cp, "s%d", dev->d_kind.biosdisk.slice); if (dev->d_kind.biosdisk.partition >= 0) cp += sprintf(cp, "%c", dev->d_kind.biosdisk.partition + 'a'); +#ifdef LOADER_GPT_SUPPORT } +#endif strcat(cp, ":"); break; Modified: head/sys/boot/i386/loader/Makefile ============================================================================== --- head/sys/boot/i386/loader/Makefile Mon Mar 9 17:09:46 2009 (r189587) +++ head/sys/boot/i386/loader/Makefile Mon Mar 9 17:16:29 2009 (r189588) @@ -51,6 +51,9 @@ CFLAGS+= -DLOADER_BZIP2_SUPPORT .if !defined(LOADER_NO_GZIP_SUPPORT) CFLAGS+= -DLOADER_GZIP_SUPPORT .endif +.if !defined(LOADER_NO_GPT_SUPPORT) +CFLAGS+= -DLOADER_GPT_SUPPORT +.endif # Always add MI sources .PATH: ${.CURDIR}/../../common Modified: head/sys/boot/i386/loader/main.c ============================================================================== --- head/sys/boot/i386/loader/main.c Mon Mar 9 17:09:46 2009 (r189587) +++ head/sys/boot/i386/loader/main.c Mon Mar 9 17:16:29 2009 (r189588) @@ -102,7 +102,7 @@ main(void) */ bios_getmem(); -#if defined(LOADER_BZIP2_SUPPORT) || defined(LOADER_FIREWIRE_SUPPORT) || defined(LOADER_ZFS_SUPPORT) +#if defined(LOADER_BZIP2_SUPPORT) || defined(LOADER_FIREWIRE_SUPPORT) || defined(LOADER_GPT_SUPPORT) || defined(LOADER_ZFS_SUPPORT) heap_top = PTOV(memtop_copyin); memtop_copyin -= 0x300000; heap_bottom = PTOV(memtop_copyin); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From: John Baldwin To: Hiroharu Tamaru Cc: sobomax@freebsd.org, pjd@freebsd.org, FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/129526: pxeboot fails to load kernel / modules Date: Mon, 9 Mar 2009 10:01:58 -0400 On Saturday 07 March 2009 1:01:05 pm Hiroharu Tamaru wrote: > Now the results: > > 1) The original pxeboot did not even stop by saying it > cannot find the root filesystem (as I reported for 7.0RC1 > pxeboot), but it silently blanked the screen out and hung > the system up. > --- I suppose the 8-current loader has grown even more? > By the way, if mfsroot.gz is unzip'ped to mfsroot, the > boot proceeds, as was so for the original 7.0RC1 pxeboot. > > 2) The patched pxeboot worked! > -- this is good, but was quite expected, right? > > 3) The patched pxeboot with LOADER_NO_GPT_SUPPORT="yes" in > /etc/make.conf gave the same symptom as the 7.0RC1 > pxeboot: it fails for gzip'ed mfsroot.gz saying the root > filesystem is not found, but succeeds for unzip'ped > mfsroot . > --- so, just removing the GPT parts are not enough, at > least for the pxeboot in current. > > and finally, FWIW, > 4) 7.0RC pxeboot hand-patched, and with > LOADER_NO_GPT_SUPPORT="yes" also failed, just like 3). > > > It sure helps the default pxeboot, so for me it is much > better if this is commited, but what would you say? Ok, I will commit it. It seems more than just GPT bloated the size too much. I'm not sure what that could be though. -- John Baldwin From: Hiroharu Tamaru To: John Baldwin Cc: sobomax@freebsd.org, pjd@freebsd.org, FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/129526: pxeboot fails to load kernel / modules Date: Tue, 10 Mar 2009 18:24:19 +0900 At Mon, 9 Mar 2009 10:01:58 -0400, John Baldwin wrote: > On Saturday 07 March 2009 1:01:05 pm Hiroharu Tamaru wrote: > > > > It sure helps the default pxeboot, so for me it is much > > better if this is commited, but what would you say? > > Ok, I will commit it. It seems more than just GPT bloated the size too much. > I'm not sure what that could be though. Thanks for the commit. It will help our setup very much. I'll be waiting for the MFC (which I noticed in the commit message) as well. By the way, I hope this won't annoy people with small embedded machines though. I mean, could it influence loader (not the PXE one but the one used for disk boot) behavior on a small system with small memory, now that the heap is at a higher place by default? Probably, it won't matter, since those people should be tuning a whole lot of things to make it work in the first place? Anyway, thanks a lot. Hiroharu Tamaru State-Changed-From-To: patched->closed State-Changed-By: jhb State-Changed-When: Fri Mar 20 15:36:37 UTC 2009 State-Changed-Why: Merged to 6.x and 7.x. http://www.freebsd.org/cgi/query-pr.cgi?pr=129526 >Unformatted: