i386 install kernel doesn't detect SATA disks

[Andy Ruhl]

I downloaded the latest netbsd-5 i386 INSTALL_FLOPPY kernel from nyftp
this morning and booted it to upgrade my machine.

It didn't detect any of my SATA disks.

I went into my bios and switch the SATA disk mode from AHCI to IDE,
then rebooted the install kernel. It detected the disks this time.

Is this correct behavior?

Andy

[Eric Haszlakiewicz]

Post by Andy Ruhl
I downloaded the latest netbsd-5 i386 INSTALL_FLOPPY kernel from nyftp
this morning and booted it to upgrade my machine.
It didn't detect any of my SATA disks.

Netbsd-5? Maybe try using 6 or a daily snapshot instead.

Eric

[Andy Ruhl]

Post by Eric Haszlakiewicz
Netbsd-5? Maybe try using 6 or a daily snapshot instead.

It was a daily snapshot from netbsd-5, dated 201408050740Z.

I'm not quite ready to upgrade to netbsd-6 yet.

The point is I'm pretty sure this didn't happen before when I did
upgrades on this system with netbsd-5, which has had the same hardware
for a few years now.

Andy

[Greg Troxel]

Post by Andy Ruhl

Post by Eric Haszlakiewicz
Netbsd-5? Maybe try using 6 or a daily snapshot instead.

It was a daily snapshot from netbsd-5, dated 201408050740Z.
I'm not quite ready to upgrade to netbsd-6 yet.
The point is I'm pretty sure this didn't happen before when I did
upgrades on this system with netbsd-5, which has had the same hardware
for a few years now.

I think in general netbsd-5 is ok with AHCI.
What is the date of your previous netbsd-5 kernel that works with AHCI?

[Andy Ruhl]

Post by Greg Troxel
I think in general netbsd-5 is ok with AHCI.
What is the date of your previous netbsd-5 kernel that works with AHCI?

I'm probably just making noise here...

My problem was with the INSTALL_FLOPPY kernel, and not the one I'm
using in production.

I was thinking AHCI was working fine with the install kernel on the
last upgrade I did with netbsd-5, which was late 2013, but it probably
really wasn't. I have amnesia.

My production kernel resembles GENERIC in regard to AHCI, which looks
like this (from netbsd-5 synced this morning):

(andy@)[/usr/src/sys/arch/i386/conf] $ head -1 GENERIC && grep ahci GENERIC
# $NetBSD: GENERIC,v 1.915.2.14 2013/06/19 07:50:14 bouyer Exp $
ahcisata* at pci? dev ? function ? # AHCI SATA controllers
ahcisata* at jmide?

And INSTALL_FLOPPY looks like this:

(andy@)[/usr/src/sys/arch/i386/conf] $ head -1 INSTALL_FLOPPY && grep
ahci INSTALL_FLOPPY
# $NetBSD: INSTALL_FLOPPY,v 1.1.16.4 2013/06/19 07:50:15 bouyer Exp $
#ahcisata* at pci? dev ? function ? # AHCI SATA controllers

So it appears that someone thinks there shouldn't be AHCI for SATA in
the install kernel. My result was the install kernel didn't detect my
SATA disks until I rebooted and put them in IDE mode in the BIOS. And
they wouldn't work with the production system until I rebooted and set
them back to AHCI (fsbn error, I didn't write it down). Somewhere
between slightly and mildly annoying.

I went back in cvsweb a ways and it's been the same for a while.

Andy

[Greg Troxel]

Post by Andy Ruhl
ahci INSTALL_FLOPPY
# $NetBSD: INSTALL_FLOPPY,v 1.1.16.4 2013/06/19 07:50:15 bouyer Exp $
#ahcisata* at pci? dev ? function ? # AHCI SATA controllers
So it appears that someone thinks there shouldn't be AHCI for SATA in
the install kernel. My result was the install kernel didn't detect my
SATA disks until I rebooted and put them in IDE mode in the BIOS. And
they wouldn't work with the production system until I rebooted and set
them back to AHCI (fsbn error, I didn't write it down). Somewhere
between slightly and mildly annoying.

I suspect that the theory is that machines where people use floppies do
not have AHCI, and that machines with AHCI will have a CDROM drive.

I guess the questions are:

Why are you using INSTALL_FLOPPY, rather than INSTALL on a CD?

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


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.

[Andy Ruhl]

Post by Greg Troxel
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.

Post by Greg Troxel
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).

Post by Greg Troxel
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
back up and unpack kernel
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