revolutionpi / imagebakery Goto Github PK

It appears that the path to the dt-blob file is incorrect (the specified file does not exist after installation of the raspberrypi-kernel package from the official Kunbus/Revolution Pi package repo). It seems to me that the file name should be specific to the model, in which case the user should be able to pass the model info as a parameter on script invocation. One should then include the model specification as part of the file path.

Hello,

I can build the image successfully, there is one part that I don't know how to make it work is either increasing the size of the available space for the application. I tried to comment out this part but still the image is around 1.6GB ~ 1.7GB

# shrink image to speed up flashing
resize2fs -M "$LOOPDEVICE"p2
PARTSIZE=$(dumpe2fs -h "$LOOPDEVICE"p2 | egrep "^Block count:" | cut -d" " -f3-)
PARTSIZE=$(($PARTSIZE * 16))   # ext4 uses 4k blocks, partitions use 512 bytes
sfdisk --dump "$LOOPDEVICE" | /bin/sed -r -e "\$!n
\$s/size=[^,]+/size=$PARTSIZE/" | /sbin/sfdisk "$LOOPDEVICE"
PARTSTART=$(cat /sys/block/$(basename "$LOOPDEVICE")/$(basename "$LOOPDEVICE"p2)/start)
truncate -s $((512 * ($PARTSTART + $PARTSIZE))) "$1"

Can you advise with some solutions?

Thanks,

Baking an image with the latest Raspbian Lite (2019-04-08-raspbian-stretch-lite.zip) and flashing a device with it leads to the following error message after entering product/serial/mac on first-run:

/usr/sbin/revpi-factory-reset: line 49: /usr/bin/dtoverlay: No such file or directory
Password:	getSerNum() failed -1

Adjusting the README to mention a specific version of Raspbian instead of the latest one would already be helpful enough.

With this command:

./imagebakery/shrink_image.sh 2017-04-10-raspbian-jessie.img `date +%F`-raspbian-shrunk.img

The script exists after creating the destination filesystem

The partition table has been altered.
Syncing disks.
+ partx 2017-05-30-raspbian-shrunk.img
NR START     END SECTORS SIZE NAME UUID
 1  8192   92159   83968  41M      402e4a57-01
 2 92160 7589887 7497728 3,6G      402e4a57-02
+ losetup /dev/loop1 2017-05-30-raspbian-shrunk.img
+ partprobe /dev/loop1
+ mkfs.ext4 /dev/loop1p2
mke2fs 1.43.4 (31-Jan-2017)
/dev/loop1p2 contains am ext4 file system
	last mounted on Tue May 30 10:14:04 2017
Proceed anyway? (y,N) y

Is it mke2fs returning something else than 0?

Hi,

the kernel being baked into the image is for an ARMv6, which means there are no floating point instruction sets for the RevPi Core 1. Still the image being shipped is armhf... this causes problems with the architecture of self created debian packages and the corresponding ABI of the compiled binaries. The latter has to be gnueabi, the former to apease the debian package manager gnueabihf, since we are talkinkg about a armhf image.

Running a application compiled for armhf (gnueabihf), making use of the floating point instruction set results in segfaults. Currently we're working around the issue by emulating fp operations in the program itself and shipping a arm (gnueabi) version as a binary in a armhf debian package... its a little messy.

Are we the only ones having this issue?

Any chance of fixing this, considering Core3 is the currently sold product (we happen to have only one Core1, everything else is Core3)

Best regards,
lwk

Imagebakery uses fdisk to manipulate the image file. On debian buster fdisk (libfdisk) has a bug where it fails if the MSB in the image UID is set.

The issue is documented in the Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972244

The raspios_armhf-2021-03-25 is based on Debian buster, which is now "oldstable". apt-get update fails with:

"changed its 'Suite' from 'stable' to 'oldstable'"

This must be accepted explicitly and apt-secure is proposed.
I guess another way would be to update to 'oldstable' in the .list files.
I also found this online: sudo apt-get update --allow-releaseinfo-change

What would be the best way to change the customize_image.sh to accommodate for this?

When running customize_image.sh on Raspbian Stretch lite 08-04-2019 , getting an error :
failed to create symbolic link '$IMAGEDIR/etc/cron.hourly/logrotate': File exists

Adding a line in the shell script to remove the $IMAGEDIR/etc/cron.hourly/logrotate solves the issue.