rootfs mounts read only

[Michael Mitchell]

this is the first time i have been using the CI20, and i managed to flash the debian7 beta image to NAND by following the instructions. 

however, the rootfs filesystem is mounting read only. this makes it difficult to customize the linux distribution. i am unfamiliar with performing triage on ubifs, so i am at a loss as to what things to check. attached is the list of the mounted devices 

ci20@ci20:~$ mount

ubi0:root on / type ubifs (ro,relatime)

tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=102100k,mode=755)

tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

tmpfs on /dev type tmpfs (rw,relatime,size=10240k,mode=755)

tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=204180k)

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

ubi0:boot on /boot type ubifs (rw,relatime)

rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)

ci20@ci20:~$

im not sure how to get the root filesystem mounting as read-write. any assistance or pointers would be very helpful. thank you.

[Maarten ter Huurne]

On Friday 06 February 2015 09:21:17 Michael Mitchell wrote:

> however, the rootfs filesystem is mounting read only. this makes it
> difficult to customize the linux distribution. i am unfamiliar with
> performing triage on ubifs, so i am at a loss as to what things to check.
> attached is the list of the mounted devices

If there are any errors detected on the rootfs, it will be mounted read-only
to avoid data loss. So that is a possible cause. You can read the kernel log
with "dmesg"; look for "ubi" or "mtd" (raw flash memory device).

Bye,
Maarten

[Michael Mitchell]

Quite a few of these show up in dmesg output: How does one perform equivilent 'fsck' operation

on UBFS?

[   41.874269] cljiang------bt_power_control,enable = 1

[   48.851704] UBIFS error (pid 1934): ubifs_read_node: bad node type (0 but exp

ected 9)

[   48.860352] UBIFS error (pid 1934): ubifs_read_node: bad node at LEB 385:1843

2, LEB mapping status 1

[   48.870286] UBIFS error (pid 1934): ubifs_iget: failed to read inode 20486, e

rror -22

[   48.879057] UBIFS error (pid 1934): ubifs_lookup: dead directory entry 'X11',

 error -22

[   48.887800] UBIFS warning (pid 1934): ubifs_ro_mode: switched to read-only mo

de, error -22

[   48.901957] UBIFS error (pid 1934): ubifs_read_node: bad node type (0 but exp

ected 9)

[   48.910604] UBIFS error (pid 1934): ubifs_read_node: bad node at LEB 385:1843

2, LEB mapping status 1

[   48.920515] UBIFS error (pid 1934): ubifs_iget: failed to read inode 20486, e

rror -22

[   48.929255] UBIFS error (pid 1934): ubifs_lookup: dead directory entry 'X11',

 error -22

[Maarten ter Huurne]

On Friday 06 February 2015 09:39:53 Michael Mitchell wrote:
> Quite a few of these show up in dmesg output: How does one perform
> equivilent 'fsck' operation
> on UBFS?

I don't have experience with that, but as far as I know the generic "fsck"
executable will call the file system specific one.

Bye,
Maarten

[Michael Mitchell]

ubifs has no fsck : as designed. 

http://lists.infradead.org/pipermail/linux-mtd/2010-February/029017.html

the issue occurs as part of the NAND reflashing to debian7-beta. is this a known issue?

[Delbert Franz]

I have tried twice, using different SD cards, to flash the Debian 7 beta image and both times 

I failed to boot with probably hundreds of errors reported about not being able to 

get something to write or some I/o error on the NAND.  I gave up after two tries.

The md5sums checked OK.  I conclude there is something not right with the 

image:-(

[Zubair Lutfullah Kakakhel]

Hi Michael and Delbert,

Welcome to the forum.

On 06/02/15 17:21, Michael Mitchell wrote:
> this is the first time i have been using the CI20, and i managed to flash the debian7 beta image to NAND by following the instructions.

The Beta images can be very beta.

Could you please flash the more stable image

http://elinux.org/CI20_Distros#Debian_7_2015-01-15

And then we'll try and proceed forward.

Thanks,
ZubairLK

>
> however, the rootfs filesystem is mounting read only. this makes it difficult to customize the linux distribution. i am unfamiliar with performing triage on ubifs, so i am at a loss as to what things to check. attached is the list of the mounted devices
>
> ci20@ci20:~$ mount
> ubi0:root on / type ubifs (ro,relatime)
> tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=102100k,mode=755)
> tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
> tmpfs on /dev type tmpfs (rw,relatime,size=10240k,mode=755)
> tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=204180k)
> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> ubi0:boot on /boot type ubifs (rw,relatime)
> rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
> ci20@ci20:~$
>
> im not sure how to get the root filesystem mounting as read-write. any assistance or pointers would be very helpful. thank you.
>

> --
> You received this message because you are subscribed to the Google Groups "MIPS Creator CI20" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mips-creator-c...@googlegroups.com <mailto:mips-creator-c...@googlegroups.com>.
> To post to this group, send email to mips-cre...@googlegroups.com <mailto:mips-cre...@googlegroups.com>.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/mips-creator-ci20/fc1602ba-0583-4823-b000-c3d119e9de90%40googlegroups.com <https://groups.google.com/d/msgid/mips-creator-ci20/fc1602ba-0583-4823-b000-c3d119e9de90%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Delbert Franz]

Thanks for the suggestion.

I just completed the process. This is on the Revision B board.

1. Boot up went fine

2. The "aptitude dist-upgrade" completed

3. I then did "aptitude install git vim htop gkrellm gpsd gpsd-clients" and
that completed as well.

4. I then cloned the u-boot repository. And compiled and created
the two files: spl/u-boot-spl.bin and u-boot.img. This was
looking good.

5. I then started cloning the kernel sources and that is when I
got a lockup again. It was receiving objects and got to the 2%
level.

Again, it appears to me that software is not the problem here and
that something common to all of the software I have tried is the
source.

I have downloaded the toolchain to one of my old 32-bit machines
and will now try to create a bootable SD card to get away from
the NAND completely! I'll also look for a bootable SD card
image on the Creator site. I prefer to boot from an SD card
in any case because it gives me much greater flexibility.
I just don't trust "builtin NAND" on any machine.

Delbert

[Delbert Franz]

Hi,

After some effort I got everything compiled and in order to create a bootable SD

card for Debian 7.  I used the 3.0.8 kernel and I set the -EL flag for the 

compiler and the linker loader.  I skipped the recompile of the graphics driver

and went with the frame buffer device.  No need for fancy graphics until 

we get a stable system. I used the rootfs from the 1-15-2015 version,

the one recommended for reflashing the NAND.  

I was amazed when it booted and looked OK.  So I updated.the software.

It was partway done when the desktop again locked up and the 

only way out was to cut power to the board.  

I then purged the package "consolekit" and it took lightdm out

with it.  I was then able to boot into the console.  This takes

Xorg and related items out of the picture.  However, it failed

during a simple install of three packages.  Again a lockup,

with the console still showing everything but nothing was 

responding.  

Summary:

1. Every version flashed to the NAND has locked up.  Sometimes it happens

quickly but in some cases I can do quite a bit of work before it happens.

2. Booting from an SD card shows the same behavior.  

Tentative conclusions:

1. It is not the NAND, based on these tests. 

2. It fails when running from the console only

Not at all sure what to do next but the board remains unstable and 

as a result unusable:-(

                               Delbert

 

On Friday, February 6, 2015 at 9:21:17 AM UTC-8, Michael Mitchell wrote:

[Zubair Lutfullah Kakakhel]

Hi Delbert,

Nice work with setting up a bootable SD card with the stable Debian.

This eliminates the NAND issue.

Could you please share details on how you are powering the board?

And just to further check memory, could you please run the following

apt-get install memtester
memtest 512

And see if it gives errors or locks up.

We have an IRC channel #ci20 if you wish to chat.
There are two others facing similar lockups.

And don't worry.
If we can't trace down the issue to a possible software bug, we'll move towards requesting RMA.

Thanks,
ZubairLK

>
> Delbert
>
>
>
> On Friday, February 6, 2015 at 9:21:17 AM UTC-8, Michael Mitchell wrote:
>
> this is the first time i have been using the CI20, and i managed to flash the debian7 beta image to NAND by following the instructions.
>
> however, the rootfs filesystem is mounting read only. this makes it difficult to customize the linux distribution. i am unfamiliar with performing triage on ubifs, so i am at a loss as to what things to check. attached is the list of the mounted devices
>
> ci20@ci20:~$ mount
> ubi0:root on / type ubifs (ro,relatime)
> tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=102100k,mode=755)
> tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
> tmpfs on /dev type tmpfs (rw,relatime,size=10240k,mode=755)
> tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=204180k)
> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> ubi0:boot on /boot type ubifs (rw,relatime)
> rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
> ci20@ci20:~$
>
> im not sure how to get the root filesystem mounting as read-write. any assistance or pointers would be very helpful. thank you.
>

> --
> You received this message because you are subscribed to the Google Groups "MIPS Creator CI20" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mips-creator-c...@googlegroups.com <mailto:mips-creator-c...@googlegroups.com>.
> To post to this group, send email to mips-cre...@googlegroups.com <mailto:mips-cre...@googlegroups.com>.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/mips-creator-ci20/3f75fcb8-0311-4525-b22d-73f67b97dc98%40googlegroups.com <https://groups.google.com/d/msgid/mips-creator-ci20/3f75fcb8-0311-4525-b22d-73f67b97dc98%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Delbert Franz]

On Tue, 10 Feb 2015 14:17:41 +0000

Zubair Lutfullah Kakakhel <Zubair....@imgtec.com> wrote:

deleted some lines

Hi, ZubairLK,

The power I had been using was a dual port USB power supply
that had a running Raspberry Pi plugged into it. I recalled
that this supply was 2 amps, however, I cannot verify it because
the RPi is working as a server and I am loathe to break
continuity:-) So I plugged the CI20 into a powered USB hub,
with the CI20 being the only device drawing power. The
wall wart powering the hub is rated at 2.5 amps minimum,
so I should not have a power problem.

With the new power supply, I reflashed the NAND to the version
you recommended. I then installed memtester without doing
anything else. The first run locked up without any errors
being reported. So I rebooted and tried again. For every
detected error, I took a picture of the screen. Images
4828 through 4831 show the same error and some progress
after the error before lockup.

Images 4832 and 4834 show another error which was soon
followed by system lockup. There were several lockups
prior to any error but the last image, 4834, shows the most
progress before system lockup.

I hope the images make it through to you. I have reduced their
size by about a factor of 10, so hopefully they will make it.
If not, let me know, and I can send them directly to your
E-mail.

In summary, two errors were found during the memtester runs.
Several runs reached system lockup prior to reporting any
error.

My SD card is so corrupted by the various lockups that it
does not boot reliably anymore. I don't think that testing
RAM would differ much however. I can redo the SD card and
give that try, but I suspect that system lockup will
continue to thwart our efforts at testing the memory.

Delbert

[Zubair Kakakhel]

Hi Delbert,

Thanks a lot.

Some of those memory failures will explain the unexpected lockups.

Looks like you have a bad board. Don't worry.

Please check out http://www.elinux.org/CI20_Troubleshooting#Definitely_an_RMA_after_community_troubleshooting for the RMA request.
Email them and link this post.

Kind Regards,
ZubairLK
________________________________________
From: mips-cre...@googlegroups.com [mips-cre...@googlegroups.com] on behalf of Delbert Franz [d...@sonic.net]
Sent: 10 February 2015 19:02
To: Zubair Kakakhel
Cc: mips-cre...@googlegroups.com
Subject: Re: rootfs mounts read only

--
You received this message because you are subscribed to the Google Groups "MIPS Creator CI20" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mips-creator-c...@googlegroups.com.
To post to this group, send an email to mips-cre...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mips-creator-ci20/20150210110233.08c2f4b4%40i7.