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

unsling script for openslug

Expand Messages
  • Internet User
    Can anyone guide me on running a modified unsling script for openslug? I would like to leave the rootfs in flash but install packages/configurations onto a
    Message 1 of 7 , Nov 28, 2005
      Can anyone guide me on running a modified unsling script for openslug?
      I would like to leave the rootfs in flash but install
      packages/configurations onto a disk in openslug (like unslung).

      The reason I want to do this is because "turnup -i disk /dev/sda*"
      places the entire root on my hard drive (like it's suppost to). But
      this creates 3 problems for me;

      1. My root harddrive never spins down (because it's root). I use my
      slug maybe 1 hour of the 24 hours that the hard drive is spinning!

      2. My backup script (which backs up one entire disk to another)
      closely resembles that of the liknsys orginal firmware backup which
      isn't to efficient when the disk being copied contains the rootfs.

      3. Openslug seems to randomly switch which usb port gets mounted as
      sda and sdb. From what I have read on the mailing list, no one has
      been able to duplicate the linksys behaviour of binding usb port 0{1}
      to sda{b}.
    • John Bowler
      From: Internet User ... Mount /usr, i.e. mkfs a disk partition, copy the flash /usr to it, then enter it into /etc/fstab mounted on /usr, then reboot. There
      Message 2 of 7 , Nov 28, 2005
        From: Internet User
        >Can anyone guide me on running a modified unsling script for openslug?
        >I would like to leave the rootfs in flash but install
        >packages/configurations onto a disk in openslug (like unslung).

        Mount /usr, i.e. mkfs a disk partition, copy the flash /usr to it, then
        enter it into /etc/fstab mounted on /usr, then reboot.

        There are any number of ways of setting it up. If you want to do anything
        sophisticated I would recommend starting with slugos-bag, not openslug,
        because that leaves more space in the flash. Still that costs a lot of
        setup time (i.e. more work) and, at present, you have to built it yourself.

        It's just a standard UNIX system - all of the traditional ways of splitting
        the system across multiple disks (or network partitions) work.

        John Bowler <jbowler@...>
      • Internet User
        John Bowler wrote: Mount /usr, i.e. mkfs a disk partition, copy the flash /usr to it, then enter it into /etc/fstab mounted on /usr, then
        Message 3 of 7 , Nov 29, 2005
          John Bowler <jbowler@a...> wrote:
          Mount /usr, i.e. mkfs a disk partition, copy the flash /usr to it,
          then enter it into /etc/fstab mounted on /usr, then reboot.
          <snip>
          It's just a standard UNIX system - all of the traditional ways of
          splitting the system across multiple disks (or network partitions)
          work.





          I figured it would work something like that, but I am not all that
          familiar with the unix directory structure. So I guessed I should
          have
          asked:

          If I were going to move parts of the root file system to another
          disk/partition, which directories should I primarily be concerned
          with?

          And which ones should I absolutly leave alone?


          I know the unsling script moved and symlinked the /opt directory. But
          everything doesn't sit in /opt on a full unix system right?
        • John Bowler
          From: Internet User ... /usr ... If you want to leave the root on flash you have to leave *something* there, so probably /etc. Then the following don t
          Message 4 of 7 , Nov 29, 2005
            From: Internet User
            >If I were going to move parts of the root file system to another
            >disk/partition, which directories should I primarily be concerned
            >with?

            /usr

            >And which ones should I absolutly leave alone?

            If you want to leave the root on flash you have to leave *something*
            there, so probably /etc. Then the following don't (shouldn't) have
            anything added by package installs so should be constant in size (no
            point moving):

            /bin
            /dev
            /media
            /mnt
            /proc
            /sbin
            /sys

            And the candidates to overmount in addition to /usr are:

            /boot
            /var
            /tmp (defaults to a link to /var/tmp)
            /home

            See http://www.pathname.com/fhs/

            John Bowler <jbowler@...>
          • Internet User
            ... From: Internet User ... /usr And the candidates to overmount in addition to /usr are: /boot /var /tmp (defaults to a link to /var/tmp) /home ... Okay, so
            Message 5 of 7 , Jan 3, 2006
              --- In nslu2-linux@yahoogroups.com, John Bowler <jbowler@a...> wrote:

              From: Internet User
              >If I were going to move parts of the root file system to another
              >disk/partition, which directories should I primarily be concerned
              >with?

              /usr

              And the candidates to overmount in addition to /usr are:
              /boot
              /var
              /tmp (defaults to a link to /var/tmp)
              /home

              ---

              Okay, so after several weeks of research and a couple of tries, I
              understand the concept of mounting a directory over another
              directory. And that works great in a perminent situation (ie, the
              same disk is always plugged into the same port at start and reboot),
              but what happens when that disk is (re)moved or gets a different
              device name (like sdb over sda).

              Utilizing the udev package, I was able to find a work around for the
              sda/sba assignments switching at start and reboot. I would now like
              to ask this:

              Is it possible the include the /etc directory in the list of
              directories to be overmounted? This would be preferred as the
              original flash /etc would remain untouched.

              Becuase my slug is curently set up with the /usr and /home
              directories being overmounted with 2 separate partitions and the /etc
              is on the root with my configurations for samba/sshd/httpd, if I were
              to boot my slug without the disk attached (or the disk failed), I
              loss those services. Samba and httpd are no problem, but I need sshd
              to administir the slug. I wouldn't be able the reconfigure or
              investigate, I would only be able the reflash and start from scratch.

              With uNSLUg, even if one were to unsling to a disk then remove that
              disk, the slug would still boot to the default config. If there were
              someway to do overmount the directories without changing the original
              underlying ones, openslug would be able the do the same.

              Also....
              Is it possible to overmount (pivot maybe??) multiple direcories with
              directories that all sit on one partition? As opposed to creating a
              seperate partition for every directory I want to overmount using
              fstab. I would rather not have to manage 7 seperate partitions for
              all the directories I want to move off flash.
            • Rod Whitby
              On Tue, 03 Jan 2006 10:04:45 -0000, Internet User ... mount -o bind -- Rod
              Message 6 of 7 , Jan 3, 2006
                On Tue, 03 Jan 2006 10:04:45 -0000, "Internet User"
                <deshawn@...> said:
                > Is it possible to overmount (pivot maybe??) multiple direcories with
                > directories that all sit on one partition? As opposed to creating a
                > seperate partition for every directory I want to overmount using
                > fstab. I would rather not have to manage 7 seperate partitions for
                > all the directories I want to move off flas

                mount -o bind

                -- Rod
              • John Bowler
                From: Internet User [deshawn] ... Well... for /usr I would *not* remove the original flash contents, so that if the mount fails dropbear still works. Likewise
                Message 7 of 7 , Jan 3, 2006
                  From: Internet User [deshawn]
                  >Okay, so after several weeks of research and a couple of tries, I
                  >understand the concept of mounting a directory over another
                  >directory. And that works great in a perminent situation (ie, the
                  >same disk is always plugged into the same port at start and reboot),
                  >but what happens when that disk is (re)moved or gets a different
                  >device name (like sdb over sda).

                  Well... for /usr I would *not* remove the original flash contents,
                  so that if the mount fails dropbear still works. Likewise I would
                  leave the root home directory in /home.

                  I would also ipkg remove those kernel modules which are not required -
                  specifically the ones for either reiserfs or ext2. (I.e. whichever file
                  system you are *not* using on the disk.) Plus I would ipkg remove
                  the corresponding file system utilities. (These packages are listed
                  explicitly in the monotone file <openembedded>/conf/distro/openslug.conf -
                  this file describes the consequences of removing each of the removeable
                  packages.)

                  >Utilizing the udev package, I was able to find a work around for the
                  >sda/sba assignments switching at start and reboot.

                  That's something which definately needs fixing in openslug...

                  >Is it possible the include the /etc directory in the list of
                  >directories to be overmounted? This would be preferred as the
                  >original flash /etc would remain untouched.

                  If you do that (it is possible) then the only thing *not* overmounted
                  is /lib. Also I believe /etc is probably the second most frequently
                  accessed directory on a running system (after /var).

                  It *is* useful to make a system with /lib from the flash and nothing
                  else, because that makes it slightly easier to upgrade the kernel.
                  All the same, it would be difficult to get this right because an
                  accidental ipkg upgrade of a kernel module might make the system
                  unbootable, with no recovery.

                  On balance I would recommend not overmounting /etc

                  >Becuase my slug is curently set up with the /usr and /home
                  >directories being overmounted with 2 separate partitions and the /etc
                  >is on the root with my configurations for samba/sshd/httpd, if I were
                  >to boot my slug without the disk attached (or the disk failed), I
                  >loss those services. Samba and httpd are no problem, but I need sshd
                  >to administir the slug. I wouldn't be able the reconfigure or
                  >investigate, I would only be able the reflash and start from scratch.

                  Correct - but if you don't remove the required programs from the
                  flash /usr (primarily the contents of /usr/sbin) that won't be a
                  problem.

                  >If there were
                  >someway to do overmount the directories without changing the original
                  >underlying ones, openslug would be able the do the same.

                  That's what an overmount does, it just hides the original inode
                  (directory in this case) contents.

                  John Bowler <jbowler@...>
                Your message has been successfully submitted and would be delivered to recipients shortly.