[Fedora-sparc] SPARC Status update

Upgrade from Aurora 2.99 - massive fail.

Install fresh on a U60 - massive fail (details can be provided).

Arg.

I don't have any other spare machines to waste on this - to be honest all the sparc64 machines I
look after have been running OpenBSD or Debian (or even Solaris) for several years now, whereas
Aurora has been - let's face it - essentially a dead, experimental project for too long. Way too long.

Guys, I love Aurora but seriously you're going to have to give me a good reason to not just utterly
dump it at this point.

The web site is dead. There is no documentation worth anything. You seem to have all switched to IRC
(which must be great for all the 12 year olds out there hacking Sparc/Linux...) instead of using a
perfectly good mailing list which all of us normal adults can check.

Best regards, and thanks again to all the hardworking devs. I will keep shadowing the developments
and testing new systems, but I have officially given up at this point of ever having an Aurora
machine in anything but unstable/dev/testing/broken ever again.

I hate to say it, but Debian have (multiple) perfectly fine distro versions for Sparc64. I recommend
you use them. Fedora is utterly useless for anyone who doesn't have stupid x86/x86_64/PPC boxes.

God, I just re-read this and it seems like a terrible flame but I hate because I love. Please,
please unfuck Aurora so I can actually use it again.

Cheers,

mat
------------------
***@fsck.no-ip.org
www.fsck.no-ip.org
PGPKEY: 0x5F7549AE

Post by Dennis Gilmore
Forwarding here to make sure those following this list still see it
---------- Forwarded Message ----------
Subject: [Fedora-sparc] SPARC Status update
Date: Sunday 07 March 2010, 07:03:14 pm
Hi all,
Ive pushed a fedora 12 install tree to
http://secondary.fedoraproject.org/pub/fedora-secondary/releases/test/12-
Alpha/Fedora/sparc/
which should also be on all the mirrors.
https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=sparc
will give you the list of mirrors.
Please test and report issues here.
To partition your system you need to break to a shell. either in rescue mode
or via a tty in anaconda as soon as the install starts. you should then do a
manual partition in anaconda and allocate mount point and file systems to the
partitions you have made. formatting works just fine, creating the partitions
doesn't.
some big fat warnings
Partitioning in anaconda does not work.
upgrades from previous releases are completely untested.
prelink is broken and needs to be disabled post install
selinux does not work in enforcing mode
you will need to use vnc for install (you need to select manual partitioning)
network booting the installer does not work and likely will not be supported
at all (the images are way bigger than OBP allows. we need some new solution)
The UUID issue reported on this list seems to be solely due to artifacts left
over from lvm previously being used on an install.
i've probably missed things.
Dennis

Mike Brown

2010-04-08 13:25:27 UTC

I agree to this post might be time for a face lift and to re start the
project from scratch if Aurora is going to continue in the operating
system race
three legged dogs can't win hourse races

Post by mat
Upgrade from Aurora 2.99 - massive fail.
Install fresh on a U60 - massive fail (details can be provided).
Arg.
I don't have any other spare machines to waste on this - to be honest all
the sparc64 machines I look after have been running OpenBSD or Debian (or
even Solaris) for several years now, whereas Aurora has been - let's face it
- essentially a dead, experimental project for too long. Way too long.
Guys, I love Aurora but seriously you're going to have to give me a good
reason to not just utterly dump it at this point.
The web site is dead. There is no documentation worth anything. You seem to
have all switched to IRC (which must be great for all the 12 year olds out
there hacking Sparc/Linux...) instead of using a perfectly good mailing list
which all of us normal adults can check.
Best regards, and thanks again to all the hardworking devs. I will keep
shadowing the developments and testing new systems, but I have officially
given up at this point of ever having an Aurora machine in anything but
unstable/dev/testing/broken ever again.
I hate to say it, but Debian have (multiple) perfectly fine distro versions
for Sparc64. I recommend you use them. Fedora is utterly useless for anyone
who doesn't have stupid x86/x86_64/PPC boxes.
God, I just re-read this and it seems like a terrible flame but I hate
because I love. Please, please unfuck Aurora so I can actually use it again.
Cheers,
mat
------------------
www.fsck.no-ip.org
PGPKEY: 0x5F7549AE

_______________________________________________
Aurora-sparc-user mailing list
http://lists.auroralinux.org/mailman/listinfo/aurora-sparc-user
Aurora FAQ: http://www.ecs.soton.ac.uk/~mas01r/aurorafaq.html

Tom "spot" Callaway

2010-04-08 12:30:13 UTC

Post by mat
God, I just re-read this and it seems like a terrible flame but I hate
because I love. Please, please unfuck Aurora so I can actually use it
again.

You're right Mat. We should just retire Aurora. All of our work lately
has been into getting a solid Fedora 12 release, and we're really,
really close. (I did an F-12 GUI install on a U10, and Dennis swears he
has auto-partitioning working.)

The original reason I created Aurora was because Red Hat Linux dropped
support for SPARC, and I couldn't legally call it "Red Hat Linux"
anymore. Now, with Fedora, we have a solid infrastructure for doing a
architecture port and permission to use the name.

Aurora is now Fedora SPARC.

We'll take steps to make that clear in the old Aurora website, and we'll
be closing up the mailing lists here soon. (The archives will stick
around indefinitely, thanks to our generous hosting provider.)

Fedora SPARC has a new mailing list, with some recent activity even:
https://admin.fedoraproject.org/mailman/listinfo/sparc

And hey, even if you're not a 12 year old (I haven't been 12 in almost
20 years), we are talking on IRC about our work, and you're welcome to
join us on #fedora-sparc. I'll try to post more regularly to the
fedora-sparc mailing list, and guilt Dennis into doing it too.

Give our latest builds a try:

Download the ISO from here:
http://secondary.fedoraproject.org/pub/fedora-secondary/releases/test/12-Alpha/Fedora/sparc/iso/

Then, append "updates=http://sparc.koji.fedoraproject.org/updates.img"
to your install (assuming you want more functional partitioning).

The plan is to get a very solid Beta out once we have most of the key
packages rebuilding, get some testing feedback, then mark it as Fedora
12 and move on to 13.

****
To everyone who helped us out in the Aurora SPARC Linux Project, thank
you. We outlasted Sun (barely), and we hope you'll come join us in
Fedora SPARC. Same core people, same craziness, (some of the same bugs),
and same fun. :)

~spot

T. Ribbrock

2010-04-08 13:56:44 UTC

Post by mat
God, I just re-read this and it seems like a terrible flame but I hate
because I love. Please, please unfuck Aurora so I can actually use it
again.

[...]

Thanks Tom for that clarification - in a way,that was overdue.
Admittedly, I didn't follow Aurora too closely over the past years
mostly due to personal time constraints, but given the slow decline of
the aurora mailing lists, it sure looked as if the whole project was
completely doomed. Heck, I even began dabbling with Ubuntu Sparc for
that very reason... ;-)
I haven't decided whether I'll give Fedora Sparc a shot yet (I've been
playing more with SGI machines recently) - somehow, Fedora never reached
the same level of "feeling at home" the "old" Red Hat had (up until
RH7.3/8/9) for me. In that regard, Aurora was a very good follow-up,
which is one of the reasons I liked it so much.

On the other hand, Linux on Sparc just got a whole lot more interesting
for hobbyists given the recent license changes that Oracle announced
(or better: Failed to properly announce) for Solaris - and the fact the
OpenSolaris does not come with frame buffer support for the older
machines does not help, either. So, I might start experimenting again at
some point... ;-)

I'd also agree with mat on mailing list vs. IRC - personally, I find the
former much more practical for the type of communication I'm involved in
as a user. Nonetheless, I can imaginge that the more online way of IRC
has advantages when developing.

Post by Tom "spot" Callaway
We'll take steps to make that clear in the old Aurora website, and we'll
be closing up the mailing lists here soon. (The archives will stick
around indefinitely, thanks to our generous hosting provider.)

Please do - every now and then I still meet people asking about Aurora
and providing clear pointers on the website would be very helpful.

Post by Tom "spot" Callaway
https://admin.fedoraproject.org/mailman/listinfo/sparc

Thanks - being curious as I am, I might just follow that one... ;-)

[...]

Post by Tom "spot" Callaway
****
To everyone who helped us out in the Aurora SPARC Linux Project, thank
you. We outlasted Sun (barely), and we hope you'll come join us in
Fedora SPARC. Same core people, same craziness, (some of the same bugs),
and same fun. :)

Well, I would like to add my thanks to this list - it certainly was fun
at the time! Special thanks to you Tom and the other who initiated this!

Regards,

Thomas

--
-----------------------------------------------------------------------------
Thomas Ribbrock http://www.ribbrock.org
"You have to live on the edge of reality - to make your dreams come true!"

mat

2010-04-13 16:36:17 UTC

Oops, looks like I broke the first rule of mailing list postings last week and sent a message whilst
drinking and annoyed... *facepalm*

Sorry about that everyone, and thanks for the sane and helpful replies. Really I deserved a proper
flaming for that last rant so I think the least I could do is jump back in to some testing, eh?

I'd already been using the latest fc12 test install tree with no luck. Appending the image from koji
at boot did indeed give an apparently fully functional partitioner this time (previously I had been
escaping to shell to fdisk manually and running the install over VNC) and let me complete a regular
GUI install on my test machine, an U60 SMP box. I tried a minimal install as well as a default
install with Desktop Environment, etc, and disabled prelink as per usual before reboot.

There is some progress but a regular boot still dies with *lots* of libc.so.6 segment map errors.
Single user mode does equally badly but does dump me to a prompt eventually with a read-only
filesystem that I can't remount rw. And that's as far as I've got with limited time for testing.

So, questions:

Will this still theoretically run on an old ultra1? They are about the only other spare machines I
have lying around apart from the U60 to test with at the moment.

Are there anymore obvious 'gotchas' I'm missing?

Do I cancel the old Aurora mailing list now, and use the Fedora-Sparc list instead?

And finally, I've been digging around sparc.koji.fedoraproject.org for a while now, but it's
difficult to see how (or even if) it can be used as a resource by testers like me. Obviously it's
not 'repo-ised' although I can download individual builds on a RPM by RPM basis. Am I missing
something here as well, or is it simply the developers automated build tree? I *do* know this one is
a stupid question :)

Other than that, thanks again developers (especially Spot) and I'm happy to see this project still
alive and kicking. Hopefully under the auspices of Fedora proper it has a long future ahead of it
and I look forward to a FC12/13 working build before too long.

Aurora is dead, long live Aurora!

Cheers,

mat
------------------
***@fsck.no-ip.org
www.fsck.no-ip.org
PGPKEY: 0x5F7549AE

Tom "spot" Callaway

2010-04-13 16:55:53 UTC

Post by mat
Oops, looks like I broke the first rule of mailing list postings last
week and sent a message whilst drinking and annoyed... *facepalm*
Sorry about that everyone, and thanks for the sane and helpful replies.
Really I deserved a proper flaming for that last rant so I think the
least I could do is jump back in to some testing, eh?
I'd already been using the latest fc12 test install tree with no luck.
Appending the image from koji at boot did indeed give an apparently
fully functional partitioner this time (previously I had been escaping
to shell to fdisk manually and running the install over VNC) and let me
complete a regular GUI install on my test machine, an U60 SMP box. I
tried a minimal install as well as a default install with Desktop
Environment, etc, and disabled prelink as per usual before reboot.
There is some progress but a regular boot still dies with *lots* of
libc.so.6 segment map errors. Single user mode does equally badly but
does dump me to a prompt eventually with a read-only filesystem that I
can't remount rw. And that's as far as I've got with limited time for
testing.

I'm pretty sure this is the old prelink bug rearing its ugly head again.
Booting into Rescue Mode and running:
prelink -ua && rpm -e prelink

Should do the trick. I think we've got it fixed with the latest update.

~spot

Dennis Gilmore

2010-04-13 17:47:42 UTC

I'm pretty sure this is the old prelink bug rearing its ugly head again.
prelink -ua && rpm -e prelink
Should do the trick. I think we've got it fixed with the latest update.

newer builds have prelink disabled by default. I need to respin anaconda and
spin up some beta isos. the issue could also be selinux preventing things
from running. there is a kernel to fix it which will land in the next compose.

Dennis

Rafal Maszkowski

2010-04-17 10:59:28 UTC

I'm pretty sure this is the old prelink bug rearing its ugly head again.
prelink -ua && rpm -e prelink
Should do the trick. I think we've got it fixed with the latest update.

I still run Aurora corresponding to fedora 9 on one of the servers
(E450). After old clamav support drop I feel that I am finally forced to
upgrade, maybe on Monday.

The question is if I should use the 12-Alpha or development version.
When do you plan to upload new packages?

Do you plan to compile updates after v. 12 is released? Or maybe they
are included already in the devel tree?

I used to use the 32-bit userspace but the 64-bit one works quite nice
on Intel-like machines so maybe I will use sparc64 in this new install.
I managed to upgrade from f6 to f9 without big troubles but a jump do
f11 or f12 is to big so I will make a fresh install. I will not be
testing any ISO images, I will make a bootstrap tree on Intel f12
machine.

R.

--
Uniwersytet katolicki to oksymoron udający tautologię.

Dennis Gilmore

2010-04-21 01:58:23 UTC

I'm pretty sure this is the old prelink bug rearing its ugly head again.
prelink -ua && rpm -e prelink
Should do the trick. I think we've got it fixed with the latest update.

newer builds have prelink disabled by default. I need to respin anaconda
and spin up some beta isos. the issue could also be selinux preventing
things from running. there is a kernel to fix it which will land in the
next compose.

I did a Beta compose today, ive done one test install of it. I need to do a
couple more

Post by Rafal Maszkowski
Do you plan to compile updates after v. 12 is released? Or maybe they
are included already in the devel tree?

Yes updates are planned. currently quite a few of them are compiled. Im in the
process of signing the ones built so they can be pushed out

Post by Rafal Maszkowski
I used to use the 32-bit userspace but the 64-bit one works quite nice
on Intel-like machines so maybe I will use sparc64 in this new install.
I managed to upgrade from f6 to f9 without big troubles but a jump do
f11 or f12 is to big so I will make a fresh install. I will not be
testing any ISO images, I will make a bootstrap tree on Intel f12
machine.

We nly support 32 bit userland and 64 bit kernel. I do not think you will
successfully be able to do what your attempting the %post scripts in the
packages will not be able to run. and you wont be able to run silo to install
the bootloader. you could likely use mock or febootstrap to setup a new
environment from your existing install. All of which is untested.

Dennis

Rafal Maszkowski

2010-04-21 10:05:45 UTC

I'm pretty sure this is the old prelink bug rearing its ugly head again.
prelink -ua && rpm -e prelink
Should do the trick. I think we've got it fixed with the latest update.

newer builds have prelink disabled by default. I need to respin anaconda
and spin up some beta isos. the issue could also be selinux preventing
things from running. there is a kernel to fix it which will land in the
next compose.

I did a Beta compose today, ive done one test install of it. I need to do a
couple more

I will try to update to this version when it appears on the servers.

I have created a bootstrap tree on a Fedora 12 x86_64 machine (just rpm
-r ..., nothing more sophisticated). It did not work well, there were
problems with the %post scripts but I got most of the packages installed
somehow.

I moved this tree into a Sparc64 Fedora 9 machine and used it to install
(rpm -r ... again) the next stage tree - this time without many
problems. Why should not the %post scripts run in this case? It looked
like there were at least not complaining any more.

My plan is:
- boot from the Fedora-12-Alpha-sparc-netinst.iso CD in rescue mode (I
hope there is such)
- set up MDs and LVM volumes, copy my 2nd state sparc64 bootstrap tree
on them
- use grub2 for booting

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?
- should I expect problems with silo? It will have all the necessary
32-bits libraries in place.
- are there any fundamental problems with the 64-bits userspace or the
main problem is that nobody tested it yet?

BTW the sparc64 devel version installs smoothly except dwdiff which has
dependency problems:
dwdiff-1.5-4.fc12.sparc64 z rawhide ma problemy z rozwi�zywaniem zale�no�ci
--> Brakuj�ca zale�no��: libicui18n.so.40()(64bit) jest wymagane przez pakiet dwdiff-1.5-4.fc12.sparc64 (rawhide)
dwdiff-1.5-4.fc12.sparc64 z rawhide ma problemy z rozwi�zywaniem zale�no�ci
--> Brakuj�ca zale�no��: libicudata.so.40()(64bit) jest wymagane przez pakiet dwdiff-1.5-4.fc12.sparc64 (rawhide)
dwdiff-1.5-4.fc12.sparc64 z rawhide ma problemy z rozwi�zywaniem zale�no�ci
--> Brakuj�ca zale�no��: libicuuc.so.40()(64bit) jest wymagane przez pakiet dwdiff-1.5-4.fc12.sparc64 (rawhide)
Błąd: Brakująca zależność: libicui18n.so.40()(64bit) jest wymagane przez pakiet dwdiff-1.5-4.fc12.sparc64 (rawhide)
Błąd: Brakująca zależność: libicuuc.so.40()(64bit) jest wymagane przez pakiet dwdiff-1.5-4.fc12.sparc64 (rawhide)
Błąd: Brakująca zależność: libicudata.so.40()(64bit) jest wymagane przez pakiet dwdiff-1.5-4.fc12.sparc64 (rawhide)

R.

--
Uniwersytet katolicki to oksymoron udający tautologię.

Dennis Gilmore

2010-04-21 12:35:48 UTC

I'm pretty sure this is the old prelink bug rearing its ugly head again.
prelink -ua && rpm -e prelink
Should do the trick. I think we've got it fixed with the latest update.

newer builds have prelink disabled by default. I need to respin
anaconda and spin up some beta isos. the issue could also be
selinux preventing things from running. there is a kernel to fix it
which will land in the next compose.

I did a Beta compose today, ive done one test install of it. I need to
do a couple more

I will try to update to this version when it appears on the servers.

We nly support 32 bit userland and 64 bit kernel. I do not think you
will successfully be able to do what your attempting the %post scripts
in the packages will not be able to run. and you wont be able to run
silo to install the bootloader. you could likely use mock or
febootstrap to setup a new environment from your existing install. All
of which is untested.

ive not once gotten a successful boot with grub2

Post by Rafal Maszkowski
- 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

Post by Rafal Maszkowski
- 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

Post by Rafal Maszkowski
BTW the sparc64 devel version installs smoothly except dwdiff which has
dwdiff-1.5-4.fc12.sparc64 z rawhide ma problemy z rozwiï¿œzywaniem zaleï¿œnoï¿œci
--> Brakujï¿œca zaleï¿œnoï¿œï¿œ: libicui18n.so.40()(64bit) jest wymagane przez
pakiet dwdiff-1.5-4.fc12.sparc64 (rawhide) dwdiff-1.5-4.fc12.sparc64 z
libicudata.so.40()(64bit) jest wymagane przez pakiet
dwdiff-1.5-4.fc12.sparc64 (rawhide) dwdiff-1.5-4.fc12.sparc64 z rawhide ma
libicuuc.so.40()(64bit) jest wymagane przez pakiet
libicui18n.so.40()(64bit) jest wymagane przez pakiet
libicuuc.so.40()(64bit) jest wymagane przez pakiet
libicudata.so.40()(64bit) jest wymagane przez pakiet
dwdiff-1.5-4.fc12.sparc64 (rawhide)

there are some broken deps in the tree

This should be taken to the fedora sparc list
https://admin.fedoraproject.org/mailman/listinfo/sparc

Dennis

Rafal Maszkowski

2010-04-21 14:02:34 UTC

...

Post by Rafal Maszkowski
# 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).
- 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 .

Post by Rafal Maszkowski
- 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.

Post by Rafal Maszkowski
- are there any fundamental problems with the 64-bits userspace or the
main problem is that nobody tested it yet?

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).