Howdy!
I just pushed out another round of images for testing.
There's really only "one" big change with this image, the sorta change
that will re-write every wiki document.
NO VFAT PARTITION REQUIRED!!!
Let me repeat that... THE VFAT "boot" PARTITION IS NOT REQUIRED! 
Okay, only the "console" images fully feature this, as the lxde's
still export /dev/mmcblk0p1 as vfat for windows users..
The magic is this:
dd if=MLO of=/dev/sdX count=1 seek=1 conv=notrunc bs=128k
dd if=u-boot.img of=/dev/sdX count=2 seek=1 conv=notrunc bs=384k
So far i've only got it to reliabley work on omap4+ bootroms (which
include the am335x).. so beagle/beagle-xm, not yet...
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-09-03
3.8 -> 3.14 transition:
http://elinux.org/Beagleboard:Capes_3.8_to_3.14
Regards,
Okay, only the āconsoleā images fully feature this, as the lxdeās
still export /dev/mmcblk0p1 as vfat for windows usersā¦ 
How about . . .
file=/path/to/ntfs-partition
???
Could be a fat partition that has nothing but the beaglebone support files on it ect ( for windows ), but was curious about NTFS file system support. Was actually thinking about this the other day . . .
Maybe.. we have ntfs support enabled in the kernel..
But really this 'fat' partition was 'fat' as we needed it to boot.
Thus we also used it as pass thru to windows, so if you were to
inserted the microSD card you'd see the fat partition..
It might work as ntfs...
Regards,
Robert, well I was just thinking of some simple way for the Windows users who need it to still get their files off a shipped BBB.
One curious thing that Iāve been looking into a little at a time was that Windows now has a fully featured NFS client built in for enterprise versions. But ive been juggling many pet projects in my spare time lately so . . .
Iāve actually been fighting an Ubuntu 14.04 install the last couple days. Iām sure Ubuntu works fine out of the box, but as soon as you try to start doing anything other than what Canonical wants you to do . . . there is a bunch of kicking, scratching, and biting going on.
So, Iāve opted out of Ubuntu, for Lubuntu, or perhaps Xubuntu.
You need to be really good about wiping out the FAT partition before you
do this or you'll run into problems of the ROM finding things that
aren't there anymore. Doing a dd if=/dev/zero of=/dev/sdXp1 before
re-doing the partition table is a good idea.
dd if=MLO of=/dev/sdX count=1 seek=1 conv=notrunc bs=128k
dd if=u-boot.img of=/dev/sdX count=2 seek=1 conv=notrunc bs=384k
So far i've only got it to reliabley work on omap4+ bootroms (which
include the am335x).. so beagle/beagle-xm, not yet...
You need to be really good about wiping out the FAT partition before you
do this or you'll run into problems of the ROM finding things that
aren't there anymore. Doing a dd if=/dev/zero of=/dev/sdXp1 before
re-doing the partition table is a good idea.
Yeah, we do both a zero out and read back flush for good measures...
dd if=/dev/zero of=${media} bs=1M count=100 || drive_error_ro
sync
dd if=${media} of=/dev/null bs=1M count=100
sync
mkfs.ext4 in debian jessie started getting picky, so we had to zero
out past the end of the first partition, otherwise it still saw the
old partition and warned us. (therefor we couldn't no longer script
that..)
Regards,
Tom, by the way.. When we 'update' a dd'ed bootloader, how many
sectors should be blank with /dev/zero to be on the safe side. (this
is for situations where i don't wan to blow out mbr, but just want to
update the mlo/u-boot.img)
Regards,
Just updating an existing one? This isn't NAND/NOR so you're fine just
overwriting things in place. You can even store a back-up MLO at 0x200
offset (ROM checks 0x0, 0x100 0x200 and 0x300 and we cut the last
location off the list and put U-Boot there).
MBR/GPT's MBR emu is at the first sectors of the card. So are you using relocateable MBR/GPT? Or how are you handling that issue?
Would it be wise to also support backup boot loader in case first one gets corrupt? -- if I recon correctly the bootrom should also support that.
This is good.
I really like that when I plug it into my desktop usb port I now have the whole root file system mounting and available for overview from my desktop. So with only a usb connection I can ssh into 192.168.7.2 where I do most of my work but I can still mouse around the file system with a gui overview without the overhead of a desktop running on the BBB.
Note:
I started with this image :
http://rcn-ee.net/deb/testing/2014-09-04/console/bone-debian-7.6-console-armhf-2014-09-04-2gb.img.xz
which has just one ext4 partition. No fat. No cholesterol.
(console images are anorexic to began with, so I had to force feed it a mass of debs to build up its strength.)
I donāt know what happens to your gadget functionality if you convert from an existing system
Thank you Robert.
Howdy!
I just pushed out another round of images for testing.
There's really only "one" big change with this image, the sorta change
that will re-write every wiki document.
NO VFAT PARTITION REQUIRED!!!
Let me repeat that... THE VFAT "boot" PARTITION IS NOT REQUIRED!
So far i've only got it to reliabley work on omap4+ bootroms (which
include the am335x).. so beagle/beagle-xm, not yet...
MBR/GPT's MBR emu is at the first sectors of the card. So are you using
relocateable MBR/GPT? Or how are you handling that issue?
Traditionally it's been a msdos partition setup... Either way, the
first file MLO gets stored at 128k
Would it be wise to also support backup boot loader in case first one gets
corrupt? -- if I recon correctly the bootrom should also support that.
We never had a backup boot loader previously.. It was just stored in
the "fat" partition as a file and was also shared over usb as a
"gadget usb flash drive".
So, we are offering more protection, as windows user's can't randomly delete it.
Regards,
So, we are offering more protection, as windows userās canāt randomly delete it.
That should read āclueless usersā, since Iām a windows user myself and have never had that problem 
So, we are offering more protection, as windows userās canāt randomly delete it.
That should read āclueless usersā, since Iām a windows user myself and have never had that problem
All windows users are clueless
##enable BBB: eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v2.sh
I suppose this will need to be changed. The tools needed ( now just ātoolā as in singular ), and the actual script file.
I wonder how many people out there realize how powerful this is in combination with TFTP / NFS . . .
##enable BBB: eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v2.sh
I suppose this will need to be changed. The tools needed ( now just ātoolā as in singular ), and the actual script file.
I wonder how many people out there realize how powerful this is in combination with TFTP / NFS . . .
Oh, so this is why you were to pissed at me. It was a joke. You set it up and I couldnāt resist
Iām not purposefully mean or demeaning so please donāt take this the wrong way. It was just meant as a little light hearted humor.
Regards,
John
Not even close, but do feel free to think whatever you like.
I am sorry as what I am posting is not entirely related to this thread but is a feature request for debian.
I liked the console image as it saves a lot of disc image by removing all the GUI softwares. I am running my BBB headless mostly controlling it using ssh and by bone portal. For console image, I guess addition of the bone 101 portal will be good as it is used over the network and is not related to lxde.
Could you please add the node.js, bone 101 and cloud9 back to the console image?
You can add 'node.js' via:
sudo apt-get install nodejs nodejs-legacy npm
bone101/cloud9: follow this bash function:
https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org.sh#L227
note, i still haven't fixed everything for the jekyll transition..
Regards,