Bug 264032 - riscv VM images are empty/blank
Summary: riscv VM images are empty/blank
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: riscv (show other bugs)
Version: 13.1-RELEASE
Hardware: riscv Any
: --- Affects Many People
Assignee: FreeBSD Release Engineering
URL: https://download.freebsd.org/ftp/rele...
: 264039 (view as bug list)
Depends on:
Blocks: 264030
  Show dependency treegraph
Reported: 2022-05-17 00:06 UTC by John-Mark Gurney
Modified: 2023-09-27 14:54 UTC (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description John-Mark Gurney freebsd_committer 2022-05-17 00:06:41 UTC
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.
Comment 1 John-Mark Gurney freebsd_committer 2022-05-17 00:07:59 UTC
change to re@  I think I'm doing this correct.
Comment 2 Glen Barber freebsd_committer 2022-05-17 03:59:50 UTC
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.
Comment 3 Glen Barber freebsd_committer 2022-05-17 12:44:46 UTC
*** Bug 264039 has been marked as a duplicate of this bug. ***
Comment 4 Li-Wen Hsu freebsd_committer 2022-07-12 19:47:36 UTC
(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?
Comment 5 Mark Johnston freebsd_committer 2022-07-12 19:49:57 UTC
(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.
Comment 6 Glen Barber freebsd_committer 2022-07-12 19:56:26 UTC
(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.
Comment 7 Glen Barber freebsd_committer 2022-07-12 19:57:41 UTC
(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)?
Comment 8 Glen Barber freebsd_committer 2022-07-12 19:58:58 UTC
(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.
Comment 9 Glen Barber freebsd_committer 2022-07-12 20:02:16 UTC
(In reply to Glen Barber from comment #6)
The empty images have been removed.

I'll keep this PR open, following feedback from Mark.
Comment 10 Mark Johnston freebsd_committer 2022-07-12 20:03:29 UTC
(In reply to Glen Barber from comment #7)
Not to my knowledge.  What kind of issues?
Comment 11 Graham Perrin freebsd_committer 2022-07-12 20:09:42 UTC
See also: bug 265179
Comment 12 Glen Barber freebsd_committer 2022-07-12 20:11:28 UTC
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
Comment 13 Mark Johnston freebsd_committer 2022-07-12 20:53:05 UTC
(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.
Comment 14 Mark Johnston freebsd_committer 2022-07-12 21:30:02 UTC
(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.
Comment 15 Glen Barber freebsd_committer 2022-07-13 03:50:52 UTC
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.)
Comment 17 Kornel Dulęba 2022-07-13 07:20:56 UTC
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.
Comment 18 Glen Barber freebsd_committer 2022-07-13 11:24:17 UTC
(In reply to Graham Perrin from comment #16)
Yes, thank you for the reminder.
Comment 19 Kornel Dulęba 2022-07-14 13:47:52 UTC
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.
Comment 20 Mark Johnston freebsd_committer 2022-07-14 13:52:37 UTC
(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:


See also comment 14.
Comment 21 Kornel Dulęba 2022-07-14 14:01:13 UTC
(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.
Comment 22 Mark Johnston freebsd_committer 2022-07-14 14:08:06 UTC
(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
# 1@cff7c9b40: internal old_cstotal
ndir   int32_t 0x00000884
nbfree int32_t 0x0000ab9b
nifree int32_t 0x000aa131
nffree int32_t 0x0000006b
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
# 1@cff7c9e70: internal cstotal
ndir        int64_t 0x000000000000088c
nbfree      int64_t 0x000000000000ab8e
nifree      int64_t 0x00000000000aa0ef
nffree      int64_t 0x000000000000004e
numclusters int64_t 0x0000000000000000
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 =====
Comment 23 Ed Maste freebsd_committer 2023-09-27 14:54:01 UTC
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?