Using setup_sdcard.sh script from prebuilt images resulting in readonly fs

[Paulo Sherring]

Hello all.
I have been searching this for a while and could not find any hints.
I am trying to use the image provided here: https://rcn-ee.net/deb/rootfs/wheezy/debian-7.7-console-armhf-2014-10-29.tar.xz to create a sdcard for beaglebone black. I do not want to transfer the sdcard's content to the embedded memory, i want to use the image from the sdcard it self. I can boot to it, but i keep getting read only fs, so i cannot mount or change at all the fs.
I managed RW to boot it from u-boot by interrupting the countdown and issuing the boot command. This way, I can boot to the sdcard while getting a read-write FS.
I don't understand how the two differs nor how interrupting the countdown changes anything from booting directly.

Any help is appreciated.
Thanks!
Paulo Sherring.

[Robert Nelson]

What parameters are you passing to 'setup_sdcard.sh' ?

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Paulo Sherring]

Hello there!

I am issuing sudo ./setup_sdcard.sh  --mmc /dev/mmcblk0 --uboot bone --dtb beaglebone

Did i get it wrong?
Thanks!

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/ekKtYyMx67I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Mon, Jan 5, 2015 at 7:18 PM, Paulo Sherring <pauloas...@gmail.com> wrote:
> Hello there!
> I am issuing sudo ./setup_sdcard.sh --mmc /dev/mmcblk0 --uboot bone --dtb
> beaglebone

Oh "--dtb xyz" replaced "--boot xyz"... No idea what would happen if
you add them both together..

[Paulo Sherring]

So, what arguments should I issue to achieve a fully functional rw file system? Should I go only with -- boot?
Thanks again!

[Robert Nelson]

On Mon, Jan 5, 2015 at 7:58 PM, Paulo Sherring <pauloas...@gmail.com> wrote:
> So, what arguments should I issue to achieve a fully functional rw file
> system? Should I go only with -- boot?

It should work out of the box with:

sudo ./setup_sdcard.sh --mmc /dev/mmcblk0 --dtb beaglebone

[Paulo Sherring]

I just tried this, no luck. I am on Debian, should it be a problem?

[Paulo Sherring]

Curiously, I am able to copy and paste to the mounted FS on my develpment machine, live on beaglebone, but cant change anything neither over SSH nor over serial terminal.

Any thoughts?

Thanks again!

--

[Robert Nelson]

On Mon, Jan 5, 2015 at 8:56 PM, Paulo Sherring <pauloas...@gmail.com> wrote:
> Curiously, I am able to copy and paste to the mounted FS on my develpment
> machine, live on beaglebone, but cant change anything neither over SSH nor
> over serial terminal.

BTW, which version of Debian... There is issues with Jessie/Sid where
i had to do a few work-a-rounds in the script to make it reliable.

If it is Jessie/Sid, the quick fix, is just meld against this dir:
https://github.com/RobertCNelson/omap-image-builder/tree/master/tools

The setup_sdcard.sh script and hwpack's is pretty forward compatible.

Can you please pastebin.com the terminal log output from
"setup_sdcard.sh" and your serial bootlog from power on.

[Paulo Sherring]

I am on wheezy 7.7, so I suppose no workaround is needed.

Follows pastebin
setup_sdcard.sh output
serial console output
dmesg output

I noticed on dmesg that the kernel boot args includes a ro
" Kernel command line: console=ttyO0,115200n8 root=UUID=497d0971-9902-43ef-ae44-bdc274b6c40c ro rootfstype=ext4 rootwait fixrtc quiet"

I don't know if this is the reason for this unwanted behavior.

Thanks again!
Paulo Sherring.

[Robert Nelson]

On Tue, Jan 6, 2015 at 8:53 AM, Paulo Sherring <pauloas...@gmail.com> wrote:
> I am on wheezy 7.7, so I suppose no workaround is needed.
> Follows pastebin
> setup_sdcard.sh output
> serial console output
> dmesg output

Thanks reviewing right now..

>
> I noticed on dmesg that the kernel boot args includes a ro
> " Kernel command line: console=ttyO0,115200n8
> root=UUID=497d0971-9902-43ef-ae44-bdc274b6c40c ro rootfstype=ext4 rootwait
> fixrtc quiet"
> I don't know if this is the reason for this unwanted behavior.

'ro' is needed for fsck to run on bootup (when needed), the system
will switch to "rw" when it's happy with the rootfs.

[Robert Nelson]

On Tue, Jan 6, 2015 at 8:53 AM, Paulo Sherring <pauloas...@gmail.com> wrote:

> I am on wheezy 7.7, so I suppose no workaround is needed.
> Follows pastebin
> setup_sdcard.sh output
> serial console output
> dmesg output

Well:

[ 107.406982] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p1,
blocknr = 747). There's a risk of filesystem corruption in case of
system crash.
[ 107.935165] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p1,
blocknr = 495). There's a risk of filesystem corruption in case of
system crash.
[ 107.935212] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p1,
blocknr = 1). There's a risk of filesystem corruption in case of
system crash.
[ 107.935271] EXT4-fs error (device mmcblk0p1): __ext4_new_inode:983:
comm sed: failed to insert inode 1613: doubly allocated?
[ 107.971541] Aborting journal on device mmcblk0p1-8.
[ 107.990492] EXT4-fs (mmcblk0p1): Remounting filesystem read-only
[ 108.001162] EXT4-fs error (device mmcblk0p1): ext4_journal_check_start:56:
[ 108.016033] EXT4-fs error (device mmcblk0p1) in ext4_create:2259: IO failure
[ 108.029254] Detected aborted journal
[ 439.446492] SysRq : Emergency Remount R/O
[ 439.454698] Emergency Remount complete

It looks like your microSD card is toast...

[Robert Nelson]

On Tue, Jan 6, 2015 at 9:06 AM, Robert Nelson <robert...@gmail.com> wrote:
> On Tue, Jan 6, 2015 at 8:53 AM, Paulo Sherring <pauloas...@gmail.com> wrote:
>> I am on wheezy 7.7, so I suppose no workaround is needed.
>> Follows pastebin
>> setup_sdcard.sh output
>> serial console output
>> dmesg output
>
> Well:
>
> [ 107.406982] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p1,
> blocknr = 747). There's a risk of filesystem corruption in case of
> system crash.
> [ 107.935165] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p1,
> blocknr = 495). There's a risk of filesystem corruption in case of
> system crash.
> [ 107.935212] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p1,
> blocknr = 1). There's a risk of filesystem corruption in case of
> system crash.
> [ 107.935271] EXT4-fs error (device mmcblk0p1): __ext4_new_inode:983:
> comm sed: failed to insert inode 1613: doubly allocated?
> [ 107.971541] Aborting journal on device mmcblk0p1-8.
> [ 107.990492] EXT4-fs (mmcblk0p1): Remounting filesystem read-only

^^ this is where the system gave up and just mounted your drive as
'ro' to atleast give you access..

[Paulo Sherring]

Well, that is another sdcard, again and again (and again). That is just sad. Is there a tool for me to test an sdcard integrity, since i don't have yet skills to parse linux output?

Thanks!

Paulo Sherring.

[Robert Nelson]

On Tue, Jan 6, 2015 at 9:13 AM, Paulo Sherring <pauloas...@gmail.com> wrote:
> Well, that is another sdcard, again and again (and again). That is just sad.
> Is there a tool for me to test an sdcard integrity, since i don't have yet
> skills to parse linux output?

Humm.. If it's happening with multiple sdcard's, i'd also double check
with a spare usb-microSD adapter..

Or try the dd method:

Grab the *.img from here:

http://elinux.org/BeagleBoardDebian#BeagleBone.2FBeagleBone_Black

and:

unxz bone-debian-7.7-console-armhf-2014-10-29-2gb.img.xz
sudo dd if=./bone-debian-7.7-console-armhf-2014-10-29-2gb.img of=/dev/sdX

where /dev/sdX is your device your flashing...

[Paulo Sherring]

I just tested with two micro sdcards, that are not very used, i bought them a few months ago, and three micro sd readers ( one builtin, 2 usb). All three of them resulted in the same error. Depending on the device used, i was /dev/sdb or /dev/mmcblk0.

dd'ing the image to the card worked just fine but it has the anoying issue that it takes too long to burn the card (about 5 times longer, maybe?).

Thanks!

[evilwulfie]

What brand.
What class.
Have you tried to format and test them on another system ?

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Paulo Sherring]

One is from adata, another from Kingston and other from multilaser, a Brazilian brand,  likely a generic one rebranded. All class 4.
Just tried on an Ubuntu 14.04 machine,  same results: dd'ing did fine, setup_sdcard.sh.
Thanks!
Paulo Sherri

[Robert Nelson]

On Tue, Jan 6, 2015 at 1:49 PM, Paulo Sherring <pauloas...@gmail.com> wrote:
> One is from adata, another from Kingston and other from multilaser, a
> Brazilian brand, likely a generic one rebranded. All class 4.
> Just tried on an Ubuntu 14.04 machine, same results: dd'ing did fine,
> setup_sdcard.sh.

I don't remember all the changes i've made to setup_sdcard.sh.. but
here's a very fresh image:

https://rcn-ee.net/rootfs/2015-01-06/debian-7.7-console-armhf-2015-01-06.tar.xz

Wondering if it will randomly fix it..

[Paulo Sherring]

The new image worked! Thank you both for the great help!
Paulo Sherring.

[Paulo Sherring]

I have one more request, if you will... The older - and buggy (at least for me) - image used USB to present the dev pc with its file system and I no longer get this with the new image. How can i get it back?
 Thanks!

Paulo Sherring.


Em terça-feira, 6 de janeiro de 2015 16h52min13s UTC-3, RobertCNelson escreveu:

[Robert Nelson]

On Tue, Jan 6, 2015 at 3:17 PM, Paulo Sherring <pauloas...@gmail.com> wrote:
> I have one more request, if you will... The older - and buggy (at least for
> me) - image used USB to present the dev pc with its file system and I no
> longer get this with the new image. How can i get it back?

So there was a big issues.. Turns out presenting your whole file
system over usb as a flash device was a no-no-no. ;) (it was useful,
but the kernel doesn't like that at all..)

But if you, add the "--beagleboard.org-production" flag to
setup_sdcard.sh it'll carve out a 100Mb partition which it'll share a
usb flash drive.

[Paulo Sherring]

I was going to mess with kernel, that was why I wanted that :(
BTW, i tried the ubuntu console image and it also presented the same issue.
But thank you! Again!

Paulo Sherring.

[Robert Nelson]

On Tue, Jan 6, 2015 at 4:20 PM, Paulo Sherring <pauloas...@gmail.com> wrote:
> I was going to mess with kernel, that was why I wanted that :(
> BTW, i tried the ubuntu console image and it also presented the same issue.
> But thank you! Again!

You can add it back:

It's in this if statement:

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L83

on your board, that file is located: /opt/scripts/boot/am335x_evm.sh

[Paulo Sherring]

Sorry for possible noob, silly question: So should I change the script and copy it to, say, /etc/init.d/am335x_evm.sh, crate a symbolic link in /etc/rcS.d and run update-rc.d script defaults ? Or is there another way to do it?

Thanks!

[Robert Nelson]

On Tue, Jan 6, 2015 at 9:13 PM, Paulo Sherring <pauloas...@gmail.com> wrote:
> Sorry for possible noob, silly question: So should I change the script and
> copy it to, say, /etc/init.d/am335x_evm.sh, crate a symbolic link in
> /etc/rcS.d and run update-rc.d script defaults ? Or is there another way to
> do it?

That script is already called by default on bootup.

[Paulo Sherring]

One last question for this matter: when is this script triggered and where is it instantiated?

[Robert Nelson]

On Wed, Jan 7, 2015 at 2:26 PM, Paulo Sherring <pauloas...@gmail.com> wrote:
> One last question for this matter: when is this script triggered and where
> is it instantiated?

/etc/init.d/generic-boot-script.sh

https://github.com/RobertCNelson/omap-image-builder/blob/master/target/init_scripts/generic-debian.sh

[Paulo Sherring]

If it is worth noting, i had to comment out the g_serial (line #86) and uncomment the g_ether (line #88) for getting the desired behavior of showing up as ethernet over USB,which I think is the most common behavior.
As for mount the whole file system as storage unit, turns out the it got all buggy, complaining about dirty metadata, so I gave it up.
I owe you a coffee! Big time!
Thanks!
Paulo Sherring.

[William Hermans]

If it is worth noting, i had to comment out the g_serial (line #86) and uncomment the g_ether (line #88) for getting the desired behavior of showing up as ethernet over USB,which I think is the most common behavior.

Only one gadget driver can be loaded at a time. This is why g_multi exists. As it offers all 3 ( g_serial, g_ether, and g_mass_storage ) all in one driver. However, I've yet to determine where to point the g_mass_storage portion of the driver to, when in fact all you want is just g_ether *and* g_serial *only*.

I would assume something like /dev/null, but i never really cared enough about to to test it. I just change /etc/modules to reflect what I want loaded at boot, for whatever sittuation.

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Paulo Sherring]

When using the newly supplied image, I could not get cape manager (i mean, I am not getting the /sys/devices/bone_capemgr.*/ directory. Do I have to do something before I get it?

Thanks!

Paulo Sherring.

( PS: Should I open a new thread for this question?)

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/ekKtYyMx67I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Robert Nelson]

On Mon, Jan 19, 2015 at 4:41 PM, Paulo Sherring
<pauloas...@gmail.com> wrote:
> When using the newly supplied image, I could not get cape manager (i mean, I
> am not getting the /sys/devices/bone_capemgr.*/ directory. Do I have to do
> something before I get it?
>
> Thanks!
> Paulo Sherring.
>
> ( PS: Should I open a new thread for this question?)

I would... and when you do.. actually make your question more
descriptive, by including the version of the image used, etc..

[Paulo Sherring]

Just found this: https://www.marshut.net/ivvyiz/bone-capemgr-9-disappeared.html

Is this still the case?

Paulo Sherring.

[Robert Nelson]

On Mon, Jan 19, 2015 at 4:45 PM, Paulo Sherring
<pauloas...@gmail.com> wrote:
> Just found this:
> https://www.marshut.net/ivvyiz/bone-capemgr-9-disappeared.html
> Is this still the case?

No the case is...

Your using an image that i'm trying to get people off the ancient v3.8.x kernel.

But you still need it, so downgrade:

sudo apt-get update
sudo apt-get install linux-image-3.8.13-bone69
sudo reboot

[Rick Mann]

Capemgr is gone. I don't know if it will be coming back. You now have to enable things by building your own device tree, and I've barely figured out how to make that work. RCN has dtb-rebuilder available for some versions of the kernel. You'll have to use that to make your own version of a complete .dtb (it's a bit easier than it sounds, but not easy). That should cause the individual sysfs nodes you need to appear.

Rick Mann
rm...@latencyzero.com

[Paulo Sherring]

Rick and Robert, I have found nowhere but the email archive I attached before any information on this. High hitting pages on topic, such as Derek Molloy's and Hipster Circuit's are all outdated, with no reference to this, sadly. I will try to contact them and suggest that they put on a notice on their pages.

I am on this dtb-builder right now, and, honestly, it makes so more sense than capemgr. I know that capemgr has the advantage of being able to unload and load DTB's on runtime, but I guess it has very little application. At least i guess so.

But, thanks again for sharing!

Paulo Sherring.

[Robert Nelson]

On Tue, Jan 20, 2015 at 12:44 PM, Paulo Sherring
<pauloas...@gmail.com> wrote:
> Rick and Robert, I have found nowhere but the email archive I attached
> before any information on this. High hitting pages on topic, such as Derek
> Molloy's and Hipster Circuit's are all outdated, with no reference to this,
> sadly. I will try to contact them and suggest that they put on a notice on
> their pages.
> I am on this dtb-builder right now, and, honestly, it makes so more sense
> than capemgr. I know that capemgr has the advantage of being able to unload
> and load DTB's on runtime, but I guess it has very little application. At
> least i guess so.

This should help explain it:

v3.8.x (bb.org): overlay/capemgr
mainline: v3.9.x -> v3.19.x: dtb-builder like hacks:
mainline: v3.19.x: overlay

We still support v3.8.x (bb.org) and have it available in the tree,
however for non-overlay-capemgr reasons I have v3.14.x the default
kernel on my Debian/Ubuntu elinux image.

[Paulo Sherring]

There are a lot of people still depending on overlays, maybe that should pose an issue on moving on. It seems to me that it is a simple matter of getting the outdated tutorials on using capemgr and finding out ways to replace its usage. It seems so for the main tutorials providers i have found lately, they all depend on capemgr.
I could not find a single source on how to change pinmux without capemgr, i.e., doing so directly on main dts. Could you give me any pointers?

I have tried mapping memory directly with mmap, but i couldn't, probably because the kernel is locking the memory for pinmux driver.

I have just downgraded so I could get the work done, but, since I will be using the plataform for a while, I most certain need to it the right way.
Thanks!
Paulo Sherring.

--
For more options, visit http://beagleboard.org/discuss
---

[Robert Nelson]

On Wed, Jan 21, 2015 at 3:30 PM, Paulo Sherring
<pauloas...@gmail.com> wrote:
> There are a lot of people still depending on overlays, maybe that should
> pose an issue on moving on. It seems to me that it is a simple matter of
> getting the outdated tutorials on using capemgr and finding out ways to
> replace its usage. It seems so for the main tutorials providers i have found
> lately, they all depend on capemgr.
> I could not find a single source on how to change pinmux without capemgr,
> i.e., doing so directly on main dts. Could you give me any pointers?
> I have tried mapping memory directly with mmap, but i couldn't, probably
> because the kernel is locking the memory for pinmux driver.
> I have just downgraded so I could get the work done, but, since I will be
> using the plataform for a while, I most certain need to it the right way.
> Thanks!

https://github.com/cdsteinkuehler/beaglebone-universal-io

[Paulo Sherring]

I have found this before, it is based on overlays, as well as every other sources i have found.

Any other thoughts?

Thanks!

Paulo Sherring.

[Robert Nelson]

On Wed, Jan 21, 2015 at 3:47 PM, Paulo Sherring
<pauloas...@gmail.com> wrote:
> I have found this before, it is based on overlays, as well as every other
> sources i have found.
> Any other thoughts?

The "overlay" is built into the v3.14.x ti kernel..

Just use config-pin to modify the pinmux.. *

*not all (100%) pins/pinmuxs are enabled..

[Paulo Sherring]

I just got it working in 3.8.x.
But as for 3.14.x-ti:
In its README.md, it states

"echo cape-universaln > /sys/devices/bone_capemgr.*/slots"

Since I don't have /sys/devices/bone_capemgr.*/slots at all in 3.14.x, what should I do?

[Robert Nelson]

On Wed, Jan 21, 2015 at 3:55 PM, Paulo Sherring
<pauloas...@gmail.com> wrote:
> I just got it working in 3.8.x.
> But as for 3.14.x-ti:
> In its README.md, it states
>
> "echo cape-universaln > /sys/devices/bone_capemgr.*/slots"
>
> Since I don't have /sys/devices/bone_capemgr.*/slots at all in 3.14.x, what
> should I do?

Yes, i know what the README.md says..

To repeat: "The "overlay" is built into the v3.14.x ti kernel.."..

config-pin works out of the box with v3.14.x

[Paulo Sherring]

Ok, will try! Thanks!