Jump to content

miked

Members
  • Posts

    32
  • Joined

  • Last visited

Recent Profile Visitors

1034 profile views
  1. nand-sata-install.sh exits if it's not run from an SD card, and later checks the root filesystem for a few supported types, it looks like. Is there any reason this script couldn't support FEL/NFS-root? It seems like it would be the ultimate least-cost solution to failures due to bad SD cards. (However, FEL is fairly advanced and I don't know how many people go for a board with emmc but don't have a good sd card to spare. Is there a place where potential features are listed and people can vote or express interest, to see if such features are worth doing?) DEBUG_MODE runs "git add" and I unexpectedly end up with a lot of files to be committed, after the build script is done. Is this supposed to happen? Would this have happened because of some unhandled state I'm in, such as having outdated code (using FORCE_CHECKOUT="no") and the git add + git reset then not behaving as it was intended? Does this need further investigation? Since it's doing a git add, and it seems to want me to edit code only(?) in the middle of running the build script, I'd assumed that DEBUG_MODE was intended to be used to patch the code using known-working fixes, and not to iteratively write/compile/test changes. Is this true?
  2. I was thinking of user edits of source files, and of wanting to treat compile.sh like make. If Ubuntu is your main system, neither is needed, but is it still recommended to keep your system clean or for security? Also if the boot fails before video and networking are initialized, it may be the only way(?) to see status/failure messages.
  3. The remaining outstanding issues I've seen so far involve trying to use the scripts for experimentation and kernel hacking. My impression of the scripts is that they weren't meant for this, instead for automating building known good images, but I think it's appropriate for someone who wants to hack on the build to also expect to hack on the build scripts. The scripts do maybe 95% of what I want, and it would be a nightmare to try to get started making a custom build without them. Stuff I immediately hacked into the scripts after downloading a fresh copy: - Option to keep the rootfs persistent for FEL, and another option to control when to (re)create the rootfs. Desired things I haven't got around to: - A separate script for cleaning various things (including build output, downloads, mounts, nfs server etc), with dialog options. - compile_kernel when code changes instead of when deb doesn't exist. Or, figure out quickest way to compile kernel without building too much else. - A doc to help with pulling useful commands out of the scripts to use in standalone scripts. - Documenting suggested hacks Docs: - Wherever something is recommended (eg. virtualbox, DHCP server and UART console monitor for FEL), it would be helpful if it explained why, or what will be missed by anyone skipping the recommendation.
  4. I can't reproduce the toolchain download error. I should have copied the messages and directory lists. However I remember the file gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux.tar.xz being about 41Mb when it should have been 48 or something. Come to think of it... I only remember *one* message showing ######################################################################## 100.0% If that was really the case, it's likely that that was for the .asc file and I mistakenly thought it claimed to download the whole .xz file. Unfortunately I don't recall if there was any output before that, for the .xz file, showing an incomplete download or not. I figured I had network problems or there was a server problem. curl is using the "-f" flag so it might have hidden a fail message. I can repro a download error simply by unplugging the network for a minute while downloading. curl didn't resume downloading when it was plugged back in, and about 10 minutes later it failed. However, it failed with an error message: ############ 17.4% curl: (56) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104 The script displayed "[ warn ] Verification failed" and continued running.
  5. A few small hangups... They might be mentioned in documentation (I could in the near future), if there's nothing to fix. If RELEASE variable is set, no dialog option for BUILD_DESKTOP is presented. They both must be set, or you get no desktop. Toolchains: Are these all needed? Are they all downloaded because it's easier than figuring out which are needed? Are the different versions of gcc-linaro-*-x86_64_arm-linux-gnueabihf redundant? If they're not needed, a docs section on customizing the scripts could mention commenting them out. I had an odd situation where one of the toolchains was downloaded each time I ran compile.sh. I think the download was ending prematurely???, even though curl displayed 100.0% progress. The gpg verify failed, and there was a warning displayed, but it was quickly (half second maybe?) pushed offscreen by a full-screen option dialog. I assume this is rare enough to not justify any changes. NFS: The first time I try to boot FEL, it doesn't work because the nfs-kernel-server isn't started yet. After the script finished, I ended up with a lot of memory being used until I stop the server. Edit: This must have been an unusual circumstance as it didn't happen upon retesting. Maybe it only happens with tmpfs, maybe only if the board isn't shut down properly?
  6. Patching If I build Armbian, it will patch the source files. If I edit one of the patched files, and run compile.sh again, advanced_patch function will silently overwrite my changes. I believe this is what's described here, with a work-around: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=1707 "You need make changes to 4 files, but make changes directly to the kernel source is not allowed by default. Because compilation scripts will revert all changes . So we need make patches:" I expected being able to modify code and rebuild.
  7. Your suggestions sound good. Minimal changes and then maybe a "howto" in the documentation should allow non-experts to do all this. I could write that later if I get it figured out enough.
  8. I got obsessed with getting FEL boot working for me, and ran compile.sh countless times while working with different network settings, UART, h3disp settings etc. Meanwhile I kept hacking on the build scripts to get to FEL as quick as possible, and I remember the moment it became bearable, when I could get to fel-load in under 10 seconds (by loading a rootfs tgz that already had everything installed). I thought about making my own script for FEL or to just source debootstrap-ng.sh and fel-load.sh, but since compile.sh sets up so many variables, build names etc, I figured it would be easier to just modify it. I love the idea of FEL at the moment and I know I'll use this, so: Suggestions for FEL options Edit: I think these are too messy. See simpler options below?... 1. Add options to skip getting any code, and compiling. Then once a rootfs tgz is built, you can skip clean and clock sync, and basically everything before debootstrap-ng.sh. 2. Add options FEL_SAVE_ROOTFS and ROOTFS_FILENAME_SUFFIX. Save a rootfs tgz after installing kernel headers etc. Better yet, I do this after the FEL boot has been done and quit, so I can boot into FEL system, configure it, install packages etc, and have that saved to run later. 3. Add an option to skip installing kernel headers etc, instead using the previously saved rootfs (chosen via ROOTFS_FILENAME_SUFFIX). 4. (Maybe) add an option to not use a tmpfs for FEL, and not delete output/cache/sdcard. With other options set, creating/loading the rootfs is skipped on subsequent runs, and I just get straight to the FEL stuff in about a second. I wanted this option because the memory cost of the tmpfs was too high while having multiple browser windows open etc. I've made no changes to fel-load.sh and personally haven't had a problem so far with it doing all its configuration every time, no matter what other options I've set. Using these options, I can do several things: - Keep a persistent FEL rootfs on my host. Back it up when I want to a tgz. - Change ROOTFS_FILENAME_SUFFIX to have multiple different FEL rootfs images saved. Optionally save them out after finishing FEL, so they are each optionally persistent. One problem (at least the way I cobbled this together) is that I have to set the right combinations of options, both when I want to rebuild a rootfs and then after when I want to reuse it. These hacks have been immensely useful for playing with FEL, and I suspect they'll be useful for experimenting with other build configurations, but I don't know if they'll be useful after that. It may require endless tweaks to do what I want (eg. should /boot be excluded or not when loading a saved rootfs?). Also... it may be too early for me to suggest changes as I might keep changing everything as I figure out what I'm doing. For example the simplest way to achieve all of the above might be: Simpler suggestions for FEL options - Optionally (SKIP_BUILD) skip everything before debootstrap-ng.sh - Optionally (FEL_PERSISTENT) don't use a tmpfs and don't delete output/cache/sdcard/ - Don't install kernel headers etc. if they're already there (or if SKIP_BUILD && FEL_PERSISTENT). The use of a tmpfs and saving/switching the rootfs images can be done manually if needed.
  9. Initial thoughts: - Why is root needed, and what will it do to my system? (Docs could give an overview of what it will install, etc). Is this why virtualbox etc. is recommended? (but not needed?) Is it conceivable to run as normal user, with a few sudo calls for anything needing root? - Why does it update code (and sunxi tools etc) every time it is run? It seems to be set up for automating regular builds, but I imagine users who are trying to patch or hack on their system might have to compile several times and wouldn't want to get code while making changes. (There is the ".ignore_changes" option but it is handled differently from the other options. If it was documented, and perhaps echo'd a message that code updating was being skipped, that might suffice). - Similarly, does it need to automatically clean everything? While experimenting with FEL mode, it takes many minutes compiling and prepping the image each time, even if no changes were made, and then unmounts the image when done, so it is difficult to continue experimenting outside of compile.sh.
  10. I'm currently trying out various features before going through the tools in detail and attempting to tackle all scenarios. I'll write down some thoughts in this thread for now.
  11. Yes, and reminders. All the info we need is here: http://docs.armbian.com/Process_Armbian-Task-Tracking/ ? Everything feels in a state of flux, I easily lose track of what's temporary/experimental and what's up-to-date, and stuff can get lost in a sea of posts. Extra reminders are probably helpful until everyone gets the hang of things? Are we encouraged to post more task status updates, even if not a lot of progress has been made?
  12. Thanks, I've just fixed this. I don't know the answer to the first 2 issues. mkdocs was treating the list as a table. I replaced the first "|" with "|" to stop it. Adding blank lines between the items also works but makes the list look different from the others on the page.
  13. I've added a welcome message to the docs Home, to temporarily minimally address some UX issues. There are several use cases for the documentation: 1. New users, who might easily give up and try something else unless they're walked through everything right from the start. - Getting Started should be prominent for them. - "What is the current state of Armbian?" might need to be answered in the docs, since outdated info about hardware acceleration, HDMI etc. can be found elsewhere and may deter these users (or maybe that should be left to the main armbian.com site) 2. Users of all levels who have frequently asked questions. - Do people still look for FAQ sections? If so one should exist and be easily seen. 3. People who've run into problems - FAQ and/or Troubleshooting should be easily found. 4. Serious users who will actually read through the ToC and documentation
  14. Does the cron job run on a regular interval, or does it run after commits? If the latter, is it only when certain files are committed?
  15. Oh no. Thanks. This happens with small browser windows too. The easy fix blocks content underneath, so I'll have to figure out how to do this right. Edit: Removed position:fixed until a proper fix can be found. Maybe keeping it onscreen all the time is not worth doing?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines