Re: i386 install kernel doesn't detect SATA disks

[Andy Ruhl <acruhl%gmail.com@localhost>]

On Thu, Aug 7, 2014 at 3:45 AM, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>
>   Why are you using INSTALL_FLOPPY, rather than INSTALL on a CD?

Because it's nice and easy. I can put it in / and call it install or
netbsdi or something, then boot it from the secondary boot loader like
this:

boot hd0a:netbsdi

Then just point it at the latest daily build of netbsd-5 on nyftp to
get the sets.

>   If you are updating from older netbsd-5 to newer netbsd-5, do you
>   really need to boot like that?

Not sure, I'm just doing what seems logical to me:

1. Sync and build a kernel from netbsd-5 using my custom config
2. Put that kernel in place and reboot to make sure it works
3. Boot from the install kernel as I mentioned above and install all
the sets I want except the kernel one, because I already have a new
kernel
4. Reboot and I have a new install

And it's always worked.

I could use the CD, but then I have to actually burn a CD which is
time consuming and fairly unnecessary because either way I'm
downloading approximately the same amount of data (either I download
the iso image with all the sets, or I just download all the sets
during install with the install kernel).

> To point 2, I use (and partially wrote, and asked others to write)
> pkgsrc/sysutils/etcmanage, which has an INSTALL-NetBSD script that
> unpacks a build on a running system.  This is pretty trivial, and the
> only tricky part is to use this order:
>
>   back up and unpack kernel
>   unpack sets:
>     everthing but base and etc/xetc
>     base
>     DO NOT unpack etc/xetc
>
> The ordering reason is that when crossing from 4 to 5, there were new
> syscalls and libc used them, and if you unpacked the 5 base (including
> libc) on a system running a 4 kernel, nothing worked.  But if you
> already have the kernel, you can push reset.  Of course you should
> unpack the kernel and reboot first.  The reason to do base last is that
> the commands to unpack base will still work when the rest have been
> updated.  So even doing a cross-branch update and forgetting to boot the
> new kernel, the above is a one-reset-button method.
>
> The point of etcmanage is to decide how to update /etc.  It's hard to
> figure out etcmanage, but once done people seem to like it.  I update
> systems along the stable branch with this all the time, with no manual
> intervention - just run the INSTALL-NetBSD script and reboot.  The
> BUILD-NetBSD script does the build and prepares some etcmanage data.
>
> There is a different package sysbuild/sysupdate that addresses much of
> the same issues.
>
>
> You can of course change the INSTALL_FLOPPY kernel config and do a full
> release build and use the kernel you built.

So what I'm doing with the install kernel seems pretty similar, other
than the etcmanage method has less downtime because the system isn't
ever running the install kernel. I've always just trusted postinstall
in the installer to merge etc properly, and I can't remember the last
time it didn't do that.

So it's time to try etcmanage. I'll check it out. Thanks for that.

Andy