**** BEGIN LOGGING AT Thu Apr 11 02:59:58 2019 Apr 11 03:00:53 if your first partition starts at sector 2048 ... a somewhat large u-boot.img can take up more space than it ought to Apr 11 03:01:21 and u-boot has been growing over time Apr 11 03:01:41 well if it were to intrude on the ext4 partition by more than 1 KB, e2fsck would scream bloody murder at you Apr 11 03:01:51 that's what i assumed Apr 11 03:02:03 but it's certainly enough that u-boot refuses to boot from the partition Apr 11 03:02:20 are you sure that's not just a problem with that u-boot? Apr 11 03:04:18 pretty sure, i got the heads-up on this issue from rcn-ee[m] back in 2016 Apr 11 03:04:19 since the stuff at the beginning of an ext4 partition (apart from the first 1KB, which it leaves unused) are definitely critical filesystem structures Apr 11 03:05:06 which is (at least one reason why) the beagleboard.org images were switched to start at 8192 Apr 11 03:06:05 i've been avoiding addressing it until now because the am335x_boneblack target got removed from u-boot 2019.04 on the grounds that the am335x_evm target supports beaglebone black Apr 11 03:06:30 though i'm wondering if it's worth getting that reverted... Apr 11 03:06:44 you mean the default config file? Apr 11 03:06:51 yes Apr 11 03:07:08 i could obviously just revert it for the debian builds, but that would be overhead to maintain over time Apr 11 03:07:13 just use a custom config file? Apr 11 03:07:40 how big was the u-boot.img you installed? Apr 11 03:07:42 if i made a custom config file for every board supported in debian ... Apr 11 03:07:48 that would be rather unsustainable Apr 11 03:08:36 i think the one i installed was 530k ... the am335x_evm build is over 700k Apr 11 03:08:58 the ones that worked without problems were around 400k Apr 11 03:09:08 i *thought* 530k would actually fit Apr 11 03:09:09 530k is not too big Apr 11 03:09:11 it does Apr 11 03:09:55 start sector is 768, so if your root partition starts at 2048, you have 1280 sectors (i.e. 640 KB) of space for u-boot.img Apr 11 03:10:20 so 700k would definitely be too large Apr 11 03:10:27 a better choice of offsets would allow more space Apr 11 03:10:34 indeed Apr 11 03:10:57 the symptoms were identical to what rcn-ee[m] mentioned Apr 11 03:11:07 maybe i actually copied the larger image... Apr 11 03:11:56 CH+MLO can be located at offset 0 (the 1-sector CH is compatible with the partition map) and its size can never exceed 128KB (in fact its max is something like 109 KB iirc), so u-boot.img could begin at sector 256 Apr 11 03:12:32 * vagrantc suspects it gets interesting adding GPT to the mix of possibilities Apr 11 03:12:56 if you consider it to be too hacky to have the partition map and CH occupy the same sector, u-boot.img could at least start at offset 512 instead of 768 Apr 11 03:13:23 so then it's a matter of getting that changed in u-boot upstream Apr 11 03:13:41 and ... getting everyone else to support it Apr 11 03:14:07 "everyone else" ? Apr 11 03:14:44 I mean, yeah you need to be sure to install u-boot.img to the right offset Apr 11 03:15:01 (it actually shouldn't care whether you install CH+MLO at offset 0 or 256) Apr 11 03:15:02 exactly Apr 11 03:15:15 the instructions have been around for ages to install it at 768 Apr 11 03:15:16 MLO could also check multiple offsets Apr 11 03:15:29 yes, checking multiple offsets seems like a good idea Apr 11 03:15:46 ROM tries to find the CH at offsets 0, 256, 512, and 768 Apr 11 03:15:53 (and MLO starts at the next sector) Apr 11 03:16:57 dd conv=fsync,notrunc if=/usr/lib/u-boot/am335x_evm/MLO of=/dev/mmcblkX count=1 seek=1 bs=128k Apr 11 03:17:00 dd conv=fsync,notrunc if=/usr/lib/u-boot/am335x_evm/u-boot.img of=/dev/mmcblkX count=2 seek=1 bs=384k Apr 11 03:17:14 those were the instructions for the last ... 5 years, at least Apr 11 03:17:49 s,am335x_evm,am335x_boneblack,g Apr 11 03:18:45 I'd personally not write it like that, but yeah Apr 11 03:19:31 was the instructions i was given back then, though i'd rather use a consistant offset ... Apr 11 03:19:35 just I'd omit bs and count, and just use seek=256 and seek=768 Apr 11 03:19:41 right Apr 11 03:21:06 it's certainly less obfuscated that way Apr 11 03:22:09 that second dd also makes me nervous since it's asking to transfer two blocks of 384 KB, i.e. 768 KB. fortunately I know dd won't pad the data out to full blocks when the input isn't a multiple of the block size (by default) Apr 11 03:22:21 guess it was 520k and 692k image sizes ... maybe i wrote the larger one Apr 11 03:22:44 i'm pretty sure that would have destroyed your ext4 partition Apr 11 03:22:44 zmatt: right ... i didn't think it would pad the data Apr 11 03:23:04 but i've been using that for years in this setup Apr 11 03:23:33 so i didn't *think* that would have suddenly started padding it Apr 11 03:23:59 it doesn't Apr 11 03:24:08 unless you pass an option to make it do so Apr 11 03:24:17 it just looks weird Apr 11 03:24:27 those dd arguments I mean Apr 11 03:24:34 agreed. Apr 11 03:26:29 i'll change them on the next upload Apr 11 03:28:18 zmatt: thanks for the suggestions Apr 11 03:39:21 so, I just tried to see what happens if you overwrite the first 52KB of an ext4 partition with garbage (which is what would have happened if you wrote a 692KB u-boot.img to offset 768 with your ext4 partition starting at offset 2048) Apr 11 03:39:31 mount doesn't even recognize it as ext4 anymore Apr 11 03:40:07 hmmm. Apr 11 03:40:17 very curious. Apr 11 03:41:26 e2fsck -p also refuses to recover it, but e2fsck -y does recover it... question is in what state Apr 11 03:43:02 it actually looks like it may have fully recovered using the backup superblock Apr 11 03:48:03 so, as long as it's under ~640k it should be fine? Apr 11 03:48:44 i'll have to experiment more ... that's just a minor change to the config that should be maintainable over time. Apr 11 03:48:54 e.g. drop the extraneous .dtb files. Apr 11 03:49:07 for backwards-compatibility... Apr 11 03:49:52 of course using offset 8192 for the root partition is probably a good idea anyway Apr 11 03:50:18 I don't think the change from 2048 to 8192 was done for space reasons... rcn's u-boot.img files have never even gotten close to the limit Apr 11 03:50:24 indeed, but this gives people who have an old install a way to not have to mangle their partition table Apr 11 03:50:46 if they have an old install, they probably don't want to replace their u-boot either Apr 11 03:51:06 i guess i'm a strange bird. Apr 11 03:51:30 i keep my u-boot up to date... Apr 11 03:51:42 i don't frequently reinstall or build a new image Apr 11 03:51:48 that actually does sound like a strange thing to do Apr 11 03:52:17 it seems unlikely it would give any benefit, and at worst it will break your system Apr 11 03:52:26 but i also maintain u-boot in debian, so i kind of have to regularly test it Apr 11 03:52:33 that's fair Apr 11 03:53:15 but you can also just fix the partition layout of your existing system and not have to worry about it anymore Apr 11 03:54:44 i'm not sure debian-installer supports creating partitions at anything other than 2048 out of the box ... so ... Apr 11 03:54:53 anyway, it would also be nice (and probably pretty easy) to make SPL check a few offsets for u-boot.img, that would bump the space available for u-boot.img to 768 or 896 KB without fixing the partition layout Apr 11 03:55:04 that's really not good Apr 11 03:55:25 or at least, whatever the default tools usually create Apr 11 03:55:37 on flash storage you'd kind of prefer to not have the frequently-modified superblock of your filesystem in the same NAND flash block as your bootloader Apr 11 03:55:49 right Apr 11 03:56:05 (and partition table) Apr 11 03:56:47 i'm all for moving to 8192 by default, but also looking at all the things that need to be updated to support it Apr 11 03:56:47 although, to be fair, if that superblock gets hosed then your system probably won't boot anymore anyway Apr 11 03:57:55 it's a bigger concern on some other embedded systems I guess, where recovery might be much harder if you lose u-boot (e.g. if it can't natively boot from sd card) Apr 11 03:58:12 fortunately the bbb is trivial to recover Apr 11 03:59:54 it's very nice when boards support a recovery method Apr 11 04:01:50 we're currently designing a custom board which won't have an sd card slot... it'll be fun :D (though to be fair, I'm kind of happy to finally have an excuse to get netbooting for flashing/recovery working, since that's going to streamline things compared to the current flasher-card based procedure) Apr 11 10:35:21 I am a research student in Computer Science and Engineering. My subject is related with rechargeable sensors and wireless mobile chargers to charge such sensors. It would be of great help for my research, if you can tell that if any such kind of rechargeable sensors and wireless mobile charger to charge them are commercially available. Apr 11 11:00:44 there are wireless charging kits cheaply and easily available eg https://www.ebay.co.uk/itm/Q113130687885 Apr 11 11:01:10 that's just a thin receiver the size of a phone with a micro usb output Apr 11 11:01:56 would be nice if you could get a package of receiver + lipo circuit + lipo but not hard to assemble Apr 11 11:02:03 artag: too late, he left Apr 11 11:02:08 lol Apr 11 11:02:44 he actually waited a full minute for someone answering ;) Apr 11 11:02:53 don't know if that sets a record Apr 11 11:16:01 sadly not. I didn't actually notice it was 30 mins old, I thought my irc client had just flagged this window Apr 11 13:23:00 I am looking for the libraries for the Comm cape as the get hub links are broken. Any suggestions? Apr 11 16:10:32 hrm. Apr 11 16:10:45 sfdisk --move-data fails to mount entirely now Apr 11 16:11:05 er, after "sfdisk --move-data" the partition fails to mount. Apr 11 16:13:12 adventures in partition offsets and u-boot corruption. Apr 11 16:15:30 beaglebone black defaults to loading u-boot off of eMMC, only falling back to microSD if it's not present ... or you press the boot button or something? Apr 11 16:15:37 it's been a while Apr 11 16:19:21 but seems to work after "fsck.ext4 -y" ... Apr 11 19:21:37 Using a BBB for hosting web pages is not easy. At first, if it works, leave it and see what happens. Apr 11 19:21:38 ... Apr 11 19:22:31 The BBB, if not plugged in during a three week phase, may not be accessible any longer, right, which in turn creates the router login page to show. Apr 11 19:22:48 On the web address! Apr 11 19:23:24 I had routed and left things while forgetting. My home router info. was listed online for a month! Ha! Apr 11 19:23:40 No bugs (so far)! Apr 11 19:24:11 servers are not easy. I do not care what people say. Apr 11 19:26:58 systemd...it allows for daemons to be started for particular users, too. That is nice! Apr 11 19:29:26 mike runs this program and paul runs this program instead. Nice! Apr 11 19:33:35 break time from goofing up...I need it. 95% goof and 5% corrections. Apr 11 22:28:33 Port Forwarding! Apr 11 22:28:43 I think I am on to something, now! Apr 11 22:31:58 Servers are in my "future!" Apr 12 02:26:02 I done it right, finally. Apr 12 02:26:11 Servers and html pages galore! **** ENDING LOGGING AT Fri Apr 12 02:59:57 2019