On Wednesday 21 April 2010 09:02:34 am Rafal Maszkowski wrote:
> On Wed, Apr 21, 2010 at 07:35:48AM -0500, Dennis Gilmore wrote:
> > On Wednesday 21 April 2010 05:05:45 am Rafal Maszkowski wrote:
> ...
>
> > > I have adapted a grub2 to example with a hope that it may work:
> > > # Timeout for menu
> > > set timeout=10
> > > # Set default boot entry as Entry 0
> > > set default=0
> > > # Entry 0 - Load Linux kernel
> > > menuentry "My Linux Kernel on (hd0,1)" {
> > >
> > > set root=(hd0,1)
> > > linux /vmlinuz-2.6.32.9-72.fc12.sparc64 root=LABEL=/
> > > initrd /initramfs-2.6.32.9-72.fc12.sparc64.img
> > >
> > > }
> > > If it does not work I can use silo instead (with the needed sparc32
> > > libraries installed).
> > > Burning questions:
> > > - does not grub2 make sense at all in these circumstances?
> >
> > ive not once gotten a successful boot with grub2
>
> I will try it once or twice befove giving up and using silo.
> Is the configuration above theoretically correct? I will use /dev/sda1
> for /boot .
grub2 is designed to dynamically build the config. and last i tried that
dynamic building did not work at all on fedora as the grub2 folks made
assumptions about how to work out disks that changed. at a rough glance it
looks like its likely right.
> > > - should I expect problems with silo? It will have all the necessary
> > >
> > > 32-bits libraries in place.
> >
> > silo only needs the 32 bit glibc installed and only then to actually run
> > the silo command there would be no problems
>
> I expected it to be so.
>
> > > - are there any fundamental problems with the 64-bits userspace or the
> > >
> > > main problem is that nobody tested it yet?
> >
> > No one has tested it. binaries are bigger, which in turn means it takes
> > longer to load and run, uses more ram, and you do not gain additional
> > cpu features by doing it, x86_64 you gain access to additional
> > registers and other thinsg that make it worthwhile. sparc64 you don't
>
> So actually it does not make any sense to keep development/sparc64 tree?
> Anyway switching between 64 and 32 bits with use of yum is not very
> difficult. Maybe I will do it once the machine is running. I am copying
> my sparc64 tree on my new logical volumes (on top of RAID6 and RAID5
> MDs).
We build the sparc64 tree because we have to. to build anything 64 bit we
have to build everything 64 bit. if you need access to more than 4gb ram per
process. say a big database then the 64 bit versions will come in handy.
thats really the only place you get a win with 64 bit binaries.
Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ sparc mailing list sparc@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/sparc
