Install world fails, computer almost unusable
Kent Stewart
kstewart at owt.com
Thu Apr 8 13:23:22 PDT 2004
On Thursday 08 April 2004 07:09 am, Remko Lodder wrote:
> Artem Koutchine wrote:
> > IMHO the upgrade pricedure is unstable and wrong in either case.
>
> Then why is it a proven working procedure? (I upgraded my boxes from
> 5.0-RC1 to 5.2.1-p4 (all the way) And it never failed on me!)
I agree because I am one of the people that made the statfs transition
on current just fine. I started following the boot -s procedure to do
the installworld when you couldn't do an installworld on a 4.0 kernel.
>
> Previously on 4.x it also worked out fine (another method i used over
> there, but that also worked out)
>
> > If you build, install a new kernel and reboot and they make
> > installworld you may face code dumps because all world is not
> > compatible with the new kernel.
>
> Not at my machine.
I have had a few panics but they were due to bad changes being made to
the kernel. Even then, backing up to kernel.old worked and continued to
work until the problem was fixed.
>
> > IMHO this thing must be resolved in the future and it would be
> > nice
> >
> > to do it this way:
> > 1) build kernel and install it into a buffer
>
> /boot will be fine for me (like it does now)
>
> > 2) build workld and install it into a buffer
>
> That requires that you have a lot of diskspace, so some users can
> have issues with this, and then again in my opinion there is no
> problem, and if there is a problem this won't solve it.
>
> > 3) make changes to config files and install new config file into a
> > buffer
>
> install kernel, reboot, make buildworld, reboot in singleusermode
> make installworld, mergemaster -p , reboot, mergemaster.
> does the same imho.
I may be confused here but if you do a buildworld after you do an
install kernel, you used the old system to built the kernel. You want
the new buildworld available when you do the buildkernel.
>
> > 4) reboot
>
> we already done that
>
> > 5) during reboot load shoud check the install buffer and if there
> > is something in it then copy it into a real working filesystem.
> >
> > This way we will abvoid nonmtaching executables and kernel at any
> > given time.
> >
> > What do you think?
>
> My opinion is clear, i'll stick with the current way freebsd handles
> new installations, they work for me, and they never failed on me.
Me too!! It has worked for me over several serious changes that would
break your system and they never failed.
Kent
--
Kent Stewart
Richland, WA
http://users.owt.com/kstewart/index.html
More information about the freebsd-questions
mailing list