the files at:
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.
/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
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
(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:
– should there be late-breaking news?
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 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 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 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?