Any interest in 64bit x86_64 port?

[Terry Chan]

Great work!

devfs is SAFE to use in kernel 2.4.x and the Lunar ISOs have been using
devfs on all the 2.4.x kernels we've supported including 2.4.20, 2.4.22,
2.4.23.

When your iso is available for testing let us know and we can upload it
to the Lunar web server for hosting/mirroring and greater downloading
bandwidth.

Some of the changes you mentioned have been incorporated into more recent
lunar ISOs.  The latest testing ISO is available at
http://www.lunar-linux.org/lunar/testing/lunar-20031210-1.iso.bz2.

The directory structures have changed a bit compared to the 1.3 iso you
used as your starting base.

You'll probably need to use a more recent iso and recompile and fix
scripts again.  The 20031210-1 iso will eventually become the 1.3.3 iso.

Terry Chan
-----------------------------------------------------------
On Thu, Dec 18, 2003 at 12:49:17PM -0800, Mike Marion wrote:
> Like Subj says... wondering if there's any interest in a lunar
> opteron/athlon64 port?
> 
> I've actually done a complete port of the lunar-1.3 iso to 64bit and have it
> working on my home box:
> 
> mmarion @ opteron 4 [~]% uname -a
> Linux opteron 2.4.23 #1 Sat Dec 13 16:51:31 PST 2003 x86_64 unknown
> mmarion @ opteron 5 [~]% head /etc/motd
> 
> Welcome to Lunar Linux 1.3 (mouse X).
> 
> See man lfirsttime ASAP.
> 
> Also See man pages for lunar, moonbase, lin and lrm.
> 
> Please remember that the ISO is not a full featured
> working system. Add your favorite tools and programs
> via lin mechanism.
> ====
> 
> I did some modifications to the lunar.install script on the iso so that it
> makes /dev/discs links back to the real /dev/[s|h]d* devices since devfs isn't
> safe to use in the 2.4 kernel (don't know about 2.6 yet).   The change I did
> looks at dmesg output for the partition checks, so if you partition the disk,
> you'll have to reboot again to get the part links in the /dev/discs directory,
> but from there on it's the same as a 32bit host.
> 
> I also had to make modifications to /var/lib/lunar/functions/optimize.lunar
> /var/lib/lunar/menu/optimize.menu to add in opteron info.  The only flag I
> added for opteron systems if -fPIC since autoconf seems to miss setting that a
> lot.  
> 
> Many lunar packages install just fine using lin.. a few will fail saying
> x86_64-pc-linux-gnu is unknown, adding --host=i686 in the BUILD file for that
> package seems to work just fine (should unless odd asm or pointer code is used
> I would suppose).  
> 
> Some moonbase changes I had to make were...
> glibc: Changed BUILD script to use /lib64 instead of /lib when it does the
> library replacements after a successful build.
> 
> xfree86: Had to build dev version 4.3.99.901 to get a working xfree, and found
> out the hard way that every library in it needs -fPIC flag, except for the
> font areas.. -fPIC breaks the font stuff.
> 
> The changes I made to my moonbase require that I don't update the moonbase
> yet... it'll break my stuff.   Shouldn't be too hard to add in some case
> and/or if statements to check for x86_64 arch eventually instead though.
> 
> A few things won't build 64bit at all... lilo being one important one, so my
> iso keeps the 32bit version and has the required 32bit libraries still
> installed in /lib.  
> 
> Hoping I can get my iso image online soon so anyone that wants to test can...
> can't just drop on my home box for fear of saturating my cable model uplink.
> Due to having some 64 and 32bit libraries, my iso is much larger... 500meg vs
> 250.  I also had to install Linux-PAM on the iso as the shadow package breaks
> in 64bit without it: you can login initial time without password after
> install, but any login after that results in seg fault.. but only on consoles,
> remote login via sshd is ok... go figure.  Having Linux-PAM there and shadow
> linked to it seems to work.  Could be an issue with my box for all I know...
> Opteron 144, Asus SK8N mobo.  
> 
> I currently find that I have to build my kernel without any APIC support (word
> from an AMD tech we had at work recently is that the nforce3 chipset wrongly
> reports APIC ability), and several drivers disabled... aic7* drivers, IBM
> ServeRAID and PCI hotplug.
> 
> More info to follow if/when I think of it... and if people are interested.
> 
> -- 
> Mike Marion-Unix SysAdmin/Staff Engineer-http://www.miguelito.org
> "If the government were to set technology standards," said Richard Diamond, a
> spokesman for House Majority Leader Dick Armey, R-Texas, "we'd still be using
> eight-track tapes right now."  ==> Article about the SSSCA/CBDTPA
> http://www.foxnews.com/story/0,2933,48567,00.html
> 
> 
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> 
> _______________________________________________
> lunar mailing list
> lunar at lunar-linux.org
> http://dbguin.lunar-linux.org/mailman/listinfo/lunar