astlinux-devel Mailing List for AstLinux

Hi Devs,

Michael Keuter tried a a genx86_64-serial build with 4 GB RAM installed (Jetway NF9HG-2930), but only 3 GB (2914 MB) RAM was recognized.

So we started digging, this could be Syslinux, RUNNIX or the genx86_64 kernel config...

First we tried temporarily appending to the "syslinux.cfg" to directly boot to the AstLinux image, skipping RUNNIX (quite simple if anyone is interested), and presto almost 4 GB (3859 MB) of total RAM.

So RUNNIX is limiting the RAM.

Next we tried recompiling the RUNNIX kernel with PAE enabled:
--
CONFIG_HIGHMEM64G=y
CONFIG_X86_PAE=y
(among others)
--
Now booting normally, Syslinux -> RUNNIX -> AstLinux, again almost 4 GB (3859 MB) of total RAM.

As it turns out with non-PAE enabled RUNNIX, the “BIOS-provided physical RAM map” is trimmed to 3 GB, and that trimmed RAM map is passed on to the 64-bit x86_64 AstLinux image (via kexec), thereby also limiting the x86_64 image to 3 GB of usable RAM.  Unfortunately the net5501 and alix hardware are not PAE capable, so a PAE enabled RUNNIX won't work across all boards.

While it was important to fully understand why the genx86_64-serial build was being limited to 3 GB, for the real world, AstLinux really only needs 1 GB for most any situation, with 2 GB recommended to be future-proofed.

In my words...
"The bottom line, there is absolutely no benefit for an AstLinux system to have more than 2 GB of RAM, more can exist but is unnecessary."

While we could solve this "non-problem" with two different flavors of RUNNIX, it seems confusing and unneeded at this point in time.

The following entry below is added to our FAQ, comments always welcomed...

Frequently Asked Questions -> Only up to 3 GB RAM is recognized
http://doc.astlinux.org/userdoc:faq#only_up_to_3_gb_ram_is_recognized
--
The bottom line, as of the year 2016, there is absolutely no benefit for an AstLinux system to have more than 2 GB of RAM, more can exist but is unnecessary.

For 32-bit (non-PAE enabled) Linux, the maximum addressable user-space RAM is around 3 GB. This is the case for all AstLinux board types except x86_64 based images.

For 64-bit (x86_64) Linux, the maximum addressable RAM is only limited by your hardware, so you would expect to see about 4 GB with 4 GB RAM installed, but with the AstLinux system, the bootloader is RUNNIX (a 32-bit, non-PAE enabled Linux Kernel) which is common across all AstLinux board types. As it turns out with RUNNIX, the “BIOS-provided physical RAM map” is trimmed to 3 GB, and that trimmed RAM map is passed on to the 64-bit x86_64 AstLinux image (via kexec), thereby also limiting the x86_64 image to 3 GB of usable RAM.

The AstLinux developers have demonstrated that if the RUNNIX bootloader was compiled with a 32-bit, PAE enabled Linux Kernel, the “BIOS-provided physical RAM map” is not trimmed and the kexec'ed 64-bit x86_64 AstLinux image sees all the RAM. Unfortunately the net5501 and alix hardware are not PAE capable.

The added confusion of multiple RUNNIX flavors would not actually solve a real-world problem, so the maximum recognized RAM currently remains at 3 GB. The day when greater then 3 GB RAM is useful, the RUNNIX bootloader can be compiled with a PAE enabled Linux Kernel.
--

Lonnie

Hi Devs,

I have updated the developer documentation, mostly added the "Linux Build System" section at the front.

Development Environment
http://doc.astlinux.org/devdoc:documentation#linux_build_system

Feel free to tweak or propose changes here.

Lonnie

Am 12.12.2015 um 02:13 schrieb David Kerr <da...@ke...>:

> Just to confirm that I installed 64-bit version on my PC Engines APU this evening and its working fine.
> 
> Looking good so far.
> 
> David

Hi David,

thanks for testing it.

Michael

http://www.mksolutions.info

David,

Thanks for reporting, great to hear !

Lonnie


On Dec 11, 2015, at 7:13 PM, David Kerr <Da...@Ke...> wrote:

> Just to confirm that I installed 64-bit version on my PC Engines APU this evening and its working fine.
> 
> Looking good so far.
> 
> David

Just to confirm that I installed 64-bit version on my PC Engines APU this
evening and its working fine.

Looking good so far.

David

Perfect.  Thanks.

David

On Fri, Dec 11, 2015 at 1:30 PM, Lonnie Abelbeck <li...@lo...>
wrote:

> Hi David,
>
> Revision r7395 moves the README crosstool-ng URL into a script
> "~/astlinux/1.0/crosstool-ng-src/get-crosstool-ng.sh" which also allows us
> to overlay whatever patches we want.  Your
> "900-Allow-new-versions-of-make.patch" is added and it all seems to work.
>
> Thanks for your work.
>
> Lonnie
>
>
> On Dec 10, 2015, at 3:36 PM, David Kerr <Da...@Ke...> wrote:
>
> > Lonnie,
> >   The solution to the make version check is to place the attached .patch
> file into the directory
> > ~/source-control/crosstool-ng-1.20.0/patches/eglibc/2_18
> > The 2_18 directory doesn't exist, will need to be created as part of the
> copy, which you could do in the get-files.sh script.  However, the patch
> file must be copied over before running the 'sudo make install' part of the
> instructions (which copies all the patch files into
> /usr/local/lib/ct-ng.1.20.0 and it is from there that the ct-ng build picks
> up patches) so you will need to reorder the crosstool build
> instructions/script to put the get-files part up front.
> >
> > Over to you to decide next steps.
> >
> > David
> >
> > On Wed, Dec 9, 2015 at 11:46 AM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > Thanks David,
> >
> > I added your finding to: http://doc.astlinux.org/devdoc:packages
> >
> > I'll have to look into the other issue, thanks for the reminder.
> >
> > BTW, I'm still using Debian 6 in a VM for my build system, just saying
> :-)
> >
> > Lonnie
> >
> >
> > On Dec 9, 2015, at 10:27 AM, David Kerr <Da...@Ke...> wrote:
> >
> > > Happen to be creating a new build environment from scratch again, this
> time on Ubuntu 15.10.  Both problems reported below still exist... need to
> apt-get install libtool-bin and make version check fails.
> > >
> > > First can be solved by updating
> http://doc.astlinux.org/devdoc:packages
> > >
> > > The second would require a patch in crosstools (I just brute force
> edited  the
> ~/source-control/ctng-1.20.0-3.2/.build/src/eglibc-2_18/configure script to
> make progress).  Could maybe we copy over a patch file when the
> get-files.sh script is run to install eglibc-2_18?
> > >
> > > David
> > >
> > > On Fri, May 15, 2015 at 10:18 AM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > > Hi David,
> > >
> > > Thanks for your report from the bleeding-edge, good info.  Ubuntu
> 14.04 LTS uses make version 3.81 which works by default.
> > >
> > > >From the eglibc-2_19 source, the eglibc folks fixed this with a
> sledge hammer...
> > > --
> > >   case $ac_prog_version in
> > >     '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
> > >     3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*)
> > >        ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
> > >     *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
> > >
> > >   esac
> > > --
> > > we currently use eglibc-2_18.
> > >
> > > As for needing package "libtool-bin" the AstLinux current required
> packages include "libtool", I wonder if "libtool-bin" was separated out,
> but it would seem "libtool" should include the binary, here is a link:
> > >
> > >
> http://packages.ubuntu.com/search?suite=default&arch=i386&searchon=names&keywords=libtool
> > >
> > > Lonnie
> > >
> > > PS: Truly unfortunate that the upstream crosstool-ng chose to
> completely remove eglibc support, so crosstool-ng 1.20.0 is the last with
> eglibc support and little tweaks like this won't be included.
> > >
> > >
> > > On May 15, 2015, at 7:53 AM, David Kerr <Da...@Ke...> wrote:
> > >
> > > > I installed Ubuntu 15.04 64-bit this week and attempted to build
> Astlinux.  I ran into two additional problems with building crosstool-ng...
> > > >
> > > > 1) I needed to apt-get install libtool-bin
> > > > 2) I ran into the bug documented here...
> http://stackoverflow.com/questions/24494613/crosstool-ng-1-19-0-make-error-with-eglibc
> > > > and applied the "fix" documented here...
> http://colocsbar.blogspot.fr/2014/01/crosstool-ng-1190-et-make-40.html
> > > > (thought I changed the make version test to test for 4.* rather than
> 4.0*)
> > > >
> > > > Once I had crosstool-ng I was able to run through a build.  Using
> default config it failed at wanpipe, but as I don't normally compile that
> in my custom build I just went and applied my mods to .config so as not to
> compile that. Build then completed.
> > > >
> > > > I have not attempted to run it yet, but the build completed.
> > > >
> > > > David
> > > >
> > > > On Wed, May 13, 2015 at 9:54 AM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > > > Update:
> > > >
> > > > The read-only eglibc SVN repository is now working again, having
> been moved to Linux Foundation systems, thanks to Michael Halstead.
> > > >
> > > > I'm thinking we should continue with our eglibc fix of hosting our
> own "eglibc-2_18.tar.bz2" to keep things as predictable as possible.
> > > >
> > > > Thanks to Joseph S. Myers and Michael Halstead getting the eglibc
> SVN moved and running again.
> > > >
> > > > Lonnie
> > > >
> > > >
> > > > On May 7, 2015, at 8:43 PM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > > >
> > > > > Hi Devs,
> > > > >
> > > > > Recently Martin Harriss built his own custom AstLinux image from
> source using the SVN, and in the process he reported the svn server at
> eglibc.org is not working, as such "ct-ng build" fails to download
> eglibc-2_18.
> > > > >
> > > > > As you may know, eglibc development has stopped and they recommend
> switching back to glibc, but with a perfectly good and smaller eglibc-2_18
> there is no reason not to continue using it in AstLinux.  Unfortunately the
> eglibc.org svn server needs restarting and I have not been able to
> contact any of the previous developers.
> > > > >
> > > > > So, crosstool-ng uses 'svn' at svn.eglibc.org to extract the
> needed files and then creates a tarball "eglibc-2_18.tar.bz2".  If that
> tarball exists when "ct-ng build" is called it will skip the process of
> creating it's own via svn.
> > > > >
> > > > > As such, we now host the eglibc-2_18 tarball and install it via a
> user script before "ct-ng build" is called.  The README file is changed to
> reflect this change.
> > > > >
> > > > > crosstool-ng, tweak toolchain instructions to workaround broken
> svn server at eglibc.org
> > > > > http://sourceforge.net/p/astlinux/code/7064
> > > > >
> > > > > Since the toolchain is not normally rebuilt, thanks to Martin for
> reporting the issue.
> > > > >
> > > > > Lonnie
> > > >
> > > >
> ------------------------------------------------------------------------------
> > > > One dashboard for servers and applications across
> Physical-Virtual-Cloud
> > > > Widest out-of-the-box monitoring support with 50+ applications
> > > > Performance metrics, stats and reports that give you Actionable
> Insights
> > > > Deep dive visibility with transaction tracing using APM Insight.
> > > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > > _______________________________________________
> > > > Astlinux-devel mailing list
> > > > Ast...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > > >
> > > > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> > > >
> > > >
> ------------------------------------------------------------------------------
> > > > One dashboard for servers and applications across
> Physical-Virtual-Cloud
> > > > Widest out-of-the-box monitoring support with 50+ applications
> > > > Performance metrics, stats and reports that give you Actionable
> Insights
> > > > Deep dive visibility with transaction tracing using APM Insight.
> > > >
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________
> > > > Astlinux-devel mailing list
> > > > Ast...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > > >
> > > > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > One dashboard for servers and applications across
> Physical-Virtual-Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable
> Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > _______________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> > >
> > >
> ------------------------------------------------------------------------------
> > > _______________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >
> >
> <001-Allow-new-versions-of-make.patch>------------------------------------------------------------------------------
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

Hi David,

Revision r7395 moves the README crosstool-ng URL into a script "~/astlinux/1.0/crosstool-ng-src/get-crosstool-ng.sh" which also allows us to overlay whatever patches we want.  Your "900-Allow-new-versions-of-make.patch" is added and it all seems to work.

Thanks for your work.

Lonnie


On Dec 10, 2015, at 3:36 PM, David Kerr <Da...@Ke...> wrote:

> Lonnie,
>   The solution to the make version check is to place the attached .patch file into the directory
> ~/source-control/crosstool-ng-1.20.0/patches/eglibc/2_18
> The 2_18 directory doesn't exist, will need to be created as part of the copy, which you could do in the get-files.sh script.  However, the patch file must be copied over before running the 'sudo make install' part of the instructions (which copies all the patch files into /usr/local/lib/ct-ng.1.20.0 and it is from there that the ct-ng build picks up patches) so you will need to reorder the crosstool build instructions/script to put the get-files part up front.
> 
> Over to you to decide next steps.  
> 
> David
> 
> On Wed, Dec 9, 2015 at 11:46 AM, Lonnie Abelbeck <li...@lo...> wrote:
> Thanks David,
> 
> I added your finding to: http://doc.astlinux.org/devdoc:packages
> 
> I'll have to look into the other issue, thanks for the reminder.
> 
> BTW, I'm still using Debian 6 in a VM for my build system, just saying :-)
> 
> Lonnie
> 
> 
> On Dec 9, 2015, at 10:27 AM, David Kerr <Da...@Ke...> wrote:
> 
> > Happen to be creating a new build environment from scratch again, this time on Ubuntu 15.10.  Both problems reported below still exist... need to apt-get install libtool-bin and make version check fails.
> >
> > First can be solved by updating http://doc.astlinux.org/devdoc:packages
> >
> > The second would require a patch in crosstools (I just brute force edited  the ~/source-control/ctng-1.20.0-3.2/.build/src/eglibc-2_18/configure script to make progress).  Could maybe we copy over a patch file when the get-files.sh script is run to install eglibc-2_18?
> >
> > David
> >
> > On Fri, May 15, 2015 at 10:18 AM, Lonnie Abelbeck <li...@lo...> wrote:
> > Hi David,
> >
> > Thanks for your report from the bleeding-edge, good info.  Ubuntu 14.04 LTS uses make version 3.81 which works by default.
> >
> > >From the eglibc-2_19 source, the eglibc folks fixed this with a sledge hammer...
> > --
> >   case $ac_prog_version in
> >     '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
> >     3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*)
> >        ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
> >     *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
> >
> >   esac
> > --
> > we currently use eglibc-2_18.
> >
> > As for needing package "libtool-bin" the AstLinux current required packages include "libtool", I wonder if "libtool-bin" was separated out, but it would seem "libtool" should include the binary, here is a link:
> >
> > http://packages.ubuntu.com/search?suite=default&arch=i386&searchon=names&keywords=libtool
> >
> > Lonnie
> >
> > PS: Truly unfortunate that the upstream crosstool-ng chose to completely remove eglibc support, so crosstool-ng 1.20.0 is the last with eglibc support and little tweaks like this won't be included.
> >
> >
> > On May 15, 2015, at 7:53 AM, David Kerr <Da...@Ke...> wrote:
> >
> > > I installed Ubuntu 15.04 64-bit this week and attempted to build Astlinux.  I ran into two additional problems with building crosstool-ng...
> > >
> > > 1) I needed to apt-get install libtool-bin
> > > 2) I ran into the bug documented here... http://stackoverflow.com/questions/24494613/crosstool-ng-1-19-0-make-error-with-eglibc
> > > and applied the "fix" documented here... http://colocsbar.blogspot.fr/2014/01/crosstool-ng-1190-et-make-40.html
> > > (thought I changed the make version test to test for 4.* rather than 4.0*)
> > >
> > > Once I had crosstool-ng I was able to run through a build.  Using default config it failed at wanpipe, but as I don't normally compile that in my custom build I just went and applied my mods to .config so as not to compile that. Build then completed.
> > >
> > > I have not attempted to run it yet, but the build completed.
> > >
> > > David
> > >
> > > On Wed, May 13, 2015 at 9:54 AM, Lonnie Abelbeck <li...@lo...> wrote:
> > > Update:
> > >
> > > The read-only eglibc SVN repository is now working again, having been moved to Linux Foundation systems, thanks to Michael Halstead.
> > >
> > > I'm thinking we should continue with our eglibc fix of hosting our own "eglibc-2_18.tar.bz2" to keep things as predictable as possible.
> > >
> > > Thanks to Joseph S. Myers and Michael Halstead getting the eglibc SVN moved and running again.
> > >
> > > Lonnie
> > >
> > >
> > > On May 7, 2015, at 8:43 PM, Lonnie Abelbeck <li...@lo...> wrote:
> > >
> > > > Hi Devs,
> > > >
> > > > Recently Martin Harriss built his own custom AstLinux image from source using the SVN, and in the process he reported the svn server at eglibc.org is not working, as such "ct-ng build" fails to download eglibc-2_18.
> > > >
> > > > As you may know, eglibc development has stopped and they recommend switching back to glibc, but with a perfectly good and smaller eglibc-2_18 there is no reason not to continue using it in AstLinux.  Unfortunately the eglibc.org svn server needs restarting and I have not been able to contact any of the previous developers.
> > > >
> > > > So, crosstool-ng uses 'svn' at svn.eglibc.org to extract the needed files and then creates a tarball "eglibc-2_18.tar.bz2".  If that tarball exists when "ct-ng build" is called it will skip the process of creating it's own via svn.
> > > >
> > > > As such, we now host the eglibc-2_18 tarball and install it via a user script before "ct-ng build" is called.  The README file is changed to reflect this change.
> > > >
> > > > crosstool-ng, tweak toolchain instructions to workaround broken svn server at eglibc.org
> > > > http://sourceforge.net/p/astlinux/code/7064
> > > >
> > > > Since the toolchain is not normally rebuilt, thanks to Martin for reporting the issue.
> > > >
> > > > Lonnie
> > >
> > > ------------------------------------------------------------------------------
> > > One dashboard for servers and applications across Physical-Virtual-Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > _______________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> > >
> > > ------------------------------------------------------------------------------
> > > One dashboard for servers and applications across Physical-Virtual-Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> >
> >
> > ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> <001-Allow-new-versions-of-make.patch>------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Thanks David !

Lonnie

On Dec 10, 2015, at 3:36 PM, David Kerr <Da...@Ke...> wrote:

> Lonnie,
>   The solution to the make version check is to place the attached .patch file into the directory
> ~/source-control/crosstool-ng-1.20.0/patches/eglibc/2_18
> The 2_18 directory doesn't exist, will need to be created as part of the copy, which you could do in the get-files.sh script.  However, the patch file must be copied over before running the 'sudo make install' part of the instructions (which copies all the patch files into /usr/local/lib/ct-ng.1.20.0 and it is from there that the ct-ng build picks up patches) so you will need to reorder the crosstool build instructions/script to put the get-files part up front.
> 
> Over to you to decide next steps.  
> 
> David
> 
> On Wed, Dec 9, 2015 at 11:46 AM, Lonnie Abelbeck <li...@lo...> wrote:
> Thanks David,
> 
> I added your finding to: http://doc.astlinux.org/devdoc:packages
> 
> I'll have to look into the other issue, thanks for the reminder.
> 
> BTW, I'm still using Debian 6 in a VM for my build system, just saying :-)
> 
> Lonnie
> 
> 
> On Dec 9, 2015, at 10:27 AM, David Kerr <Da...@Ke...> wrote:
> 
> > Happen to be creating a new build environment from scratch again, this time on Ubuntu 15.10.  Both problems reported below still exist... need to apt-get install libtool-bin and make version check fails.
> >
> > First can be solved by updating http://doc.astlinux.org/devdoc:packages
> >
> > The second would require a patch in crosstools (I just brute force edited  the ~/source-control/ctng-1.20.0-3.2/.build/src/eglibc-2_18/configure script to make progress).  Could maybe we copy over a patch file when the get-files.sh script is run to install eglibc-2_18?
> >
> > David
> >
> > On Fri, May 15, 2015 at 10:18 AM, Lonnie Abelbeck <li...@lo...> wrote:
> > Hi David,
> >
> > Thanks for your report from the bleeding-edge, good info.  Ubuntu 14.04 LTS uses make version 3.81 which works by default.
> >
> > >From the eglibc-2_19 source, the eglibc folks fixed this with a sledge hammer...
> > --
> >   case $ac_prog_version in
> >     '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
> >     3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*)
> >        ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
> >     *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
> >
> >   esac
> > --
> > we currently use eglibc-2_18.
> >
> > As for needing package "libtool-bin" the AstLinux current required packages include "libtool", I wonder if "libtool-bin" was separated out, but it would seem "libtool" should include the binary, here is a link:
> >
> > http://packages.ubuntu.com/search?suite=default&arch=i386&searchon=names&keywords=libtool
> >
> > Lonnie
> >
> > PS: Truly unfortunate that the upstream crosstool-ng chose to completely remove eglibc support, so crosstool-ng 1.20.0 is the last with eglibc support and little tweaks like this won't be included.
> >
> >
> > On May 15, 2015, at 7:53 AM, David Kerr <Da...@Ke...> wrote:
> >
> > > I installed Ubuntu 15.04 64-bit this week and attempted to build Astlinux.  I ran into two additional problems with building crosstool-ng...
> > >
> > > 1) I needed to apt-get install libtool-bin
> > > 2) I ran into the bug documented here... http://stackoverflow.com/questions/24494613/crosstool-ng-1-19-0-make-error-with-eglibc
> > > and applied the "fix" documented here... http://colocsbar.blogspot.fr/2014/01/crosstool-ng-1190-et-make-40.html
> > > (thought I changed the make version test to test for 4.* rather than 4.0*)
> > >
> > > Once I had crosstool-ng I was able to run through a build.  Using default config it failed at wanpipe, but as I don't normally compile that in my custom build I just went and applied my mods to .config so as not to compile that. Build then completed.
> > >
> > > I have not attempted to run it yet, but the build completed.
> > >
> > > David
> > >
> > > On Wed, May 13, 2015 at 9:54 AM, Lonnie Abelbeck <li...@lo...> wrote:
> > > Update:
> > >
> > > The read-only eglibc SVN repository is now working again, having been moved to Linux Foundation systems, thanks to Michael Halstead.
> > >
> > > I'm thinking we should continue with our eglibc fix of hosting our own "eglibc-2_18.tar.bz2" to keep things as predictable as possible.
> > >
> > > Thanks to Joseph S. Myers and Michael Halstead getting the eglibc SVN moved and running again.
> > >
> > > Lonnie
> > >
> > >
> > > On May 7, 2015, at 8:43 PM, Lonnie Abelbeck <li...@lo...> wrote:
> > >
> > > > Hi Devs,
> > > >
> > > > Recently Martin Harriss built his own custom AstLinux image from source using the SVN, and in the process he reported the svn server at eglibc.org is not working, as such "ct-ng build" fails to download eglibc-2_18.
> > > >
> > > > As you may know, eglibc development has stopped and they recommend switching back to glibc, but with a perfectly good and smaller eglibc-2_18 there is no reason not to continue using it in AstLinux.  Unfortunately the eglibc.org svn server needs restarting and I have not been able to contact any of the previous developers.
> > > >
> > > > So, crosstool-ng uses 'svn' at svn.eglibc.org to extract the needed files and then creates a tarball "eglibc-2_18.tar.bz2".  If that tarball exists when "ct-ng build" is called it will skip the process of creating it's own via svn.
> > > >
> > > > As such, we now host the eglibc-2_18 tarball and install it via a user script before "ct-ng build" is called.  The README file is changed to reflect this change.
> > > >
> > > > crosstool-ng, tweak toolchain instructions to workaround broken svn server at eglibc.org
> > > > http://sourceforge.net/p/astlinux/code/7064
> > > >
> > > > Since the toolchain is not normally rebuilt, thanks to Martin for reporting the issue.
> > > >
> > > > Lonnie
> > >
> > > ------------------------------------------------------------------------------
> > > One dashboard for servers and applications across Physical-Virtual-Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > _______________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> > >
> > > ------------------------------------------------------------------------------
> > > One dashboard for servers and applications across Physical-Virtual-Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> >
> >
> > ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> <001-Allow-new-versions-of-make.patch>------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Lonnie,
  The solution to the make version check is to place the attached .patch
file into the directory
~/source-control/crosstool-ng-1.20.0/patches/eglibc/2_18
The 2_18 directory doesn't exist, will need to be created as part of the
copy, which you could do in the get-files.sh script.  However, the patch
file must be copied over before running the 'sudo make install' part of the
instructions (which copies all the patch files into
/usr/local/lib/ct-ng.1.20.0 and it is from there that the ct-ng build picks
up patches) so you will need to reorder the crosstool build
instructions/script to put the get-files part up front.

Over to you to decide next steps.

David

On Wed, Dec 9, 2015 at 11:46 AM, Lonnie Abelbeck <li...@lo...>
wrote:

> Thanks David,
>
> I added your finding to: http://doc.astlinux.org/devdoc:packages
>
> I'll have to look into the other issue, thanks for the reminder.
>
> BTW, I'm still using Debian 6 in a VM for my build system, just saying :-)
>
> Lonnie
>
>
> On Dec 9, 2015, at 10:27 AM, David Kerr <Da...@Ke...> wrote:
>
> > Happen to be creating a new build environment from scratch again, this
> time on Ubuntu 15.10.  Both problems reported below still exist... need to
> apt-get install libtool-bin and make version check fails.
> >
> > First can be solved by updating http://doc.astlinux.org/devdoc:packages
> >
> > The second would require a patch in crosstools (I just brute force
> edited  the
> ~/source-control/ctng-1.20.0-3.2/.build/src/eglibc-2_18/configure script to
> make progress).  Could maybe we copy over a patch file when the
> get-files.sh script is run to install eglibc-2_18?
> >
> > David
> >
> > On Fri, May 15, 2015 at 10:18 AM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > Hi David,
> >
> > Thanks for your report from the bleeding-edge, good info.  Ubuntu 14.04
> LTS uses make version 3.81 which works by default.
> >
> > >From the eglibc-2_19 source, the eglibc folks fixed this with a sledge
> hammer...
> > --
> >   case $ac_prog_version in
> >     '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
> >     3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*)
> >        ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
> >     *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
> >
> >   esac
> > --
> > we currently use eglibc-2_18.
> >
> > As for needing package "libtool-bin" the AstLinux current required
> packages include "libtool", I wonder if "libtool-bin" was separated out,
> but it would seem "libtool" should include the binary, here is a link:
> >
> >
> http://packages.ubuntu.com/search?suite=default&arch=i386&searchon=names&keywords=libtool
> >
> > Lonnie
> >
> > PS: Truly unfortunate that the upstream crosstool-ng chose to completely
> remove eglibc support, so crosstool-ng 1.20.0 is the last with eglibc
> support and little tweaks like this won't be included.
> >
> >
> > On May 15, 2015, at 7:53 AM, David Kerr <Da...@Ke...> wrote:
> >
> > > I installed Ubuntu 15.04 64-bit this week and attempted to build
> Astlinux.  I ran into two additional problems with building crosstool-ng...
> > >
> > > 1) I needed to apt-get install libtool-bin
> > > 2) I ran into the bug documented here...
> http://stackoverflow.com/questions/24494613/crosstool-ng-1-19-0-make-error-with-eglibc
> > > and applied the "fix" documented here...
> http://colocsbar.blogspot.fr/2014/01/crosstool-ng-1190-et-make-40.html
> > > (thought I changed the make version test to test for 4.* rather than
> 4.0*)
> > >
> > > Once I had crosstool-ng I was able to run through a build.  Using
> default config it failed at wanpipe, but as I don't normally compile that
> in my custom build I just went and applied my mods to .config so as not to
> compile that. Build then completed.
> > >
> > > I have not attempted to run it yet, but the build completed.
> > >
> > > David
> > >
> > > On Wed, May 13, 2015 at 9:54 AM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > > Update:
> > >
> > > The read-only eglibc SVN repository is now working again, having been
> moved to Linux Foundation systems, thanks to Michael Halstead.
> > >
> > > I'm thinking we should continue with our eglibc fix of hosting our own
> "eglibc-2_18.tar.bz2" to keep things as predictable as possible.
> > >
> > > Thanks to Joseph S. Myers and Michael Halstead getting the eglibc SVN
> moved and running again.
> > >
> > > Lonnie
> > >
> > >
> > > On May 7, 2015, at 8:43 PM, Lonnie Abelbeck <li...@lo...>
> wrote:
> > >
> > > > Hi Devs,
> > > >
> > > > Recently Martin Harriss built his own custom AstLinux image from
> source using the SVN, and in the process he reported the svn server at
> eglibc.org is not working, as such "ct-ng build" fails to download
> eglibc-2_18.
> > > >
> > > > As you may know, eglibc development has stopped and they recommend
> switching back to glibc, but with a perfectly good and smaller eglibc-2_18
> there is no reason not to continue using it in AstLinux.  Unfortunately the
> eglibc.org svn server needs restarting and I have not been able to
> contact any of the previous developers.
> > > >
> > > > So, crosstool-ng uses 'svn' at svn.eglibc.org to extract the needed
> files and then creates a tarball "eglibc-2_18.tar.bz2".  If that tarball
> exists when "ct-ng build" is called it will skip the process of creating
> it's own via svn.
> > > >
> > > > As such, we now host the eglibc-2_18 tarball and install it via a
> user script before "ct-ng build" is called.  The README file is changed to
> reflect this change.
> > > >
> > > > crosstool-ng, tweak toolchain instructions to workaround broken svn
> server at eglibc.org
> > > > http://sourceforge.net/p/astlinux/code/7064
> > > >
> > > > Since the toolchain is not normally rebuilt, thanks to Martin for
> reporting the issue.
> > > >
> > > > Lonnie
> > >
> > >
> ------------------------------------------------------------------------------
> > > One dashboard for servers and applications across
> Physical-Virtual-Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable
> Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > _______________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> > >
> > >
> ------------------------------------------------------------------------------
> > > One dashboard for servers and applications across
> Physical-Virtual-Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable
> Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > >
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >
> >
> >
> ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

David,

Good to know.  I'm kind of surprised Ubuntu 15.04 works.

Looking forward to when you are testing AstLinux x86_64 on your APU1...

Lonnie



On Dec 9, 2015, at 9:20 PM, David Kerr <Da...@Ke...> wrote:

> So, boldly going where no one has gone before, I attempted to do a build on Ubuntu 15.10 and failed.  Problem is pretty close to the start, building initrd, fails on host-pkg-config 0.25 building.  This package generates lots of warnings in the compile and ultimately ends up with...
> 
> 
> So, back to 15.04 in the meantime.
> 
> Thanks
> David
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

David,

All you really need is the latest /usr/sbin/upgrade-run-image script, architecture independent.

You should be able to copy that script anywhere on your 32-bit system and perform the switch as described.

Lonnie



On Dec 9, 2015, at 9:11 PM, David Kerr <Da...@Ke...> wrote:

> So, instructions for switching to 64-bit say to use the command line and that the existing 32-bit system needs to be r7353 or later.  Is there any way to do the switch without first installing a 32-bit version (I'm on 7328) or do I need to go build a up-to-date 32-bit version first?
> 
> Thanks
> David
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

So, boldly going where no one has gone before, I attempted to do a build on
Ubuntu 15.10 and failed.  Problem is pretty close to the start, building
initrd, fails on host-pkg-config 0.25 building.  This package generates
lots of warnings in the compile and ultimately ends up with...

./.libs/libglib.a(gutils.o): In function `g_bit_nth_msf':
gutils.c:(.text+0x30): multiple definition of `g_bit_nth_msf'
testglib.o:testglib.c:(.text+0x150): first defined here
./.libs/libglib.a(gutils.o): In function `g_bit_storage':
gutils.c:(.text+0x70): multiple definition of `g_bit_storage'
testglib.o:testglib.c:(.text+0x190): first defined here
collect2: error: ld returned 1 exit status
Makefile:575: recipe for target 'testglib' failed
make[5]: *** [testglib] Error 1
make[5]: Leaving directory
'/mnt/david/AstLinuxBuild/astlinux/1.0/output/build/host-pkg-config-0.25/glib-1.2.10'
Makefile:650: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
'/mnt/david/AstLinuxBuild/astlinux/1.0/output/build/host-pkg-config-0.25/glib-1.2.10'
Makefile:480: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory
'/mnt/david/AstLinuxBuild/astlinux/1.0/output/build/host-pkg-config-0.25/glib-1.2.10'
Makefile:671: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
'/mnt/david/AstLinuxBuild/astlinux/1.0/output/build/host-pkg-config-0.25'
Makefile:433: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory
'/mnt/david/AstLinuxBuild/astlinux/1.0/output/build/host-pkg-config-0.25'
package/Makefile.package.in:288: recipe for target
'/home/david/astlinux/1.0/output/build/host-pkg-config-0.25/.stamp_built'
failed
make: ***
[/home/david/astlinux/1.0/output/build/host-pkg-config-0.25/.stamp_built]
Error 2

real 3m23.339s
user 1m44.800s
sys 0m30.252s
Initrd build failed.
mkdir -p /home/david/astlinux/1.0/output/build/buildroot-config/lxdialog
make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc"
obj=/home/david/astlinux/1.0/output/build/buildroot-config -C
package/config -f Makefile.br conf
make[1]: Entering directory
'/mnt/david/AstLinuxBuild/astlinux/1.0/package/config'
/usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE
 -I/home/david/astlinux/1.0/output/build/buildroot-config  -MM *.c >
/home/david/astlinux/1.0/output/build/buildroot-config/.depend 2>/dev/null
|| :
/usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE
 -I/home/david/astlinux/1.0/output/build/buildroot-config   -c conf.c -o
/home/david/astlinux/1.0/output/build/buildroot-config/conf.o
/usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE
 -I/home/david/astlinux/1.0/output/build/buildroot-config   -c kxgettext.c
-o /home/david/astlinux/1.0/output/build/buildroot-config/kxgettext.o
/usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE
 -I/home/david/astlinux/1.0/output/build/buildroot-config  -I. -c
/home/david/astlinux/1.0/output/build/buildroot-config/zconf.tab.c -o
/home/david/astlinux/1.0/output/build/buildroot-config/zconf.tab.o
/usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE
 -I/home/david/astlinux/1.0/output/build/buildroot-config
/home/david/astlinux/1.0/output/build/buildroot-config/conf.o
/home/david/astlinux/1.0/output/build/buildroot-config/zconf.tab.o   -o
/home/david/astlinux/1.0/output/build/buildroot-config/conf
rm /home/david/astlinux/1.0/output/build/buildroot-config/zconf.tab.c
make[1]: Leaving directory
'/mnt/david/AstLinuxBuild/astlinux/1.0/package/config'
mkdir -p /home/david/astlinux/1.0/output/build/buildroot-config
#
# configuration written to /mnt/david/AstLinuxBuild/astlinux/1.0/.config
#

Fails whether trying to build 32-bit or 64-bit.

Where is the build log saved for initrd?  I'd like to compare with the
successful builds on Ubuntu 15.04 (above is copy/paste from console).

There may be some major differences between Ubuntu 15.04 and 15.10, for a
start linux kernel is now 4.2, was 3.19.  So at the moment I'm pointing the
finger at Ubuntu and not anything I did [wrong] when setting up the system
for building AstLinux.

So, back to 15.04 in the meantime.

Thanks
David

So, instructions for switching to 64-bit say to use the command line and
that the existing 32-bit system needs to be r7353 or later.  Is there any
way to do the switch without first installing a 32-bit version (I'm on
7328) or do I need to go build a up-to-date 32-bit version first?

Thanks
David

Update,

Hopefully SVN r7388's "kernel-reboot" script is now production quality.  I'm using it on my x86_64 build on my main AstLinux box. :-)

"kexec -f ..." is now divided into "kexec -l ..." and "kexec -e" which allows the "/etc/rc shutdown" to occur toward the end instead of the beginning, this simplifies things and a tmpfs mount can be eliminated.

This is the same program flow that the big distros use as well for a kexec reboot.

BTW, this also works for "virgin" images saving time during the setup process.  Also works with "noram" and the image mounted via loop.

Dev tip: Use " losetup -f " instead of hard coding "/dev/loop0" or such.

Lonnie



On Dec 6, 2015, at 9:51 PM, Lonnie Abelbeck <li...@lo...> wrote:

> Hi Devs,
> 
> Michael Keuter suggested adding "sreboot" support to the web interface in some way, I personally wasn't too enamored since "sreboot" only restarted the current image and that would be confusing when firmware changes were made,, etc. .
> BTW, if you do not know "sreboot" is an old script that uses 'kexec' to restart the current image.
> 
> That got us thinking, what if we created a new script that did a System Reboot *exactly* the same way as RUNNIX does, but skip all the extra steps: BIOS boot, Syslinux, RUNNIX and all the fixed delays involved.
> 
> The new script is "/sbin/kernel-reboot" and has been well tested in SVN r7377 and later.  The web interface now uses "/sbin/kernel-reboot" and automatically reduces the "reboot countdown timer" by 30 seconds.
> 
> These are the steps that are skipped by using "kernel-reboot"...
> --
> BIOS MemCheck and Boot: 4-10 seconds
> 
> Syslinux plus boot prompt: 5-6 seconds
> 
> RUNNIX boot time (varies): 10-16 seconds
> 
> RUNNIX rootdelay=10: 10 seconds
> --
> Total: 29 - 42 seconds
> 
> So the automatic 30 second reduction is a quite safe value, I have found that reducing the time (Prefs tab) by 10 more seconds (40 total) is often desirable, but better to default on the lower end.
> 
> This change only directly effects the web interface, and a new Prefs tab option 'Disable faster "kernel-reboot" System Reboot' reverts back to the classic method all the time if ever desired.
> 
> Most importantly, to the user this is all automatic, with reboots taking 30 seconds less.
> 
> Of course from the CLI you can issue a "kernel-reboot" instead of a "reboot" to minimize reboot times.
> 
> Why didn't we think of this sooner. :-)
> 
> Lonnie

Thanks,

And just a reminder "setconsole-speed-tty" only works after persistent storage ( /admin/setup.php ) is configured as it edits /etc/inittab on your "asturw" overlay.

Lonnie

On Dec 9, 2015, at 3:39 PM, David Kerr <Da...@Ke...> wrote:

> Lonnie,
>   Yes apparently I was doing bad things.  Ok, I will change to follow your recommendation.
> 
> Thanks
> David
> 
> 
> On Wed, Dec 9, 2015 at 4:00 PM, Lonnie Abelbeck <li...@lo...> wrote:
> David,
> 
> It's Tradition, as the song goes.  I don't think we want to make default console speed changes for an architecture change.  I know that would personally case me a lot of grief from a user's point of view (developer hat off).
> 
> Of course the real problem is the APU's Coreboot does not support BIOS console speed settings other than at compile time.  I never understood that.
> 
> But, a PC Engines APU user only has to do the following, *once* to stray from the defaults.
> --
> setconsole-speed-tty 115200 ttyS0
> --
> and a reboot.  That's it.
> 
> Additionally, if you are using the "Switching Images between i586 and x86_64" technique from: http://doc.astlinux.org/devdoc:devdoc_switch_i586_x86_64
> your serial console settings should follow without any changes.
> 
> 
> > so I'm modifying these settings in my custom build.
> 
> If that means you are manually editing project/astlinux/board/genx86_64-serial/ files for the genx86_64-serial board type for your build, **do not do that** !!! That will cause problems with upgrades getting the console correct.
> 
> Just perform the one-time "setconsole-speed-tty" and things are set forever, even with run-image upgrades, and RUNNIX upgrades.
> 
> Lonnie
> 
> 
> 
> On Dec 9, 2015, at 12:19 PM, David Kerr <Da...@Ke...> wrote:
> 
> > Could we perhaps, maybe, bring the serial port speed up to more current standards for the 64-bit version of AstLinux.  Like maybe change the default baud rate from 19,200 to 115,200.  Maybe?  Please?  This is the default speed of PC Engines APU boards, so I'm modifying these settings in my custom build.  Would be nice if it was the default!
> >
> > Thanks,
> > David
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Lonnie,
  Yes apparently I was doing bad things.  Ok, I will change to follow your
recommendation.

Thanks
David


On Wed, Dec 9, 2015 at 4:00 PM, Lonnie Abelbeck <li...@lo...>
wrote:

> David,
>
> It's Tradition, as the song goes.  I don't think we want to make default
> console speed changes for an architecture change.  I know that would
> personally case me a lot of grief from a user's point of view (developer
> hat off).
>
> Of course the real problem is the APU's Coreboot does not support BIOS
> console speed settings other than at compile time.  I never understood that.
>
> But, a PC Engines APU user only has to do the following, *once* to stray
> from the defaults.
> --
> setconsole-speed-tty 115200 ttyS0
> --
> and a reboot.  That's it.
>
> Additionally, if you are using the "Switching Images between i586 and
> x86_64" technique from:
> http://doc.astlinux.org/devdoc:devdoc_switch_i586_x86_64
> your serial console settings should follow without any changes.
>
>
> > so I'm modifying these settings in my custom build.
>
> If that means you are manually editing
> project/astlinux/board/genx86_64-serial/ files for the genx86_64-serial
> board type for your build, **do not do that** !!! That will cause problems
> with upgrades getting the console correct.
>
> Just perform the one-time "setconsole-speed-tty" and things are set
> forever, even with run-image upgrades, and RUNNIX upgrades.
>
> Lonnie
>
>
>
> On Dec 9, 2015, at 12:19 PM, David Kerr <Da...@Ke...> wrote:
>
> > Could we perhaps, maybe, bring the serial port speed up to more current
> standards for the 64-bit version of AstLinux.  Like maybe change the
> default baud rate from 19,200 to 115,200.  Maybe?  Please?  This is the
> default speed of PC Engines APU boards, so I'm modifying these settings in
> my custom build.  Would be nice if it was the default!
> >
> > Thanks,
> > David
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

David,

It's Tradition, as the song goes.  I don't think we want to make default console speed changes for an architecture change.  I know that would personally case me a lot of grief from a user's point of view (developer hat off).

Of course the real problem is the APU's Coreboot does not support BIOS console speed settings other than at compile time.  I never understood that.

But, a PC Engines APU user only has to do the following, *once* to stray from the defaults.
--
setconsole-speed-tty 115200 ttyS0
--
and a reboot.  That's it.

Additionally, if you are using the "Switching Images between i586 and x86_64" technique from: http://doc.astlinux.org/devdoc:devdoc_switch_i586_x86_64
your serial console settings should follow without any changes.


> so I'm modifying these settings in my custom build. 

If that means you are manually editing project/astlinux/board/genx86_64-serial/ files for the genx86_64-serial board type for your build, **do not do that** !!! That will cause problems with upgrades getting the console correct.

Just perform the one-time "setconsole-speed-tty" and things are set forever, even with run-image upgrades, and RUNNIX upgrades.

Lonnie



On Dec 9, 2015, at 12:19 PM, David Kerr <Da...@Ke...> wrote:

> Could we perhaps, maybe, bring the serial port speed up to more current standards for the 64-bit version of AstLinux.  Like maybe change the default baud rate from 19,200 to 115,200.  Maybe?  Please?  This is the default speed of PC Engines APU boards, so I'm modifying these settings in my custom build.  Would be nice if it was the default!
> 
> Thanks,
> David
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Could we perhaps, maybe, bring the serial port speed up to more current
standards for the 64-bit version of AstLinux.  Like maybe change the
default baud rate from 19,200 to 115,200.  Maybe?  Please?  This is the
default speed of PC Engines APU boards, so I'm modifying these settings in
my custom build.  Would be nice if it was the default!

Thanks,
David

Thanks David,

I added your finding to: http://doc.astlinux.org/devdoc:packages

I'll have to look into the other issue, thanks for the reminder.

BTW, I'm still using Debian 6 in a VM for my build system, just saying :-)

Lonnie


On Dec 9, 2015, at 10:27 AM, David Kerr <Da...@Ke...> wrote:

> Happen to be creating a new build environment from scratch again, this time on Ubuntu 15.10.  Both problems reported below still exist... need to apt-get install libtool-bin and make version check fails.
> 
> First can be solved by updating http://doc.astlinux.org/devdoc:packages
> 
> The second would require a patch in crosstools (I just brute force edited  the ~/source-control/ctng-1.20.0-3.2/.build/src/eglibc-2_18/configure script to make progress).  Could maybe we copy over a patch file when the get-files.sh script is run to install eglibc-2_18?
> 
> David 
> 
> On Fri, May 15, 2015 at 10:18 AM, Lonnie Abelbeck <li...@lo...> wrote:
> Hi David,
> 
> Thanks for your report from the bleeding-edge, good info.  Ubuntu 14.04 LTS uses make version 3.81 which works by default.
> 
> >From the eglibc-2_19 source, the eglibc folks fixed this with a sledge hammer...
> --
>   case $ac_prog_version in
>     '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
>     3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*)
>        ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
>     *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
> 
>   esac
> --
> we currently use eglibc-2_18.
> 
> As for needing package "libtool-bin" the AstLinux current required packages include "libtool", I wonder if "libtool-bin" was separated out, but it would seem "libtool" should include the binary, here is a link:
> 
> http://packages.ubuntu.com/search?suite=default&arch=i386&searchon=names&keywords=libtool
> 
> Lonnie
> 
> PS: Truly unfortunate that the upstream crosstool-ng chose to completely remove eglibc support, so crosstool-ng 1.20.0 is the last with eglibc support and little tweaks like this won't be included.
> 
> 
> On May 15, 2015, at 7:53 AM, David Kerr <Da...@Ke...> wrote:
> 
> > I installed Ubuntu 15.04 64-bit this week and attempted to build Astlinux.  I ran into two additional problems with building crosstool-ng...
> >
> > 1) I needed to apt-get install libtool-bin
> > 2) I ran into the bug documented here... http://stackoverflow.com/questions/24494613/crosstool-ng-1-19-0-make-error-with-eglibc
> > and applied the "fix" documented here... http://colocsbar.blogspot.fr/2014/01/crosstool-ng-1190-et-make-40.html
> > (thought I changed the make version test to test for 4.* rather than 4.0*)
> >
> > Once I had crosstool-ng I was able to run through a build.  Using default config it failed at wanpipe, but as I don't normally compile that in my custom build I just went and applied my mods to .config so as not to compile that. Build then completed.
> >
> > I have not attempted to run it yet, but the build completed.
> >
> > David
> >
> > On Wed, May 13, 2015 at 9:54 AM, Lonnie Abelbeck <li...@lo...> wrote:
> > Update:
> >
> > The read-only eglibc SVN repository is now working again, having been moved to Linux Foundation systems, thanks to Michael Halstead.
> >
> > I'm thinking we should continue with our eglibc fix of hosting our own "eglibc-2_18.tar.bz2" to keep things as predictable as possible.
> >
> > Thanks to Joseph S. Myers and Michael Halstead getting the eglibc SVN moved and running again.
> >
> > Lonnie
> >
> >
> > On May 7, 2015, at 8:43 PM, Lonnie Abelbeck <li...@lo...> wrote:
> >
> > > Hi Devs,
> > >
> > > Recently Martin Harriss built his own custom AstLinux image from source using the SVN, and in the process he reported the svn server at eglibc.org is not working, as such "ct-ng build" fails to download eglibc-2_18.
> > >
> > > As you may know, eglibc development has stopped and they recommend switching back to glibc, but with a perfectly good and smaller eglibc-2_18 there is no reason not to continue using it in AstLinux.  Unfortunately the eglibc.org svn server needs restarting and I have not been able to contact any of the previous developers.
> > >
> > > So, crosstool-ng uses 'svn' at svn.eglibc.org to extract the needed files and then creates a tarball "eglibc-2_18.tar.bz2".  If that tarball exists when "ct-ng build" is called it will skip the process of creating it's own via svn.
> > >
> > > As such, we now host the eglibc-2_18 tarball and install it via a user script before "ct-ng build" is called.  The README file is changed to reflect this change.
> > >
> > > crosstool-ng, tweak toolchain instructions to workaround broken svn server at eglibc.org
> > > http://sourceforge.net/p/astlinux/code/7064
> > >
> > > Since the toolchain is not normally rebuilt, thanks to Martin for reporting the issue.
> > >
> > > Lonnie
> >
> > ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> >
> > ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Happen to be creating a new build environment from scratch again, this time
on Ubuntu 15.10.  Both problems reported below still exist... need to
apt-get install libtool-bin and make version check fails.

First can be solved by updating http://doc.astlinux.org/devdoc:packages

The second would require a patch in crosstools (I just brute force edited
 the ~/source-control/ctng-1.20.0-3.2/.build/src/eglibc-2_18/configure
script to make progress).  Could maybe we copy over a patch file when the
get-files.sh script is run to install eglibc-2_18?

David

On Fri, May 15, 2015 at 10:18 AM, Lonnie Abelbeck <li...@lo...
> wrote:

> Hi David,
>
> Thanks for your report from the bleeding-edge, good info.  Ubuntu 14.04
> LTS uses make version 3.81 which works by default.
>
> >From the eglibc-2_19 source, the eglibc folks fixed this with a sledge
> hammer...
> --
>   case $ac_prog_version in
>     '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
>     3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*)
>        ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
>     *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
>
>   esac
> --
> we currently use eglibc-2_18.
>
> As for needing package "libtool-bin" the AstLinux current required
> packages include "libtool", I wonder if "libtool-bin" was separated out,
> but it would seem "libtool" should include the binary, here is a link:
>
>
> http://packages.ubuntu.com/search?suite=default&arch=i386&searchon=names&keywords=libtool
>
> Lonnie
>
> PS: Truly unfortunate that the upstream crosstool-ng chose to completely
> remove eglibc support, so crosstool-ng 1.20.0 is the last with eglibc
> support and little tweaks like this won't be included.
>
>
> On May 15, 2015, at 7:53 AM, David Kerr <Da...@Ke...> wrote:
>
> > I installed Ubuntu 15.04 64-bit this week and attempted to build
> Astlinux.  I ran into two additional problems with building crosstool-ng...
> >
> > 1) I needed to apt-get install libtool-bin
> > 2) I ran into the bug documented here...
> http://stackoverflow.com/questions/24494613/crosstool-ng-1-19-0-make-error-with-eglibc
> > and applied the "fix" documented here...
> http://colocsbar.blogspot.fr/2014/01/crosstool-ng-1190-et-make-40.html
> > (thought I changed the make version test to test for 4.* rather than
> 4.0*)
> >
> > Once I had crosstool-ng I was able to run through a build.  Using
> default config it failed at wanpipe, but as I don't normally compile that
> in my custom build I just went and applied my mods to .config so as not to
> compile that. Build then completed.
> >
> > I have not attempted to run it yet, but the build completed.
> >
> > David
> >
> > On Wed, May 13, 2015 at 9:54 AM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > Update:
> >
> > The read-only eglibc SVN repository is now working again, having been
> moved to Linux Foundation systems, thanks to Michael Halstead.
> >
> > I'm thinking we should continue with our eglibc fix of hosting our own
> "eglibc-2_18.tar.bz2" to keep things as predictable as possible.
> >
> > Thanks to Joseph S. Myers and Michael Halstead getting the eglibc SVN
> moved and running again.
> >
> > Lonnie
> >
> >
> > On May 7, 2015, at 8:43 PM, Lonnie Abelbeck <li...@lo...>
> wrote:
> >
> > > Hi Devs,
> > >
> > > Recently Martin Harriss built his own custom AstLinux image from
> source using the SVN, and in the process he reported the svn server at
> eglibc.org is not working, as such "ct-ng build" fails to download
> eglibc-2_18.
> > >
> > > As you may know, eglibc development has stopped and they recommend
> switching back to glibc, but with a perfectly good and smaller eglibc-2_18
> there is no reason not to continue using it in AstLinux.  Unfortunately the
> eglibc.org svn server needs restarting and I have not been able to
> contact any of the previous developers.
> > >
> > > So, crosstool-ng uses 'svn' at svn.eglibc.org to extract the needed
> files and then creates a tarball "eglibc-2_18.tar.bz2".  If that tarball
> exists when "ct-ng build" is called it will skip the process of creating
> it's own via svn.
> > >
> > > As such, we now host the eglibc-2_18 tarball and install it via a user
> script before "ct-ng build" is called.  The README file is changed to
> reflect this change.
> > >
> > > crosstool-ng, tweak toolchain instructions to workaround broken svn
> server at eglibc.org
> > > http://sourceforge.net/p/astlinux/code/7064
> > >
> > > Since the toolchain is not normally rebuilt, thanks to Martin for
> reporting the issue.
> > >
> > > Lonnie
> >
> >
> ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >
> >
> ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> >
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

exactly...

I figured it could get real confusing getting the matching initrd bit'ness built correctly, so there is a new file added when building "initrd.arch" which keeps track of the initrd arch flavor and automatically rebuilds the initrd.img if that does not match with the current .config arch flavor.

Lonnie

On Dec 8, 2015, at 10:24 PM, David Kerr <Da...@Ke...> wrote:

> Ah, ok.  I thought I had to manually copy over the initrd.config from the 64 bit directory.  I guess the build script takes care of that.
> 
> Thanks
> David
> 
> 
> 
> On Tue, Dec 8, 2015 at 11:04 PM, Lonnie Abelbeck <li...@lo...> wrote:
> Hi David,
> 
> The build engine build.astlinux.org would have to modified if we moved files around, prefer to leave the placement as is.
> 
> You should never modify the initrd.config file, only the .config is to be changed to your liking, so if you want x86_64 Asterisk 11...
> 
> ----
> cp x86_64-configs/astlinux-ast11.config .config
> (tweak if desired)
> 
> rm -rf output
> 
> ./scripts/build genx86_64-serial
> ----
> That's it.  The initrd is automatically built to match.
> 
> Be sure to place the resulting build into a "genx86_64-serial" directory in your private repository.  Don't mix-up what you built and where it goes.
> 
> Lonnie
> 
> http://doc.astlinux.org/devdoc:documentation
> 
> 
> On Dec 8, 2015, at 9:34 PM, David Kerr <Da...@Ke...> wrote:
> 
> > I'm starting to explore 64 bit build and notice that the .config files for 64 bit have been placed in a subdirectory x86_64-configs. I think we should move the 32-bit config files into a corresponding directory rather than leaving them in the top level directory.
> >
> > In particular I'm thinking of initrd.config which is a SVN file (whereas .config is not) so copying over the 64-bit version then makes that a modified file as far as SVN is concerned.  But it would be overall cleaner and make things less susceptible to error.
> >
> > David
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Ah, ok.  I thought I had to manually copy over the initrd.config from the
64 bit directory.  I guess the build script takes care of that.

Thanks
David



On Tue, Dec 8, 2015 at 11:04 PM, Lonnie Abelbeck <li...@lo...>
wrote:

> Hi David,
>
> The build engine build.astlinux.org would have to modified if we moved
> files around, prefer to leave the placement as is.
>
> You should never modify the initrd.config file, only the .config is to be
> changed to your liking, so if you want x86_64 Asterisk 11...
>
> ----
> cp x86_64-configs/astlinux-ast11.config .config
> (tweak if desired)
>
> rm -rf output
>
> ./scripts/build genx86_64-serial
> ----
> That's it.  The initrd is automatically built to match.
>
> Be sure to place the resulting build into a "genx86_64-serial" directory
> in your private repository.  Don't mix-up what you built and where it goes.
>
> Lonnie
>
> http://doc.astlinux.org/devdoc:documentation
>
>
> On Dec 8, 2015, at 9:34 PM, David Kerr <Da...@Ke...> wrote:
>
> > I'm starting to explore 64 bit build and notice that the .config files
> for 64 bit have been placed in a subdirectory x86_64-configs. I think we
> should move the 32-bit config files into a corresponding directory rather
> than leaving them in the top level directory.
> >
> > In particular I'm thinking of initrd.config which is a SVN file (whereas
> .config is not) so copying over the 64-bit version then makes that a
> modified file as far as SVN is concerned.  But it would be overall cleaner
> and make things less susceptible to error.
> >
> > David
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

Hi David,

The build engine build.astlinux.org would have to modified if we moved files around, prefer to leave the placement as is.

You should never modify the initrd.config file, only the .config is to be changed to your liking, so if you want x86_64 Asterisk 11...

----
cp x86_64-configs/astlinux-ast11.config .config
(tweak if desired)

rm -rf output

./scripts/build genx86_64-serial
----
That's it.  The initrd is automatically built to match.

Be sure to place the resulting build into a "genx86_64-serial" directory in your private repository.  Don't mix-up what you built and where it goes.

Lonnie

http://doc.astlinux.org/devdoc:documentation


On Dec 8, 2015, at 9:34 PM, David Kerr <Da...@Ke...> wrote:

> I'm starting to explore 64 bit build and notice that the .config files for 64 bit have been placed in a subdirectory x86_64-configs. I think we should move the 32-bit config files into a corresponding directory rather than leaving them in the top level directory.
> 
> In particular I'm thinking of initrd.config which is a SVN file (whereas .config is not) so copying over the 64-bit version then makes that a modified file as far as SVN is concerned.  But it would be overall cleaner and make things less susceptible to error.
> 
> David
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Hi David,

Much appreciated giving this a go...

I think it is a good idea to build both, just to have, but you only need x86_64 if you are only building "genx86_64-serial" images.

You can skip the 32-bit build part, but be sure you still run the script...
--
sh ~/astlinux/1.0/crosstool-ng-src/get-files.sh
--

Each "ct-ng build" generates a separate, parallel toolchain.

Lonnie


On Dec 8, 2015, at 9:36 PM, David Kerr <Da...@Ke...> wrote:

> When creating crosstools for 64-bit is it first necessary to create the 32-bit version?  The step-by-step instructions take me through building 32-bit first then copy over new .config and build 64-bit.
> 
> Thanks
> David
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

When creating crosstools for 64-bit is it first necessary to create the
32-bit version?  The step-by-step instructions take me through building
32-bit first then copy over new .config and build 64-bit.

Thanks
David