Sparc Live CD

[Eric Nichols]

I would like to build a live CD for my Ultra 2 that will act as a static web
server.  Basically everything would work in memory.  The perfect secure
server.

However I have having difficulty trying to figure out how to build one using
debian tools.  dfsbuild looked like the obvious choice but it does not support
sparc.  I talked with the maintainer and the reason that sparc is not support
is that is he simply does not have the hardware but was willing to accept
patches to the project.

I honestly am just an end-user in this endeavor but am willing to test anything.
Can anyone assist?
Thanks
Eric


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Sparc Live CD

[Martin]

On Tue, 2008-06-03 at 20:51 -0400, Eric Nichols wrote:
 I would like to build a live CD for my Ultra 2 that will act as a static web
 server.  Basically everything would work in memory.  The perfect secure
 server.
For easy of maintenance I would have thought it would be worth exporting
(read only) some of the filesystem from another machine.  That way
updating the website / reconfiguring the web server can be done by
simply editing a file - you don't need to burn a new CD.  Also you may
wish to log to a network filesystem or set up syslog to log to another
machine.

If you have a look at the LSB you will see which parts of the filesystem
have to be writable and which can be mounted read only.

 However I have having difficulty trying to figure out how to build one using
 debian tools.  dfsbuild looked like the obvious choice but it does not support
 sparc.  I talked with the maintainer and the reason that sparc is not support
 is that is he simply does not have the hardware but was willing to accept
 patches to the project.
 
 I honestly am just an end-user in this endeavor but am willing to test 
 anything.
 Can anyone assist?
Given that the install CDs are (basically) minimal live CDs, thus is
probably just a case of building things, little to no actual 'porting'
is likely required.  You're probably best off picking a script /
program / system that can either build an image from a running system or
from debian packages.  I believe a number of these exist, a few years
ago I the knoppix one was quite highly rated IIRC.

Beyond that - dive in and give it a go.  You are more likely to be able
to find material / documentation / assistance for any detailed problems
you encounter, then you are to be able to find general help.

One possibility would be to first build the image you want for x86
(documenting in detail what you did) and then try the same thing for
SPARC.  This should help separate problems with the tools from
portability issues.

HTH

Cheers,
 - Martin



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

RE: Netra X1 install problem/oddity

[Gary W. Smith]

Good call.  I found it in the initrd.img file.  So I removed that
module, saved, and it booted just fine with network.  I am getting some
errors on the TX side according to ifconfig BUT everything appears to be
working fine on this box.  The stats below are lying as the network
interface is sending and receiving (did 1 byte pings for a couple
seconds) and it but no traffic is being logged.  I assume this is a
driver issue and not really anything to do with the hardware but if you
have any ideas of how to fix or if it's even important, please let me
know.

Anyway, it's working now so I'll start to play with the machines.
Thanks for the help and I'm sure that I'll ask for more later

debian:~# ifconfig
eth1  Link encap:Ethernet  HWaddr 00:03:BA:0C:38:D5  
  inet addr:10.0.16.113  Bcast:10.0.16.255  Mask:255.255.255.0
  inet6 addr: fe80::203:baff:fe0c:38d5/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:164 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:112 dropped:0 overruns:0 carrier:112
  collisions:0 txqueuelen:1000 
  RX bytes:61864 (60.4 KiB)  TX bytes:0 (0.0 b)
  Interrupt:9 

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:8 errors:0 dropped:0 overruns:0 frame:0
  TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:560 (560.0 b)  TX bytes:560 (560.0 b)


 -Original Message-
 From: Richard Mortimer [mailto:[EMAIL PROTECTED]
 Sent: Monday, June 02, 2008 4:07 PM
 To: Gary W. Smith
 Cc: Steve Haavik; Martin Habets; debian-sparc@lists.debian.org
 Subject: RE: Netra X1 install problem/oddity
 
 Hello,
 
 I'm working from memory here but I vaguely remember having a similar
 problem some time ago. I seem to remember that the kernel module and
 blacklist files are built into the initrd/initramfs files. I think
that
 you need to regenerate that to get the changes to work during boot.
 
 I cannot easily get access to my X1 at the moment so I cannot check
 myself - sorry.
 
 Richard
 
 On Mon, 2008-06-02 at 07:53 -0700, Gary W. Smith wrote:
  Steve,
 
  Thanks for the follow up on this.  I did the echo trick but it still
  didn't work.  I also did remove dmfe.ko and then issue depmod -a to
  rebuild the catalog but it still loads the module.  It seems like
 this
  module is in the kernel or something.  Anyway, I'll play around with
  it a little more.  In a worse case scenario, I'll script something
on
  startup.
 
  Gary
 
 
 
 __
  From: Steve Haavik [mailto:[EMAIL PROTECTED]
  Sent: Mon 6/2/2008 4:25 AM
  To: Gary W. Smith
  Cc: Martin Habets; debian-sparc@lists.debian.org
  Subject: RE: Netra X1 install problem/oddity
 
 
  I've still got a few Netra X1's running.
  From my notes:
 
  First thing after booting the tftpimage jump to a shell and:
 
  modprobe -r dmfe
  modprobe -r tulip
  modprobe tulip
 
  Then you can continue the install.
 
  After it reboots to the new system:
 
  echo 'blacklist dmfe'  /etc/modprobe.d/dmfe-blacklist
 
  If all else fails you could track down and delete dmfe.ko but you'd
  have
  to remember to do that after every kernel upgrade. The above method
  worked
  fine on my production boxes.
 
 
 
 --
 Richard Mortimer [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]