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

Re: [nslu2-linux] Newbie questions

Expand Messages
  • Laurent Gilson
    Hello ... telnet in and run df . If the root-fs (called / ) has more then 5MB free: congrats, it worked. cu
    Message 1 of 15 , Mar 1, 2006
    • 0 Attachment
      Hello




      > And 2)
      > The Readme sez "confirm that the root filesystem is being loaded from
      > the external disk." How do I do this?

      telnet in and run "df". If the root-fs (called "/") has more then 5MB
      free: congrats, it worked.

      cu
    • John Clonts
      Now that I ve bumbled around on my slug for a few weeks, I seem to be missing a couple of concepts (well, more than a couple! but I ll only ask about a
      Message 2 of 15 , May 30, 2006
      • 0 Attachment
        Now that I've bumbled around on my slug for a few weeks, I seem to be
        missing a couple of concepts (well, more than a couple! but I'll only
        ask about a couple!) I'm using openslug.

        1) What exactly is the distinction between the cross feed and the
        native feed? I.e. why is package X in the cross feed and package Y in
        the native feed? Are there any in both?

        2) What is the difference between a package for unslung and one for
        openslug. Is it usually/mainly just that unslung packages generally
        install into /opt?

        3) If there is a package that I want for openslug and it exists for
        unslung (e.g. ffmpeg), how is the best way to get it? I tried
        building it but it seems I first need an associate's degree in
        OpenEmbedded :)

        Thanks!
        John
      • Marcel Nijenhof
        ... There is a difference in the way we build the packages. Most of the packages we build with a cross compiler on a fast intel system. Those are the packages
        Message 3 of 15 , May 31, 2006
        • 0 Attachment
          On Tue, 2006-05-30 at 19:26 -0500, John Clonts wrote:
          > Now that I've bumbled around on my slug for a few weeks, I seem to be
          > missing a couple of concepts (well, more than a couple! but I'll only
          > ask about a couple!) I'm using openslug.
          >
          > 1) What exactly is the distinction between the cross feed and the
          > native feed? I.e. why is package X in the cross feed and package Y in
          > the native feed? Are there any in both?

          There is a difference in the way we build the packages.

          Most of the packages we build with a cross compiler on a fast
          intel system. Those are the packages in the cross feed.

          This won't work well for all software so some packages we build
          on a slug. Those are in the native feed.

          >
          > 2) What is the difference between a package for unslung and one for
          > openslug. Is it usually/mainly just that unslung packages generally
          > install into /opt?

          Unslung is a linux distro based on the linksys software. Openslug is
          based on openembeded and uses a different kernel and libraries.

          --
          Marceln
        • John Clonts
          ... Ok, so generally it is easier to native compile because the configure script is actually running in and examining the environment it is going to be
          Message 4 of 15 , May 31, 2006
          • 0 Attachment
            On 5/31/06, Marcel Nijenhof <nslu2@...> wrote:
            > On Tue, 2006-05-30 at 19:26 -0500, John Clonts wrote:
            > > Now that I've bumbled around on my slug for a few weeks, I seem to be
            > > missing a couple of concepts (well, more than a couple! but I'll only
            > > ask about a couple!) I'm using openslug.
            > >
            > > 1) What exactly is the distinction between the cross feed and the
            > > native feed? I.e. why is package X in the cross feed and package Y in
            > > the native feed? Are there any in both?
            >
            > There is a difference in the way we build the packages.
            >
            > Most of the packages we build with a cross compiler on a fast
            > intel system. Those are the packages in the cross feed.
            >
            > This won't work well for all software so some packages we build
            > on a slug. Those are in the native feed.
            >

            Ok, so generally it is easier to native compile because the configure
            script is actually running in and examining the environment it is
            going to be targeting... I think I understand that.

            But to the user who invokes "ipkg install somepackage", it doesn't
            really matter whether that is coming from the native or the cross feed
            since the ipkg configuration is probably set to look in both feeds
            anyway. (right?)

            > >
            > > 2) What is the difference between a package for unslung and one for
            > > openslug. Is it usually/mainly just that unslung packages generally
            > > install into /opt?
            >
            > Unslung is a linux distro based on the linksys software. Openslug is
            > based on openembeded and uses a different kernel and libraries.
            >

            So, when I took an unslung package (ffmpeg), downloaded and installed
            it (into /opt), added /opt/bin to my path and /opt/lib to my
            ld.so.conf, I am just gambling whether its going to work or not?

            I did this (with ffmpeg) and it is "sort of" working :) I.e. it runs
            and generates an mpeg output file, it's just that the file is not
            quite right. But then neither was the file produced by my ffmpeg
            openembedded compile (both existing and newer CVS versions). I'm
            trying to figure out whether to pursue it here, on the openembedded
            forum(s), or on the ffmpeg forum(s).


            Thanks!
            John
          • Laurent Gilson
            Hello, ... right. The while native vs cross thing is only interesting developers or powerusers compiling stuff themselfs. The typical user don t have to deal
            Message 5 of 15 , May 31, 2006
            • 0 Attachment
              Hello,

              > But to the user who invokes "ipkg install somepackage", it doesn't
              > really matter whether that is coming from the native or the cross feed
              > since the ipkg configuration is probably set to look in both feeds
              > anyway. (right?)

              right.

              The while native vs cross thing is only interesting developers or
              powerusers compiling stuff themselfs. The typical user don't have to deal
              with it.

              >> > 2) What is the difference between a package for unslung and one for
              >> > openslug. Is it usually/mainly just that unslung packages generally
              >> > install into /opt?
              >>
              >> Unslung is a linux distro based on the linksys software. Openslug is
              >> based on openembeded and uses a different kernel and libraries.
              >>
              >
              > So, when I took an unslung package (ffmpeg), downloaded and installed
              > it (into /opt), added /opt/bin to my path and /opt/lib to my
              > ld.so.conf, I am just gambling whether its going to work or not?

              yes.

              Both linux have almost the same libs. But only "almost". So hiccups from
              missing libs/packets may be possible.

              > I did this (with ffmpeg) and it is "sort of" working :) I.e. it runs
              > and generates an mpeg output file, it's just that the file is not
              > quite right. But then neither was the file produced by my ffmpeg
              > openembedded compile (both existing and newer CVS versions). I'm
              > trying to figure out whether to pursue it here, on the openembedded
              > forum(s), or on the ffmpeg forum(s).

              ffmpeg is not written for the endianess of the slug. In fact: it's written
              without testing for other endianess. I suggest going debianslug (the
              debian-kernel switches the endianess at startup).

              cu
            • list.nslu2-linux@rwhitby.net
              Let s get the terminology right here. DebianSlug is one of the variants of the SlugOS distribution (which also includes OpenSlug and UcSlugC) which is itself
              Message 6 of 15 , May 31, 2006
              • 0 Attachment
                Let's get the terminology right here. DebianSlug is one of the variants of the SlugOS distribution (which also includes OpenSlug and UcSlugC) which is itself based on OpenEmbedded.
                Then there is the debian-installer image which uses the official Debain kernel (built by Debian, not by nslu2-linux).
                Both of them run little-endian, due to a short assembly language prepend to the kernel (i.e. it's not the kernel which does the endian swap, it's a short piece of assembly code that we put just before the kernel is flash).
                So if you want a little-endian version of OpenSlug which has exactly the same set of packages as OpenSlug but runs them little-endian, then use DebianSlug (which will have it's first binary release as part of SlugOS 3.x soon), not the debian-installer image.
                If you want to run the Debian packages, then you have two choices. Either take part in the testing of the debian-installer image (which does not have all the latest kernel patches from nslu2-linux included yet), or use DebianSlug and debootstrap.
                Note that DebianSlug and the debian-installer image will eventually become the same thing (when nslu2-linux is able to get all it's latest kernel patches accepted by Linus and Debian), and nslu2-linux and the Debian kernel team are working closely together to make that happen. We have two kernels (the SlugOS kernel and the official Debian arm kernel) and we are working to make them into a single kernel that can be used by both sets of users.

                -- Rod
                -----Original Message-----
                ffmpeg is not written for the endianess of the slug. In fact: it's written without testing for other endianess. I suggest going debianslug (the debian-kernel switches the endianess at startup).



                cu






                SPONSORED LINKS
                Communication and networking Wireless communication and networking Linksys nslu2



                YAHOO! GROUPS LINKS
                Visit your group "nslu2-linux" on the web.
                To unsubscribe from this group, send an email to:
                nslu2-linux-unsubscribe@yahoogroups.com
                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
              • h8dc
                ... become the same thing (when nslu2-linux is able to get all it s latest kernel patches accepted by Linus and Debian), and nslu2-linux and the Debian kernel
                Message 7 of 15 , Jun 9, 2006
                • 0 Attachment
                  --- In nslu2-linux@yahoogroups.com, list.nslu2-linux@... wrote:

                  > Note that DebianSlug and the debian-installer image will eventually
                  become the same thing (when nslu2-linux is able to get all it's latest
                  kernel patches accepted by Linus and Debian), and nslu2-linux and the
                  Debian kernel team are working closely together to make that happen.
                  We have two kernels (the SlugOS kernel and the official Debian arm
                  kernel) and we are working to make them into a single kernel that can
                  be used by both sets of users.
                  -----

                  Fascinating! Care to offer a ballpark prognostication as to when that
                  might be? "This year" or "sometime next year" would be perfectly
                  acceptable answers. :-)


                  Thanks,
                  h8dc
                • Rod Whitby
                  ... It s not a fast process. We need to re-base the patches against the latest Linux kernel, then submit them for comment on the linux-arm-kernel mailing list,
                  Message 8 of 15 , Jun 9, 2006
                  • 0 Attachment
                    >> Rod Whitby wrote:
                    >> Note that DebianSlug and the debian-installer image will eventually
                    >> become the same thing (when nslu2-linux is able to get all it's latest
                    >> kernel patches accepted by Linus and Debian), and nslu2-linux and the
                    >> Debian kernel team are working closely together to make that happen.
                    >> We have two kernels (the SlugOS kernel and the official Debian arm
                    >> kernel) and we are working to make them into a single kernel that can
                    >> be used by both sets of users.

                    > h8dc wrote:
                    > Fascinating! Care to offer a ballpark prognostication as to when that
                    > might be? "This year" or "sometime next year" would be perfectly
                    > acceptable answers. :-)

                    It's not a fast process.

                    We need to re-base the patches against the latest Linux kernel, then
                    submit them for comment on the linux-arm-kernel mailing list, then ask
                    the IXP4XX maintainer and the ARM maintainer to approve the patches
                    (there is usually a couple of rounds of improvement or changes in this
                    step), then wait for the ARM maintainer to push these to Linus for
                    inclusion at kernel.org (there is only a two week window per kernel
                    version for this), then wait for the Debian kernel team to include that
                    new version of the kernel which contains those patches.

                    We also need to do some work to make sure that the Debian/NSLU2
                    (debian-installer) image has the same recovery, upgrade and
                    boot-from-alternate-root-options (like flash sticks and nfs rootfs) that
                    DebianSlug (SlugOS) currently has before we can consider them merged.

                    Note that no matter which firmware image you use (DebianSlug or
                    Debian/NSLU2), you can still use exactly the same resulting Debian
                    installation on your hard disk. You can even swap between DebianSlug
                    and Debian/NSLU2 kernels (as long as you swap the corresponding kernel
                    modules at the same time). So going with one or the other does not make
                    it easier or harder to use Debian on an NSLU2 (once you've completed the
                    initial Debian installation). It's only the initial installation of
                    Debian (via the debian-installer, or via debootstrap) which is different
                    (apart from the fact that the Debian/NSLU2 kernel doesn't contain all
                    the latest patches).

                    I personally currently use DebianSlug and the debootstrap procedure, but
                    now that we have released the DebianSlug binary image I will start to
                    spend more time on the merge. Other NSLU2-Linux developers use the
                    Debian/NSLU2 kernel. There is no one single answer.

                    It's a trade-off between ease of installation (Debian/NSLU2) versus
                    having a full NSLU2-Linux set of kernel patches installed (DebianSlug).
                    Both may need to progress forward independently, even while we are
                    trying to merge them (since the path to merging involves pushing thing
                    through the official kernel.org release).

                    -- Rod
                  • andrewnslu2
                    ... wrote: ... So I have installed Debian/NSLU2 and enjoyed the easy/standard installation process, and now have a harddrive full of debian
                    Message 9 of 15 , Jun 12, 2006
                    • 0 Attachment
                      --- In nslu2-linux@yahoogroups.com, Rod Whitby <list.nslu2-linux@...>
                      wrote:
                      <snip>
                      > Note that no matter which firmware image you use (DebianSlug or
                      > Debian/NSLU2), you can still use exactly the same resulting Debian
                      > installation on your hard disk. You can even swap between DebianSlug
                      > and Debian/NSLU2 kernels (as long as you swap the corresponding kernel
                      > modules at the same time). So going with one or the other does not make
                      > it easier or harder to use Debian on an NSLU2 (once you've completed the
                      > initial Debian installation). It's only the initial installation of
                      > Debian (via the debian-installer, or via debootstrap) which is different
                      > (apart from the fact that the Debian/NSLU2 kernel doesn't contain all
                      > the latest patches).

                      <snip>

                      So I have installed Debian/NSLU2 and enjoyed the easy/standard
                      installation process, and now have a harddrive full of debian
                      goodness, but a kernel which is a little behind the times. Just how
                      easy would it be to swap to the SlugOS Debian kernel? I know how to
                      reflash with upslug, but how would the hdd filesystem need to be
                      changed? would you make a backup of the boot and kernel module
                      directories, and install modules again with ipkg? or manually set up
                      the modules to agree with whatever modules exists before?

                      Or is it not worth bothering with and just wait for an official
                      Debian/NSLU2 update?

                      Seems to me this could be something that could be easily scripted...
                    • John Reiser
                      ... It seems to me that the procedure should be something like: 0. e2fsck -f the filesystem on the harddrive (use a different machine.) 1. Flash DebianSlug
                      Message 10 of 15 , Jun 12, 2006
                      • 0 Attachment
                        andrewnslu2 wrote:
                        > So I have installed Debian/NSLU2 and enjoyed the easy/standard
                        > installation process, and now have a harddrive full of debian
                        > goodness, but a kernel which is a little behind the times. Just how
                        > easy would it be to swap to the SlugOS Debian kernel?

                        It seems to me that the procedure should be something like:
                        0. "e2fsck -f" the filesystem on the harddrive (use a different machine.)
                        1. Flash DebianSlug firmware into NSLU2 (no harddrive connected!)
                        2. Connect harddrive to NSLU2, boot DebianSlug firmware.
                        3. "turnup -f disk" which overrides the usual check
                        that the filesystem should be empty.

                        This should overlay the SlugOS Debian kernel (plus some other files) on
                        top of the otherwise-ready filesystem. Then, the kernel and kernel modules
                        on the harddrive may be updated only with DebianSlug updates (until Debian
                        receives and merges all the NSLU2-specific kernel changes.)

                        --
                      • Rod Whitby
                        ... Make sure you use reflash to do this, as this will save your DebianSlug configuration settings. ... You also should copy the new set of kernel modules
                        Message 11 of 15 , Jun 12, 2006
                        • 0 Attachment
                          John Reiser wrote:
                          > It seems to me that the procedure should be something like:
                          > 0. "e2fsck -f" the filesystem on the harddrive (use a different machine.)
                          > 1. Flash DebianSlug firmware into NSLU2 (no harddrive connected!)

                          Make sure you use "reflash" to do this, as this will save your
                          DebianSlug configuration settings.

                          > 2. Connect harddrive to NSLU2, boot DebianSlug firmware.

                          You also should copy the new set of kernel modules from the flash to the
                          rootfs on the hard disk.

                          > 3. "turnup -f disk" which overrides the usual check
                          > that the filesystem should be empty.
                          >
                          > This should overlay the SlugOS Debian kernel (plus some other files) on
                          > top of the otherwise-ready filesystem. Then, the kernel and kernel modules
                          > on the harddrive may be updated only with DebianSlug updates (until Debian
                          > receives and merges all the NSLU2-specific kernel changes.)

                          Actually, the SlugOS kernel (there is no such thing as a SlugOS Debian
                          kernel - it's either a SlugOS kernel or a Debian kernel, it can't be
                          both) is loaded by the bootloader directly from flash before anything
                          else. So the contents of /boot on the Debian hard disk is irrelevant
                          for SlugOS booting purposes.

                          So the SlugOS kernel is loaded from flash, and then runs /linuxrc on the
                          internal SlugOS rootfs, which detects that you have turned up to disk
                          and then pivots to the Debian rootfs on disk, where you must have the
                          SlugOS kernel modules correctly copied to /lib/modules (as these are
                          loaded after the Debian rootfs takes control).

                          -- Rod
                        • andrewnslu2
                          ... machine.) ... files) on ... modules ... (until Debian ... OK so the turnup script marks the JFFS2 to point the boot script to the sda filesystem, is there
                          Message 12 of 15 , Jun 13, 2006
                          • 0 Attachment
                            --- In nslu2-linux@yahoogroups.com, Rod Whitby <list.nslu2-linux@...>
                            wrote:
                            >
                            > John Reiser wrote:
                            > > It seems to me that the procedure should be something like:
                            > > 0. "e2fsck -f" the filesystem on the harddrive (use a different
                            machine.)
                            > > 1. Flash DebianSlug firmware into NSLU2 (no harddrive connected!)
                            >
                            > Make sure you use "reflash" to do this, as this will save your
                            > DebianSlug configuration settings.
                            >
                            > > 2. Connect harddrive to NSLU2, boot DebianSlug firmware.
                            >
                            > You also should copy the new set of kernel modules from the flash to the
                            > rootfs on the hard disk.
                            >
                            > > 3. "turnup -f disk" which overrides the usual check
                            > > that the filesystem should be empty.
                            > >
                            > > This should overlay the SlugOS Debian kernel (plus some other
                            files) on
                            > > top of the otherwise-ready filesystem. Then, the kernel and kernel
                            modules
                            > > on the harddrive may be updated only with DebianSlug updates
                            (until Debian
                            > > receives and merges all the NSLU2-specific kernel changes.)
                            >
                            > Actually, the SlugOS kernel (there is no such thing as a SlugOS Debian
                            > kernel - it's either a SlugOS kernel or a Debian kernel, it can't be
                            > both) is loaded by the bootloader directly from flash before anything
                            > else. So the contents of /boot on the Debian hard disk is irrelevant
                            > for SlugOS booting purposes.
                            >
                            > So the SlugOS kernel is loaded from flash, and then runs /linuxrc on the
                            > internal SlugOS rootfs, which detects that you have turned up to disk
                            > and then pivots to the Debian rootfs on disk, where you must have the
                            > SlugOS kernel modules correctly copied to /lib/modules (as these are
                            > loaded after the Debian rootfs takes control).
                            >
                            > -- Rod
                            >

                            OK so the turnup script marks the JFFS2 to point the boot script to
                            the sda filesystem, is there anything else it does? specifically -
                            does it clobber anything on the disk?
                            If the ONLY difference between the Debian/NSLU2 and SlugOS EXTERNAL
                            filesystems is the lib/module directory, then that sounds like it
                            would be easy to switch between Slugos and Debian/NSLU2.

                            I do wonder about the startup method though, does Debian/NSLU2 boot
                            the same way? i.e. with the kernel proper & initrd in flash & a pivot
                            root? what about the /linuxrc? would this need to change between the two?

                            My main reason for doing all this is to get the newer kernel with to
                            use stuff like bluetooth. I like running the official Debian distro
                            but the upstream acceptance process sounds like it will take an age!

                            Andrew
                          • Rod Whitby
                            ... The turnup script check for some things on the disk, to reduce the chance that the disk is not bootable, and then modified /linuxrc on the flash. As far
                            Message 13 of 15 , Jun 14, 2006
                            • 0 Attachment
                              andrewnslu2 wrote:
                              > OK so the turnup script marks the JFFS2 to point the boot script to
                              > the sda filesystem, is there anything else it does? specifically -
                              > does it clobber anything on the disk?

                              The turnup script check for some things on the disk, to reduce the
                              chance that the disk is not bootable, and then modified /linuxrc on the
                              flash. As far as I know, it does not modify anything on the disk unless
                              you tell it to initialise the disk.

                              > If the ONLY difference between the Debian/NSLU2 and SlugOS EXTERNAL
                              > filesystems is the lib/module directory, then that sounds like it
                              > would be easy to switch between Slugos and Debian/NSLU2.

                              Yes, as long as you are careful with the /lib/modules directory, you can
                              easily switch between the two kernels.

                              > I do wonder about the startup method though, does Debian/NSLU2 boot
                              > the same way? i.e. with the kernel proper & initrd in flash & a pivot
                              > root? what about the /linuxrc? would this need to change between the two?

                              To tell you the truth, I don't know what the latest status of this is.
                              That's what I need to find out now that the SlugOS release is done.
                              Martin M. (tbm) would be the person to ask.

                              > My main reason for doing all this is to get the newer kernel with to
                              > use stuff like bluetooth. I like running the official Debian distro
                              > but the upstream acceptance process sounds like it will take an age!

                              I personally run the latest NSLU2-Linux kernel and modules, and the
                              official Debian distro for userland. The best of both worlds. I expect
                              it will take some time to get the kernel patches upstream and down into
                              Debian, but that is definitely the goal.

                              -- Rod
                            • andrewnslu2
                              ... to the ... on the ... two? ... If anyone is interested - I did replace the DI kernel with the SlugOS 3.1, and it seems to work! A couple of minor issues
                              Message 14 of 15 , Sep 8, 2006
                              • 0 Attachment
                                --- In nslu2-linux@yahoogroups.com, "andrewnslu2" <andrewnslu2@...> wrote:
                                >
                                > --- In nslu2-linux@yahoogroups.com, Rod Whitby <list.nslu2-linux@>
                                > wrote:
                                > >
                                > > John Reiser wrote:
                                > > > It seems to me that the procedure should be something like:
                                > > > 0. "e2fsck -f" the filesystem on the harddrive (use a different
                                > machine.)
                                > > > 1. Flash DebianSlug firmware into NSLU2 (no harddrive connected!)
                                > >
                                > > Make sure you use "reflash" to do this, as this will save your
                                > > DebianSlug configuration settings.
                                > >
                                > > > 2. Connect harddrive to NSLU2, boot DebianSlug firmware.
                                > >
                                > > You also should copy the new set of kernel modules from the flash
                                to the
                                > > rootfs on the hard disk.
                                > >
                                > > > 3. "turnup -f disk" which overrides the usual check
                                > > > that the filesystem should be empty.
                                > > >
                                > > > This should overlay the SlugOS Debian kernel (plus some other
                                > files) on
                                > > > top of the otherwise-ready filesystem. Then, the kernel and kernel
                                > modules
                                > > > on the harddrive may be updated only with DebianSlug updates
                                > (until Debian
                                > > > receives and merges all the NSLU2-specific kernel changes.)
                                > >
                                > > Actually, the SlugOS kernel (there is no such thing as a SlugOS Debian
                                > > kernel - it's either a SlugOS kernel or a Debian kernel, it can't be
                                > > both) is loaded by the bootloader directly from flash before anything
                                > > else. So the contents of /boot on the Debian hard disk is irrelevant
                                > > for SlugOS booting purposes.
                                > >
                                > > So the SlugOS kernel is loaded from flash, and then runs /linuxrc
                                on the
                                > > internal SlugOS rootfs, which detects that you have turned up to disk
                                > > and then pivots to the Debian rootfs on disk, where you must have the
                                > > SlugOS kernel modules correctly copied to /lib/modules (as these are
                                > > loaded after the Debian rootfs takes control).
                                > >
                                > > -- Rod
                                > >
                                >
                                > OK so the turnup script marks the JFFS2 to point the boot script to
                                > the sda filesystem, is there anything else it does? specifically -
                                > does it clobber anything on the disk?
                                > If the ONLY difference between the Debian/NSLU2 and SlugOS EXTERNAL
                                > filesystems is the lib/module directory, then that sounds like it
                                > would be easy to switch between Slugos and Debian/NSLU2.
                                >
                                > I do wonder about the startup method though, does Debian/NSLU2 boot
                                > the same way? i.e. with the kernel proper & initrd in flash & a pivot
                                > root? what about the /linuxrc? would this need to change between the
                                two?
                                >
                                > My main reason for doing all this is to get the newer kernel with to
                                > use stuff like bluetooth. I like running the official Debian distro
                                > but the upstream acceptance process sounds like it will take an age!
                                >
                                > Andrew
                                >

                                If anyone is interested - I did replace the DI kernel with the SlugOS
                                3.1, and it seems to work! A couple of minor issues but nothing that
                                could not be debugged with a serial cable.

                                Is this something that people whould like a how-to on? it looks like a
                                smooth update for the DI kernel is still a way off...
                              Your message has been successfully submitted and would be delivered to recipients shortly.