HARMbian Posted October 1, 2015 Posted October 1, 2015 Greetings, everyone I decided to try armbian for my recently acquired cubox-i4pro. Unfortunately it was missing some kernel modules that I require. No problem, it is easy enough to change the kernel configuration and recompile! Debian Jessie (main system) is even listed as a working development environment, so I thought I would test the included compile script using the instructions from the github. I had recently completed some cross-compilation (for armel, not armhf), so I manually updated the dependencies and read through instructions and looked through the script before getting started. First I compiled the kernel only with the following settings: KERNEL_ONLY="yes" SOURCE_COMPILE="yes" KERNEL_CONFIGURE="yes" It completed successfully with a runtime of 20 minutes. With the files appearing in output/debs/ as expected. Next step was to continue the image compilation using the kernel I had just compiled, but it was not clear whether SOURCE_COMPILE should be set to "yes" or "no". The documentation reads: SOURCE_COMPILE="yes" # force source compilation #If we choose this option, we will be selecting one of previously compiled kernels. This is conflicting information! I think I tried: KERNEL_ONLY="no" SOURCE_COMPILE="no" KERNEL_CONFIGURE="no" I was able to select the kernel I had just compiled, but there was some error directories not existing at later stages, so I cancelled the script Since the initial kernel compiled without issue, i decided to recompile everything again as the full image. I recloned a new lib from github in a clean directory and proceeded with: KERNEL_ONLY="yes" SOURCE_COMPILE="yes" KERNEL_CONFIGURE="yes" FORCE_CHECKOUT="no" (maybe) I chose not to build a Desktop Environment Again, the kernel compiled OK, and the script continued - I was watching the progress. At this point it had been running dpkg, and may have been compressing the vmlinux image, I'm not sure whether the script completed or not, but at this moment it caused my machine to shutdown normally (no other tasks were running). I tried to reboot, and am met with the dreaded: Operating system not found I booted from a live image and to my horror I see that the system disk (/dev/sda) is bare. ALL PARTITIONS WIPED! I am now in the proccess of trying to recover my precious data, but I don't hold much hope for that. Let this serve as a warning for others: THIS SCRIPT CAN NOT BE TRUSTED! Use only in a VirtualMachine, if you dare!
Igor Posted October 1, 2015 Posted October 1, 2015 I am sorry to hear this. If you were playing with script, anything is possible. I am trying to understand what you did and how is possible. You must be running scrip over and over again until you run out of LOOP devices, force breaking in the middle ... can be the problem. I already made a fix for this but it was not working properly, so it was disabled. I have harden this part. In normal condition script works as expected! Yes, it can break under certain conditions and bugs are always possible, no matter how close we look. Sometimes we learn the hard way
Moorviper Posted October 2, 2015 Posted October 2, 2015 Your fault NEVER trust a script you didn't write. READ it first to understand what it does. Never use a build environment on your real pc, only on a VM. Be awake. Think before you hit enter when you typed in your root-pw. these is my basic attitude in using build-script's never had any problems :-)
Recommended Posts