On Thu, Apr 13, 2023 at 11:35:49AM -0600, Theo de Raadt wrote: > No laptop should be that slow. Something is wrong. > > If not running the installer, does 'systat vm 1' show interrupt storms > or other root causes? > > Or is it only the installer. So the way to debug this is a bit quirky, > I've done this before. It is not simply, I will describe it in small > rough steps. > > First, you want a GENERIC or GENERIC.MP kernel for the installer, but with > the RAMDISK features. Diff the config files to tell the difference. You > don't want SMALL_KERNEL, in particular. > > The kernel will now support more features. At this point, get it up and > running in the installer, and see if it is slow. > > If it is still slow, you can now download proper test binaries like vmstat > and systat, and full sysctl, and see if you can see what hw.sensors and > interrupts look like. > > You need to identify something that is different.
I understand the approach. I just need to find good chunk of time to look into it. > The installer timeouts are serving people with common cases, so they > don't need to wait. Making the timeouts ridiculously long does not serve > those people > Make sense. > > Mikolaj Kucharski <miko...@kucharski.name> wrote: > > > Hi, > > > > I have an amd64 based cheap laptop, which has extremly slow I/O and even > > slower I/O in the installer. The result is, that fsck during upgrade, > > triggered via sysupgrade -s, takes ages. Basically makes upgrade > > non-usable. I need to follow manual upgrade or I edit via the > > gzip, rdsetroot -x, vnconfig, mount, vi, umount, vnconfig -u, > > rdsetroot, gzip dance the WATCHDOG_PERIOD_SEC in install.sub and > > bump it to 60 minutes, then I can sysupgrade the machine. > > > > Would it be possible to bump it to 60 minutes? > > > > I have that laptop powered off at the moment, but I will upgrade to > > -current in coming days and will post in the thread dmesg from > > GENERIC.MP and RAMDISK_CD. > > -- Regards, Mikolaj
