Thanks - I will try the environment variable changes less booting to USB by
default until I actually see it work.  I see that you changed the wiki.

I have successfully remounted it in the past  - the problem is that a number
of the init.d scripts, including if-up and ntpd fail due to not being able
to write to disk.  So it's not really a usable system until you go back and
basically enter runlevel 5 manually.  This is true when using the latest
stock etch distribution with 0 modifications.  I think the default behavior
of USB booting ought to be re-examined in that context.

USB drives with write protect switches are reasonably common and could
provide the same functionality.

Thanks to all the list for the help.

Tom

On Thu, Jan 14, 2010 at 9:28 PM, Jason Manley <[email protected]>wrote:

> I think the key error is that you weren't escaping your new commands.
>
> But I suggest you start from scratch. Erase any changes you may have made
> and return to defaults (this will restore your apparent missing 'partitions'
> variable, which automounts the onboard flash memory):
>
>  * run clearenv
>
>  * reset
>
>  * setenv ethaddr=02:00:00:xx:xx:xx
> (where xx:xx:xx is your board's serial number)
>
>  * saveenv
>
>  * reset
> Now your board is back to the way it was when shipped from the factory.
>
> To tell it to boot to usb by default...
>  * setenv bootcmd run usbboot
>
> To set the default kernel boot arguments (according to the wiki)...
>  * setenv bootargs console=ttyS0,115200 mtdparts=\$\{partitions\}
> rootdelay=8 root='/dev/sda1 rw'\; bootm 0xfc000000
>
>  * saveenv
>
> I think the problem might be that the command on the wiki doesn't escape
> the semi colons, dollar signs or curly-braces, so uboot interprets these as
> separate commands.
>
>
> However, Marc at KAT suggests that you rather start with it mounted RO (the
> default) and then remount it after the kernel's started. He considers this a
> "safer" option.
>
> To do this manually, once booted into linux, do
>
>  * mount -o remount,rw /
>
> Apparently you can make that change automatic on boot in fstab, though I
> haven't tried this myself.
>
> Jason
>
>
>
>
> On 15 Jan 2010, at 03:22, Mark Wagner wrote:
>
>  Hi Tom,
>>
>> Have any of these permutations worked for you?  I've gotten it to boot
>> with the command I sent you earlier, but Jason also mentioned to me awhile
>> ago that editing the fstab file would work too, but I haven't tried that
>> yet.
>>
>> Mark
>>
>> On Thu, Jan 14, 2010 at 3:23 PM, Tom Downes <[email protected]> wrote:
>> Mark:
>>
>> I think the problem might be more basic.  I have not found clear
>> instructions on the precise command that one is supposed to run to change
>> the usbboot environment variable.  It appears to be csh-like environment
>> that one is greeted with when you break the automatic boot process.
>>
>> I think the problem that I was having before was that when I ran:
>>
>> setenv usbboot bootargs console=ttyS0,115200 mtdparts=${partitions}
>> rootdelay=8 root=/dev/sda1 rw; bootm fc000000
>>
>> it interpreted "bootm fc000000" as a 2nd command rather than part of the
>> setenv.  It also seems like there should be a second setenv after usbboot so
>> that usbboot is not so much an environment variable itself as a shorthand
>> for setting the bootargs environment variable to values appropriate for
>> booting by USB.
>>
>> So... I have tried a number of permutations of the below code, putting in
>> single/double quotes all around (to manipulate whether the $ is interpreted
>> literally or whether its value is taken in), including where you suggest and
>> around ${partitions}.  Putting single or double quotes around the whole
>> thing allows the setenv commad to be interpreted as a single command rather
>> than one setenv followed by a bootm.
>>
>> Variation of what I have tried:
>>
>> setenv usbboot 'setenv bootargs console=ttyS0,115200
>> mtdparts=${partitions} rootdelay=8 root=/dev/sda1 rw; bootm fc000000'
>>
>> Sorry for being obtuse, but I'm not sure this booting environment is
>> really csh/tcsh or just some extremely basic CLI.
>>
>> Tom
>>
>> On Thu, Jan 14, 2010 at 2:46 PM, Mark Wagner <[email protected]>
>> wrote:
>> Hi Tom,
>>
>> I needed to change root=/dev/sda1 rw to root='/dev/sda1 rw' (add qoutes)
>> in the command below to get the usb filesystem mounted read/write.
>>
>> Mark
>>
>>
>>
>> On Thu, Jan 14, 2010 at 2:39 PM, Tom Downes <[email protected]> wrote:
>> Yes, it boots read-only even trying to set usbboot as below.  Though, as I
>> said, I cannot set mtdparts=${partitions}, I have to remove the dollar sign.
>>  If that is important then I'm not sure what to do because if I leave the
>> dollar sign in it immediately boots and not to USB.
>>
>>
>> setenv usbboot bootargs console=ttyS0,115200 mtdparts=${partitions}
>> rootdelay=8 root=/dev/sda1 rw; bootm fc000000
>>
>> I'll look into things more this afternoon.
>>
>> Tom
>>
>>
>> On Tue, Jan 12, 2010 at 8:22 AM, Zhiwei Liu <[email protected]> wrote:
>>
>> Tom,
>>
>> Do you mean it still mounts the new filesystem read-only even if you
>> change the usbboot environment to "bootargs console=ttyS0,115200
>> mtdparts=${partitions}
>> rootdelay=8 root=/dev/sda1 rw; bootm fc000000"?
>>
>> I wish I could play with the environment a little bit, but I made it to
>> boot off the USB stick automatically.
>> I can not interrupt the standard boot process at uboot. I'm still
>> struggling to bring it back to the standard
>> boot process, It seems like I have to reload the uboot to overwrite the
>> 'bootargs' environment.
>>
>> FYR, I also had some warnings when booting.
>> --------------------------------------------------
>> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
>> VFS: Mounted root (ext2 filesystem).
>> Freeing unused kernel memory: 136k init
>> INIT: version 2.86 booting
>> warning: can't open /etc/mtab: No such file or directory
>> mount: wrong fs type, bad option, bad superblock on tmpfs,
>>       missing codepage or other error
>>       In some cases useful info is found in syslog - try
>>       dmesg | tail  or so
>> ---------------------------------------------------
>> I don't know how to fix that.
>>
>> Zhiwei
>>
>>
>>
>>
>> On Tue, Jan 5, 2010 at 5:18 PM, Tom Downes <[email protected]> wrote:
>> Zhiwei (and others):
>>
>> We are having the same problem as you upon upgrading to the 20091006
>> kernel and the 20091130 etch file system on USB.  We have an older
>> filesystem (don't recall the date) on one USB stick and the new one on
>> another.  Both USB sticks are formatted ext2 and are the same
>> brand/model.
>>
>> For some reason, when booting by "run usbboot" it will mount the old
>> filesystem read-write but the new filesystem read-only.  Doing a
>> remount fixes the problem, but of course the boot process has had a
>> number of failures along the way.
>>
>> This is after changing the usbboot environment variable to what you
>> list, but when I try to do it with the dollar sign for partitions it
>> immediately runs.  So if I remove that, it will work.  Is that really
>> an environment variable?  In any case, it works for one system, but
>> not the other so I'm not sure it's the issue precisely.
>>
>> setenv usbboot bootargs console=ttyS0,115200 mtdparts=${partitions}
>> rootdelay=8 root=/dev/sda1 rw; bootm fc000000
>> saveenv
>> run usbboot
>>
>> (minus the dollar sign for mtdparts)
>>
>> For both USB sticks it will complain about the file systems not having
>> been checked.  I have gone through and run "tune2fs -c 0 -i 0" on the
>> new stick and done a manual force check with "e2fsck -fp".  On the
>> ROACH and on a true desktop.  Yet it still gives the error.  My
>> impression is that sometimes the kernel will mount an ext2 fs
>> read-only if it doesn't think that it has been checked.  I would think
>> that this is the source of the problem were it not for the fact that
>> the same kernel mounts one disk read-write and the other read-only.
>>
>> I usually get the date set correctly along the way and do soft reboots
>> so that the clock doesn't get too far off.  Otherwise I would be
>> concerned about automatic checks for a given number of days (despite
>> my use of tune2fs).
>>
>> In both cases it also complains about the jffs2 filesystem not
>> mounting properly at the very end of boot.
>>
>> I'm a bit baffled...
>>
>> Tom
>>
>>
>>
>>
>>
>>
>>
>

Reply via email to