Loading ...
Sorry, an error occurred while loading the content.

Re: [nslu2-linux] unslung 3.16

Expand Messages
  • Rod Whitby
    ... Correct. ... In 3.x, you can easily recover with a reflash. Combine that with using the resling script to save and restore any modifications you do make
    Message 1 of 2 , Dec 30, 2004
    • 0 Attachment
      On Thu, 30 Dec 2004 07:57:36 -0000, ov <ov2k@...> wrote:
      > Perhaps I've read the README wrong, but it seems like under the new
      > unslung 3.16, the root filesystem has been moved into the flash
      > memory.


      > I'm interested in 3.16 for some of the other features, but
      > I'd rather keep the root filesystem on the disk, as with 2.12, so that
      > if I screw something up, I can recover by unplugging the disk.

      In 3.x, you can easily recover with a reflash. Combine that with
      using the resling script to save and restore any modifications you do
      make to the rootfs.

      > I'm thinking of something like a boot order. The NSLU2 will check the
      > flash memory for a boot order (at this point, disk first or internal
      > flash first). If it's disk first, dig around the disk for a viable
      > root filesystem and use that. If there isn't one, fall back to the
      > internal flash.

      It's in the works. We have to reimplement the boot switchbox to use
      pivot_root instead of real-root-dev to be able to do this. We are
      also going to include booting from an NFS mounted disk too.

      > Thoughts? I don't really know much about the boot process, so is this
      > even doable? Does anybody else think these are reasonable concerns?

      It is definitely doable, and is in the pipeline. We're just working
      out the best way to do it, given that in the past we have had to put a
      "sleep 10 seconds" in there to make sure that USB disks were

      As far as concerns about writing to flash goes, here's the facts:

      1/ As far as I know, each block of 256kb in the flash is rated for at
      least 100000 erase/write cycles.

      2/ The jffs2 filesystem is specifically designed for flash, and has
      wear leveling and other intelligent things to reduce the number of
      erase/write cycles.

      3/ The /var and /dev directory trees are mounted as ramdisks on boot,
      so any writes to these areas after boot are not going anywhere near
      the flash.

      4/ It is our intention that the only writes to flash (unless the user
      changes intentionally changes something) should be at boot, and when
      packages are first installed. If you find a package that is writing
      things to flash at run-time, then report it as a slugbug and it will
      be given the highest priority.

      5/ So our contention is that even if you reboot your NSLU2 or install
      packages 3 times a day, then your flash should last at least 90 years

      Having said all that, each person who installs custom firmware takes
      individual responsibility for their actions. The development team
      takes all care and precautions, but if you (the collective you, not
      Oliver in particular) are a person who is prone to court actions
      because the Unslung firmware broke your $80 NSLU2, then we'd prefer
      that you didn't use the Unslung firmware in the first place :-)

      And having said all that, we are re-implementing the ability to load
      the rootfs from an external disk instead of the internal flash.

      -- Rod
    Your message has been successfully submitted and would be delivered to recipients shortly.