On 2022-01-24 21:25 +09, rgc <[email protected]> wrote:
> i got the upgrade messages. attached below.
> 1/19 update seems to OK (i only detached the external USB after the
> upgrade failed, so at this time the USB is attached)
>
> 1/20 failed upgrade. last 1/21 email was a success (this is after i
> removed the external USB device)
>
> sd2 is the RAID 1 (consists of sd0 + sd1)
> sd3 is the external USB device. connected via the dock USB port.
>
> the log might look weird as it list amdgpu, and inteldrm fw. the HDD
> was transplanted from an AMD Ryzen machine to this T440p machine.
>
>
> dmesg.boot did not contain RAMDISK_CD logs. i rebooted several times
> already. sorry about that.
>
>
> On Sun, Jan 23, 2022 at 05:01:11PM +0100, Florian Obser wrote:
>> The installer sends an email to root with
>>      Subject: $(hostname) upgrade log
>> containing all the information of the upgrade run.
>> Please show the contents of those mails for an upgrade run with and
>> without the removable device attached. And indicated which one is which.
>> 
>> There is also a good chance that the dmesg buffer keeps the dmesg of the
>> bsd.rd run and is accessible in /var/run/dmesg.boot. If so please
>> provide the bsd.rd dmesg with and without the removable device attached.
>> 
>> That might shed some light on what is going on.
>> 
>> 
>> On 2022-01-23 10:03 UTC, Stuart Henderson <[email protected]> wrote:
>> > Installing the UP kernel on an MP system is definitely a bug. Forwarding
>> > to bugs@ where there's more chance of it being seen by somebody with
>> > time to look at it.
>> >
>> > This might explain the several reports I've seen where people have had
>> > 1 cpu show up (and usually have "helpful" people telling them to set
>> > hw.smt=1 ...)
>> >
>> >
>> > From: rgc <[email protected]>
>> > Newsgroups: gmane.os.openbsd.misc
>> > Subject: sysupgrade, softraid and USB removable devices
>> > Date: Fri, 21 Jan 2022 20:29:09 +0900
>> >
>> > misc@
>> >
>> > to document and share something that puzzled me for a bit. other
>> > users might encounter it too.
>> >
>> > given the random nature of device enumeration i don't think it is a
>> > bug. BUT this scenario is very easy to reproduce.
>> >
>> >
>> > recently i have acquired an old Thinkpad T440p. i populated it with
>> > 2 SATA SSDs in a RAID 1 configuration. one in main HDD bay, the other
>> > drive in a caddy that fits in the CD bay. GPT whole disk.
>> >
>> > i also have a 2Tb external USB device that i use as a backup device.
>> >
>> > i did a sysupgrade to GENERIC.MP#275 today and was surprised to see
>> > the updater installed an SP kernel.
>> > ---
>> > syncing disks... done
>> > rebooting...
>> > OpenBSD 7.0-current (RAMDISK_CD) #268: Thu Jan 20 13:09:19 MST 2022
>> >     [email protected]:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
>> > real mem = 17035915264 (16246MB)
>> > ---
>> >
>> > after install:
>> > ---
>> > root on rd0a swap on rd0b dump on rd0b
>> > syncing disks...
>> > OpenBSD 7.0-current (GENERIC) #271: Thu Jan 20 12:55:58 MST 2022
>> >     [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC
>> > real mem = 17035915264 (16246MB)
>> > ---
>> >
>> > i forced the same update and looked *more* closely at the logs.
>> >
>> > i see something like (copying from a video on my phone):
>> >
>> > ---
>> > <dmesg>
>> > softraid0: volume sd3 is roaming, it used to be sd2, updating metadata.
>> > :
>> > <upgrade>
>> > :
>> > Making all device nodes... done.
>> > fw_update: added none; update none; kept ...
>> > installboot: cross-device install
>> >
>> > Failed to install bootblocks.
>> > You will not be able to boot OpenBSD from sd2.
>> > <reboot>
>> > ---
>> >
>> > despite the ominous message, the laptop boots but only with an SP kernel.
>> >
>> > during upgrade, i see sd0 as one of the RAID disk; sd1 as the other RAID
>> > disk.  sd2 is the external USB device.  sd3 is the softraid device.
>> >
>> > on a *normal* boot. sd0 and sd1 are the RAID disks. sd2 is the
>> > softraid device. and sd3 is the external USB device. i guess this is why
>> > i see the *roaming* message.
>> >
>> > the upgrade seems to have skipped installing the MP kernel afterwards.

[...]

> From [email protected] Thu Jan 20 21:36:40 2022
> Return-Path: <[email protected]>
> Delivered-To: [email protected]
> Received: from localhost (glitch.my.domain [local])
>       by glitch.my.domain (OpenSMTPD) with ESMTPA id cca2947b
>       for <[email protected]>;
>       Thu, 20 Jan 2022 21:36:40 +0900 (JST)
> From: Charlie Root <[email protected]>
> Date: Thu, 20 Jan 2022 21:36:40 +0900 (JST)
> To: [email protected]
> Subject: glitch.my.domain upgrade log
> Message-ID: <[email protected]>
> Status: RO
> Content-Length: 3166
> Lines: 54
>
> Choose your keyboard layout ('?' or 'L' for list) [default] default
> Available disks are: sd2 sd3.

sd2 is the backup disk, sd3 is the raid1

> Which disk is the root disk? ('?' for details) [sd2] sd2

the backup disk contains a partition "a" containing /bsd.upgrade and
/auto_upgrade.conf for some reason. That means check_unattendedupgrade()
will pick this disk as the root partition to install the upgrade to.

distrib/miniroot/install.sub:
  3313                          if mount -t ffs -r /dev/${_d}a /mnt; then
  3314                                  [[ -f /mnt/bsd.upgrade && -f 
/mnt/auto_upgrade.conf ]]
  3315                                  _rc=$?
  3316                                  ((_rc == 0)) && cp 
/mnt/auto_upgrade.conf /
  3317                                  echo "Which disk is the root disk = 
${_d}" >> /auto_upgrade.conf

That's probably the root cause why everything goes sideways.

> Checking root filesystem (fsck -fp /dev/sd2a)... OK.
> Mounting root filesystem (mount -o ro /dev/sd2a /mnt)... OK.
> Force checking of clean non-root filesystems? [no] no
> fsck -p c42a5477a342c1f7.a... OK.
> fsck -p c42a5477a342c1f7.l... OK.
> fsck -p c42a5477a342c1f7.d... OK.
> fsck -p c42a5477a342c1f7.f... OK.
> fsck -p c42a5477a342c1f7.g... OK.
> fsck -p c42a5477a342c1f7.h... OK.
> fsck -p c42a5477a342c1f7.k... OK.
> fsck -p c42a5477a342c1f7.j... OK.
> fsck -p c42a5477a342c1f7.e... OK.
> /dev/sd3a (c42a5477a342c1f7.a) on /mnt type ffs (rw, local)

sd2a also contains a valid /etc/fstab that then goes ahead and mounts
*sd3* because it uses DUIDs.

> /dev/sd3l (c42a5477a342c1f7.l) on /mnt/home type ffs (rw, local, nodev, 
> nosuid)
> /dev/sd3d (c42a5477a342c1f7.d) on /mnt/tmp type ffs (rw, local, nodev, nosuid)
> /dev/sd3f (c42a5477a342c1f7.f) on /mnt/usr type ffs (rw, local, nodev)
> /dev/sd3g (c42a5477a342c1f7.g) on /mnt/usr/X11R6 type ffs (rw, local, nodev)
> /dev/sd3h (c42a5477a342c1f7.h) on /mnt/usr/local type ffs (rw, local, nodev, 
> wxallowed)
> /dev/sd3k (c42a5477a342c1f7.k) on /mnt/usr/obj type ffs (rw, local, nodev, 
> nosuid)
> /dev/sd3j (c42a5477a342c1f7.j) on /mnt/usr/src type ffs (rw, local, nodev, 
> nosuid)
> /dev/sd3e (c42a5477a342c1f7.e) on /mnt/var type ffs (rw, local, 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') [7.0/amd64] /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] bsd.rd        [X] comp70.tgz    [X] game70.tgz    
> [X] xshare70.tgz  [X] xserv70.tgz
>     [X] bsd.mp        [X] base70.tgz    [X] man70.tgz     [X] xbase70.tgz   
> [X] xfont70.tgz
> Set name(s)? (or 'abort' or 'done') [done] done
> Directory does not contain SHA256.sig. Continue without verification? [no] yes
> Installing bsd          100% |**************************| 22250 KB    00:00   
>  
> Installing bsd.mp       100% |**************************| 22351 KB    00:00   
>  

we are installing bsd.mp

> Installing bsd.rd       100% |**************************|  4477 KB    00:00   
>  
> Installing base70.tgz   100% |**************************|   329 MB    00:27   
>  
> Installing comp70.tgz   100% |**************************| 73422 KB    00:16   
>  
> Installing man70.tgz    100% |**************************|  7589 KB    00:06   
>  
> Installing game70.tgz   100% |**************************|  2744 KB    00:00   
>  
> Installing xbase70.tgz  100% |**************************| 53633 KB    00:08   
>  
> Installing xshare70.tgz 100% |**************************|  4544 KB    00:08   
>  
> Installing xfont70.tgz  100% |**************************| 22965 KB    00:05   
>  
> Installing xserv70.tgz  100% |**************************| 19683 KB    00:01   
>  
> Location of sets? (disk http nfs or 'done') [done] done
> Making all device nodes... done.
> fw_update: added none; updated none; kept amdgpu,intel,inteldrm,iwm,uvideo,vmm
> installboot: cross-device install

  2872          md_installboot $ROOTDISK

and $ROOTDISK is sd2

>
> Failed to install bootblocks.
> You will not be able to boot OpenBSD from sd2.

md_installboot calls exit in this case so we never reach
"Multiprocessor machine; using bsd.mp instead of bsd.":

  2872          md_installboot $ROOTDISK
  2873
  2874          chmod og-rwx /mnt/bsd{,.mp,.rd} 2>/dev/null
  2875          if [[ -f /mnt/bsd.mp ]] && ((NCPU > 1)); then
  2876                  _kernel=$_kernel.MP
  2877                  echo "Multiprocessor machine; using bsd.mp instead of 
bsd."
  2878                  mv /mnt/bsd /mnt/bsd.sp 2>/dev/null
  2879                  mv /mnt/bsd.mp /mnt/bsd
  2880          fi


-- 
I'm not entirely sure you are real.

Reply via email to