**** BEGIN LOGGING AT Thu Mar 19 03:00:02 2020 Mar 19 19:20:23 Hello, I need to backup the eMMC, but I don't have a microSD, but I have a USB flashdrive. Will that work? Can I pass a device drive as argument to the backup script? Mar 19 20:08:54 which backup script? Mar 19 20:08:59 oh he left Mar 19 20:26:02 sorry I had an Internet disrupt, and the IRC log doesn't show recent activity. Mar 19 20:26:03 I need to backup the eMMC, but I don't have a microSD, but I have a USB flashdrive. Will that work? Can I pass a device drive as argument to the backup script? Mar 19 20:26:27 which backup script? Mar 19 20:27:56 I was reading a guide where the guy used /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh Mar 19 20:29:05 well one problem would be that you'd have difficulty restoring that backup since the beaglebone can't boot from a usb drive Mar 19 20:31:07 Ok. With that script I will end with a copy of the system as .img file in the microSD? Mar 19 20:31:36 or I will end with a copy of the system written as raw binary data in the microSD? Mar 19 20:33:39 no, based on the name I'd presume it will make your microsd a bootable flasher. Mar 19 20:33:54 you could make an image of that though Mar 19 20:34:07 what I personally do is boot from sd card and then make an image of the eMMC Mar 19 20:34:54 (and then shrink the filesystem to minimum size) Mar 19 20:35:45 to boot from an sd card, the sd card needs to have an image system? Mar 19 20:35:58 some bootable system Mar 19 20:36:18 e.g. a console image Mar 19 20:37:50 like the iot one in the official website? Mar 19 20:37:57 iot is pretty bloated Mar 19 20:38:10 ok Mar 19 20:38:21 you can find the console image here: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Stretch_Console_Snapshot Mar 19 20:38:34 thank you Mar 19 20:38:42 but note that just because my way of making backups works well for me doesn't mean it's the best solution for everyone Mar 19 20:39:56 for example if you're a Windows user then making an image file on an ext4-formatted sd card may not be very convenient if you want to later copy that file onto your pc, since Windows won't be able to mount the card Mar 19 20:44:18 Ok, I'm a Debian user so there's no problem with ext4. I have been using RPI, but that doesn't have an eMMC, so backups are differently. What I'm missing is an official guide in https://beagleboard.org Mar 19 20:44:35 how does elinux relate to beagleboard? Mar 19 20:45:18 is that a different community? I have seen that they have also have other boards, like RPI... Mar 19 20:50:29 elinux is just a general resource for embedded linux Mar 19 20:51:15 that particular page however is maintained by the person who maintains the kernels and debian images for beagleboard.org Mar 19 20:52:48 and I agree it would be nice to have a simple way to make backups... I guess the script that makes an eMMC-flasher sd card from eMMC contents is the closest thing Mar 19 20:56:25 In your method, you boot from the SD, when you want to backup the system you dd from emmc to a file in the SD, right? and if you want to restore from a saved system you dd from the file in the SD to the emmc, right? Mar 19 20:59:05 well, more or less Mar 19 21:01:48 I generally backup just the filesystem since that makes it easier to then shrink it to minimum size and I know all our systems use the same u-boot version anyway. for flashing I have a script that will wipe (blkdiscard) and partition the eMMC, write the filesystem image and expand to fit, and install u-boot Mar 19 21:02:37 this is also because often when I do this it's not because I want to restore an old backup to the same beaglebone but either restore it to new hardware because the old one is borked or most commonly flash a new beaglebone with the same image. Mar 19 21:03:17 because the latter is the typical use-case, the script also takes care of regenerating unique identifiers (filesystem uuid, machine id), setting the hostname, generating ssh keys Mar 19 21:03:35 but all this is kinda specific to our environment I think :) Mar 19 21:05:03 (another reason to shrink the filesystem and later reexpand it is to accommodate the fact that different beaglebones may have different eMMC chips which, despite all being "4GB", actually have slightly different sizes) Mar 19 21:05:36 (and it just makes flashing faster if you don't have to write empty space) Mar 19 21:07:33 ok thank you by sharing that Mar 19 21:07:56 sorry for the wall of text that might not be terribly useful ;) (at least our procedures are still sorta approachable right now... eventually I plan to be in the position to say "oh, we reflash/backup/restore via ethernet" ;-) Mar 19 21:08:12 np :) Mar 19 21:08:23 do you work for bb? Mar 19 21:08:28 nope Mar 19 21:08:35 oh :) Mar 19 21:08:53 I have no particular affiliation with them, we're just a company that happens to use beaglebones Mar 19 21:10:04 cool... I'm in this project were I was asked to program their stuff, and then replicate the system to other bbb boards Mar 19 21:10:35 then easiest is definitely to use the script to make an eMMC flasher sd card, and use that to flash other beaglebones Mar 19 21:11:06 :) Mar 19 21:11:44 unless the number of boards is big enough that tooling the flashing process to handle whatever per-beaglebone customization is needed (e.g. hostname) is more efficient than performing that customization on each beaglebone after flashing Mar 19 21:13:19 yes Mar 19 21:15:41 I need to buy the microSD, but I'm afraid of left my home. https://tinyurl.com/vlk2gme Mar 19 21:16:00 :D Mar 19 23:21:20 zmatt:is it fair to assume the pin files will always be located I that folder you are using in the python script Mar 19 23:24:30 MattB0ne: /sys/bus/platform/drivers/bone-pinmux-helper/ contains symlinks to all pinmux helper devices (along with three standard attributes: "uevent", "bind", and "unbind") Mar 19 23:25:21 right how portable would it be to hard code that part of the path Mar 19 23:25:27 fully Mar 19 23:25:56 well, that part could only change if the name of the driver is changed, which seems implausible Mar 19 23:26:18 the name of the driver is also used in various udev rules, so if that were to change, a lot more would break Mar 19 23:26:46 (in particular, you wouldn't be able to change the pinmux settings even if you were able to locate them since their permissions wouldn't be setup) Mar 19 23:27:42 but if you want guaranteed paths I can probably make an udev rule for you that creates proper symlinks Mar 19 23:27:48 to eliminate all uncertainty about paths Mar 19 23:28:34 (I already have a similar one for gpios: https://pastebin.com/YKW7Wcqu ) Mar 19 23:31:03 or you can just try "/sys/bus/platform/drivers/bone-pinmux-helper/%s_pinmux/state" and "/sys/bus/platform/drivers/bone-pinmux-helper/ocp:%s_pinmux/state" ... if I remember correctly those are the two options Mar 19 23:31:30 (depending on kernel version) Mar 19 23:32:17 (why they put pinmux helpers in &ocp is a mystery to me, they absolutely do not belong there) Mar 19 23:35:52 ah never mind, the prefix can be different Mar 19 23:45:32 why is the latest Debian image have such an old build of g++ Mar 19 23:45:35 MattB0ne: https://pastebin.com/raw/X6iFaAxB Mar 19 23:47:00 what does this do? Mar 19 23:48:32 creates a directory /dev/pinmux/ with symlinks to pinmux state attributes, whose name is guaranteed to be the name of the pinmux helper node, e.g. /dev/pinmux/P9_11_pinmux Mar 19 23:49:04 regardless of where they are located in sysfs Mar 19 23:49:33 (and should the driver name ever change for some inexplicable reason, you'd only need to update the udev rule and not your applications) Mar 19 23:51:57 and debian stretch uses gcc 6.3 and that's never going to change since it's an old debian release. I don't know what the reason is the default images haven't moved to debian buster yet but presumably there is a reason Mar 20 00:03:29 doh Mar 20 00:04:53 tha ks for the script Mar 20 00:05:29 sucks about Debian stretch my life would be a lot easier with some of the newer libraries in the later versions Mar 20 00:08:00 yeah I use buster... with some stuff from backports I think, or maybe even bullseye (though mixing packages from different releases should not be done unless you're comfortable with the possibility of having to resolve terrible package dependency deadlocks some time in the future) Mar 20 02:13:21 This is a test Mar 20 02:13:45 Works... **** ENDING LOGGING AT Fri Mar 20 02:59:57 2020