buzzmarshall has quit [Quit: Konversation terminated!]
rob_w has joined #beagle
Shadyman has quit [Quit: Leaving.]
alan_o has quit [Remote host closed the connection]
rob_w has quit [Remote host closed the connection]
giort has joined #beagle
giort has quit [Client Quit]
florian has joined #beagle
rob_w has joined #beagle
vd89 has joined #beagle
vd has quit [Ping timeout: 256 seconds]
Guest48 has joined #beagle
<Guest48>
Hello all. Good to see you all!
<Guest48>
Can anyone suggest me how to use USB1 on Pocketbeagle please?
<Guest48>
Since my connection is like this.
<Guest48>
BBE connected to PB at USB0 and a usb device is connected to PB at USB1 but PB is not showing the usb device connected at USB1. BBE detects PB well at /dev/ttyACM0
ikarso has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
vd898 has joined #beagle
vd89 has quit [Ping timeout: 256 seconds]
zjason` is now known as zjason
alan_o has joined #beagle
rob_w has quit [Remote host closed the connection]
Guest63 has joined #beagle
Guest63 has quit [Client Quit]
Guest48 has quit [Quit: Client closed]
Guest22 has joined #beagle
Guest22 has quit [Client Quit]
MTBeagleFan has joined #beagle
florian has quit [Quit: Ex-Chat]
<MTBeagleFan>
Does anyone know why the power button on the Beaglebone AI does not power down the the beaglebone like it did on the beaglebone black.
<zmatt>
that sounds like probably a driver issue
<zmatt>
or maybe the pmic isn't capable of generating an event for whatever the button is connected to
<zmatt>
but that would be dumb
<zmatt>
let's see, it connects to PWRON
russ has quit [Ping timeout: 246 seconds]
russ has joined #beagle
<zmatt>
the pmic can most definitely generate an interrupt when it's pressed
<MTBeagleFan>
zmatt: Thanks. :)
<zmatt>
I'm looking at the palmas-pwrbutton driver
<zmatt>
yeah dunno, looks fine at a glance, ditto for the bbai DT
<zmatt>
I don't have my bbai at hand to try it myself nor time to dig deeper I'm afraid
<MTBeagleFan>
No problem, I appreciate the help.
<zmatt>
if you're using a 4.14-ti kernel (default on TIDL images) it might be useful to try a 4.19-ti kernel (default on non-TIDL images)
vd898 has quit [Quit: Client closed]
vd898 has joined #beagle
russ has quit [Ping timeout: 265 seconds]
russ has joined #beagle
the_person48 has joined #beagle
<the_person48>
hey guys, I have a debian image on a microSD card that I am happy with, with a uboot overlay that I created. I am just trying to backup the image and make a few copies on other microSD cards, but am having trouble
<the_person48>
I tried making the image file with the dd command:
<the_person48>
1) plugged in the microSD card using a USB card reader
<the_person48>
then I reversed the process onto another microSD card, with the final command being:
<the_person48>
dd if=debian_image.img of=/dev/sdb
<the_person48>
but for some reason, the beaglebone won't boot from the image on the new card. when I power on the beaglebone holding the user boot button, it doesn't boot. When I don't hold the user boot button, it boots from the eMMC instead, which is not what I want
<the_person48>
I also tried putting the image onto a new microSD card with balena etcher: https://www.balena.io/etcher/
<the_person48>
which tells me "it looks like this is not a bootable image. the image does not appear to contain a partition table, and might not be recognized or bootable by your device"
<the_person48>
any idea what might be wrong here? I'm not clear if there's something wrong with how I made the image, or how I'm trying to put it on the new cards, or both
<the_person48>
the original image was on a 64 GB microSD Samsung EVO plus card
<the_person48>
the new cards I'm trying to put the image on are 64 GB SanDisk extreme, might that be causing or contributing to the issue?
dinuxbg has quit [Ping timeout: 260 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
buzzmarshall has joined #beagle
MTBeagleFan5 has joined #beagle
MTBeagleFan5 has quit [Client Quit]
the_person48 has quit [Quit: Client closed]
the_person48 has joined #beagle
set_ has quit [Ping timeout: 252 seconds]
<zmatt>
that error suggests something went horribly wrong with making the backup
<zmatt>
the_person48: can you pastebin the output of: hexdump -C debian_image.img | head -n 20
<the_person48>
gotcha
<zmatt>
also, reading or writing a 64GB image sounds pretty tedious :P
<the_person48>
my reader is USB 3.0 though so it's not too bad
<zmatt>
I'd expect the sd card to be the limiting factor, not the card reader or its connection (unless it's really terrible)
<zmatt>
this looks like you backed up the rootfs partition (sdb1), not the entire card (sdb)
<the_person48>
ah, interesting
<zmatt>
running "file debian_image.img" is another way of finding out what's going on
<the_person48>
newest_debian_image.img: Linux rev 1.0 ext4 filesystem data, UUID=78c73c53-58d6-49e4-8225-b17d456feb88, volume name "rootfs" (extents) (large files) (huge files)
<the_person48>
ok, I'll re-dd and make sure to do the whole thing this time
<zmatt>
wait
<zmatt>
you can save time
<zmatt>
I assume the rootfs starts at offset 4MB (sector 8192) ? (check with fdisk -l /dev/sdb)
<the_person48>
I want to do it on 3 cards, so I'd like to just make sure I have the process down then I'll repeat it exactly
<the_person48>
are you suggesting copying just the remaining part over?
<zmatt>
you can insert 4MB of space at the start of the file and dd only that part over
<zmatt>
btw when dd'ing I suggest using 4MB blocksize (bs=4M) instead of the default of 512 bytes
<the_person48>
gotcha
<the_person48>
how come?
<zmatt>
also, after making a backup, before flashing new cards, be sure to remove things that are supposed to be unique: /etc/machine-id /var/lib/dbus/machine-id /etc/ssh/ssh_host_*
<zmatt>
performance
<zmatt>
and 4MB tends to be the write allocation group size of sd cards
<zmatt>
that's also why the rootfs is aligned to that
<zmatt>
what I personally also do is shrink the filesystem to minimum size and then after flashing I recreate the partition table to ensure the rootfs partition spans the entire device (from its 4MB start offset on) and then expand the filesystem to fit the partition
ikarso has joined #beagle
<the_person48>
what happens if you don't remove the unique hardware stuff?
<the_person48>
and yeah, that makes sense, I don't think it needs to be 64 gb
giort has joined #beagle
<the_person48>
I just got it from an image that was on a 64 gb card so I thought I was locked into that size
<zmatt>
making the machine-id non-unique may or may not bite you in the ass later, it's just not a good idea, it's supposed to be a unique identifier. if removed they will be auto-generated at boot
<zmatt>
sharing ssh keys is a security problem since it means access to any of these systems (or the image file) allows for compromising all of the systems
<the_person48>
gotcha
<the_person48>
yeah ok that makes sense
russ has quit [Ping timeout: 245 seconds]
<zmatt>
the_person48: if it's of interest, I have this script to shrink an image file (containing a single ext2/3/4 partition): https://pastebin.com/FvK2yPhQ
<zmatt>
note: it does not preserve the original image file
russ has joined #beagle
<zmatt>
when flashing such a shrunk image, the easy way to expand the partition after flashing is by just recreating it using: echo 'start=8192,bootable' | /sbin/sfdisk $dev where $dev is the target device (e.g. /dev/sdb or whatever)
<zmatt>
(instead of rudely hardcoding the partition start offset you could use the detection logic from my shrink-image script)
<the_person48>
gotcha
<the_person48>
thanks
the_person48 has quit [Quit: Client closed]
<zmatt>
then expand the filesystem using /sbin/resize2fs $part where $part is the partition device (e.g. /dev/sdb1)
russ has quit [Ping timeout: 245 seconds]
<zmatt>
beware that the repartitioning causes /dev/sdb1 to disappear and reappear, so when doing this in a script you may need a brief sleep or whatever between these steps, otherwise there's a chance the partition device hasn't reappeared yet causing the second step to fail
<zmatt>
also, resize2fs refuses to resize a filesystem that hasn't been checked by e2fsck -f. shrink-image will do so as part of the shrinking process, but if you've mounted the filesystem after shrinking then you should run e2fsck -f on it again before flashing
<zmatt>
oh, and after flashing you should probably also randomize the filesystem uuid using: yes | tune2fs -U random $part where $part is the partition device
<zmatt>
that's another one where I'm not sure if failing to do so will ever bite you in the ass, but I do it anyway to be safe
<zmatt>
possibly something might get upset if you had multiple filesystems attached with the same uuid
<zmatt>
*have
russ has joined #beagle
russ has quit [Ping timeout: 245 seconds]
<zmatt>
oh he left
russ has joined #beagle
giort has quit [Quit: giort]
Shadyman has joined #beagle
russ has quit [Ping timeout: 245 seconds]
vd898 has quit [Quit: Client closed]
vd898 has joined #beagle
russ has joined #beagle
giort has joined #beagle
giort has quit [Quit: giort]
MTBeagleFan has quit [Quit: Client closed]
MTBeagleFan has joined #beagle
MTBeagleFan has quit [Client Quit]
set_ has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]