**** BEGIN LOGGING AT Fri Apr 30 02:59:56 2021 Apr 30 08:00:44 hey there Apr 30 08:01:39 I'm having issue trying to flash a 2020 beaglebone black, as stated in the documentation I've edited the /boot/uEnv.txt file to enable init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh Apr 30 08:01:57 after rebooting it actually erased my SD card and copied the content of the eMMC into it rather than... the opposite Apr 30 08:50:24 markand: you edited the /boot/uEnv.txt file on eMMC rather than the one on SD card Apr 30 08:50:40 the easiest way to reflash is to just download a pre-made flasher image to begin with Apr 30 08:51:41 but what happened here is probably that either your sd card was unbootable or the bootloader on eMMC was too ancient to understand how to boot it, so when you tried to boot from SD card it just booted from eMMC instead Apr 30 08:53:17 the workaround for the latter is powering on the beaglebone with the boot button ("S2") held down during power-on (you can let go once the power led turns on), which makes bootrom ignore eMMC and load the bootloader from SD card instead Apr 30 09:01:29 zmatt, in fact we have our own set of prebuilt images that run a specific software Apr 30 09:01:56 we have <=2018 BBB that we used to simply power on pressing the boot option and the process would immediately copy the SD into the eMMC Apr 30 09:02:06 but on the >=2020 it's no longer possible Apr 30 09:02:12 markand: okay, well the only difference between a flasher and a normal image is uncommenting that one line Apr 30 09:02:19 pressing the S2 button makes the bone trying to boot from SD Apr 30 09:02:39 the function of the S2 button has not changed Apr 30 09:03:15 but there is definitely an issue then, because I promise you that on my desk there are two BBB and that powering one with the S2 button does not the same thing than the other Apr 30 09:03:26 one older from element14 Apr 30 09:03:29 when exactly are you pressing the S2 button? Apr 30 09:03:30 and one from last year Apr 30 09:03:41 before plugging the USB cable Apr 30 09:04:25 so just to confirm, the image you're trying to boot is quite old? Apr 30 09:04:56 like, what era of u-boot and kernel are we talking about? Apr 30 09:04:58 honestly I don't know because the ones who created the images left the company without any documentation ._. Apr 30 09:05:12 but yes I think they are around from 2018 Apr 30 09:05:20 2018 isn't old Apr 30 09:05:27 I can mount one and tell you anything you want Apr 30 09:07:25 and if your sd card was already a flasher card, why did you try to modify it to turn it into a flasher card when it was already supposed to be one? Apr 30 09:07:46 I don't think they are flasher card, let me mount to check Apr 30 09:08:00 well didn't you previously use them to flash beaglebones? Apr 30 09:08:34 yes but colleagues told that to flash they needed to press the S2 button and after than the led were cycling during the process Apr 30 09:08:42 and since our new cards from 2020, it's no longer working Apr 30 09:08:50 that's what we're not able to understand Apr 30 09:08:55 then they misexplained the process Apr 30 09:09:42 unless there's custom logic in your image that's unlike any standard image, the S2 button has no impact on whether it will boot or flash Apr 30 09:10:24 so the SD card first partition has definitely cmdline=init=/opt/scripts/tools/eMMS/init-eMMC-flasher-v3.sh Apr 30 09:10:32 inside the boot/uEnv file Apr 30 09:10:38 all booting with the S2 button held down does is make bootrom ignore eMMC and load the bootloader (u-boot) from SD card instead of from eMMC Apr 30 09:10:48 yeah, so your sd card is a flasher card Apr 30 09:10:52 yes Apr 30 09:11:03 now, I'd like to know why it isn't flashing ;p Apr 30 09:11:42 unfortunately plugging a HDMI cable does not show anything at all Apr 30 09:12:00 boot issues are best debugged using the serial console Apr 30 09:12:30 I need to wait until I receive my USB TTL converter Apr 30 09:12:59 the only two hypothesis I can think of are: 1. you failed to held down the S2 button during power on (it's a pretty small fiddly button after all). or 2. the bootloader on SD card is inexplicably deciding to boot the system on eMMC instead of the one on SD card Apr 30 09:14:02 :q Apr 30 09:14:21 but if it was deciding to boot from the eMMC I'd see the default BBB graphical environment at some point Apr 30 09:14:30 there's an easy way to test hypothesis 1: try doing it without any SD card inserted. the expected result is that the system does not boot at all (power led turns on, nothing else happens). you can then (without power cycling) insert an sd card and press the reset button Apr 30 09:14:38 the BBB hasn't shipped with a graphical environment in quite a while Apr 30 09:14:40 if I do it on our 2020+ the D42 LED stays fixed Apr 30 09:14:56 Oo Apr 30 09:15:25 those (from embest) do boot to a graphical environment if I power them on directly out of the box Apr 30 09:16:01 must be preduced quite a while ago and be running some pretty old system Apr 30 09:16:28 that may explain lots of things Apr 30 09:16:36 I'll try to clarify this with my colleagues Apr 30 09:17:12 regardless, since your sd card is a flasher, if it boots it will flash Apr 30 09:17:29 if there's no major incompatibility with the bootloader on eMMC and system on sd card then the S2 button is superfluous Apr 30 09:18:58 the main use of the S2 button is to make it boot from SD card if the bootloader on eMMC is too ancient or weird to understand how to boot the system on SD card Apr 30 09:54:36 okay received my FTDI converter, let see what the boot says... Apr 30 10:31:14 hmmm not sure what I'm doing wrong with picocom: https://paste.centos.org/view/a6373a37 Apr 30 10:31:17 :) Apr 30 10:31:36 baudrate probably Apr 30 10:31:41 actually using this one: https://fr.rs-online.com/web/p/cables-raspberry-pi/7676200/ Apr 30 10:31:44 it should be 115200 Apr 30 10:31:58 yes, I use picocom -b 115200 /dev/ttyUSB0 though Apr 30 10:32:23 hum Apr 30 10:34:29 and you connected black -> pin 1 (marked with dot), orange -> pin 4, yellow -> pin 5 ? Apr 30 10:36:06 aaah yes Apr 30 10:36:11 I've swapped the orange and yellow Apr 30 10:36:15 work, thanks ! Apr 30 10:36:37 connecting output to output is not great for the health of electronics Apr 30 10:37:40 I've followed this diagram https://www.blaess.fr/christophe/2013/05/17/console-serie-de-debug-pour-beaglebone-black/ Apr 30 10:37:45 so the guy was probably wrong Apr 30 10:37:52 anyway Apr 30 10:37:59 now I have the issue why it's not flashing Apr 30 10:38:22 the script on the SD card seems to not find /dev/mmcblk1 Apr 30 10:38:38 https://paste.centos.org/view/ddad4b91 Apr 30 10:39:35 so when attempting to boot from sd card it just doesn't boot at all? that's something you failed to mention before Apr 30 10:39:59 it boots to the sD card and try to open the eMMC flasher script but fails to that point ^ Apr 30 10:40:00 that would have been pretty crucial information Apr 30 10:40:20 I was unable to tell if it boots at all since there was no screen output Apr 30 10:40:29 so we were quite stuck until I got this serial cable Apr 30 10:40:33 well the leds would have shown you probably? Apr 30 10:40:42 regardless, is this kernel 3.8.x ? Apr 30 10:40:48 I think yes Apr 30 10:41:08 okay so your system isn't from 2018, it's something truly ancient Apr 30 10:41:38 heh, they named the image with the date of 2018 Apr 30 10:41:39 ¯\_(ツ)_/¯ Apr 30 10:41:41 the quick fix: update the kernel package to the latest 3.8.x one Apr 30 10:42:20 your kernel is too old to recognize modern eMMC v5, but rcn backported the patch to the 3.8.x series for those silly people still using it Apr 30 10:43:50 easiest way of doing that is probably changing your image to a non-flasher (by commenting out that line in its /boot/uEnv.txt), booting the sd card, installing the kernel with apt, and then changing back its /boot/uEnv.txt Apr 30 10:44:52 it's also possible to do it by mounting the sd card or image thereof on a debian host system and then using systemd-nspawn + qemu-arm-static to spawn a shell inside the image Apr 30 10:45:19 (or other linux distro probably, but I know the exact steps on debian) Apr 30 10:46:14 the upgrade_kernel.sh is supposed to be ran from the beaglebone itself I suppose Apr 30 10:46:48 yes the chroot was the idea Apr 30 10:46:51 let me try Apr 30 10:47:44 chroot does not suffice Apr 30 10:48:05 ah yes it takes the kernel version from the host Apr 30 10:49:52 you can't chroot inside an image of foreign architecture in the first place Apr 30 10:50:08 I'm running on a rpi right now so same arch ;p Apr 30 10:50:12 ah Apr 30 10:50:32 then I guess you can just use apt to install the kernel Apr 30 10:50:55 ah yes the current kernel is 3.5 Apr 30 10:51:01 3.5 ?!???!? Apr 30 10:51:04 what? Apr 30 10:51:06 yeah x) Apr 30 10:51:14 okay that changes everything Apr 30 10:51:16 ii linux-image-3.8.13-bone79 1wheezy armhf Linux kernel, version 3.8.13-bone79 Apr 30 10:51:22 ... Apr 30 10:51:25 that's 3.8 Apr 30 10:51:29 what Apr 30 10:51:34 oh sorry Apr 30 10:51:36 wrong line Apr 30 10:51:37 ii linux-base 3.5 all Linux image base package Apr 30 10:51:40 phew Apr 30 10:52:45 so you can probably just apt-get install linux-image-3.8.13-bone86 Apr 30 10:53:18 the eMMC patch was applied in -bone80 (june 2016) Apr 30 10:53:36 first need to fix the mirror broken Apr 30 10:53:41 apt does not update Apr 30 10:53:56 https://www.youtube.com/watch?v=AbSehcT19u0 Apr 30 10:54:00 relevant video of me right now Apr 30 10:57:11 I mean, that happens when you let stuff get older and older and older and never update anything Apr 30 10:57:45 at some point you end up forced to update something, and then you find yourself in hell Apr 30 11:21:40 heh yes, but we're not going to keep this for long anyway Apr 30 11:21:58 we're planning a major overhaul of our machine Apr 30 11:31:39 markand: in case it's ever useful, here's a script to spawn a root shell inside a foreign-architecture disk image: https://pastebin.com/SzVTzT3g Apr 30 11:32:00 (adapting it to a foreign-architecture sd card should be easy enough) Apr 30 11:32:08 ah yes I use qemu-user-static a lot :) Apr 30 11:32:16 ok :) Apr 30 11:32:24 it's so great to build minimal images for my SBCs Apr 30 11:32:36 but I admit I never knew/used beaglebone before Apr 30 11:32:51 and the uname -a you get is pretty funny... "Linux beaglebone 5.9.0-5-amd64 #1 SMP Debian 5.9.15-1 (2020-12-17) armv7l GNU/Linux" Apr 30 11:33:38 linux-image updated, finger crossed Apr 30 11:34:35 it's booting! Apr 30 11:34:42 \o/ Apr 30 11:34:54 thanks a lot zmatt, you've fixed 2 days of headhaches Apr 30 15:03:54 zmatt, I have another small issue now while booting our fresh created https://paste.centos.org/view/9a681b68 Apr 30 15:04:16 once in the emergency shell I can start these services fine, I suspect the boot is so fast that /dev/mmc* isn't present at the time Apr 30 15:05:10 I mean, it should normally take that into account Apr 30 15:06:07 you could try updating the initramfs package, see if that helps Apr 30 15:06:27 or just don't use initramfs in the first place (but I think that had problems on ancient kernels) Apr 30 16:15:12 update-initramfs -u did the trick Apr 30 16:15:19 thanks again zmatt Apr 30 16:20:58 what is initramfs anyway Apr 30 16:36:03 the short answer would be it used to be required to load the rootfile system tho nowadays there are other ways handling things Apr 30 16:41:34 kinda depends on what your playing with for hardware and how your bootloader goes about setting up the kernel and root file system Apr 30 16:42:34 buzzmarshall: it's not (and never has been) needed when all drivers required for the kernel to find and mount your root filesystem are built into the kernel, which is the case for beaglebone kernels Apr 30 16:42:46 the problem with old kernels are that the mmcblk numbering was not stable Apr 30 16:42:57 some systems would use a root file system which may contain some tools like busybox or other stuff that in a compressed archive loaded with the kernel by the bootloader Apr 30 16:43:04 which made it problematic for u-boot to specify the root filesystem Apr 30 16:43:18 i never said it was mandatory Apr 30 16:43:33 and there are still systems that use it Apr 30 16:43:59 nearly all do Apr 30 16:44:09 use initramfs Apr 30 16:44:39 generic linux distros at least normally will Apr 30 16:45:10 since it means the kernel doesn't need to include hardware-specific drivers, it suffices if those are included in the initramfs as modules Apr 30 16:46:40 yes i understand all of tht Apr 30 16:47:19 it was a general statement not something specific to arm or other non pc cpu's Apr 30 19:02:53 Hi Good-Afternoon: I created a service, and try to get user keyboard input in the service script. But it fails to call/run the script. Apr 30 19:03:28 uhh, get user keyboard input how? Apr 30 19:04:04 "user input" and "service" are normally kinda mutually exclusive Apr 30 19:04:11 wait and then read from the keyboard input Apr 30 19:04:16 what keyboard? Apr 30 19:04:39 and how? Apr 30 19:04:48 from console Apr 30 19:04:53 tty13 Apr 30 19:05:24 tty13 ? what a strange number? Apr 30 19:05:33 I was referencing : https://www.golinuxcloud.com/read-user-input-during-boot-stage-linux/ Apr 30 19:06:18 I see, that explains the tty13 Apr 30 19:06:30 this looks gross though Apr 30 19:06:58 what do the logs say? Apr 30 19:08:00 it says failed to start "MNU Installation" which is the service description Apr 30 19:08:03 also, this looks like something that probably shouldn't be used other than by installers or such Apr 30 19:08:15 given how it's blocking all normal login Apr 30 19:08:22 (including via ssh) Apr 30 19:08:47 full logs please, "failed to start" is not meaningful info Apr 30 19:09:38 journalctl -b -u mnu gives all logs related to mnu.service Apr 30 19:09:52 adding --no-pager is probably a good idea for ease of copy-pasting Apr 30 19:16:23 Messages, service, and script: https://pastebin.com/e5qDSh3M Apr 30 19:16:54 is your script executable? Apr 30 19:17:21 as in, chmod a+x Apr 30 19:18:04 the script is -rwxr-xr-x Apr 30 19:19:18 I just found that : systemctl enable take-user-input.service , but that service is not in my service. I may have to install it first Apr 30 19:19:42 can you add the --no-pager flag to journalctl so the log output isn't truncated? Apr 30 19:19:54 that was the example name of their example service Apr 30 19:22:10 I added --no-pager, it outputs the same. Apr 30 19:24:26 ok. It is the example service Apr 30 19:25:30 Basically, I just copied whole service script. Apr 30 19:25:58 with --no-pager it does not truncate log output.. what you pasted is already truncated Apr 30 19:29:00 sorry, it was cut by console window: https://pastebin.com/841Qd70t Apr 30 19:29:31 well there's your answer Apr 30 19:29:45 it never even got to executing your script Apr 30 19:30:01 I spotted typo ncu-install but script name is ncu_install.sh Apr 30 19:30:41 hmm? ExecStart=/ncu_install/ncu_install.sh Apr 30 19:30:46 looks fine in what you pasted Apr 30 19:30:57 I'm referring to "/usr/bin/chvt: No such file or directory" Apr 30 19:32:02 it might be in /bin instead of /usr/bin, or whatever package it belongs to isn't installed Apr 30 19:32:36 but chvt command can run from shell Apr 30 19:32:52 then the path is probably wrong, check "which chvt" Apr 30 19:33:34 I see. chvt is installed not under /usr/bin Apr 30 19:34:54 chvt is under /bin  not /usr/bin Apr 30 19:40:39 The service is started, but no prompt from the booting console for entering anything May 01 02:22:17 What happened? May 01 02:42:11 How is the V coming along? Any super projects yet w/ it? May 01 02:58:36 Well, I am solely asking outside of the booting and/or image usage... May 01 02:59:13 I have been readin' the forum. It seems people are getting the hang of the Beta version. May 01 02:59:34 Someone posted a photo. It had a huge heatsink w/ copper on it! May 01 02:59:43 Nice! **** ENDING LOGGING AT Sat May 01 03:00:43 2021