Bug 264032
| Summary: | riscv VM images are empty/blank | ||
|---|---|---|---|
| Product: | Base System | Reporter: | John-Mark Gurney <jmg> |
| Component: | riscv | Assignee: | FreeBSD Release Engineering <re> |
| Status: | In Progress --- | ||
| Severity: | Affects Many People | CC: | asomers, emaste, grahamperrin, kd, kornel555, lvd.lopata, lwhsu, markj |
| Priority: | --- | ||
| Version: | 13.1-RELEASE | ||
| Hardware: | riscv | ||
| OS: | Any | ||
| URL: | https://download.freebsd.org/ftp/releases/VM-IMAGES/13.1-RELEASE/riscv64/Latest/ | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264640 | ||
| Bug Depends on: | |||
| Bug Blocks: | 264030 | ||
|
Description
John-Mark Gurney
2022-05-17 00:06:41 UTC
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? |