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. 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 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 >
