debian 2015-12-07 (fat partition final removal)

GoogleGroups
1

So with today's upload:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-12-07

We have something new, inspirated by Stephan Klatt (1), we no longer
ship a fat partition for "any" iamges...

The fat/documentation/drivers partition is now an apt-get package:
doc-beaglebone-getting-started

Which get's uncompressed and symlinked to:

/var/local/usb_mass_storage.img

This gives us another (96Mb - 40Mb = 56Mb) of extra space on the final sdcard's.

If your building a custom documentation image, look at the script in
the "beaglebone-getting-started" (2)

~/beaglebone-getting-started$ sudo ./scripts/generate_img.sh

beaglebone-getting-started-2015-12-04.img.xz

1: https://github.com/RobertCNelson/boot-scripts/commit/fc39a484648c58e02a4b65063c6ae7901e58aac1
2: https://github.com/beagleboard/beaglebone-getting-started/blob/master/scripts/generate_img.sh

and finally a couple questions for the commuinty..

#1: should we mark this as "ro"/"cdrom", as right now it's loaded via:

modprobe g_multi file=${usb_image_file} cdrom=0 ro=0 stall=0
removable=1 nofua=1 ${g_network} || true

and yes, you can add/remove files from the image from your
linux/windows/mac system.

For new users, they might get confused on how to access their copied
"file", so if we mark that as 'ro' they won't be able to do that..

Thoughts?

#2: Possible Upgrade problems, from the log it followed the symlink,
so this might not be an issue..

debian@beaglebone:~$ journalctl | grep img
Dec 08 19:52:28 beaglebone kernel: LUN: removable file:
/var/cache/doc-beaglebone-getting-started/beaglebone-getting-started-2015-12-04.img

in the package i'm doing,

ln -sf /var/cache/${package}/beaglebone-getting-started-${core_version}.img
/var/local/usb_mass_storage.img

So the symlink should point to the 'updated' *.img, should we "keep"
the old file, till a reboot.. I'd like to not rmmod g_multi as the
user might be logged in via serial/g_ether and bam, there's goes the
connection..

Thoughts?

Regards,

2

#2: Possible Upgrade problems, from the log it followed the symlink,
so this might not be an issue..

debian@beaglebone:~$ journalctl | grep img
Dec 08 19:52:28 beaglebone kernel: LUN: removable file:
/var/cache/doc-beaglebone-getting-started/beaglebone-getting-started-2015-12-04.img

in the package i'm doing,

ln -sf /var/cache/${package}/beaglebone-getting-started-${core_version}.img
/var/local/usb_mass_storage.img

So the symlink should point to the 'updated' *.img, should we "keep"
the old file, till a reboot.. I'd like to not rmmod g_multi as the
user might be logged in via serial/g_ether and bam, there's goes the
connection..

Ahh, on 2, i can follow:

cat /sys/module/usb_f_mass_storage/holders/g_multi/parameters/file

and figure out what's going on, so while the "img" won't be updated
till you actually reboot there shouldn't be any other problems..

Regards,

3

This mounted partition is a loopback image file ? Why would it matter if that was r/w ?

4

So anyway, if its not a loopback image file, that is one option, another options would be to use a tmpfs directory(128M, or whatever ). Or am I missing the question entirely ?

5

Yeap, it's a raw *.img file..

The question a new user might have:

I've copied a file to the "flash drive" on windows, but i can't seem
to access it on the beagle..

and then explain how to rmmod g_multi, mount *.img as a loop back, etc
on the beagle... .:wink:

Now if we set it ro/cdrom, they couldn't get stuck like ^..

Regards,

6

I don’t understand what you’re getting at. Are you proposing the cure is to make the “drive” inaccessible ?

7

Just "ro"... So it'll just provide the documentation, and that's it.

But right now, you do what ever you want to the "40MB" flash drive..

Regards,

8

Well, I don’t know. Personally, I do not see much point in having the 40M flash drive at all, if it’s not writable. But me . . . I use multiple Linux machines, sshfs Samba NFS, blah blah blah, and do not worry about all that. Despite my desktop being Windows.

So for documentation only, you have Nodejs, and a “web server” serving up docs already.

Also, this flash drive would have to be fat, fat32, or ntfs in order to be readable on windows. The first two types have no concept of permissions. . . and . . . yeah, I do not know. Do you think this is a good idea ? I don’t, but I kind of look at things differently than the typical Linux / Windows newb.

9

Because, well, I’m not a newb with either :slight_smile:

10

So anyway, RAW image file mounted to the filesystem via a mountpoint, then that mountpoint shared out over g_multi ? That doesnt work ?

11

Correct it is fat...

So some background, in the big "default" 2GB/4GB desktop image's we've
always had a "96MB fat" partition, that contained this repo:

https://github.com/beagleboard/beaglebone-getting-started

Which contain:

windows drivers
mac drivers
schematic
etc..

So by moving it to an *.img, we save space and we can upgrade it... So
when windows 10.xyz comes out, new drivers can be "apt-get update ;
apt-get upgrade" away..

Regards,

12

I thought about that, it would mirror what we did previously:

/dev/mmcblk0p1 -> usb flash
/dev/mmcblk0p1 and mounted at /boot/uboot/

Jason ran into issues with that and told us to stop

/var/local/usb_mass_storage.img -> usb flash
/var/local/usb_mass_storage.img -> mounted somewhere...

Regards,

13

So by moving it to an *.img, we save space and we can upgrade it… So
when windows 10.xyz comes out, new drivers can be "apt-get update ;
apt-get upgrade" away…

OK, that sounds fairly ingenious, assuming MS updates doesnt bork g_multi before it can be upgraded :wink:

14

Define “issues”, perhaps I can test / offer a solution.

15

I of course assume, we get the driver out, before the mass's upgrade. :wink:

and then hopefully they run apt and upgrade their bone..

so for the 1 out of 10K users it'll work perfect..

Regards,

16

Jason will have to chime in, as he dealt with the users at a workshop..

17

Another option: Have a dynamic link to the latest drivers, or, just overwrite the old ones( later is probably not so good of an idea, but is possible ).

18

erm, That is to say. Nodejs can be made to be pretty smart. To the point if you drop a file into a folder, it can dynamically offer up a link to that file.