GENERIC64 aarch64 failure to autoboot

To: NetBSD current-users <current-users%netbsd.org@localhost>
Subject: GENERIC64 aarch64 failure to autoboot
From: Chavdar Ivanov <ci4ic4%gmail.com@localhost>
Date: Sat, 4 Mar 2023 13:31:58 +0000

Hi,

I may have mentioned in some earlier mail to the list that I am
running a (free) instance on Oracle OCI of aarch64 NetBSD-current
machine. As there is no foreign OS support for the free instances
there, following a suggestion elsewhere on this list, I was able to
overwrite the boot disk of a Ubuntu guest with the live-image of an
aarch64 NetBSD-current guest. All went well; I proceeded with pkgsrc
etc. and have done several sysupgrades - using sysutil/sysupgrade on
manually transferred kernel and sets directories,all this without a
problem, actually very much recommended to anyone who wants to have a
decent AARCH64 QEMU free instance in the cloud - up to 24GB/4cores is
actually free, no problem with networking etc.

Since my last aarch64 build yesterday, 03/03/2023, my machine no
longer boots automatically, it cannot see its root disk and I have to
connect to the serial console one gets on OCI and select the boot disk
manually. There is no change on the cloud side, as I can still boot
onetbsd and it proceeds as before. The interesting diffs in the
process follow:

 -----------------kernel from 30/01/2023--------------
[   1.3495762] sd0: fabricating a geometry
[   1.3654912] sd0: 47694 MB, 47694 cyl, 64 head, 32 sec, 512
bytes/sect x 97677312 sectors
[   1.3696969] sd0: fabricating a geometry
[   1.3797015] dk0 at sd0: "EFI system", 262144 blocks at 2048, type: msdos
[   1.3897890] dk1 at sd0: "cc8f4a89-edc0-48d1-b9ce-b40d227a4a07",
97411072 blocks at 264192, type: ffs
[   1.4097270] sd0: async, 8-bit transfers, tagged queueing
......
[   3.2743726] boot device: <unknown>
[   3.2743726] root on dk1
[   3.2743726] root file system type: ffs
[   3.2843774] kern.module.path=/stand/evbarm/10.99.2/modules
Sat Mar  4 12:41:17 UTC 2023
Starting root file system check:
/dev/rdk1: file system is clean; not checking
Not resizing / (NAME=cc8f4a89-edc0-48d1-b9ce-b40d227a4a07): already correct size
Setting sysctl variables:
ddb.onpanic: 1 -> 0

----------------kernel from 03/03/2023-----------------
[   1.7012844] sd0 at scsibus0 target 0 lun 1: <ORACLE, BlockVolume,
1.0> disk fixed
[   1.7235943] sd0: fabricating a geometry
[   1.7235943] sd0: 47694 MB, 47694 cyl, 64 head, 32 sec, 512
bytes/sect x 97677312 sectors
[   1.7330480] sd0: fabricating a geometry
[   1.7330480] dk0 at sd0: "EFI system", 262144 blocks at 2048, type: msdos
[   1.7330480] dk1 at sd0: "cc8f4a89-edc0-48d1-b9ce-b40d227a4a07",
97411072 blocks at 264192, type: ffs
[   1.7431542] sd0: async, 8-bit transfers, tagged queueing
...
[   3.0014644] boot device: sd0
[   3.0014644] root on sd0a dumps on sd0b
[   3.0121746] vfs_mountroot: can't open root device
[   3.0226157] cannot mount root, error = 16
[   3.0226157] root device (default sd0a): list
[   8.0440822] use one of: dk0 dk1 vioif0 sd0[a-p] wedge:EFI system
wedge:cc8f4a89-edc0-48d1-b9ce-b40d227a4a07 ddb halt reboot
[   8.0440822] root device (default sd0a): dk1
[  10.0516176] dump device:
[  10.1093156] file system (default generic):
[  10.7765265] root on dk1
[  10.7765265] root file system type: ffs
[  10.7865339] kern.module.path=/stand/evbarm/10.99.2/modules
[  10.7886598] init path (default /sbin/init):
[  12.7982026] init: trying /sbin/init
Sat Mar  4 12:50:15 UTC 2023
Starting root file system check:
....


GENERIC64 diffs:

 cvs diff -u -r 1.207 -r 1.210 GENERIC64
Index: GENERIC64
===================================================================
RCS file: /cvsroot/src/sys/arch/evbarm/conf/GENERIC64,v
retrieving revision 1.207
retrieving revision 1.210
diff -u -r1.207 -r1.210
--- GENERIC64   24 Dec 2022 15:46:50 -0000      1.207
+++ GENERIC64   25 Feb 2023 08:19:35 -0000      1.210
@@ -1,5 +1,5 @@
 #
-#      $NetBSD: GENERIC64,v 1.207 2022/12/24 15:46:50 nia Exp $
+#      $NetBSD: GENERIC64,v 1.210 2023/02/25 08:19:35 skrll Exp $
 #
 #      GENERIC ARM (aarch64) kernel
 #
@@ -47,7 +47,9 @@
 #options       EARLYCONS=sunxi, CONSADDR=0x01c28000
 #options       EARLYCONS=tegra, CONSADDR=0x70006000
 #options       EARLYCONS=thunderx, CONSADDR=0x87e024000000
-#options       EARLYCONS=virt, CONSADDR=0x09000000
+
+# The QEMU virt machine
+#options       EARLYCONS=plcom, CONSADDR=0x09000000

 # Hardware management of the Access flag and dirty state (HAFDBS).
 options        ARMV81_HAFDBS
@@ -412,6 +414,7 @@
 ahcisata*      at fdt?                 # AHCI SATA
 ahcisata*      at acpi?
 ahcisata*      at pci? dev ? function ?
+siisata*       at pci? dev ? function ?
 atabus*        at ata?
 atapibus*      at atapi?
 wd*            at atabus? drive ?
@@ -561,4 +564,5 @@
 scsibus*       at scsi?
 sd*            at scsibus? target ? lun ?      # SCSI disk drives

-cinclude "arch/evbarm/conf/GENERIC64.local"
+# Pull in optional local configuration - always at end
+cinclude       "arch/evbarm/conf/GENERIC64.local"

So the kernel that boots OK says that the boot device is unknown,
whereas the new one incorrectly identifies sd0 as the boot device - it
should be dk1, or whatever the NAME is (the fstab has NAME=...
identifying dk1).

Here is the entire diff between the two dmesg's, after stripping the [*] bits:

--- dmesg-m-30012023    2023-03-04 13:03:13.740831959 +0000
+++ dmesg-m-03032023    2023-03-04 13:02:56.818630839 +0000
@@ -7,7 +7,7 @@
  Copyright (c) 1982, 1986, 1989, 1991, 1993
      The Regents of the University of California.  All rights reserved.

- NetBSD 10.99.2 (GENERIC64) #2: Mon Jan 30 21:08:24 GMT 2023
+ NetBSD 10.99.2 (GENERIC64) #0: Fri Mar  3 23:19:59 GMT 2023
        sysbuild%ymir.lorien.lan@localhost:/home/sysbuild/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
  total memory = 12261 MB
  avail memory = 11820 MB
@@ -244,11 +244,11 @@
  uhub1 at usb1: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0,
rev 2.00/1.00, addr 0
  uhub1: 4 ports with 4 removable, self powered
  cpu0: PMU interrupting on irq 23
- sd0 at scsibus0 target 0 lun 1: <ORACLE, BlockVolume, 1.0> disk fixed
  WARNING: system needs entropy for security; see entropy(7)
+ sd0 at scsibus0 target 0 lun 1: <ORACLE, BlockVolume, 1.0> disk fixed
+ IPsec: Initialized Security Association Processing.
  sd0: fabricating a geometry
  sd0: 47694 MB, 47694 cyl, 64 head, 32 sec, 512 bytes/sect x 97677312 sectors
- IPsec: Initialized Security Association Processing.
  sd0: fabricating a geometry
  sd0: GPT GUID: 1c5147b4-96a7-4a45-bcdc-35c78f10962b
  dk0 at sd0: "EFI system", 262144 blocks at 2048, type: msdos
@@ -268,8 +268,18 @@
  wsmouse1 at ums1 mux 0
  swwdog0: software watchdog initialized
  WARNING: 1 error while detecting hardware; check system log.
- boot device: <unknown>
+ boot device: sd0
+ root on sd0a dumps on sd0b
+ vfs_mountroot: can't open root device
+ cannot mount root, error = 16
+ root device (default sd0a): dk1
+ dump device:
+ file system (default generic):
  root on dk1
  root file system type: ffs


Any ideas, with apologies for the long[ish] mail,

Chavdar

-- 
----

Follow-Ups:
- Re: GENERIC64 aarch64 failure to autoboot
  - From: Michael van Elst
- Re: GENERIC64 aarch64 failure to autoboot
  - From: Christof Meerwald

Prev by Date: daily CVS update output
Next by Date: Re: GENERIC64 aarch64 failure to autoboot
Previous by Thread: LVM snapshot status
Next by Thread: Re: GENERIC64 aarch64 failure to autoboot
Indexes:

Home | Main Index | Thread Index | Old Index