the files at: https://download.freebsd.org/ftp/releases/VM-IMAGES/13.1-RELEASE/riscv64/Latest/ Are all 32 bytes, and when unxz'd result in zero byte files. If I got the depends/blocks wrong, feel free to fix it.
change to re@ I think I'm doing this correct.
They have apparently been zero-sized files throughout the entire release cycle, and no one had noticed. The only actionable point at this time is to pull them from the mirrors.
*** Bug 264039 has been marked as a duplicate of this bug. ***
(In reply to Glen Barber from comment #2) The empty files are still on all mirrors, are we going to pull them down or upload new ones?
(In reply to Li-Wen Hsu from comment #4) It also seems that the latest snapshots have the same problem, so the underlying issue, whatever it is wasn't fixed. I'll see if I can reproduce it locally.
(In reply to Li-Wen Hsu from comment #4) They are going to be pulled. Apologies for the delay in getting rid of these empty images.
(In reply to Mark Johnston from comment #5) Possibly related, I am seeing new (weird) issues with aarch64 and riscv on stable/13. Are we missing any MFCs to stable/13, particularly with makefs(8)?
(In reply to Glen Barber from comment #7) I ask specifically about makefs(8) because that is the only thing notable that I see that had been changed/implemented in our image build process, particularly moving from using md(4)-backed files.
(In reply to Glen Barber from comment #6) The empty images have been removed. I'll keep this PR open, following feedback from Mark.
(In reply to Glen Barber from comment #7) Not to my knowledge. What kind of issues?
See also: bug 265179
I just found the following error in last week's snapshot builds. This is the 'vm-image' target for amd64, but the error is the same for riscv and aarch64 as well. (This is on stable/13, yet I do not see similar errors on main.) Creating image... Please wait. Creating `/tmp/efiboot.0hqOWP' /tmp/efiboot.0hqOWP: 65528 sectors in 65528 FAT32 clusters (512 bytes/cluster) BytesPerSec=512 SecPerClust=1 ResSectors=32 FATs=2 Media=0xf0 SecPerTrack=63 Heads=255 HiddenSecs=0 HugeSectors=66584 FATsecs=512 RootCluster=2 FSInfo=1 Backup=2 Populating `/tmp/efiboot.0hqOWP' Image `/tmp/efiboot.0hqOWP' complete Building filesystem... Please wait. makefs: `/usr/obj/usr/src/amd64.amd64/release/vm-image' size of 4305321984 is larger than the maxsize of 4294967296. Building final disk image... Please wait. mkimg: partition 4: No such file or directory touch vm-image
(In reply to Glen Barber from comment #12) release/Makefile.vm sets VMSIZE=4096m. The error seems to be saying that there is more than 4096m of input data. Looks like the default needs to be bumped? I just reproduced the same problem locally with riscv, and bumping VMSIZE indeed fixes it.
(In reply to Mark Johnston from comment #13) Hmm, may be a bug in commit ecdc04d006de93eb343ce3b77208abd937d4f8ac ? I had to bump the VM image size from 4GB to 5GB to avoid the error from makefs, but running df(1) in a VM gives me: root@freebsd:~ # df -h Filesystem Size Used Avail Capacity Mounted on /dev/vtbd0p3 4.8G 3.5G 977M 79% / devfs 1.0K 1.0K 0B 100% /dev /dev/gpt/efiesp 32M 1.1M 31M 4% /boot/efi Or perhaps I misunderstand what exactly df is reporting.
No, I believe you understand correctly what df(1) reports. Note, for both main and stable/13, I had already bumped the size from 3072M to 4096M (cf83038cec6874aafacf56a1cac531d079af016b in main, immediately MFC'd). I had not (yet) done this for riscv/riscv64, however. Could you please confirm which TARGET/TARGET_ARCH you had built? (Although, I do not think it is relevant, more of a curiosity at this point.)
(In reply to Glen Barber from comment #9) Since availability no longer matches what was announced: <https://www.freebsd.org/releases/13.1R/announce.asc> | <https://www.freebsd.org/releases/13.1R/announce/#_availability> | <https://www.freebsd.org/releases/13.1R/announce/#_riscv_riscv64> – should there be late-breaking news? <https://www.freebsd.org/releases/13.1R/errata/#late-news> | <https://github.com/freebsd/freebsd-doc/blob/main/website/content/en/releases/13.1R/errata.adoc#late-breaking-news> | <https://cgit.freebsd.org/doc/tree/website/content/en/releases/13.1R/errata.adoc#n105>
Looks like it's caused by ecdc04d006de. The formula for calculating the output partition size looks like this: max(roundup(1.08*autocalculated_size, block_size), min_size(-M)). Without this patch autocalculated_size would usually not be enough to fit all the files and we'd have to pass the size through -M. I'll look into this.
(In reply to Graham Perrin from comment #16) Yes, thank you for the reminder.
After looking into this a bit more, I start to think that ecdc04d006de might not be the culprit, or at least it didn't cause the riscv VM image build failure. The release/riscv/GENERICSD.conf config doesn't use makefs at all. It specifies EMBEDDEDBUILD=1, which causes release/release.sh to use logic located in release/tools/arm.subr. Instead of creating rootfs with makefs it makes a new partition with newfs and then populates it with installworld, installkernel etc. Build failure using that configuration can't be related to the makefs changes. Maybe we just reached a point where 4GB is just not enough for a VM image? I'll try to build VM images using WITH_VMIMAGES instead and see what happens.
(In reply to Kornel Dulęba from comment #19) I think the VM image builds won't use GENERIDSD.conf? I tested the build like this: # make -C vm-image WITH_VMIMAGES=1 VMFORMATS=raw TARGET=riscv TARGET_ARCH=riscv64 KERNCONF=GENERIC See also comment 14.
(In reply to Mark Johnston from comment #20) Hmm, good point. Could you share the output of `ffsinfo -l1 /dev/vtbd0p3`? I've noticed that the image size of GENERICSD.conf was just bumped in https://cgit.freebsd.org/src/commit/?id=1dfcff294e44d4b45813288ef4095c36abb22f0e, so I though that that was failing to build too.
(In reply to Kornel Dulęba from comment #21) Here you go: root@freebsd:~ # ffsinfo -l1 /dev/vtbd0p3 ===== START SUPERBLOCK ===== # 0@cff7c9a80: primary sblock sblkno int32_t 0x00000018 cblkno int32_t 0x00000020 iblkno int32_t 0x00000028 dblkno int32_t 0x000013c0 old_cgoffset int32_t 0x00000000 old_cgmask int32_t 0x00000000 old_time int32_t 0 old_size int32_t 0x00000000 old_dsize int32_t 0x00000000 ncg int32_t 0x00000009 bsize int32_t 0x00008000 fsize int32_t 0x00001000 frag int32_t 0x00000008 minfree int32_t 0x00000008 old_rotdelay int32_t 0x00000000 old_rps int32_t 0x00000000 bmask int32_t 0xffff8000 fmask int32_t 0xfffff000 bshift int32_t 0x0000000f fshift int32_t 0x0000000c maxcontig int32_t 0x00000002 maxbpg int32_t 0x00002000 fragshift int32_t 0x00000003 fsbtodb int32_t 0x00000003 sbsize int32_t 0x00001000 spare1 int32_t[2] 0x00000000 0x00000000 nindir int32_t 0x00001000 inopb int32_t 0x00000080 old_nspf int32_t 0x00000000 optim int32_t 0x00000000 old_npsect int32_t 0x00000000 old_interleave int32_t 0x00000000 old_trackskew int32_t 0x00000000 id int32_t[2] 0x62cddef9 0x284e4aba old_csaddr int32_t 0x00000000 cssize int32_t 0x00001000 cgsize int32_t 0x00008000 spare2 int32_t 0x00000000 old_nsect int32_t 0x00000000 old_spc int32_t 0x00000000 old_ncyl int32_t 0x00000000 old_cpg int32_t 0x00000000 ipg int32_t 0x00013980 fpg int32_t 0x00027250 ===== START CYLINDER SUMMARY ===== # 1@cff7c9b40: internal old_cstotal ndir int32_t 0x00000884 nbfree int32_t 0x0000ab9b nifree int32_t 0x000aa131 nffree int32_t 0x0000006b ===== END CYLINDER SUMMARY ===== fmod int8_t 0x00 clean int8_t 0x00 ronly int8_t 0x00 old_flags int8_t 0xffffff80 fsmnt u_char[MAXMNTLEN] "/" volname u_char[MAXVOLLEN] "rootfs" swuid u_int64_t 0x0000000000000000 pad int32_t 0x00000000 cgrotor int32_t 0x00000000 old_cpc int32_t 0x00000000 maxbsize int32_t 0x00008000 unrefs int64_t 0x00000000 sblockloc int64_t 0x0000000000010000 ===== START CYLINDER SUMMARY TOTAL ===== # 1@cff7c9e70: internal cstotal ndir int64_t 0x000000000000088c nbfree int64_t 0x000000000000ab8e nifree int64_t 0x00000000000aa0ef nffree int64_t 0x000000000000004e numclusters int64_t 0x0000000000000000 ===== END CYLINDER SUMMARY TOTAL ===== time ufs_time_t 1657807640 size int64_t 0x0000000000140000 dsize int64_t 0x0000000000134eff csaddr ufs2_daddr_t 0x00000000000013c0 pendingblocks int64_t 0x0000000000000000 pendinginodes int32_t 0x00000000 snapinum int32_t[ 0] 0x00000000 avgfilesize int32_t 0x00004000 avgfpdir int32_t 0x00000040 save_cgsize int32_t 0x00000000 flags int32_t 0x00000002 contigsumsize int32_t 0x00000002 maxsymlinklen int32_t 0x00000078 old_inodefmt int32_t 0x00000002 maxfilesize u_int64_t 0x000800800805ffff qbmask int64_t 0x0000000000007fff qfmask int64_t 0x0000000000000fff state int32_t 0x00000000 old_postblformat int32_t 0x00000000 old_nrpos int32_t 0x00000000 spare5 int32_t[2] 0x00000000 0x00000000 magic int32_t 0x19540119 ===== END SUPERBLOCK =====
I have not tried booting them but the snapshot images in https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/riscv64/20230921/ are not empty files. I suppose this is fixed?
(In reply to Ed Maste from comment #23) The images for 13-RELEASE still empty, but 14-RELEASE and 15-CURRENT appears to be ok.
This was fixed, but 13.x got bigger so it's now unfixed on 13. I'll bump the riscv64 VM sizes there.
Should be fixed in 13 as of a few minutes ago. I'm adding a check to the snapshot builds to hopefully catch these out-of-disk-space errors faster in the future.