Re: sysupgrade woes on beaglebone black
On Jan 10 11:01:03, flor...@openbsd.org wrote: > > It seems I am missing out on > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.1141&r2=1.1142&f=h > > - I can't figure out how to pass the -x option that sets $UU > > (and thus makes the timer reset before each set is installed). > > Those are not the droids you are looking for, you have UU set. > > Line 73: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/dot.profile?annotate=1.44 On Jan 10 10:06:16, cho...@jtan.com wrote: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/dot.profile.diff?r1=1.42&r2=1.43 Thank you. The reboot happens around 30 min total though - always in the middle of comp66.tgz, which itself is not taking 30 min (I am measuring it). That makes me think the timer does not really get reset before every set: [timer reset?] > Installing bsd100% |**| 6248 KB00:05 ETA [timer reset?] > Installing bsd.rd 100% |**| 11229 KB00:10 ETA [timer reset?] > Installing base66.tgz 100% |**| 99116 MB - 07:12edT- [timer reset?] > Installing comp66.tgz 83% |* | 45312 KB - > stalledT-syncing disks... done > > rebooting... ... but it's not 30 min from the last reset at this point (i.e., 30 min since the installation of _this_set_ began), it's 30 min from the very beginning. Just to be sure: it's a sysupgrade, not an fresh install. The /autoinstall -x you have kindly showed me above, is that what's run once the /bsd.upgrade kernel reboots? Am I missing something else?
Re: sysupgrade woes on beaglebone black
Jan Stary writes: > - I can't figure out how to pass the -x option that sets $UU > (and thus makes the timer reset before each set is installed). You don't. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/dot.profile.diff?r1=1.42&r2=1.43 Matthew
Re: sysupgrade woes on beaglebone black
On Fri, Jan 10, 2020 at 10:06:41AM +0100, Jan Stary wrote: > It seems it's the SD card that is slow (the machine > is a BeagleBone Black) - will try with a faster one. > > It seems I am missing out on > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.1141&r2=1.1142&f=h > - I can't figure out how to pass the -x option that sets $UU > (and thus makes the timer reset before each set is installed). Those are not the droids you are looking for, you have UU set. Line 73: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/dot.profile?annotate=1.44 > > Thank you for the insight. > -- I'm not entirely sure you are real.
Re: sysupgrade woes on beaglebone black
On Fri, Jan 10, 2020 at 10:06:41AM +0100, Jan Stary wrote: > On Jan 09 11:44:25, h...@stare.cz wrote: > > Installing bsd 100% |**| 6248 KB00:05 ETA > > Installing bsd.rd 100% |**| 11229 KB00:10 ETA > > Installing base66.tgz 100% |**| 99116 MB - > > 07:12edT- > > Installing comp66.tgz83% |* | 45312 KB - > > stalledT-syncing disks... done > > rebooting... > > On Jan 09 14:48:25, dera...@openbsd.org wrote: > > > https://marc.info/?l=openbsd-cvs&m=156889553923923&w=2 > > > Looking at install.sub, it seems that the watchdog timer (30 min) > > > is reset after installing every set. I don't see the watchdog being > > > reset whenever there is "progress" - did you mean the completion > > > of a set (as opposed to just not being -stalled-)? > > > > > > Also, the resets only happen with $UU, which is only set with -x > > > - where should that option be passed? (not in sysupgrade.) > > > > > > Grandpa's analog stopwatch on a chain says > > > that it indeed reboot around the 30 min mark. > > > > This entire design is intentional. > > > > If a machine gets stuck doing an upgrade, we want it to abandon the > > upgrade and go back to the /bsd kernel (which hopefully has not been > > installed yet). > > Well, /bsd is the first thing that gest installed, > and is relatively small compared to the other sets. > In this particular machine, the watchdog timeout hits when > bsd, bsd.rd, base, and half of comp have been installed. > > > Your machine is too slow. > > It seems it's the SD card that is slow (the machine > is a BeagleBone Black) - will try with a faster one. Support for using edma with ommmc(4) is lacking, that would help. > > It seems I am missing out on > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.1141&r2=1.1142&f=h > - I can't figure out how to pass the -x option that sets $UU > (and thus makes the timer reset before each set is installed). > > Thank you for the insight. > >
Re: sysupgrade woes on beaglebone black
On Jan 09 11:44:25, h...@stare.cz wrote: > Installing bsd100% |**| 6248 KB00:05 ETA > Installing bsd.rd 100% |**| 11229 KB00:10 ETA > Installing base66.tgz 100% |**| 99116 MB - 07:12edT- > Installing comp66.tgz 83% |* | 45312 KB - > stalledT-syncing disks... done > rebooting... On Jan 09 14:48:25, dera...@openbsd.org wrote: > > https://marc.info/?l=openbsd-cvs&m=156889553923923&w=2 > > Looking at install.sub, it seems that the watchdog timer (30 min) > > is reset after installing every set. I don't see the watchdog being > > reset whenever there is "progress" - did you mean the completion > > of a set (as opposed to just not being -stalled-)? > > > > Also, the resets only happen with $UU, which is only set with -x > > - where should that option be passed? (not in sysupgrade.) > > > > Grandpa's analog stopwatch on a chain says > > that it indeed reboot around the 30 min mark. > > This entire design is intentional. > > If a machine gets stuck doing an upgrade, we want it to abandon the > upgrade and go back to the /bsd kernel (which hopefully has not been > installed yet). Well, /bsd is the first thing that gest installed, and is relatively small compared to the other sets. In this particular machine, the watchdog timeout hits when bsd, bsd.rd, base, and half of comp have been installed. > Your machine is too slow. It seems it's the SD card that is slow (the machine is a BeagleBone Black) - will try with a faster one. It seems I am missing out on http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.1141&r2=1.1142&f=h - I can't figure out how to pass the -x option that sets $UU (and thus makes the timer reset before each set is installed). Thank you for the insight.
Re: sysupgrade woes on beaglebone black
Jan Stary wrote: > On Jan 09 11:03:57, t...@tedunangst.com wrote: > > Jan Stary wrote: > > > Installing base66.tgz 100% |**| 99116 MB - > > > 07:12edT- > > > Installing comp66.tgz 83% |* | 45312 KB - > > > stalledT-syncing disks... done > > > rebooting... > > > > > > Why does it reboot here? The SD card is slow, and is being both read > > > and written at this point, but even if it stalled the installer horribly, > > > it would not reboot, right? > > > > there's a watchdog timeout that reboots. I believe there was a bug fixed > > after 6.6 to reset it if progress is being made. > > Thank you. > > https://marc.info/?l=openbsd-cvs&m=156889553923923&w=2 > Looking at install.sub, it seems that the watchdog timer (30 min) > is reset after installing every set. I don't see the watchdog being > reset whenever there is "progress" - did you mean the completion > of a set (as opposed to just not being -stalled-)? > > Also, the resets only happen with $UU, which is only set with -x > - where should that option be passed? (not in sysupgrade.) > > Grandpa's analog stopwatch on a chain says > that it indeed reboot around the 30 min mark. This entire design is intentional. If a machine gets stuck doing an upgrade, we want it to abandon the upgrade and go back to the /bsd kernel (which hopefully has not been installed yet). Your machine is too slow. Can you scrounge up some nickels?
Re: sysupgrade woes on beaglebone black
On Jan 09 11:03:57, t...@tedunangst.com wrote: > Jan Stary wrote: > > Installing base66.tgz 100% |**| 99116 MB - > > 07:12edT- > > Installing comp66.tgz83% |* | 45312 KB - > > stalledT-syncing disks... done > > rebooting... > > > > Why does it reboot here? The SD card is slow, and is being both read > > and written at this point, but even if it stalled the installer horribly, > > it would not reboot, right? > > there's a watchdog timeout that reboots. I believe there was a bug fixed > after 6.6 to reset it if progress is being made. Thank you. https://marc.info/?l=openbsd-cvs&m=156889553923923&w=2 Looking at install.sub, it seems that the watchdog timer (30 min) is reset after installing every set. I don't see the watchdog being reset whenever there is "progress" - did you mean the completion of a set (as opposed to just not being -stalled-)? Also, the resets only happen with $UU, which is only set with -x - where should that option be passed? (not in sysupgrade.) Grandpa's analog stopwatch on a chain says that it indeed reboot around the 30 min mark. Jan
Re: sysupgrade woes on beaglebone black
Jan Stary wrote: > Installing base66.tgz 100% |**| 99116 MB - 07:12edT- > Installing comp66.tgz 83% |* | 45312 KB - > stalledT-syncing disks... done > rebooting... > > Why does it reboot here? The SD card is slow, and is being both read > and written at this point, but even if it stalled the installer horribly, > it would not reboot, right? there's a watchdog timeout that reboots. I believe there was a bug fixed after 6.6 to reset it if progress is being made.
sysupgrade woes on beaglebone black
This is current/armv7 on a BeagleBone Black (dmesg below).
I am trying to upgrade with sysupgrade -s.
It downloads the sets, reboots, starts installing,
but does not quite finish:
[...]
Welcome to the OpenBSD/armv7 6.6 installation program.
Performing non-interactive upgrade...
Terminal type? [vt220] vt220
Available disks are: sd0.
Which disk is the root disk? ('?' for details) [sd0] sd0
Checking root filesystem (fsck -fp /dev/sd0a)... OK.
Mounting root filesystem (mount -o ro /dev/sd0a /mnt)... OK.
Force checking of clean non-root filesystems? [no] no
fsck -p 93aae518915c8841.d... OK.
fsck -p 93aae518915c8841.e... OK.
fsck -p 93aae518915c8841.f... OK.
fsck -p 93aae518915c8841.g... OK.
fsck -p 93aae518915c8841.h... OK.
fsck -p 93aae518915c8841.j... OK.
fsck -p 93aae518915c8841.k... OK.
fsck -p 93aae518915c8841.l... OK.
fsck -p 93aae518915c8841.m... OK.
/dev/sd0a (93aae518915c8841.a) on /mnt type ffs (rw, local)
/dev/sd0d (93aae518915c8841.d) on /mnt/usr type ffs (rw, local, noatime, nodev)
/dev/sd0e (93aae518915c8841.e) on /mnt/usr/local type ffs (rw, local, noatime,
nodev, wxallowed)
/dev/sd0f (93aae518915c8841.f) on /mnt/var type ffs (rw, local, noatime, nodev,
nosuid)
/dev/sd0g (93aae518915c8841.g) on /mnt/var/log type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd0h (93aae518915c8841.h) on /mnt/var/www type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd0j (93aae518915c8841.j) on /mnt/var/mail type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd0k (93aae518915c8841.k) on /mnt/tmp type ffs (rw, local, noatime, nodev,
nosuid)
/dev/sd0l (93aae518915c8841.l) on /mnt/home type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd0m (93aae518915c8841.m) on /mnt/backup type ffs (rw, local, noatime,
nodev, nosuid)
Let's upgrade the sets!
Location of sets? (disk http nfs or 'done') [http] disk
Is the disk partition already mounted? [yes] yes
Pathname to the sets? (or 'done') [6.6/armv7] /home/_sysupgrade/
Select sets by entering a set name, a file name pattern or 'all'. De-select
sets by prepending a '-', e.g.: '-game*'. Selected sets are labelled '[X]'.
[X] bsd [X] comp66.tgz[X] xbase66.tgz [X] xserv66.tgz
[X] bsd.rd[X] man66.tgz [X] xshare66.tgz
[X] base66.tgz[X] game66.tgz[X] xfont66.tgz
Set name(s)? (or 'abort' or 'done') [done] done
Directory does not contain SHA256.sig. Continue without verification? [no] yes
Installing bsd 100% |**| 6248 KB00:05 ETA
Installing bsd.rd 100% |**| 11229 KB00:10 ETA
Installing base66.tgz 100% |**| 99116 MB - 07:12edT-
Installing comp66.tgz83% |* | 45312 KB -
stalledT-syncing disks... done
rebooting...
Why does it reboot here? The SD card is slow, and is being both read
and written at this point, but even if it stalled the installer horribly,
it would not reboot, right?
Yes, there is space on the filesystem.
Yes, the sets are completely downloaded,
and the hashes have been verified (also checked manualy).
A manual upgrade goes just fine.
Jan
OpenBSD 6.6-current (GENERIC) #248: Mon Jan 6 12:02:06 MST 2020
dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/GENERIC
real mem = 477814784 (455MB)
avail mem = 458121216 (436MB)
mainbus0 at root: TI AM335x BeagleBone Black
cpu0 at mainbus0 mpidr 0: ARM Cortex-A8 r3p2
cpu0: 32KB 64b/line 4-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 256KB 64b/line 8-way L2 cache
omap0 at mainbus0
prcm0 at omap0 rev 0.2
dmtimer0 at omap0 rev 3.1
dmtimer1 at omap0 rev 3.1
simplebus0 at mainbus0: "ocp"
simplebus1 at simplebus0: "l4_wkup"
"wkup_m3" at simplebus1 not configured
simplebus2 at simplebus1: "prcm"
"l4_per_cm" at simplebus2 not configured
"l4_wkup_cm" at simplebus2 not configured
"mpu_cm" at simplebus2 not configured
"l4_rtc_cm" at simplebus2 not configured
"gfx_l3_cm" at simplebus2 not configured
"l4_cefuse_cm" at simplebus2 not configured
simplebus3 at simplebus1: "scm"
syscon0 at simplebus3: "scm_conf"
pinctrl0 at simplebus3
"wkup_m3_ipc" at simplebus3 not configured
"dma-router" at simplebus3 not configured
intc0 at simplebus0 rev 5.0
"edma" at simplebus0 not configured
"tptc" at simplebus0 not configured
"tptc" at simplebus0 not configured
"tptc" at simplebus0 not configured
omgpio0 at simplebus0: rev 0.1
gpio0 at omgpio0: 32 pins
omgpio1 at simplebus0: rev 0.1
gpio1 at omgpio1: 32 pins
omgpio2 at simplebus0: rev 0.1
gpio2 at omgpio2: 32 pins
omgpio3 at simplebus0: rev 0.1
gpio3 at omgpio3: 32 pins
com0 at simplebus0: ti16750, 64 byte fifo
com0: console
tiiic0 at simplebus0 rev 0.11
iic0 at tiiic0
"ti,tps65217" at iic0 addr 0x24 not configured
"atmel,24c256" at iic0 addr 0x50 not configured
nxphdmi0 at iic0 addr 0x70: rev 0x0301
nxphdmi0: no display detected
tiiic1 at simplebus0 rev 0.11
iic1 at tiiic1
"atmel,24c256" at iic1 addr 0x54 not configured
"atmel,24c256" at iic1 addr 0x55 not configured
"atmel,24c256" at iic1
