Building our own OrangePi image?

Is it authorized to download the stretch version of an image from Armbian…then run the prep script to build our own dietpi V6.4?

I downloaded the Armbian Debian_stretch_next for Orange Pi Zero
Installed it…got it working (took me several tries…uggh), did a full apt update and upgrade (it updated the kernel from the stretch repository)
Then ran the dietpi prep script…it took a LOOOOOONG time…but built a dietpi V6.2 which then upgraded to V6.4, currently working VERY well and stable

Is that a viable and correct way to build a dietpi image for those if we do it ourselves rather than the dietpi team?

For the life of me I could not get a Debian stretch build on the OPiZero… (I guess mainly because it needs user interaction to install???)[or I just don’t know what pre-load script I should use]

Just wanting to know if this is a viable/legal/whatever method to build our own images

Then your SD card is too slow. If such a task like deleting a lot of packages takes a ‘LOOOOOONG’ time this is an indication that random IO storage performance is too low. Unfortunately the speed tests DietPi has included test only for irrelevant sequential performance.

Oversimplified: Sequential performance is important when you store pictures or video on your SD card (the ‘camera’ use case), random IO performance is important when running an operating system from SD card (the ‘single board computer’ use case).

I bet if you replace your SD card with a cheap SanDisk Ultra A1 then such tasks that now take that ‘LOOOOOONG’ will finish almost instantly afterwards since those new A1 rated SD cards are usually at least 100 times faster than old SD cards when it’s about random IO with small chunks of data.

Check Jeff Geerling’s numbers, notes and testing methodology: Raspberry Pi microSD card performance comparison - 2015 | Jeff Geerling (the interesting stuff starts with ‘iozone 4K Random read/write’)

Roger that…ordered 2-16GB A1’s
When I get them in will shutdown -h now, image the drive with Win32 Disk Imager then re-write to new card and see how well it does

a ‘LOOOOOONG’ time on the class 10 was about 20-30 minutes…so not ‘that’ long…just felt that way when I was up past my bed time…

I do know when I burned the image to the disk…it was telling me it was getting around 17-18MB’s

That’s sequential IO (writing a large file to card) but that’s not happening that much or any more as soon as you start an OS from the SD card. Then it’s all about random IO. Quoting Jeff Geerling (who did pioneer work here in SBC land):

There is an order-of-magnitude difference between most cheap cards and the slightly-more-expensive ones (even if both are rated as being in the same class)

Look at his numbers: Raspberry Pi microSD card performance comparison - 2015 | Jeff Geerling

The hdparm and dd numbers show sequential performance while the 4K rand columns show random IO performance. With sequential workloads (storing pictures or videos on SD card, writing a whole OS image to it) the differences between fast and slow cards are close to irrelevant but with random IO (accessing small files, updating filesystem structures, accessing databases and similar ‘common Linux tasks’) those fast and new A1 rated cards show magnitudes higher performance :slight_smile:

If you really want to see how well the A1 cards perform you might need to start again with the Stretch image you used in the beginning and then let the prep script run again. This should finish magnitudes faster now. But why using Win32 Disk Imager? This tool doesn’t catch errors that happen from time to time when writing an OS image to SD card. Doesn’t DietPi recommend Etcher that implements verify after write?

Haven’t checked if Etcher reads images from SD cards…I’ll definitely look though

Hi,

Being open source, you can use any pre-image you like. You can also host the images (unofficially) you create anywhere you like.

The only thing we wont allow, is for any ARMbian based images to be hosted on diet.com.

Really?

Can I get support from DietPi here?

Or from ARMbian? I have use their offical image , so where is my support?

It will be a "offical DietPi " image. Have a look:

───────────────────────────────────────
 DietPi     | Update available
 ───────────────────────────────────────
 v6.2       | OrangePi One (armv7l)
 ───────────────────────────────────────
 IP eth0    | 192.168.0.100
 ───────────────────────────────────────

 Created by : Daniel Knight
 Web        : http://DietPi.com
 Twitter    : http://twitter.com/dietpi_
 Donate     : http://goo.gl/pzISt9
 DietPi's web hosting is powered by: MyVirtualServer.com

 dietpi-launcher  = All the DietPi programs in one place.
 dietpi-config    = Feature rich configuration tool for your device.
 dietpi-software  = Select optimized software for installation.
 dietpi-update    = Run now to update DietPi (from v6.2 to v6.4).
 htop             = Resource monitor.
 cpu              = Shows CPU information and stats.

root@OrangePi-One:~#

I read here:

Created by : Daniel Knight
Web : > http://DietPi.com

I can’t find any hints that it is a unofficial image. It looks like all my other DietPi installations …
Have download it from the web.

Come on, boys and girls … I need help, my Kodi is not working, my wifi loose connection and I have no sound.

Roger that…maybe a writeup/howto for those people who want those images should be created so people can still enjoy Dietpi, but have to build them themselves. (and learn a little along the way :wink: )

I already “tweaked” my build…I should probably just go ahead and create a “stock” image for others to use

 ───────────────────────────────────────
 DietPi     | 22:04 | Tue 13/03/18
 ───────────────────────────────────────
 v6.4       | OrangePi Zero (armv7l)
 ───────────────────────────────────────
 eth0       | 192.168.0.98
 ───────────────────────────────────────

 Created by : Daniel Knight
 Web        : http://DietPi.com
 Twitter    : http://twitter.com/dietpi_
 Donate     : http://goo.gl/pzISt9
 DietPi's web hosting is powered by: MyVirtualServer.com

 dietpi-launcher  = All the DietPi programs in one place.
 dietpi-config    = Feature rich configuration tool for your device.
 dietpi-software  = Select optimized software for installation.
 htop             = Resource monitor.
 cpu              = Shows CPU information and stats.

And yeah…unfortunately…there will probably be no support from either community save for basic issues…but I am effective enough at Linux to pick my way thru most problems (Google is my friend in those situations )

Can I get support from you for this image published by you?

How does it looks?

───────────────────────────────────────
DietPi | 22:04 | Tue 13/03/18
───────────────────────────────────────
v6.4 | OrangePi Zero (armv7l)
───────────────────────────────────────
eth0 | 192.168.0.98
───────────────────────────────────────

Created by : John Doe (WarHawk)
Web : http:// WarHawk.net

Device image possible thanks to: ARMbian and DietPi

:question:

It operates and boots fine…but offering support…I wouldn’t know how to troubleshoot (other than small issues)

I will rebuild a stock image when I get the new A1 cards in and PM you with the image file

I got the issue mentioned by k-plan:

  • Currently, using DietPi-Prep from within DietPi-Banner it still mentions that is created by Daniel Knight and we will offer support for it.
  • As we cannot guarantee quality of any user created image, based on base image quality/kernel etc, and we do not want to offer ARMbian based images explicitly, this is not a good practice so far.
  • But on the other hand, according to DietPi frontend, the credits are still correct and in case of feature requests or DietPi-only related issues, we might want/allow users of these custom images to still address us.

Maybe we should rework the credits when offering DietPi-Prep for public use:

  • Clarify that current credits are related to DietPi code only.
  • Add a custom field that contains credits to base image (Raspbian, Meveric, Debian, even ARMbian if user uses it, etc.), and
  • a custom field “who” created the final DietPi-Image, which will on our end be filled with “Daniel Knight” for official images and where user could fill his own name/account/email, especially if resharing.
  • Both fields then need to be filled during DietPi-Prep process. If left empty, the 1st need to make clear, that we are responsible for DietPi code only.

This would address and clarify the relation between what is our official DietPi coding work, what is base image related and by times out of our control, and what is part of the combination/configuration/setup of base image and DietPi preparation, including testing and in case manual image adjustments (removing old kernel modules, zerofill, packaging, WiFi/Bluetooth choices etc.).

Does anyone know a way to build the debian stretch install on an orangepi without needing user interaction

Maybe even offer a dietpi preseeding script/file for users to grab the stock debian installer image, build it, then upgrade to dietpi with the DietPi-Prep script.

https://www.debian.org/releases/stable/armhf/apb.html.en

This way…the users build a full dietpi orangepi distro and no longer have to trouble the developers (unless something botches which we know it will :frowning: )

Or…I will have to build a TV out adapter and have physical access to the install process to get it built…

@WarHawk:

  • As far as I know, it is not (yet) possible to install Debian stock full featured on most OrangePi (Allwinner SBCs) without doing some prior kernel+bootloader compiling and deployment. If it were be possible, we would start creating OPi images fast :smiley:. Debian installer + mainline kernel seems to work somehow for some SBCs, but then lacks essential features, ethernet etc. But Debian is making progress there and it could be worth trying again.
  • Generally for machines, where this is possible, I wrote down the steps we do for our image creations: https://github.com/Fourdee/DietPi/issues/1505

Anyway, thanks for sharing the link to Debian installer automation :+1:, this is extremely useful for our image creation. I am not sure, if it is possible to automate getting the latest and correct image + implementing the automation config file, where both also depends on the machine you use and where you want to install the image to (MMC/USB, other attached drives?). But at least we can provide a automation config that automate most things (all that definitely is possible/correct on all machines) and also use this for faster own image creation.

Per the supported hardware…it supports the H2+ and H3 architecture under the 2.1 supported Hardware
2.1.4. Platforms supported by Debian/armhf
https://www.debian.org/releases/stable/armhf/ch02s01.html.en#2.1.4.%20Platforms%20supported%20by%20Debian/armhf

Certain Allwinner sunXi-based development boards and embedded systems

The armmp kernel supports several development boards and embedded systems based on the Allwinner A10 (architecture codename “sun4i”), A10s/A13 (architecture codename “sun5i”), A20 (architecture codename “sun7i”), A31/A31s (architecture codename “sun6i”) and A23/A33 (part of the “sun8i” family) SoCs. Full installer support (including provision of ready-made SD card images with the installer) is currently available for the following sunXi-based systems:

Cubietech Cubieboard 1 + 2 / Cubietruck

LeMaker Banana Pi and Banana Pro

LinkSprite pcDuino and pcDuino3

Olimex A10-Olinuxino-LIME / A20-Olinuxino-LIME / A20-Olinuxino-LIME2 / A20-Olinuxino Micro / A20-SOM-EVB

Xunlong OrangePi Plus

System support for Allwinner sunXi-based devices is limited to drivers and device-tree information available in the mainline Linux kernel. Vendor-specific kernel trees (such as the Allwinner SDK kernels) and the android-derived linux-sunxi.org kernel 3.4 series are not supported by Debian.

The mainline Linux kernel generally supports serial console, ethernet, SATA, USB and MMC/SD-cards on Allwinner A10, A10s/A13, A20, A23/A33 and A31/A31s SoCs. The level of support for local display (HDMI/VGA/LCD) and audio hardware varies between individual systems. For most systems, the kernel doesn’t have native graphics drivers but instead uses the “simplefb” infrastructure in which the bootloader initializes the display and the kernel just re-uses the pre-initialized framebuffer. This generally works reasonably well, although it results in certain limitations (the display resolution cannot be changed on the fly and display powermanagement is not possible).

Onboard flash memory intended to be used as a mass storage device generally exists in two basic variants on sunXi-based systems: raw NAND flash and eMMC flash. Most older sunXi-based boards with onboard flash storage use raw NAND flash for which support is not generally available in the mainline kernel and therefore also not in Debian. A number of newer systems use eMMC flash instead of raw NAND flash. An eMMC flash chip basically appears as a fast, non-removable SD card and is supported in the same way as a regular SD card.

The installer includes basic support for a number of sunXi-based systems not listed above, but it is largely untested on those systems as the Debian project doesn’t have access to the corresponding hardware. No pre-built SD card images with the installer are provided for those systems. Development boards with such limited support include:

Olimex A10s-Olinuxino Micro / A13-Olinuxino / A13-Olinuxino Micro

Sinovoip BPI-M2 (A31s-based)

Xunlong Orange Pi (A20-based) / Orange Pi Mini (A20-based)

In addition to the SoCs and systems listed above, the installer has very limited support for the Allwinner H3 SoC and a number of boards based on it. Mainline kernel support for the H3 is still largely work in progress at the time of the Debian 9 release freeze, so the installer only supports serial console, MMC/SD and the USB host controller on H3-based systems. There is no driver for the on-board ethernet port of the H3 yet, so networking is only possible with a USB ethernet adaptor or a USB wifi dongle. Systems based on the H3 for which such very basic installer support is available include:

FriendlyARM NanoPi NEO

Xunlong Orange Pi Lite / Orange Pi One / Orange Pi PC / Orange Pi PC Plus / Orange Pi Plus / Orange Pi Plus 2E / Orange Pi 2

But I agree, the Allwinner boards don’t look like it has support, plus some of the peripherals are not included on the main “baseline” kernel built stock by the Debian crew.

has any of the dev team guys used QEMU to try and run a virtual ARM system to build a kernel
https://wiki.qemu.org/Documentation/Platforms/ARM

No go on TV out on the board…can’t get it to initialize

However once again…using the stretch armbian image…installed…then ran the dietpi update script and kapow…dietpi

Oh and the A1 cards are MUUUUUUCH faster!!! Thanks :wink:

I selected unknown board on install…everything that I need it to do works, but others mileage may vary

I created a few images…
Cant message fordee to test (remove if you choose so you can test)

https://mega.nz/#F!vcU2SQxD!PESByv6w_NDhqxSnMViblg

R1 dietpi is not working (Dual nics, only sees 1)

root password is dietpi123
dietpi/dietpi normal user

Used pishrink to reduce from 16GB .img file to the current smaller size, the dietpi images should resize on 1st boot since I imaged it before rebooting

Hi, i have an orange pi pc still running v159 :slight_smile: i would like to know if you WarHawk could share your steps to build? i would like to try it myself as a learning experience, but i’m just not sure where to obtain all the resources to bring together.

Sure

A. Download Orange Pi PC Armbian xenial and burn to a card
https://www.armbian.com/orange-pi-pc/#kernels-archive
B. Install entire OS, go thru the login with root:1234 create new sudoer user per their script (I recommend making a “dietpi:dietpi” user REBOOT
C. Perform the install of the PREP_SYSTEM_FOR_DIETPI.sh script
https://github.com/Fourdee/DietPi/issues/1285
D. Once it goes thru its configure it will strip out all the armbian stuff, and turn it into Dietpi, it might take some time…the A1 cards are ALOT faster than the Class 10
E. It might take a few reboots and

apt update && apt upgrade -y

to finally get it fully upgraded, if you have to then run dietpi-update

Once completed and operating properly…take win32diskimager, copy the card as a .img file or in a linux

dd if=/dev/sdc of=sdimage.img bs=4M

https://askubuntu.com/questions/227924/sd-card-cloning-using-the-dd-command

Then get pishrink and shrink the .img down

That’s pretty much how I did it…
It’s not perfect and for some reason it left the armbian package stuff in /etc/apt/sources.d so you might have to clear that out or at least comment the line out, it’s not pretty but it worked…sad that Igor and the developers here got into a pissing contest and they decided to pull armbian based imaged from their designs :frowning:

pishrink has issues…I think it expects raspbian type partitioning…so might have to use the -s option…still checking it