<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Not sure if a container would work on my 18.04 64bit desktop where I chroot into a CentOS 5 32bit directory to compile firmware for a i586 small pc-like device.
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Before the chroot I do bind mounts of dev, proc, etc. The script that mounts the bind directories also does a chroot into the tree to start sshd on a differnt port. When I'm eady to do wrk I' open up a terminal and ssh -P <port> to my desktop. If tmux was
not running int the instance it is started and I start working on the code. It works really well, but the tree is 32bit.
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
There is also one unique driver involved. It fakes ther kernel interfaces of uname and is useful for packages that refuse to use /bin/uname for architecture info. Google ''uname_hack' if intrigued.
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
I do an insmod at the start of a full build and then rmmod at the end. I don't even try to do any apt-get functions ont he desktop because I imagine ii586 coming back from 'uname -m' would cause all sorts of problems.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
I've also been using the /opt/name system since Fedora Core 2. I don't think container were around then. I have experimented briefly with them and they are cool. I'm upgrading all the embedded devices to 54bit hardware and will use a CEntOS 8 base for development.
Using a container to host that on my 18.04 desktop should work fine. <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
The web based J2EE system uses the /opt/name system. Development I do on my desktop uses a tared up install of CentOS 5 that I chroot into. To create the tared up root ot CentOS I would install the version of CEntOS required in vmplayer, do a rsync of ssh
from the host to copy / down to my dfesktop, delete the vmplayer guest I had just created because I don't need it now, and chroot into /opt/deve/CEntOS-5 to mount the binds and start SSH on different port, and then ssh -P # 127.0.0.1 and begin installing things
via yum like gcc, etc. </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
The firmware build in the C5 root does pull some things from / for the firmware. /lib/libc is an example, but OpenSSL is built and installed in the firmware instead. Years ago, it was also copied from /usr/lib. When I move to 64bit my goal is to build the
firmware from the ground up, like LFS. The GCC used to build OpenSSL would be the GCC that was built specifically for the system. At that point, I don't think C8 would have any value since this can be done on any modern 64bit disti since nothing will be
pulled from the build host. In the C5 system, I gcc that is in /usr/bin/gcc. I created my own package management system that removes packages from the firmware template directory before a package file for writing to the devices drive is created. The firmware
template directory is over 1G before running the script that purges doc and devel pacakges. It is 250M after that and then mksquashfs reduces it down to 50M. A full build of the 64bit system using the LFS method could simply start with what was created in
/tools, chroot into the template, build everything required, including gcc and friends. Copt the LFS ./ to a temp directory, remove everything not needed on the device (gcc, make, include, etc). and then end up with a 50M squashfs image.
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
To avoid confusion, I've talked about two pacakges. The one that prompted my original email was about our web based J2EE system that interfaces with "embedded" Linux devices. The devices are really small PCs with either flash or SSD, but are treated as if
they were embedded. /etc is built on every boot from a custom config file that is created by custom config commands via CLI, web interface, XML-RPC, etc. 1000 devices in the field require that they all be exact so that if one acts up, we simply replace it
and load the config from a web site, if we had backed it up via 'save cloud'. I don;t have the patience to manage 1000 CentOS 5 installatiions that will inevitibly be 1000 unique installations.
<span id="🙂">🙂</span><br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Ale <ale-bounces@ale.org> on behalf of DJ-Pfulio via Ale <ale@ale.org><br>
<b>Sent:</b> Wednesday, September 30, 2020 6:31 PM<br>
<b>To:</b> ale@ale.org <ale@ale.org><br>
<b>Subject:</b> Re: [ale] Compiling MySQL 8.0.17 on CentOS 8 on a DigitalOcean VM</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On 9/30/20 6:22 PM, Chris Fowler via Ale wrote:<br>
> I'm working on upgrading some software and I've been deploying this<br>
> software for over 15yrs similar to the SNAPs method. I don't like<br>
> SNAP because too many loop devices can be used up. I put everything<br>
> in /opt/<name> and then compile packages and put there. This method<br>
> works very well because in a pinch I can tar up that directory on<br>
> CentOS 5.X and run on CentOS 6.X during a simple upgrade.<br>
<br>
Cough ... Linux Container ... cough.<br>
_______________________________________________<br>
Ale mailing list<br>
Ale@ale.org<br>
<a href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a><br>
</div>
</span></font></div>
</body>
</html>