Date: Wed, 29 Feb 2012 16:05:08 -0500 From: John Baldwin <jhb@freebsd.org> To: rank1seeker@gmail.com Cc: Roman Divacky <rdivacky@freebsd.org>, hackers@freebsd.org Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) Message-ID: <201202291605.08267.jhb@freebsd.org> In-Reply-To: <20120229.200836.168.1@DOMY-PC> References: <20120217.074355.853.1@DOMY-PC> <201202291127.00209.jhb@freebsd.org> <20120229.200836.168.1@DOMY-PC>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, February 29, 2012 3:08:36 pm rank1seeker@gmail.com wrote: > ----- Original Message ----- > From: John Baldwin <jhb@freebsd.org> > To: rank1seeker@gmail.com > Cc: hackers@freebsd.org, "Roman Divacky" <rdivacky@freebsd.org> > Date: Wed, 29 Feb 2012 11:26:59 -0500 > Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) > > > On Tuesday, February 28, 2012 3:09:06 pm rank1seeker@gmail.com wrote: > > > ----- Original Message ----- > > > From: John Baldwin <jhb@freebsd.org> > > > To: rank1seeker@gmail.com > > > Cc: hackers@freebsd.org, "Roman Divacky" <rdivacky@freebsd.org> > > > Date: Mon, 27 Feb 2012 11:23:59 -0500 > > > Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) > > > > > > > On Saturday, February 25, 2012 9:41:48 am rank1seeker@gmail.com wrote: > > > > > > Do you only see the "No " message? Do you see the '/boot.config: /loader' > > > > > > message? (Do you have RBX_QUIET enabled perhaps? (-q)) Do you get the actual > > > > > > boot2 prompt at all? > > > > > > > > > > I don't have RBX_QUIET enabled nor any other flags > > > > > > > > > > Let the pic tell a story: > > > > > http://www.starforce.biz/stage2boot.jpg > > > > > > > > Ahh, this is helpful. You do see the '/boot.config: /loader' message. > > > > > > I've already explained that, numerous times (RE-typing ...) > > > > It was not as obvious before, and you are seeing a failure that no one else > > has reported, so you need to be patient. > > > > > > > Patch eliminates possible error, of manual "intervention" > > > > > That is, a perfectly valid patch being classified as invalid. > > > > > > > > I have no idea what you mean here. However, it seems you don't have junk in > > > > your 'opts' variable anyway. > > > > > > What I meant was that I won't manually(edit file) apply patch, but via 'patch' tool/bin. > > > > Ok. > > > > > > Hmm, you could try adding some more debugging to boot2.c to see exactly what > > > > is failing. For example, does the first call to 'parse()' fail and clear > > > > autoboot? > > > > > > I don't do nor understand c code. > > > > Ok. That will take a bit longer to fix, but that is ok. I've attached a new > > patch with some debugging output. It shouldn't fix the problem yet, but I want > > to see if any of the new messages are output, and when they are output. > > > > > How could it silently loose documented functionality? > > > > Several changes were made to boot2 to make it smaller so it could be compiled with > > clang, and it seems that at least one of those changes must have had a bug. > > > > -- > > John Baldwin > > > > > Patch fails at 9.0 RELEASE: (Is this for 9 STABLE?) Nope, patch was made against a 9.0 tree: % svn info . Path: . URL: svn+ssh://svn.freebsd.org/base/releng/9.0/sys Repository Root: svn+ssh://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 232297 Node Kind: directory Schedule: normal Last Changed Author: kensmith Last Changed Rev: 229283 Last Changed Date: 2012-01-02 09:45:30 -0500 (Mon, 02 Jan 2012) % svn stat boot/i386/boot2 M boot/i386/boot2/boot2.c % svn diff boot/i386/boot2 | md5 888f90f32bd20d1bf7e2d3277d9b697b And the file I sent to you before: % md5 ~/work/patches/boot2_test.patch MD5 (/home/jhb/work/patches/boot2_test.patch) = 888f90f32bd20d1bf7e2d3277d9b697b > I'll give you a hint (which I've mentioned at start) > > In order to expose bug, 2 conditions have to be met: > 1) boot.config in use > 2) daX device (i.e; USB stick) > > That is ... > I've created vnode image. Then, ... when I 'dd' it to HDD's slice, it boots. > BUT when I 'dd' it to USB's slice it hangs. USB booting uses a different chunk of BIOS code, and it may be doing different things which result in uninitialized memory having different values (e.g. the cmd[] array). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201202291605.08267.jhb>