Jump to content

zador.blood.stained

Members
  • Posts

    3633
  • Joined

  • Last visited

Reputation Activity

  1. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    tmpfs is faster in any case   But for me at this point lack of CPU power is the only thing that still makes using cached rootfs faster than making it from scratch
  2. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    For me without rootfs cache this (old debootstrap)
    [ o.k. ] Create and sign [ Armbian_4.81_Cubietruck_Debian_wheezy_3.4.110.zip ] [ o.k. ] Runtime [ 73 min ] turns into this (new debootstrap, again, no rootfs cache)
    [ o.k. ] Signing and compressing [ Armbian_4.81_Cubietruck_Debian_wheezy_3.4.110.zip ] [ o.k. ] Done building [ /home/zador/armbian/output/images/Armbian_4.81_Cubietruck_Debian_wheezy_3.4.110.zip ] [ o.k. ] Runtime [ 16 min ] so there may be some small improvements, depending on storage type (SSD or mechanical HDD), available RAM and internel connection speed.
     
    Yes, resolv.conf was symlinked to /run/resolvconf/... and this dir is excluded in rootfs cache. Anyway, fixed by Igor now.
  3. Like
    zador.blood.stained got a reaction from wildcat_paris in Banana Pi R as router   
    Main problem is - while switch is unconfigured - and it is configured ONLY when and if OS (i.e. Armbian) booted up to a point when init script disconnects so-called WAN port from rest so-called LAN ports.
    Unconfigured switch means it simply connects your LAN devices to whatever is on the WAN side, and depending on your ISP infrastructure it is either not good or really-really bad from security point of view.
    Possible bad things that could happen:
    Fake DHCP server/ARP poisoning attack - supplies wrong configuration to any device on LAN that is configured to use DHCP. Any device from WAN that can normally reach your WAN port (is on the same subnet/broadcast domain as you) can access any device in your LAN if this device is configured with an IP address (including link-local IPv6 addesses, adresses from ISP's DHCP server or from fake DHCP server from previous paragraph) or if it used some kind of autoconfiguration protocol (avahi/zeroconf/...). This means, that, for example, someone can access not password-protected SMB shares. Normally you don't expect such things from a device that is positioned as a router.
     
    Edit: if you are using SMB, default samba config is not optimized, you can try to improve things a little bit by adding
    socket options = TCP_NODELAY SO_KEEPALIVE IPTOS_LOWDELAY smb encrypt = disabled tls enabled = no to your smb.conf
     
    Edit 2: changed some options 
  4. Like
    zador.blood.stained reacted to wildcat_paris in [Framework] Build script improvement suggestions #1   
    @Zador
     
    I've removed trusty.tgz (which then adds 110 minutes @home to the Armbian image making process) and *no* error messages
     
    @Igor @Zador
     
    I have my first fully running Armbian dev "4.81" (ok "next" is version "5.00"!) with kernel 4.4.0-rc6
    and surprise, the patches from Corentin LABBE for AXP are working *now* http://sunxi.montjoie.ovh/patchs_current/
     
     
  5. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    7 days old cache? Maybe something's up with /etc/resolv.conf (or /etc/nsswitch.conf) inside cached rootfs? Try building without rootfs cache.
     
    Edit: /etc/resolv.conf is created or changed in install_kernel, so if for some reason it is not present in cached rootfs, DNS resolving in chroot won't work.
  6. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    Based on kernel release schedule 4.4 should may be released in less than a week. It won't be considered stable right away, but it will be a good point to check and remove obsolete patches, test new things (like OTG on cubieruck), and it should fix UAS problem with external HDD enclosure that I have  .
  7. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    OK, I fixed another small mistake in code related to build script tags, now it should work like intended.
     
    New debootstrap/image creation code needs testing (especially for compatibility with Trusty).
  8. Like
    zador.blood.stained reacted to Igor in [Device specific] Olimex A13-SOM   
    @Zador
     
    We have a stable tag so we can move on ...
    https://github.com/igorpecovnik/lib/releases/tag/v2015.12
     
    @Booli
    I checked your sources - you got the point. When things will work o-k just push it to the Github and we'll merge it.
  9. Like
    zador.blood.stained got a reaction from wildcat_paris in [Device specific] Olimex A13-SOM   
    Are you sure it is UART0? On A13 SOM UART0 pins are shared with microSD pins, so if you somehow connected to UART0 (old board revision?), no wonder you are getting garbage.
    UART1 should be the way to go, so it needs to be configured both in u-boot and in kernel.
  10. Like
    zador.blood.stained got a reaction from wildcat_paris in [wildcat_paris] yet another Lamobo-R1 config thread   
    About A20 DMA engine (quote from here):
     
    IMHO slapping cheap switch on a board with SoC originally designed for tablets, with single ethernet interface that doesn't support HW checksum offloading and calling it a "router" is not exactly a good concept 
  11. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    I agree that this directory structure is not exactly user-friendly, but right now I'm thinking like this because kernel patches don't grow on trees, if user can make, change or find a patch that he wants to apply, you can expect him to know how to figure out this directory layout. Or at least to read and understand documentation about it.
     
    Also, Armbian supports many different SBCs now and probably will support even more later, and since some boards have unique kernel or u-boot sources, some have 2 possible kernel versions, some have 1, in the end you can't make directory structure simple enough without introducing tons of workarounds and extra configuration bits in build scripts.
  12. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    It doesn't duplicate files, it creates only empty directories.
    In my mind it is one of the reasons too.
  13. Like
    zador.blood.stained got a reaction from Bernie_O in Mainline A10/A20 audio driver   
    It should work on kernel 4.4 with this patch (which is planned for 4.5).
  14. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    I almost finished adding support for building images with F2FS root filesystem (and it's relatively easy to add support for other filesystems, though I don't see the reason to do it for now), but there is small obstacle in the way - partition resizing in firstrun and resize2fs scripts.
    Igor, can you change these scripts so it's possible to disable resizing operation (while executing everything else, plus if no resizing is needed, you need to start resize2fs script right away at first boot instead of reboot)?
     
    Logic for disable resizing can look like this:
    local root_partition=$(findmnt --target / -o SOURCE -n) local rootfstype=$(blkid -s TYPE -o value $root_partition) if [[ $rootfstype != ext4 ]]; then ... Edit: or it can be just a file, i.e. /etc/.no_rootfs_resize
     
    Plus next time you will be checking kernel configs, some of them don't have f2fs enabled or it's enabled as a module, which won't work for rootfs.
    linux-cubox-default.config(5506): # CONFIG_F2FS_FS is not set linux-guitar-default.config(3334): # CONFIG_F2FS_FS is not set linux-odroid-default.config(3873): CONFIG_F2FS_FS=m linux-odroid-next.config(3481): CONFIG_F2FS_FS=m linux-s500-default.config(3334): # CONFIG_F2FS_FS is not set linux-udoo-default.config(3482): # CONFIG_F2FS_FS is not set linux-udoo-neo.config(3707): # CONFIG_F2FS_FS is not set linux-udoo-next.config(4171): # CONFIG_F2FS_FS is not set
  15. Like
    zador.blood.stained reacted to Igor in [Framework] Build script improvement suggestions #1   
    Configs fixed
    https://github.com/igorpecovnik/lib/commit/65bb88cb3394ca914e0dcf39dd8692a84e505b67
    What about sunxi legacy?
     
    I am going to fix firstrun / resize2fs next ...
  16. Like
    zador.blood.stained got a reaction from luiz_siam in Cubieboard2 NAND not reliable   
    I'm not saying that there are no problems in NAND kernel driver, but when I used rootfs on NAND on cubietruck, I don't remember any major filesystem problems even after unclean shutdowns.
  17. Like
    zador.blood.stained got a reaction from luiz_siam in Cubieboard2 NAND not reliable   
    I don't know what mounting options for rootfs were used in Armbian 3.8, but if they were data=writeback,commit=600, then it may be the main cause for the issues - these are performance optimizations that can cause FS corruption on unclean shutdowns.
    From ext4 kernel doc
     
  18. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    I think tar should support "absolute" paths in patterns, --exclude='/dev/*' and so on should be safer in case it finds directory named "dev", "proc" or "run" somewhere in the future. I'll test it later.
  19. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    Okay, I'm not crazy. Same image, reflashed
    debsums libc6-dev
    debsums: missing file /usr/include/arm-linux-gnueabihf/sys/acct.h (from libc6-dev:armhf package) debsums: missing file /usr/include/arm-linux-gnueabihf/sys/auxv.h (from libc6-dev:armhf package) ... debsums: missing file /usr/include/arm-linux-gnueabihf/sys/xattr.h (from libc6-dev:armhf package) # debsums libc6-dev 2>&1 | grep missing | wc -l 81 Edit: directory /usr/include/arm-linux-gnueabihf/sys/ is empty. All other files/directories are OK.
     
    Edit 2:
    tar cp --directory=$DEST/cache/sdcard/ --exclude='dev/*' --exclude='proc/*' --exclude='run/*' --exclude='tmp/*' \ --exclude='mnt/*' --exclude='sys/*' . | pv -p -b -r -s $(du -sb $DEST/cache/sdcard/ | cut -f1) -N "$RELEASE.tgz" | pigz > $DEST/cache/rootfs/$RELEASE.tgz --exclude='sys/*' Can this be a problem? 
     
    Edit 3: Oh no, it found another "sys" directory 
    .. debsums: missing file /usr/lib/arm-linux-gnueabihf/perl/5.20.2/sys/ioctl.ph (from perl package) debsums: missing file /usr/lib/arm-linux-gnueabihf/perl/5.20.2/sys/sysmacros.ph (from perl package) debsums: missing file /usr/lib/arm-linux-gnueabihf/perl/5.20.2/sys/ucontext.ph (from perl package) debsums: missing file /usr/lib/arm-linux-gnueabihf/perl/5.20.2/sys/select.ph (from perl package) debsums: missing file /usr/lib/arm-linux-gnueabihf/perl/5.20.2/sys/types.ph (from perl package) debsums: missing file /usr/lib/arm-linux-gnueabihf/perl/5.20.2/sys/cdefs.ph (from perl package) ...
  20. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    Okay, this is starting to get crazy.
    Fresh cubietruck jessie with next kernel, "make scripts" fails due to sys/types.h error. libc6-dev is installed.
    apt-get install --reinstall libc6-dev
    "make scripts" succeeded
     
    I checked, it doesn't have any pre- or postinstall scripts, but something is broken when it is installed in chroot.
  21. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    Yes, it's compiler related, it compiles past this point in Trusty (great, another legacy compatibility problem, goodbye cross-gcc 4.9, welcome cross-gcc 4.8. Or I need to disable stack protector options somehow).
    So what build options give errors for you? Udoo has non-default sources for both default and next kernels, which one to test?
  22. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    Did you remove packages from your build host or reinstalled OS? What libc6-dev* packages do you have installed now?
  23. Like
    zador.blood.stained got a reaction from wildcat_paris in [Framework] Build script improvement suggestions #1   
    Oops... my bad, I'll fix it ASAP. Guess saturday evenings can be hard too 
  24. Like
    zador.blood.stained got a reaction from matteobp in BananaPiPro. Video Accelerated No Work.   
    You can try compiling latest smplayer on your device.
    http://sourceforge.net/projects/smplayer/files/SMPlayer/15.11.0/smplayer-15.11.0.tar.bz2/download
    You'll need to install required dependencies (search or ask on forum.smplayer.info) and run create_deb.sh
     
    Edit: according to mpv manual, more or less recent mpv versions support playing online video natively if youtube-dl is installed. I recommend installing youtube-dl manually or with pip/pip3 since Debian package doen't update as often as it needs to do.
  25. Like
    zador.blood.stained got a reaction from Igor in [Framework] Build script improvement suggestions #1   
    Unloading wifi module for 1.5 minutes on shutdown on Jessie can be fixed by creating file
    /etc/systemd/system/systemd-modules-load.service.d/10-timeout.conf
    [Service] TimeoutStopSec=10
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines