originally posted to amd64@freebsd.org: Hi, While trying to figure out why boot/pxeboot failes on some kernels/hosts, I think i've come up with one solid nogo, if the kernel is gzipped it always fails. Can someone confirm this? or am i suffering from some local problem? thanks, danny
Danny Braniss wrote:> originally posted to amd64@freebsd.org: > > Hi, > While trying to figure out why boot/pxeboot failes on some > kernels/hosts, I think i've come up with one solid nogo, > if the kernel is gzipped it always fails. > Can someone confirm this? or am i suffering from some > local problem?I believe I've seen this before when booting i386 kernels from soekris boards. I've taken to using pxeboot to load netboot and then use netboot to load a kernel as the netboot drivers are way faster (for soekris at least). Hopping through netboot also lets you have a menu to select one of several kernels to load. Sam
On Wed, Sep 27, 2006 at 05:09:16PM +0300, Danny Braniss wrote:> originally posted to amd64@freebsd.org: > > Hi, > While trying to figure out why boot/pxeboot failes on some > kernels/hosts, I think i've come up with one solid nogo, > if the kernel is gzipped it always fails. > Can someone confirm this? or am i suffering from some > local problem? >I can confirm this: RELENG_6 doesn't pxeboot when /boot/kernel/kernel is gzipped. In my case, it hangs just after loading a loader.conf file. I've also verified that loading gzipped kernels/modules works on 7-CURRENT/i386. So it's either loader vs. pxeboot issue (unlikely, since pxeboot reuses the loader binary), or i386 vs. amd64 issue (unlikely as well as amd64 reuses the i386 boot code), or more likely because some changes were not MFCed. Perhaps this one: : sobomax 2005-12-19 09:00:11 UTC : : FreeBSD src repository : : Modified files: : sys/boot/i386/libi386 Makefile biosdisk.c biospnp.c biossmap.c : i386_copy.c : Log: : Long-long time ago, when the trees were large and memory expensive amount of : memory directly available to loader(8) and friends was limited to 640K on i386. : Those times have passed long time ago and now loader(8) can directly access : up to 4GB of RAM at least theoretically. At the same time, there are several : places where it's assumed that malloc() will only allocate memory within : first megabyte. : : Remove that assumption by allocating appropriate bounce buffers for BIOS : calls on stack where necessary. : : This allows using memory above first megabyte for heap if necessary. : : Revision Changes Path : 1.39 +3 -0 src/sys/boot/i386/libi386/Makefile : 1.46 +10 -17 src/sys/boot/i386/libi386/biosdisk.c : 1.10 +1 -1 src/sys/boot/i386/libi386/biospnp.c : 1.4 +3 -2 src/sys/boot/i386/libi386/biossmap.c : 1.11 +6 -22 src/sys/boot/i386/libi386/i386_copy.c I'll narrow this down tomorrow if noone bites me while I sleep. :-) Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060927/c5310217/attachment.pgp
> > --3uo+9/B/ebqu+fSQ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Wed, Sep 27, 2006 at 05:09:16PM +0300, Danny Braniss wrote: > > originally posted to amd64@freebsd.org: > >=20 > > Hi, > > While trying to figure out why boot/pxeboot failes on some > > kernels/hosts, I think i've come up with one solid nogo, > > if the kernel is gzipped it always fails. > > Can someone confirm this? or am i suffering from some > > local problem? > >=20 > I can confirm this: RELENG_6 doesn't pxeboot when /boot/kernel/kernel > is gzipped. In my case, it hangs just after loading a loader.conf file. > I've also verified that loading gzipped kernels/modules works on > 7-CURRENT/i386. So it's either loader vs. pxeboot issue (unlikely, > since pxeboot reuses the loader binary), or i386 vs. amd64 issue > (unlikely as well as amd64 reuses the i386 boot code), or more likely > because some changes were not MFCed. Perhaps this one: > > : sobomax 2005-12-19 09:00:11 UTC > :=20 > : FreeBSD src repository > :=20 > : Modified files: > : sys/boot/i386/libi386 Makefile biosdisk.c biospnp.c biossmap.c=20 > : i386_copy.c=20 > : Log: > : Long-long time ago, when the trees were large and memory expensive amou> nt of > : memory directly available to loader(8) and friends was limited to 640K > on i386. > : Those times have passed long time ago and now loader(8) can directly ac> cess > : up to 4GB of RAM at least theoretically. At the same time, there are se> veral > : places where it's assumed that malloc() will only allocate memory within > : first megabyte. > : =20 > : Remove that assumption by allocating appropriate bounce buffers for BIOS > : calls on stack where necessary. > : =20 > : This allows using memory above first megabyte for heap if necessary. > : =20 > : Revision Changes Path > : 1.39 +3 -0 src/sys/boot/i386/libi386/Makefile > : 1.46 +10 -17 src/sys/boot/i386/libi386/biosdisk.c > : 1.10 +1 -1 src/sys/boot/i386/libi386/biospnp.c > : 1.4 +3 -2 src/sys/boot/i386/libi386/biossmap.c > : 1.11 +6 -22 src/sys/boot/i386/libi386/i386_copy.c > > I'll narrow this down tomorrow if noone bites me while I sleep. :-)THANKS! I was begining to climb walls here, let me know when i can test it! danny
> Danny Braniss wrote: > > originally posted to amd64@freebsd.org: > > > > Hi, > > While trying to figure out why boot/pxeboot failes on some > > kernels/hosts, I think i've come up with one solid nogo, > > if the kernel is gzipped it always fails. > > Can someone confirm this? or am i suffering from some > > local problem? > > I believe I've seen this before when booting i386 kernels from soekris > boards. I've taken to using pxeboot to load netboot and then use > netboot to load a kernel as the netboot drivers are way faster (for > soekris at least). Hopping through netboot also lets you have a menu to > select one of several kernels to load. > > Sam >I'll check this asap, btw, does netboot use pxe too? danny