wildcat_paris

Usage: markdown-pdf [options] <markdown-file-path> Options: -h, --help output usage information -V, --version output the version number <markdown-file-path> Path of the markdown file to convert -c, --cwd [path] Current working directory -p, --phantom-path [path] Path to phantom binary -h, --runnings-path [path] Path to runnings (header, footer) -s, --css-path [path] Path to custom CSS file -z, --highlight-css-path [path] Path to custom highlight-CSS file -m, --remarkable-options [json-options] Options to pass to remarkable -f, --paper-format [format] "A3", "A4", "A5", "Legal", "Letter" or "Tabloid" -r, --paper-orientation [orientation] "portrait" or "landscape" -b, --paper-border [measurement] Supported dimension units are: "mm", "cm", "in", "px" -d, --render-delay [millis] Delay before rendering the PDF -t, --load-timeout [millis] Timeout before the page is rendered in case `page.onLoadFinished` isn't fired -o, --out [path] Path of where to save the PDF I am still working on but according to now:
- better code highlighting can be done with .css, since it's converted to HTML and than to PDF
- YouTube should be converted to link
- Line wraps. Probably doable with .css
- clickable TOC, have to study but I think not possible out of the box
- page numbers, currently no idea
 
Numeric prefixes, yes. I am currently creating 01-cover-page.md
 
Edit:
I am already happy even with this. One searchable document with simple TOC at start. It's also possible to create two main documents or one divided into two major section, user / geek and with different background color. That's possible to do fairly easy.
 
Edit: some structural changes
Armbian_5.14_documentations.pdf

So far USB OTG port has been defined in host mode, the same as the regular USB port. To change this behaviour and use it in gadget (device) mode see http://forum.armbian.com/index.php/topic/1417-testers-wanted-g-ether-driver-h3-device-as-ethernet-dongle/

Another update: since I was testing an A20 board today in preparation of Armbian 5.15 release, SATA was mentioned in this thread and I found 2.5" disks I gave it a try and compared NAS performance on an A20 board using SATA, old/slow USB mass storage mode, faster "USB attached SCSI protocol" mode (UAS) and also a RAID-0 between SATA/UAS (to eliminate storage bottlenecks and make the network the limiting factor)
  I used a pcDuino3 Nano running 4.6.2, at 960MHz clockspeed (performance governor) using 2 identical SpinPoint M7 (same firmware, same useage profile). Single drive tests done with the same drive to show the differences protocol (SATA, UAS, USB Mass Storage) and the bridge chip in the enclosure might make. Drive data according to smartmontools (both USB-to-SATA bridges I used are fully SAT compatible and allow to query SMART data and trigger SMART self tests): Model Family: SAMSUNG SpinPoint M7 Device Model: SAMSUNG HM500JI Firmware Version: 2AC101C4 User Capacity: 500,107,862,016 bytes [500 GB] Sector Size: 512 bytes logical/physical Form Factor: 2.5 inches Device is: In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS T13/1699-D revision 6 SATA Version is: SATA 2.6, 3.0 Gb/s SMART support is: Available - device has SMART capability. SMART support is: Enabled The iozone tests used these 3 sets (the first set is our usual test setup to get especially random IO performance, the two last test runs use twice the size of physical DRAM to show real sequential disk throughput without caches/buffers involved):
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 iozone -a -g 2000m -s 2000m -i 0 -i 1 -r 4K iozone -a -g 2000m -s 2000m -i 0 -i 1 -r 1024K Onboard SATA:
random random kB reclen write rewrite read reread read write 102400 4 6187 6403 10898 11470 497 5613 102400 16 12819 12422 22983 23358 1921 11974 102400 512 25472 25326 44996 44854 23549 25337 102400 1024 26429 26344 45306 46847 28518 26395 102400 16384 27194 27369 71150 72926 68996 27630 2048000 4 40796 39704 79686 78330 2048000 1024 40106 39322 79919 77556
  USB/UAS: lsusb: 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge dmesg: usbcore: registered new interface driver uas random random kB reclen write rewrite read reread read write 102400 4 4709 4825 6402 6599 496 4483 102400 16 12489 12306 15237 15500 1843 12022 102400 512 28286 28193 28422 29075 20617 28278 102400 1024 27861 28110 29240 29541 24940 27897 102400 16384 32088 32230 35944 36109 36408 31965 2048000 4 37538 37318 37074 37188 2048000 1024 37868 36838 37218 37293
  USB/BOT (Mass storage): lsusb: 04fc:0c15 Sunplus Technology Co., Ltd SPIF215A SATA bridge dmesg: usbcore: registered new interface driver usb-storage random random kB reclen write rewrite read reread read write 102400 4 3646 3663 4810 5090 484 3485 102400 16 10371 9723 13667 13167 1880 9858 102400 512 26678 26648 26981 27092 19296 26626 102400 1024 27536 27472 27326 27577 21148 27504 102400 16384 34559 34533 32692 33114 33020 34524 2048000 4 32443 31353 32570 32777 2048000 1024 32223 31745 32575 32726
          RAID-0 made of one SpinPoint M7 attached to SATA and the other to the UAS capable JMS567 USB enclosure   I used btrfs and enabled also LZO compression so iozone results (especially sequential) are pretty worthless. It's just about eliminating storage bottlenecks to get the idea how an A20 based NAS with GbE behaves compared to an 'USB only' NAS as above. mkfs.btrfs -m raid1 -d raid0 /dev/sda1 /dev/sdb1 mount -o compress=lzo /dev/sda1 /mnt/sda/ random random kB reclen write rewrite read reread read write 102400 4 5607 5644 8357 8595 568 5203 102400 16 13339 12873 19534 19906 2026 12318 102400 512 49861 49044 50417 52949 31396 49289 102400 1024 53645 52701 56170 57347 43232 53006 102400 16384 64269 66759 62455 64459 61649 65130 2048000 4 86293 70816 65671 65579 2048000 1024 110122 96309 154940 153801
  Simple conclusion   USB when used on a device that is 'USB Attached SCSI' capable is not that bad (applies to A20, H3 and most likely also A64 when used with mainline kernel). But it depends also on the USB-to-SATA bridge used in disk enclosures or onboard (unfortunately on all sunxi boards with an USB-to-SATA bridge the horribly slow GL830 is used that's also not UAS capable, so bad news for owners of Orange Pi Plus, Plus 2, Banana Pi M3 or Cubietruck Plus).   The Ethernet implementation in the newer Allwinner SoCs also is not that bad as the one used in A20 (here maximum network speeds differs a lot between several GbE capable sunxi boards for still unknown reasons). So when we're able to use mainline kernel on H3 devices performance will further improve (see also the measurements with the USB-GbE dongle above). At least for me SATA isn't a requirement any longer. But in case Olimex is right and Allwinner releases a pin compatible quad core A20 successor later this year it might get interesting again   Some background information: http://linux-sunxi.org/USB/UAS http://linux-sunxi.org/SATA http://linux-sunxi.org/Sunxi_devices_as_NAS

I have added this:
chown -R $SUDO_USER:$SUDO_USER $SRC at the end of compile.sh because I don't need ANY files owned by root...

done.
apt-get update apt-get install rpimonitor

None of those voltages are fine with the boards. The board may run, but USB devices and HDMI devices won't work as long as they receive the proper voltage directly from the source.
Also cheap power supplies with selectable output voltage usually have very little output amperage (200mA if you're lucky. These boards require 2000mA to work reliably with some USB devices attached)

@tkaiser, ok, before this become part of armbian i think you should run some tests and see the limitations. i updated the https://github.com/avafinger/guvcview(Guvcview runs on OPI and Pine64+ with some restrictions on the driver side). Not referenced on  Pine64 IIRC.
 
@Igor, ok then.

Building https://github.com/avafinger/guvcview with "debianization" overlay from Ubuntu resulted in these packages.

We can't help much when 3rd party hardware is used. Sorry.
 
I would suggest to try recent Vanilla kernels.

BTW, there is an alternative to this - hosting this deb file on apt.armbian.com

I've been working on the rtl8189fs patches for Mainline.
 
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
 
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
 
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
 
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
 
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.

@tk
 
to please your eyes, bold & righteous TK
 
added feature requests.
https://github.com/raspberrypi/piclone/issues

post your .config in pastebin and I will git diff. Theoretically It should not differ to much. I don't remember well which branch/repo I took. My fan runs and runs... and no way to stop it. searching for solution.
Sorry for the spoiler. I will do this next time.

There are more changes than I expected. Here.
My OdroidXU4 .config

No thanks. What's the purpose of writing stuff in C when the most critical parts rely on external tools: https://github.com/golfromeo-fr/piclone/blob/65fb5d95f84aa7ec63a93f8f944beaa0290e7c73/src/piclone.c#L140
 
The behaviour of tools like parted or fdisk might change when upgrading a package and then the whole thing might fail (and destroy your whole installation! That's why I asked @Rodolfo whether he tested his script on all 4 distro variants Armbian supports! Since it matters!). We just recently had to include a check which fdisk version we're using: https://github.com/igorpecovnik/lib/blob/2e284be77d62f7516901f7657f8e773c271aa953/scripts/firstrun#L207-220
 
So we wasted already hours (days to be honest) with testing, we made workarounds for this and that, we changed behaviour of partitioning for a reason (never ever use whole devices again since it might prevent our users from cloning a card to another card 'of the same size' since cards from different manufacturers/batches differ slightly in size so an 8GB card from Samsung isn't exactly the same size as one from Transcend) and we should not throw this stuff in the bin to replace it with tools that might work now but break with any package or OS update in the future (we do not only support Raspbian but 4 different Debian based distros).
 
The core stuff I was talking about is already there (contained in firstrun script and nand_sata_install.sh where some adoptions are IMO needed). Let's use this, maybe put the core logic in a library to be used from different tools later to achieve identical results and rely on simple scripts we can easily adopt if changes make it necessary (see above: util-linux version on Ubuntu Xenial has been increased to 2.27.1 and immediately partition resizing broke)

network is back
gr@odroidxu4:~$ dmesg  | grep 8152 [    0.754425] usbcore: registered new interface driver r8152 [    2.164556] r8152 5-1:1.0 eth0: v1.08.3 [    2.200154] r8152 5-1:1.0 enx001e06301503: renamed from eth0 I had to change /etc/network/interfaces
gr@odroidxu4:~$ cat /etc/network/interfaces auto enx001e06301503 iface enx001e06301503 inet dhcp # Wired adapter #1 ##allow-hotplug eth0 ##iface eth0 inet dhcp # Local loopback auto lo iface lo inet loopback the issue with the interface naming enx001e06301503, jessie deals with enx001e06301503, Armbian Xenial doesn't
 
so it is working!

You mean it works on SD but id doesn't work on eMMC ?
 
This shoul have change it ..
if [[ $BOARD == odroidxu4 && $BRANCH == next && -f $CACHEDIR/sdcard/etc/fstab ]] ; then sed -e 's/mmcblk0/mmcblk1/g' -i $CACHEDIR/sdcard/etc/fstab fi

awesome!. I was trying to put statical IP, changing DNS, etc. Something with the interfaces.d/ init scripts should be the problem, but no idea, time and will.

sorry to comment this so late. I can confirm I tried already last week this: xenial + odroidxu4 = not booting properly.  DHCP / Eth0 issue. I think this bug was fixed with jessie, not Xenial. I gave up trying to fix eth0.

next, next, next here
this is very promissing

I guess we won't solve this today  

@Igor
 
stuck at first boot... no way to login as root (as usual )with USB-UART and I don't see DHCP request (so no network). let's try keyboard and screen
 
 
 

Xenial CLI image with 4.6.2
http://www.armbian.com/odroid-xu4/
 
No idea if it boots. My XU4 is in action

And it's absolutely necessary to get the idea that what you're trying to do can NOT work reliably in every situation (eg. running databases they will get corrupted with such rsync attempts -- applies to our nand_sata_install.sh script as well which is why I want execution of this script as soon after installation as possible).
 
Also your script doesn't take care of 2 partition Armbian installs and the partitioning stuff is prone to errors since fdisk behaviour might change depending on version number so you should add with which of the 4 distro variants Armbian supports you tested.
 
The only way to reliably clone an installation is by shutting the installation down before and then using a second installation to create an offline clone (using dd or rsync or whatever). Cloning a 'hot system' is not possible by design without taking care of several things. It might work sometimes (or seems to work after a first check just to realize later that some minor issues start to get bigger). It's also wrong to use a single rsync instance, always add a second one at the end otherwise you increase the chance of inconsistencies greatly (to get the idea: Start your clone process and then 1 minute later do an 'apt-get upgrade' -- that might happen unattended anyway to install security updates and chances are great that dpkg issues happen or even the installation is corrupted)
 
I know that people don't like these warnings and ignore them all the time since it looks inconvenient to do it correctly and hot cloning seems to work. It will not in every situation and you will realize that always way too late. You have been warned

I am trying to configure "next" with linux-vanilla (4.6.2) and built an Armbian image then booted from SDcard (removing my eMMC)
 
So far, Samsung OSG provided examples of vanilla kernel
@jobenvil tested 4.6 kernel but compiled on board WITH partition using UUID instead of /dev/mmc
 
I got 4 cores in the "basic" model (4 little => 4 BIG), network, HDD
 
issue: mixing uboot 2012.07 and vanilla kernel
 
it seems /dev/mmcblk0 doesn't exist for uboot 2012 only boot.ini works with root=/dev/mmcblk1p2
 
to quick fix the problem I put /dev/mmcblk1p2 for root partition in boot.ini
 
* I know how to manipulate UUID and partition
 
=> is it possible to put specific UUID on partitions before writing the image with Armbian