Jump to content

miked

Members
  • Posts

    32
  • Joined

  • Last visited

Everything posted by miked

  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?
  16. I've added a navbar to the top of docs, taken from www.armbian.com and modified slightly. I did this to make the docs feel like part of the main armbian site, and to provide an always-visible link back. However now I wonder if this is unnecessary, as Sources and Forum are not set up that way. Problems: - This is stored in the documentation repo, and the navbar html would need to be separately maintained from www.armbian.com's navbar. - I had to duplicate and edit the readthedocs theme "base.html", adding only one line. If updated theme source is obtained, this would have to be updated too. - The minimum relevant css was also copied, and I might have missed some. For example the font looks different. I also changed the docs order. I can't build the docs on the server... who can do this? Hopefully I haven't screwed anything up! I should be on hand in case these changes break anything... Also might want to verify that the readthedocs source I have is the same as on the server. The following should show only one line added: diff `locate readthedocs/base.html` readthedocs_custom/base.html
  17. I've reordered the docs, in mkdocs.yml, as proposed here: http://forum.armbian.com/index.php/topic/1540-400-implement-documentation-software-solution/#entry12238 I'm not sure if I got it right. Some of it is subjective. As far as I know nothing will break by changing this order, so anyone rewriting the docs should feel free to improve on it.
  18. Oops Igor beat me to it... Why not just let a mkdocs.yml file specify the order? This way the organization is part of the content, rather than controlled by the file naming. I guess with numbers you could strip out the prefix when building the docs, otherwise urls would change if their order changed. I experimented with an idea that has a mkdocs.yml template with sections that look like this: - 'Developer Guide' : - 'FEL boot' : 'Developer-Guide_FEL-boot.md' - 'User Configurations' : 'Developer-Guide_User-Configurations.md' ##INCLUDE Developer-Guide_ - 'User Guide' : - 'Getting Started' : 'User-Guide_Getting-Started.md' - 'Advanced Features' : 'User-Guide_Advanced-Features.md' ##INCLUDE User-Guide_ It seems mkdocs treats # as a comment, so this file doesn't break mkdocs if our processing gets broken. I have a bash script replace "##INCLUDE xxx" with all the files in docs/*xxx*.md that are not already included in the template. This way, a doc writer can specify the order of everything as much as they want, and also leave a place for any new files. It also has the advantage that the displayed titles can be changed without needing to change the filenames (and subsequent URLs).
  19. Do you have a plan for how to do this? I think the order of subtopics will need to be controlled by doc writers, too. For example, "Build Options" (is this a subtopic?) shouldn't come before "Build Process" Edit: Bad example "Build Preparation". Is mkdocs.yml auto-generated so that people can add new files without having to edit anything? Is it feasible to have a human-edited mkdocs.yml (maybe a template), which controls the order of categories and topics, but have the build script add any remaining files? My goal for sort order is to have the docs read like a tutorial+reference book. It would be something like "Intro/where to find what you're looking for, getting started, advanced, developer guide, reference". If you read the web pages or pdf from start to finish, nothing should feel like it's out of place.
  20. I'm not actively doing anything at the moment, to avoid stepping on toes. I would like to QA/edit the organization and navigation of the docs (within the current tools/layout). I could probably do that now? I might add to some of the content, for beginner readers, but only after others' rewrite tasks are done.
  21. I feel that settling on filenames/URLs as quickly as possible should be a high priority. Are the current filenames settled? (including the "feel boot" typo?) If perfect permanent links are infeasible, breaking links and leaving temporary/WIP names for long periods should at least be avoided as much as we can. I don't know how much of a problem it could really be, but I imagine people googling a common question, and ending up at a permanent forum post somewhere that contains a broken link to the documentation. I was curious about collapsible navigation links and came across this mkdocs theme example: http://developer.helpmonks.com/ Code and description can be found here: https://github.com/mkdocs/mkdocs/issues/588 This appears to be a WIP, has bugs and might be hacky, and is extra complication on top of readthedocs, so I don't recommend we use it, just an idea. I downloaded the theme and tried it out on our docs. It doesn't display subsections in the navbar, which is a problem. It looks like their theme's toc.html removes it, and adds support for organizing .md files into subdirectories.
  22. Looks like it's really coming along well! Do you want UX feedback discussed here, or on https://github.com/igorpecovnik/lib.docs(are issues disabled for it???), or should we wait until it's ready for feedback? For example... When I'm at docs Home, the User Guide sections are offscreen on my computer. Even if it is onscreen, it is below stuff like Task Tracking, Changelog etc. As a complete newb, if I go to the docs, I might skim the Home doc, maybe hit Next and stop reading by the FEX section at best. I might skim the sidebar topics... if I'm lucky I'll notice "Getting started" near the bottom. Otherwise I'll think that Home is all the getting started info there is and conclude that this all requires some expertise that I don't have. I don't know if such an issue is already being addressed with a doc reorganization, or if it is now baked into the current design.
  23. I continued my permanent link experiment, it is working locally. It's a simple bash script. I'm not 100% convinced it's a good idea. It is simply: 1. A human adds markers in the source document where you want to specify an anchor name, overriding what is automatically generated. 2. When html is built, script replaces the autogenerated anchors with the specified one, in mkdoc's output files (The anchor id, and links to it in the html files and search index). The marker that goes in source can be something that will not be displayed even if not properly processed out, eg: abuse a markdown reference: "[permalink]: my-anchor-name" or fake html that browsers will ignore: "<permalink="my-anchor-name"> (the latter can be processed more cleanly). It can be used sparsely in the source, only where desired (but then a site maintainer must add the tags when the scripts warn of potential broken links), or it can be used all over (but then either the doc writers must deal with them or a site maintainer). Whether this is worth it is someone else's call, so i'll leave it until someone wants to move forward. Any decision on it should be easily changed later.
  24. This doesn't actually provide persistent links across edits, like we want. As tkaiser has described, the links that are made (and shown with a link icon on the web page if permalink: true is there) are generated from the title text. "Legacy or Vanilla?" will have a link of #legacy-or-vanilla. If the title text is changed to "Choosing a kernel" the new link becomes #choosing-a-kernel. Either way the docs web pages work fine, but if someone posted a link to "http://docs.armbian.com/user-manual/#legacy-or-vanilla"in the forum, that link is broken after the section's title is changed. ... well, not terribly broken; it will link to the top of the page, instead of the correct section. Changing the page name will fully break the link. Edit: To put this another way, a "permanent link" according to mkdocs is essentially a link to a particular string of text in a section title. It is permanent only as long as that text is permanent (which it isn't if we have ongoing documentation editing).
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines