loader(8) readin failed on 7.2R and later including 8.0R

John Baldwin jhb at freebsd.org
Wed Dec 2 15:03:32 UTC 2009


On Tuesday 01 December 2009 12:13:39 pm Hiroki Sato wrote:
> Hi,
> 
>  This may be a rare case, but I post this with the hope for ideas from
>  people here.
> 
>  I have experienced a strange loader(8) error.  After upgrading one of
>  my boxes from 7.1R to 7.2R, an error appeared on "boot" command of
>  loader(8) like this:
> 
>  | FreeBSD/i386 bootstrap loader, Revision 1.1
>  | (hrs at cmaster.allbsd.org, Mon Nov 30 04:01:24 JST 2009)
>  | Loading /boot/defaults/loader.conf
>  | /boot/kernel/kernel text=0x8b6c04
>  | readin failed
>  |
>  | elf32_loadimage: read failed
>  | /boot/kernel/kernel text=0x8b6c04
>  | readin failed
>  |
>  | elf32_loadimage: read failed
>  | Unable to load a kernel!
> 
>  (Actually the above error message was displayed when I upgraded it to
>  8.0R.  The message was the same when I tried 7.2R.)
> 
>  Replacing the /boot/loader with 7.1R's one, 7.2R's kernel worked
>  fine.
> 
>  Next, I tried to upgrade it to 8.0R.  As I explained earlier, the
>  8.0R's loader did not work either, so I replaced it with 7.1R again.
>  However, 7.1R loader(8) + 8.0R kernel displayed the following error
>  and did not work:
> 
>  | OK load /boot/kernel/kernel
>  | /boot/kernel/kernel text=0x8db9a4 data=0xdd134+0xa5e84 
syms=[0x4+0x99390+0x4+0xd2201
>  | elf32_loadimage: could not read symbols - skipped!
> 
>  While the "load" command seemed to finish, the box got stuck just
>  after entering "boot" command.
> 
>  Curious to say, I have got this symptom only on a specific box in
>  more than ten different boxes I upgraded so far; it is based on an
>  old motherboard Supermicro P4DPE[*].
> 
>  [*] http://www.supermicro.com/products/motherboard/Xeon/E7500/P4DPE.cfm
> 
>  Any workaround?  Booting from release CDROMs (7.2R and 8.0R) also
>  fail.  On the box "7.1R" or "7.1R's loader + 7.2R kernel" worked
>  fine.  It is possible something in changes of loader(8) between 7.1R
>  and 7.2R is the cause, but I am still not sure what it is...

It may be related to the loader switching to using memory > 1MB for its 
malloc().  Maybe try building the loader with 'LOADER_NO_GPT_SUPPORT=yes' in 
/etc/src.conf?

-- 
John Baldwin


More information about the freebsd-stable mailing list