Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On Wednesday, July 13th, 2022 at 6:39 PM, br0nko wrote: > I confirm that the image is bootable with your patch, thank you !!! As you > said already, it lack the resize capability, which make the image somehow > useless since it run out of space at first boot. I did try "resize_root=YES" > in rc.conf without any luck. Actually the live-image didn't resize the CF card either, the missing piece in my case was the resize_disklabel script (https://github.com/NetBSD/src/blob/trunk/distrib/utils/embedded/files/resize_disklabel), which wasn't there by default (in rc.d). Once there, the following in rc.conf is doing the job: resize_disklabel=YES resize_root=YES resize_root_flags="-p" resize_root_postcmd="/sbin/reboot -n" br0nko
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
--- Original Message ---
On Sunday, July 10th, 2022 at 10:47 AM, RVP wrote:
> Right. After ~10 hours of doing `build.sh release' I have a patch. However,
> I'm not at all certain that this script is meant to be used on the x86 arch.
> because: a) It only seems to be used by the evbarm and evbmips builds. b)`
> build live-image' already works (better!) than this script.
>
> c) it does very odd things:
> 1. writes a partition table and an MBR.
> 2. promptly over-writes it with the primary bootstrap (PBR) and the
> disklabel, so the system actually boots directly from the PBR.
>
> Still, here's the patch:
>
> ---
> diff -urN a/distrib/utils/embedded/mkimage b/distrib/utils/embedded/mkimage
> --- a/distrib/utils/embedded/mkimage 2021-09-25 08:54:30.0 +
> +++ b/distrib/utils/embedded/mkimage 2022-07-10 08:18:03.575853000 +
> @@ -255,7 +255,7 @@
> echo ${bar} Populating ffs filesystem ${bar}
> ${MAKEFS} -rx ${endian} -N ${release}/etc -t ffs \
> -O ${ffsoffset} \
> - -o d=4096,f=8192,b=65536 -b $((${extra}))m \
> + -o d=8192,f=2048,b=16384 -b $((${extra}))m \
> -F "$tmp/selected_sets" ${image} "${release}" "${mnt}"
> fi
>
> ---
>
> 1. Make sure you pass the `-r sd' or` -r wd' flags, otherwise, the script
> defaults to `ld' and builds an /etc/fstab with that baked in. 2. This doesn't
> produce a very good live image as a) there's hardly any free space left over,
> and b) it doesn't grow the root partition like` build.sh live-image' does.
>
> I'm don't know what this little oddball script is doing in the Guide...
>
> -RVP
I confirm that the image is bootable with your patch, thank you !!! As you said
already, it lack the resize capability, which make the image somehow useless
since it run out of space at first boot. I did try "resize_root=YES" in rc.conf
without any luck.
I did end-up by using the live-image. The only missing piece for me was the
"fstab_minwrites" (which is still relevant in 2022 seeing the price of CF card).
For the record:
http://rich-tbp.blogspot.com/2013/03/netbsd-on-rpi-minimizing-disk-writes.html
br0nko
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On Sun, 10 Jul 2022, Izumi Tsutsui wrote: IIRC libsa/sa/ufs.c requires large heapsize to read blocksize, from ffs, so sometimes it fails to load on blocksize=65536 fs. (but I'm nots sure 64KB blocksize is valied on FFS because newfs(8) man page just says 4KB-32KB for it) On Mon, 11 Jul 2022, matthew green wrote: FWIW, i've been using 64K block *and frag size FFS for over a decade without any problem, on a file system that almost always has extremely large files on it. I think what's happening here on x86/amd64 systems with a 64k or larger FS block-sizes is that: a) the no. of sectors exceeds the count allowed in the INT 13h disk-read call (less likely), or, b) the buffer allocated in sys/lib/libsa/ufs.c:724 crosses a 64k x86 segment boundary (more likely). I see that sys/arch/i386/stand/lib/biosdisk_ll.c:242 sets cold=1 which will most likely result in situation b) for any of the bootxx_* bootloaders. It should be documented somewhere that block-sizes > 32k are a problem for the BIOS bootloaders on the x86/amd64 arch... -RVP
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
m...@eterna.com.au (matthew green) writes: >FWIW, i've been using 64K block *and frag size FFS for over >a decade without any problem, on a file system that almost >always has extremely large files on it. >so, this should be fixed in the manual i guess. The manual just lists the default values as is and does not mention an upper limit.
re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
> (but I'm nots sure 64KB blocksize is valied on FFS because > newfs(8) man page just says 4KB-32KB for it) FWIW, i've been using 64K block *and frag size FFS for over a decade without any problem, on a file system that almost always has extremely large files on it. so, this should be fixed in the manual i guess. .mrg.
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
mlelstv@ wrote:
> r...@sdf.org (RVP) writes:
>
> >@@ -255,7 +255,7 @@
> > echo ${bar} Populating ffs filesystem ${bar}
> > ${MAKEFS} -rx ${endian} -N ${release}/etc -t ffs \
> > -O ${ffsoffset} \
> >--o d=4096,f=8192,b=65536 -b $((${extra}))m \
> >+-o d=8192,f=2048,b=16384 -b $((${extra}))m \
> > -F "$tmp/selected_sets" ${image} "${release}" "${mnt}"
>
>
> Sounds like the disklabel is incorrect then. FFS requires that
> the fragment size (not so much the blocksize) is correct, but the
> scripts seem to be inconsistent.
>
> N.B. unset fsize (== 0) defaults to fsize = BLKDEV_IOSIZE (== 2048).
I doubt recent newfs(8) or bootloaders refer bsize and fsize
in disklabel.
IIRC libsa/sa/ufs.c requires large heapsize to read blocksize,
from ffs, so sometimes it fails to load on blocksize=65536 fs.
(but I'm nots sure 64KB blocksize is valied on FFS because
newfs(8) man page just says 4KB-32KB for it)
---
Izumi Tsutsui
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
r...@sdf.org (RVP) writes:
>@@ -255,7 +255,7 @@
> echo ${bar} Populating ffs filesystem ${bar}
> ${MAKEFS} -rx ${endian} -N ${release}/etc -t ffs \
> -O ${ffsoffset} \
>- -o d=4096,f=8192,b=65536 -b $((${extra}))m \
>+ -o d=8192,f=2048,b=16384 -b $((${extra}))m \
> -F "$tmp/selected_sets" ${image} "${release}" "${mnt}"
Sounds like the disklabel is incorrect then. FFS requires that
the fragment size (not so much the blocksize) is correct, but the
scripts seem to be inconsistent.
N.B. unset fsize (== 0) defaults to fsize = BLKDEV_IOSIZE (== 2048).
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On Thu, 7 Jul 2022, br0nko wrote:
I wanted to resurrect an old i386 alix box, and I did follow the
guide to create a custom image trough mkimage
(https://www.netbsd.org/docs/guide/en/chap-inst-media.html#chap-inst-media-creating-live-images).
I did first try on amd64 so that I can first test on my laptop.
Build was successful but when I boot the USB key, I'm stuck on
primary bootstrap ("NetBSD/x86 ffsv1 Primary Bootstrap"), no error.
However I can boot it from grub (installed on the laptop hard-drive),
image is fully functional that way.
Right. After ~10 hours of doing `build.sh release' I have a patch. However,
I'm not at all certain that this script is meant to be used on the x86 arch.
because:
a) It only seems to be used by the evbarm and evbmips builds.
b) `build live-image' already works (better!) than this script.
c) it does very odd things:
1. writes a partition table and an MBR.
2. promptly over-writes it with the primary bootstrap (PBR) and the
disklabel, so the system actually boots directly from the PBR.
Still, here's the patch:
---
diff -urN a/distrib/utils/embedded/mkimage b/distrib/utils/embedded/mkimage
--- a/distrib/utils/embedded/mkimage2021-09-25 08:54:30.0 +
+++ b/distrib/utils/embedded/mkimage2022-07-10 08:18:03.575853000 +
@@ -255,7 +255,7 @@
echo ${bar} Populating ffs filesystem ${bar}
${MAKEFS} -rx ${endian} -N ${release}/etc -t ffs \
-O ${ffsoffset} \
- -o d=4096,f=8192,b=65536 -b $((${extra}))m \
+ -o d=8192,f=2048,b=16384 -b $((${extra}))m \
-F "$tmp/selected_sets" ${image} "${release}" "${mnt}"
fi
---
1. Make sure you pass the `-r sd' or `-r wd' flags, otherwise, the script
defaults to `ld' and builds an /etc/fstab with that baked in.
2. This doesn't produce a very good live image as a) there's hardly any
free space left over, and b) it doesn't grow the root partition like
`build.sh live-image' does.
I'm don't know what this little oddball script is doing in the Guide...
On Sat, 9 Jul 2022, Lloyd Parkes wrote:
63 is a popular offset because the BIOS field for track length can only
hold values 0-63.
Of course--I should've remembered that :)
-RVP
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On 8/07/22 21:01, RVP wrote: On Fri, 8 Jul 2022, br0nko wrote: 8 partitions: # size offset fstype [fsize bsize cpg/sgs] a: 2369473 63 4.2BSD 0 0 0 # (Cyl. 0*- 1156) c: 2312129 63 unused 0 0 # (Cyl. 0*- 1128) d: 2369536 0 unused 0 0 # (Cyl. 0 - 1156) This doesn't look right, does it? Offset is 63 instead of 64, 63 is a popular offset because the BIOS field for track length can only hold values 0-63. Cheers, Lloyd
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On 8/07/22 19:57, br0nko wrote: On Thursday, July 7th, 2022 at 11:25 PM, Mike Pumford wrote: On 07/07/2022 15:40, br0nko wrote: Hi, 0: NetBSD (sysid 169) start 63, size 1568384 (766 MB, Cyls 0/1/1-97/160/62), Active beg: cylinder 0, head 1, sector 1 end: cylinder 97, head 160, sector 62 Information from PBR: Not bootable: All bytes are identical (0x00) Not bootable: Bad magic number (0x) No MBR boot code in the partition table. fdisk -i /dev/rvnd0 should resolve that I think. I did give a try, using an amd64 mkimage image build from current tree (9.99.98/amd64): Note that, in general, NetBSD fdisk, installboot and disklabel can be run directly against the image itself without needing to use vnconfig. Sometimes you might need a flag to tell the command that it is being given a disk image instead of a real disk, but that's about it. Cheers, Lloyd
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On Fri, 8 Jul 2022, br0nko wrote: 8 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] a: 236947363 4.2BSD 0 0 0 # (Cyl. 0*- 1156) c: 231212963 unused 0 0# (Cyl. 0*- 1128) d: 2369536 0 unused 0 0# (Cyl. 0 - 1156) This doesn't look right, does it? Offset is 63 instead of 64, and the NetBSD slice `c' is smaller than the root `a' partition. I'll do some tests later in the evening... -RVP
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On Friday, July 8th, 2022 at 12:31 AM, RVP wrote: > On Thu, 7 Jul 2022, br0nko wrote: > > > bash-5.1# vndconfig vnd0 /home/phil/alix-netbsd.9.2.img > > bash-5.1# fdisk -vv /dev/rvnd0 > > installboot -v -o timeout=5 /dev/rsd0a /usr/mdec/bootxx_ffsv1 > > > Is rsd0a where you copied /usr/mdec/boot, and dies rsd0a start at the > same sector as rsd0c (the NetBSD slice)? A disklabel output would > be useful... > > -RVP The mkimage script is taking care of copying the mdec/boot I think, here's from an image build from current tree: bash-5.1# vndconfig vnd0 example-amd64-image.img bash-5.1# fdisk -vv /dev/rvnd0 Disk: /dev/rvnd0 NetBSD disklabel disk geometry: cylinders: 1157, heads: 64, sectors/track: 32 (2048 sectors/cylinder) total sectors: 2369536, bytes/sector: 512 BIOS disk geometry: cylinders: 148, heads: 255, sectors/track: 63 (16065 sectors/cylinder) total sectors: 2369536 Partitions aligned to 2048 sector boundaries, offset 63 Partition table: 0: NetBSD (sysid 169) start 63, size 2312129 (1129 MB, Cyls 0/1/1-143/236/29), Active beg: cylinder0, head 1, sector 1 end: cylinder 143, head 236, sector 29 Information from PBR: Not bootable: All bytes are identical (0x00) Not bootable: Bad magic number (0x) 1: (sysid 0) start 0, size 0 beg: cylinder0, head 0, sector 0 end: cylinder0, head 0, sector 0 2: (sysid 0) start 0, size 0 beg: cylinder0, head 0, sector 0 end: cylinder0, head 0, sector 0 3: (sysid 0) start 0, size 0 beg: cylinder0, head 0, sector 0 end: cylinder0, head 0, sector 0 First active partition: 0 Drive serial number: 0 (0x) bash-5.1# disklabel /dev/rvnd0 # /dev/rvnd0: type: SCSI disk: STORAGE DEVICE label: fictitious flags: removable sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 1157 total sectors: 2369536 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 8 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] a: 236947363 4.2BSD 0 0 0 # (Cyl. 0*- 1156) c: 231212963 unused 0 0# (Cyl. 0*- 1128) d: 2369536 0 unused 0 0# (Cyl. 0 - 1156) bash-5.1# mount /dev/vnd0a /mnt bash-5.1# ls /mnt .cshrc altroot boot dev lib libexec netbsd rescue sbin tmp var .profile bin boot.cfg etc libdata mnt proc root stand usr bash-5.1# md5 /mnt/boot MD5 (/mnt/boot) = 9d721d7c85264b66deff2d8472370870 bash-5.1# md5 /usr/mdec/boot MD5 (/usr/mdec/boot) = 9d721d7c85264b66deff2d8472370870 bash-5.1# cat /mnt/boot.cfg menu=Boot normally:rndseed /var/db/entropy-file;boot menu=Boot single user:rndseed /var/db/entropy-file;boot -s menu=Drop to boot prompt:prompt default=1 timeout=5 clear=1 bash-5.1# head /mnt/etc/release NetBSD 9.99.98/amd64 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. br0nko
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On Thursday, July 7th, 2022 at 11:25 PM, Mike Pumford wrote: > On 07/07/2022 15:40, br0nko wrote: > > > Hi, > > > > 0: NetBSD (sysid 169) > > start 63, size 1568384 (766 MB, Cyls 0/1/1-97/160/62), Active > > beg: cylinder 0, head 1, sector 1 > > end: cylinder 97, head 160, sector 62 > > Information from PBR: > > Not bootable: All bytes are identical (0x00) > > Not bootable: Bad magic number (0x) > > No MBR boot code in the partition table. > > fdisk -i /dev/rvnd0 > > should resolve that I think. I did give a try, using an amd64 mkimage image build from current tree (9.99.98/amd64): = bash-5.1# vndconfig vnd0 example-amd64-image.img bash-5.1# fdisk -vv /dev/rvnd0 Disk: /dev/rvnd0 NetBSD disklabel disk geometry: cylinders: 1157, heads: 64, sectors/track: 32 (2048 sectors/cylinder) total sectors: 2369536, bytes/sector: 512 BIOS disk geometry: cylinders: 148, heads: 255, sectors/track: 63 (16065 sectors/cylinder) total sectors: 2369536 Partitions aligned to 2048 sector boundaries, offset 63 Partition table: 0: NetBSD (sysid 169) start 63, size 2312129 (1129 MB, Cyls 0/1/1-143/236/29), Active beg: cylinder0, head 1, sector 1 end: cylinder 143, head 236, sector 29 Information from PBR: Not bootable: All bytes are identical (0x00) Not bootable: Bad magic number (0x) 1: (sysid 0) start 0, size 0 beg: cylinder0, head 0, sector 0 end: cylinder0, head 0, sector 0 2: (sysid 0) start 0, size 0 beg: cylinder0, head 0, sector 0 end: cylinder0, head 0, sector 0 3: (sysid 0) start 0, size 0 beg: cylinder0, head 0, sector 0 end: cylinder0, head 0, sector 0 First active partition: 0 Drive serial number: 0 (0x) bash-5.1# disklabel /dev/rvnd0 # /dev/rvnd0: type: SCSI disk: STORAGE DEVICE label: fictitious flags: removable bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 1157 total sectors: 2369536 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 8 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] a: 236947363 4.2BSD 0 0 0 # (Cyl. 0*- 1156) c: 231212963 unused 0 0# (Cyl. 0*- 1128) d: 2369536 0 unused 0 0# (Cyl. 0 - 1156) bash-5.1# fdisk -i /dev/rvnd0 Update the bootcode from /usr/mdec/mbr? [n] y We haven't written the MBR back to disk yet. This is your last chance. Should we write new partition table? [n] y = Testing in qemu, I get "NetBSD MBR boot / Error No operating system" fdisk look the same: = bash-5.1# fdisk -vv /dev/rvnd0 Disk: /dev/rvnd0 NetBSD disklabel disk geometry: cylinders: 1157, heads: 64, sectors/track: 32 (2048 sectors/cylinder) total sectors: 2369536, bytes/sector: 512 BIOS disk geometry: cylinders: 148, heads: 255, sectors/track: 63 (16065 sectors/cylinder) total sectors: 2369536 Partitions aligned to 2048 sector boundaries, offset 63 Partition table: 0: NetBSD (sysid 169) start 63, size 2312129 (1129 MB, Cyls 0/1/1-143/236/29), Active beg: cylinder0, head 1, sector 1 end: cylinder 143, head 236, sector 29 Information from PBR: Not bootable: All bytes are identical (0x00) Not bootable: Bad magic number (0x) 1: (sysid 0) start 0, size 0 beg: cylinder0, head 0, sector 0 end: cylinder0, head 0, sector 0 2: (sysid 0) start 0, size 0 beg: cylinder0, head 0, sector 0 end: cylinder0, head 0, sector 0 3: (sysid 0) start 0, size 0 beg: cylinder0, head 0, sector 0 end: cylinder0, head 0, sector 0 Bootselector disabled. First active partition: 0 Drive serial number: 0 (0x) = Reinstalling primary bootstrap show a better fdisk output: = bash-5.1# installboot -v -o timeout=5 /dev/rvnd0a /usr/mdec/bootxx_ffsv1 File system: /dev/rvnd0a Primary bootstrap: /usr/mdec/bootxx_ffsv1 Ignoring PBR with invalid magic in sector 0 of `/dev/rvnd0a' Boot options:timeout 5, flags 0, speed 9600, ioaddr 0, console pc Disk: /dev/rvnd0 NetBSD disklabel disk geometry: cylinders: 1157, heads: 64, sectors/track: 32 (2048 sectors/cylinder) total sectors: 2369536, bytes/sector: 512 BIOS disk geometry: cylinders: 148, heads: 255, sectors/track: 63 (16065 sectors/cylinder) total sectors: 2369536 Partitions aligned to 2048 sector boundaries, offset 63
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On Thu, 7 Jul 2022, br0nko wrote: bash-5.1# vndconfig vnd0 /home/phil/alix-netbsd.9.2.img bash-5.1# fdisk -vv /dev/rvnd0 installboot -v -o timeout=5 /dev/rsd0a /usr/mdec/bootxx_ffsv1 Is rsd0a where you copied /usr/mdec/boot, and dies rsd0a start at the same sector as rsd0c (the NetBSD slice)? A disklabel output would be useful... -RVP
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On 07/07/2022 15:40, br0nko wrote: Hi, 0: NetBSD (sysid 169) start 63, size 1568384 (766 MB, Cyls 0/1/1-97/160/62), Active beg: cylinder0, head 1, sector 1 end: cylinder 97, head 160, sector 62 Information from PBR: Not bootable: All bytes are identical (0x00) Not bootable: Bad magic number (0x) No MBR boot code in the partition table. fdisk -i /dev/rvnd0 should resolve that I think.
i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
Hi,
I wanted to resurrect an old i386 alix box, and I did follow the guide to
create a custom image trough mkimage
(https://www.netbsd.org/docs/guide/en/chap-inst-media.html#chap-inst-media-creating-live-images).
I did first try on amd64 so that I can first test on my laptop. Build was
successful but when I boot the USB key, I'm stuck on primary bootstrap
("NetBSD/x86 ffsv1 Primary Bootstrap"), no error. However I can boot it from
grub (installed on the laptop hard-drive) , image is fully functional that way.
Here's what fdisk show:
=
bash-5.1# vndconfig vnd0 /home/phil/alix-netbsd.9.2.img
bash-5.1# fdisk -vv /dev/rvnd0
Disk: /dev/rvnd0
NetBSD disklabel disk geometry:
cylinders: 765, heads: 64, sectors/track: 32 (2048 sectors/cylinder)
total sectors: 1568447, bytes/sector: 512
BIOS disk geometry:
cylinders: 98, heads: 255, sectors/track: 63 (16065 sectors/cylinder)
total sectors: 1568447
Partitions aligned to 16065 sector boundaries, offset 63
Partition table:
0: NetBSD (sysid 169)
start 63, size 1568384 (766 MB, Cyls 0/1/1-97/160/62), Active
beg: cylinder0, head 1, sector 1
end: cylinder 97, head 160, sector 62
Information from PBR:
Not bootable: All bytes are identical (0x00)
Not bootable: Bad magic number (0x)
1: (sysid 0)
start 0, size 0
beg: cylinder0, head 0, sector 0
end: cylinder0, head 0, sector 0
2: (sysid 0)
start 0, size 0
beg: cylinder0, head 0, sector 0
end: cylinder0, head 0, sector 0
3: (sysid 0)
start 0, size 0
beg: cylinder0, head 0, sector 0
end: cylinder0, head 0, sector 0
First active partition: 0
Drive serial number: 0 (0x)
=
I did try to reinstall the primary bootstrap:
installboot -v -o timeout=5 /dev/rsd0a /usr/mdec/bootxx_ffsv1
But it didn't fix the problem either.
I'm running out of ideas, I don't really see what I'm missing. Any help would
be highly appreciated.
Br0nko
