hinkley

  • Content Count

    9
  • Joined

  • Last visited

About hinkley

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Seems like the goalposts have moved. I have an m4v2, I'm running buster, and none of the /sys files mentioned in this thread exist anymore.
  2. Not sure how that helps with ansible. I believe the metadata is gathered and then the logic runs on the remote server, does it not? It looks like everything in Armbian that says it's Armbian are in files with 'Armbian' in the name, from /boot to /etc. Which of course general purpose Linux tools will not be looking for.
  3. Grovelling through k3s's playbook a and digging through the Armbian filesystem a little bit, I've figured out that Armbian reports: Whereas some folks on the Internet report that Rasbian returns: It seems like it might work better to follow Raspbian's pattern. It would give me something for ansible to sink its teeth into (ansible does not seem to report Distributor ID, which is a shame) Would it hurt anything to change this behavior? I haven't built a kernel in forever, let alone filed a patch to a distribution. How would I go about getti
  4. As an ansible neophyte, I'm looking through the 'ansible facts' trying to figure out how to positively identify an Armbian system, with the goal of contributing a patch to the k3s project to improve support for Armbian. Toward the end of the k3s-ansible playbook, they try to write some kernel options to a file in /boot. According to the comments, they've identified by Armbian machine as Ubuntu. At any rate, Armbian seems to want these flags in /boot/armbianEnv.txt, and the file ansible wants to modify doesn't exist so the update aborts: fatal: [t4]: FAILED! => {"chan
  5. Just ran a test, and it's still both. That's just a flat tarball of the contents of the 7z file I extracted. I'll see what it looks like to get tarball support into Etcher. It's likely I could put together a PR for that bit. From recent experience, working with tarballs in Node seems easier than zip files, so I'm surprised it isn't in there. But I also may be missing some architectural detail that is peculiar to the burning process. Also it looks like this guy just resurrected his 7zip implementation: https://github.com/quentinrossetti/node-7z but th
  6. Im not sure https://github.com/balena-io/etcher/issues/711 says tarballs couldn’t be supported. I’ll double check that they still aren’t. It clearly has a way to locate .img files in the top level directory of some archives.
  7. So if I understand what you guys are saying, it’s not the compression format that’s the problem, it’s the payload. There is no way to sign the kernel image that Etcher would accept (and that humans could accept) ? That... really seems like a feature I might like to have in Etcher itself. I’ll keep poking around their issue database and see if they have anything more to say on that. Thanks.
  8. I’d already found the github conversations from 2017 and. 2018 that were inconclusive. Your sarcastic reply of a conversation from 2016 isn’t helpful and reinforces my initial impression. Don’t make people install two pieces of software they’ve never used before to try out your stuff. And if you must, put the instructions in *one* place. It’s hostile to new and prospective users if you don’t.
  9. Etcher understands zip, gzip, bzip2, and I don't know what all else. But it has no idea what a 7z file is. So I have link in proximity for two of the three binaries I need to get, and the third buried in grey on black text at the bottom of the page where nobody will see it and instead they will feel compelled to go out to find it on their own. Are 7z files really enough smaller than bz2 that it's worth this?