NOOBS image does not build

[dlabun]

I am not sure what's changed recently, I am not getting a NOOBS image when running Pi-Gen. I've tried several times running the vanilla version straight off Github on a clean installation of Raspbian running in VMware and the image is never generated.

From looking at the build log, there's absolutely nothing that indicates the NOOBS image scripts were executed.

[dlabun]

Just to update... The deploy folder is never created in the process either. I do get my normal export image in the work folder.

[XECDesign]

Do you have appropriate stage*/EXPORT_NOOBS files? If so, could you please post their content your build.log (found in the work directory).

[dlabun]

Yes, I do have the EXPORT_NOOBS files. For the sake of troubleshooting I downloaded the most recent version of the repository and it won't even build completely.

I've attached EXPORT_NOOBS from stage 5 (I changed the extension so Github would take it) and the complete build.log. Below is just the section relevant to the export process... That's not a copy / paste error, the log ends at begin 01-run.sh.

02:53:53] Begin /home/pi/Desktop/pi-gen-nov/export-image
[02:53:53] Begin /home/pi/Desktop/pi-gen-nov/export-image/prerun.sh
[02:54:26] End /home/pi/Desktop/pi-gen-nov/export-image/prerun.sh
[02:54:27] Begin /home/pi/Desktop/pi-gen-nov/export-image/00-allow-rerun
[02:54:27] Begin /home/pi/Desktop/pi-gen-nov/export-image/00-allow-rerun/00-run.sh
[02:54:27] End /home/pi/Desktop/pi-gen-nov/export-image/00-allow-rerun/00-run.sh
[02:54:27] End /home/pi/Desktop/pi-gen-nov/export-image/00-allow-rerun
[02:54:27] Begin /home/pi/Desktop/pi-gen-nov/export-image/01-set-sources
[02:54:27] Begin /home/pi/Desktop/pi-gen-nov/export-image/01-set-sources/00-patches
[02:54:27] End /home/pi/Desktop/pi-gen-nov/export-image/01-set-sources/00-patches
[02:54:27] Begin /home/pi/Desktop/pi-gen-nov/export-image/01-set-sources/01-run.sh
[02:54:42] End /home/pi/Desktop/pi-gen-nov/export-image/01-set-sources/01-run.sh
[02:54:42] End /home/pi/Desktop/pi-gen-nov/export-image/01-set-sources
[02:54:42] Begin /home/pi/Desktop/pi-gen-nov/export-image/02-network
[02:54:42] Begin /home/pi/Desktop/pi-gen-nov/export-image/02-network/01-run.sh
[02:54:42] End /home/pi/Desktop/pi-gen-nov/export-image/02-network/01-run.sh
[02:54:42] End /home/pi/Desktop/pi-gen-nov/export-image/02-network
[02:54:42] Begin /home/pi/Desktop/pi-gen-nov/export-image/03-set-partuuid
[02:54:42] Begin /home/pi/Desktop/pi-gen-nov/export-image/03-set-partuuid/00-run.sh
[02:54:42] End /home/pi/Desktop/pi-gen-nov/export-image/03-set-partuuid/00-run.sh
[02:54:42] End /home/pi/Desktop/pi-gen-nov/export-image/03-set-partuuid
[02:54:42] Begin /home/pi/Desktop/pi-gen-nov/export-image/04-finalise
[02:54:42] Begin /home/pi/Desktop/pi-gen-nov/export-image/04-finalise/01-run.sh

build.log

EXPORT_NOOBS.txt

[XECDesign]

Oh right, forgot what you said in the forum thread. You're downloading the archive of this repo rather than doing a proper git clone, right? If so, that would be the problem.

[dlabun]

No, both cloning and downloading releases are failing. At first I got I broke something in my clone, but even fresh clones are no good.

I think this all started after the commit 93db373 on March 28th... Literally I went everything working fine to being broke. I think the problem lies in export-image/04-finalise/01-run.sh. Between stopping the HW clock and creating the deploy folder is the chunk of code connecting to Github for information. This VM has an unrestricted internet connection so doubt it's a firewall issue.

[XECDesign]

In export-image/04-finalise/01-run.sh, could you put 'set -x' near the start of the file, run the build and then paste the last chunk of output?

[432asdfpsisdfDDsdr]

Build Env: QEMU running Debian 9u4
I dont know if this matters but I built three images forked off this project , then the last one I built began failing after an update on 4/18 to :https://archive.raspberrypi.org/debian/dists/stretch/
After this new sync, I had to chroot in and finish my last project afterwards because the image would not build after that for me. From what I could tell the error messages at that time referred to a change in packages or something similar that has a mismatched hash. I thought it was just a temporary sync issue. So, this may have nothing to do with your issues or it may. My builds worked perfect between 4/11 and 4/17. I also mirrored the raspbian sites after errors on 4/18, as many devs do to reduce the netload. I have not resigned my local repos yet, and they are not setup. Regardless, I have not built a single image from pi-gen since archive.raspberrypi.org was updated, I have not tried in several days. I worked around by chrooting in and remastering the image file, which I know is not the preferred way. I'm testing a clean git clone/rebuild now to see if my error still exists, if so I will post here.

Updated:
My previous build problems with archive.raspberrypi.org starting 4/18 appear to have been temporary. So no problems on that. But I still have another issue that ive noticed before, so I'm pasting it into a new thread. This long rant is no help specifically to any problems, but the next posting might be relevant.

[dlabun]

Okay it just finished running and here's what I got:

+ ln -nsf /proc/mounts /home/pi/Desktop/pi-gen-nov/work/2018-04-24-RaspbianTest/export-image/rootfs/etc/mtab
++ find /home/pi/Desktop/pi-gen-nov/work/2018-04-24-RaspbianTest/export-image/rootfs/var/log/ -type f
+ for _FILE in $(find ${ROOTFS_DIR}/var/log/ -type f)
+ true
+ for _FILE in $(find ${ROOTFS_DIR}/var/log/ -type f)
+ true
+ for _FILE in $(find ${ROOTFS_DIR}/var/log/ -type f)
+ true
+ for _FILE in $(find ${ROOTFS_DIR}/var/log/ -type f)
+ true
+ for _FILE in $(find ${ROOTFS_DIR}/var/log/ -type f)
+ true
+ for _FILE in $(find ${ROOTFS_DIR}/var/log/ -type f)
+ true
+ for _FILE in $(find ${ROOTFS_DIR}/var/log/ -type f)
+ true
+ for _FILE in $(find ${ROOTFS_DIR}/var/log/ -type f)
+ true
+ for _FILE in $(find ${ROOTFS_DIR}/var/log/ -type f)
+ true
+ for _FILE in $(find ${ROOTFS_DIR}/var/log/ -type f)
+ true
+ rm -f /home/pi/Desktop/pi-gen-nov/work/2018-04-24-RaspbianTest/export-image/rootfs/root/.vnc/private.key
+ rm -f /home/pi/Desktop/pi-gen-nov/work/2018-04-24-RaspbianTest/export-image/rootfs/etc/vnc/updateid
++ basename /home/pi/Desktop/pi-gen-nov/stage2
+ update_issue stage2
+ local GIT_HASH
++ git rev-parse HEAD
fatal: Not a git repository (or any of the parent directories): .git
+ GIT_HASH=
pi@raspberry:

[432asdfpsisdfDDsdr]

@XECDesign
While trying to build a lite image through stage two i've seen this a couple times.
START COPY:
Command (m for help):
Disk /home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-image/2018-04-24-TestBuild20180424-4GB.img: 800 MiB, 838860800 bytes, 1638400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x804ef162

Device Boot Start End Sectors Size Id Type
/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-image/2018-04-24-TestBuild20180424-4GB.img1 8192 8192 1 512B c W95 FAT32 (LBA)
/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-image/2018-04-24-TestBuild20180424-4GB.img2 16384 1638399 1622016 792M 83 Linux

Command (m for help): The partition table has been altered.
Syncing disks.

/boot: offset 4194304, length 512
/: offset 8388608, length 830472192
mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows
mkdosfs: Too few blocks for viable filesystem

END PASTE

Perhaps Im just nuts but, or perhaps im just nuts AND
My deduction, is the math is wrong on calculating the boot partition as a 512 byte size is just large enough for a boot sector but nothing else really.

[432asdfpsisdfDDsdr]

Here's a better copy paste of whole event:
START COPY:

[16:07:56] Begin /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image/03-set-partuuid/00-run.sh
[16:07:56] End /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image/03-set-partuuid/00-run.sh
[16:07:56] End /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image/03-set-partuuid
[16:07:56] Begin /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image/04-finalise
[16:07:57] Begin /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image/04-finalise/01-run.sh
Stopping fake hwclock: saving system time.
Mode: real
Files: 2289
Linked: 411 files
Compared: 0 xattrs
Compared: 633 files
Saved: 14.37 MiB
Duration: 0.32 seconds
14905/189452/427008
adding: 2018-04-24-TestBuild20180424-lite.img (deflated 80%)
[16:10:26] End /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image/04-finalise/01-run.sh
[16:10:26] End /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image/04-finalise
[16:10:26] End /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image
[16:10:26] Begin /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-noobs
[16:10:26] Begin /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-noobs/prerun.sh
/boot: offset 4194304, length 45206016
/: offset 50331648, length 1749024768
'/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-noobs/rootfs/etc/systemd/system/multi-user.target.wants/apply_noobs_os_config.service' -> '/lib/systemd/system/apply_noobs_os_config.service'
[16:22:17] End /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-noobs/prerun.sh
[16:22:17] Begin /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-noobs/00-release
[16:22:17] Begin /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-noobs/00-release/00-run.sh
'files/partition_setup.sh' -> '/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-noobs/2018-04-24-TestBuild20180424-lite/partition_setup.sh'
'files/partitions.json' -> '/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-noobs/2018-04-24-TestBuild20180424-lite/partitions.json'
'files/os.json' -> '/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-noobs/2018-04-24-TestBuild20180424-lite/os.json'
'files/OS.png' -> '/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-noobs/2018-04-24-TestBuild20180424-lite/OS.png'
'files/release_notes.txt' -> '/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-noobs/2018-04-24-TestBuild20180424-lite/release_notes.txt'
./
./slides_vga/
./slides_vga/G.png
./slides_vga/B.png
./slides_vga/E.png
./slides_vga/D.png
./slides_vga/A.png
./slides_vga/F.png
./slides_vga/C.png
[16:22:18] End /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-noobs/00-release/00-run.sh
[16:22:18] End /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-noobs/00-release
[16:22:18] End /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-noobs
[16:22:18] Begin /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image
[16:22:18] Begin /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image/prerun.sh
du: cannot access '/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/stage4/rootfs/boot': No such file or directory
du: cannot access '/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/stage4/rootfs': No such file or directory

Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x51c014e9.

Command (m for help): Created a new DOS disklabel with disk identifier 0x804ef162.

Command (m for help): Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p):
Using default response p.
Partition number (1-4, default 1): First sector (2048-1638399, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (8192-1638399, default 1638399):
Created a new partition 1 of type 'Linux' and of size 512 B.

Command (m for help): Disk /home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-image/2018-04-24-TestBuild20180424-4GB.img: 800 MiB, 838860800 bytes, 1638400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x804ef162

Device Boot Start End Sectors Size Id Type
/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-image/2018-04-24-TestBuild20180424-4GB.img1 8192 8192 1 512B 83 Linux

Command (m for help): Selected partition 1
Partition type (type L to list all types): Changed type of partition 'Linux' to 'W95 FAT32 (LBA)'.

Command (m for help): Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p):
Using default response p.
Partition number (2-4, default 2): First sector (2048-1638399, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (16384-1638399, default 1638399):
Created a new partition 2 of type 'Linux' and of size 792 MiB.

Command (m for help):

Command (m for help):
Disk /home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-image/2018-04-24-TestBuild20180424-4GB.img: 800 MiB, 838860800 bytes, 1638400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x804ef162

Device Boot Start End Sectors Size Id Type
/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-image/2018-04-24-TestBuild20180424-4GB.img1 8192 8192 1 512B c W95 FAT32 (LBA)
/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-image/2018-04-24-TestBuild20180424-4GB.img2 16384 1638399 1622016 792M 83 Linux

Command (m for help): The partition table has been altered.
Syncing disks.

/boot: offset 4194304, length 512
/: offset 8388608, length 830472192
mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows
mkdosfs: Too few blocks for viable filesystem

END PASTE

Take what I suggest with a grain of salt, as I've just started looking at this and I may not understand whats happening or intended to happen. That being said this part doesnt look right to me:

/boot: offset 4194304, length 512

[432asdfpsisdfDDsdr]

Also note, I personally have no issue as I can work around the n00bs issue and build as "lite" for my needs mostly, I'm just trying to help on what I noticed before about a 512byte part that seemed strange.

[dlabun]

@kelsieflynn I take it you made that clone today? What's your build environment?

I'm going to spin up a fresh VM just to see if I do fail in the same spot or if I can make it as far as you.

[432asdfpsisdfDDsdr]

@dlabun

Qemu virt running debian 9update4
Specifically, I started from:

debian-9.4.0-amd64-xfce-CD-1.iso

Which is in the cd image repos.
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

After installing
I followed instructions to get the build deps update it and get it dev ready for pi-gen.
Then, then today I did a fresh git clone and then add a config file/name, added SKIP files to stages 3,4,5
then ran build.sh

Anywho, I can build lites just fine. I'll leave the rest of the this to the real devs, which I am not. In all sincerity, I'm really new to the debian building system and raspbian.

root@deb9u4-rpi-gendev:/home/dev1/NEWCLONE_4.24.2018/pi-gen# ls -al deploy/
total 357992
drwxr-xr-x 3 root root 4096 Apr 24 16:22 .
drwxr-xr-x 14 dev1 dev1 4096 Apr 24 16:08 ..
drwxr-xr-x 2 root root 4096 Apr 24 16:22 2018-04-24-TestBuild20180424-lite
-rw-r--r-- 1 root root 54142 Apr 24 16:10 2018-04-24-TestBuild20180424-lite.info
-rw-r--r-- 1 root root 366508989 Apr 24 16:10 image_2018-04-24-TestBuild20180424-lite.zip

[dlabun]

I have a fresh clone running in a new Raspbian VM, let's see how this goes... It looks like the mirrors are a little slow today so it's taking a while.

(FYI, not a Linux developer at all... I'm hardware only)

[432asdfpsisdfDDsdr]

I think I see more about what failed on my setup and why it only got a 512 byte boot part when trying to create the last image.

"[16:22:18] Begin /home/dev1/NEWCLONE_4.24.2018/pi-gen/export-image/prerun.sh
du: cannot access '/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/stage4/rootfs/boot': No such file or directory
du: cannot access '/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/stage4/rootfs': No such file or directory"

It appears to me that in the code below is where the BOOT size is set :

From :
https://github.com/RPi-Distro/pi-gen/blob/master/export-image/prerun.sh

BOOT_SIZE=$(du --apparent-size -s "${EXPORT_ROOTFS_DIR}/boot" --block-size=1 | cut -f 1)

It makes sense to me why mine failed as why du complained first and why because without my old
chroot mount, the apparent-size appears to be only 512.

Real question might be now, why did my boot chroot close after it created the "lite" stage and if it did close, why cant the noobs stage reopen? Did a loopback just go missing from losetup?

On follow up:
My loopback didnt just goaway it was still avail but is 512 in size.

Here's the stale mounts I have left over, maybe this will help the devs:

/dev/loop1: [2054]:2237732 (/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-image/2018-04-24-TestBuild20180424-4GB.img), offset 8388608, sizelimit 830472192
/dev/loop0: [2054]:2237732 (/home/dev1/NEWCLONE_4.24.2018/pi-gen/work/2018-04-24-TestBuild20180424/export-image/2018-04-24-TestBuild20180424-4GB.img), offset 4194304, sizelimit 512

I think i've surely exhausted all i can do on this at this point since from my understanding:
https://github.com/RPi-Distro/pi-gen/blob/master/export-image/prerun.sh
is where it first grabs the previous image built then re-sets it up for noobs. Then for some reason on creation of the boot partition for the noobs image it creates a initial boot partition too small, which results in a first seen error from the console (du) then the final error, when mkdosfs complains it cant make a filesystem on a 512 b filesystem,
"mkdosfs: Too few blocks for viable filesystem"
(interpretation:(because its too small)

To make it even funner to figure out when fdisk first created the relevant part /boot, it appears as if it should have gotten larger than 512B because it choose the default 16383399 for end
and 8192-1638399 , does actually result in larger than 512B, however the output statement proudly exclaims:
"Created a new partition 1 of type 'Linux' and of size 512 B."

"Partition number (1-4, default 1): First sector (2048-1638399, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (8192-1638399, default 1638399):"

I like a good math/syntax mystery myself, so i'll be following up to see what the deal is/was.

Hope this helps.

[XECDesign]

@dlabun that really looks like you're not running it from a git cloned directory.

The failing line is git rev-parse HEAD, which isn't anything fancy.

What does ls -la /home/pi/Desktop/pi-gen-nov/.git/ say?

[dlabun]

I started from scratch last night and everything is working correctly now... The only thing I could figure is that the something on my system became corrupt and was causing the script to think it wasn't a git clone directory.

Is running the tool on Raspbian advisable or should I be doing it elsewhere?

[XECDesign]

I haven't used it under Raspbian since writing the initial version, so I don't know if it still works. Current stable releases of Debian and Ubuntu should work.

[432asdfpsisdfDDsdr]

Im still curious about what happens when I build it as lite. I'll rebuild mine fresh again today without the SKIP files and see if it creates the noobs portion in my setup, perhaps thats how its suppose to work in a lite build, duh. I have used both debian 9u4 and ubuntu LTS(latest) both, but deb9u4 seems to work better for me. Eitherway, as mentioned before, I dont really have a problem with the script myself as I'm not using the noobs portion but I would still like to understand what I'm missing in my understanding here, though its likely isolated to my setup.

[XECDesign]

@kelsieflynn I've tried to skim through your posts for relevant information, but I'm struggling to understand what the problem is.

You said you added SKIP files for stages 3, 4 & 5, and then your lite images build fine? Yet, it looks like you're still trying to export later stages (which of course wouldn't work if you haven't built them). Have you deleted the EXPORT* files from those later stages?

A short summary with the relevant error messages would be helpful.

[432asdfpsisdfDDsdr]

@XECDesign
I dont have a problem per say. I've experimented a lot with this great setup, and I managed to get a few builds that worked for my cases. When something has gone wrong, I'm sure I triggered something out of order or didnt understand what was happening in the stages fully.
I've re-read over the instructions, seems like I missed putting a SKIP_IMAGES or something before. Everything works as intended, when i follow the script exactly.

What appeared to be a problem may have been my curiosity going wild, as to how the script works when creating the noobs portion. All's good here though, script works great. I dont have to tell you this script is great as you all can tell from the # of forks. But anyway, its great, all I need now is my local mirrors of the repos setup or at least a deb squid cache.

[XECDesign]

Oh, alright. Thanks, I'm glad you've found it useful.

[432asdfpsisdfDDsdr]

Sorry for the noise, Everyone struggles following me, mostly because i have a little bit of ADHD, talk to myself often, answer back often, and I go on long curiosity tangents. Its all part of how I roll.

[XECDesign]

No worries. You do you.

[XECDesign]

@dlabun okay to close?

[dlabun]

Absolutely, thanks for the help!

[kevinastone]

I ran into this issue today. I have pi-gen checked out as a git submodule in my larger project repo and build the images using docker. Since docker cannot access the parent repo, this command here fails: https://github.com/RPi-Distro/pi-gen/blob/master/scripts/common#L98

Would the team be interested to move setting and passing on GIT_HASH to the build.sh and build-docker.sh scripts? I'd think this is less fragile than trying to access the git repo in the build process itself.

[XECDesign]

passing on GIT_HASH to the build.sh

Passing from where?

[kevinastone]

Something like this where build.sh and build-docker.sh determine the git-hash and pass it into the build stages.

This would also allow overriding this in the build config file.

kevinastone@a171ecf

[XECDesign]

Ah, passing FROM build.sh rather than TO build.sh? Yeah, if it solves the problem, why not.