I've tried the following two ways of F13 installation on qemu-arm:
1.) clean f13-beta3 rootfs
2.) upgrade from f12 (note: f12 works without problems)
The command used:
qemu-system-arm -m 256M -M versatileab -kernel zImage-versatile-2.6.24-rc7.armv5tel \
-append root=0800 -hda arm1.img -net nic -net user,hostfwd=tcp::40022-:22
In both cases the boot gets frozen once the following line appears:
Enabling /etc/fstab swaps: [ OK ]
Does anybody know a solution? / Can anybody help?
Thanks in advance.
Red Hat Czech, s.r.o.
Software Engineer / BaseOS
Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic
We've tripled the RAID storage on arm.koji.fedoraproject.org. This
- There is plenty of room for signing and multiple builds.
- /mnt/koji will no longer be on SSD (but will be on multiple spindles;
we'll have to see the net performance impact, especially for newRepo
- The disk system will be busier than normal doing LVM and RAID moves
over the next few days (probably the next day or two, with another run
at the end of next week).
In other news: we're doing a sigul signing run on dist-f13 (go disks
On Wed, 2011-06-08 at 14:59 -0400, Kyle McMartin wrote:
> I'll be posting the split out kernel-noarch spec this week, which should
> rectify building kernel-doc and kernel-headers, without needing to go
> through the half-hearted rigamarole to do it now.
Great! Also +1 to considering the fake deps subpackage in there.
> We can probably cram the fake kernel crud in there for you, but I
> definitely don't want it in the main kernel spec. I also don't really
> know why you don't just build your sub-arch kernels as packages in your
> secondary build system until you get promoted, but that's your decision...
There are kernel packages being built in the ARM koji and more work will
be done, but it's not as straightforward (yet) as building a single RPM
package for all possible ARM systems people might choose to use. Until
that point, there will be people who can't install the standard kernel
package, need to build their own, and just want the dependencies. Like I
said, most of the main systems will be supportable in a single kernel
RPM in due course, and we can come asking about config changes, etc.
that we need later on to roll this back into the standard kernel.
Another question for you, related to this. David Marlin (dmarlin) is
currently working on the OMAP kernel packages. He's based his SPEC and
sources on F15 and the plan is to basically track the F15 kernel until
such time as we're ready to ask to integrate whatever will be integrated
back into the official kernel package. He's looking at using split-out
kernel config files - can I point him to you and get you to help him
figure out how those work? (he wants to make sure he's able to
regenerate the config files and merge for building, etc.)
On Wed, 2011-06-08 at 14:15 -0400, Jarod Wilson wrote:
> Jon Masters wrote:
> > On Wed, 2011-06-08 at 11:14 -0400, Jon Masters wrote:
> >> What do the kernel maintainers think about having a kernel subpackage
> >> that just provides fake deps as part of the main kernel package?
> > Anyway. To get back to the point...there are some systems that cannot
> > run a stock Fedora kernel yet or need fake kernel deps for other
> > reasons. Is there any fundamental objection to the fake-kernel package
> > being integrated by way of an official kernel sub-package? (perhaps even
> > selectively buildable and not built by default on e.g. x86?).
> Do not want. This is just as easily accomplished by a separate spec that
> doesn't clutter up the official kernel spec even further than it already is.
That's fine, it's ok in a separate package. I just wanted to raise it.
> A kernel-none package would, however, be potentially amusing to even
> relatively sane arches like x86. Install the kernel-none variant, and
> you don't get kernel updates via yum, which may be desired, if you're
> running your own locally built kernel and don't want the bootloader
> constantly being updated to point to the newly installed kernel rpm when
> you really want the locally built kernel to keep being the default boot
> kernel... But this has no way of working in Anaconda, which is another
> reason why I think it has no place in the actual kernel spec.
Good points. I generally add kernel to the excludes line in my x86 yum
configs, which achieves similar but I still think there are similar uses
for this even if that particular one can be handled elsewhere.
For installing, yea, there needs to be a kernel package that at least
supports some targets, which is where this is headed. For example, I see
a general ARMv7 kernel that supports a good subset of targets as the
most likely option in the medium term. I don't see it likely that we'd
have a one size fits all kernel image in the next few weeks :)
> I presume
> people "installing" on ARM are creating an image on another host, rather
> than actually running through an anaconda install.
Right. At the moment, there are scripts to generate a rootfs (and I will
be posting a more up to date rootfs example image with pre-canned kernel
and bits for some targets soon), but the goal is to get to a point:
1). Where the rootfs image can be generated using appliance creation
tools that already exist, since many boards are similarly used.
2). Eventually, where we have support for standard installation. I
suspect that would be using a kernel that supports major systems, but
where if you have something more exotic, you still install the fake
dependency package (after perhaps building an image) on your own.
So would you ACK the importation of such a fake dep package? If it comes
up for debate?
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
>  We're making a "one time" incompatible ABI switch in F-15 bringup to
> the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly
> referred to as the ARM EABI - but that doesn't actually exist as a
> name). The procedure call standard will be ARM AAPCS vfpv3-d16, as
> defined in section 6 of that document. Other distros are switching and
> this will form the basis of any LSB standardization effort later on.
> Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and
Marvell Kirkwood (including plug computer) devices which do not support
armv7hl will continue to work with armv5tel.
- The significant incompatibility is hardfp vs. softfp ABI (moreso than
v7 vs. v5).
I guess some people have seen this already on irc, but in case not everybody hangs out there I'd replicate this in the mailinglist.
I've got Nook Color and Fedora13 instructions together and currently they live in this forum post: http://forum.xda-developers.com/showthread.php?t=1106294
I would imagine something to that effect also needs to be added to Fedora wiki (I have not signed up for it yet), but possibly it's a good idea to hae a template
for new supported devices explanations?
Overall I think Nook Color is a great little tablet with a lot of potential, esp. now that usb host mode works and so all sorts of external equipment could be connected.
I've seen some email here about getting Fedora running on Toshiba ac100
and I'd like to say, that I managed to get it working with XFCE and other
The thing why I'm writing here is that I'm willing to help others
interested in getting Fedora on their Toshiba ac100, and the only thing on
our wiki is mension about Fedora working on this netbook, but no
instructions and no kernel. So can someone give me instructions about
contributing to wiki, or I can just freely put information there?
Just some notes about Fedora on Toshiba ac100. I'm using phh's dirty
kernel 2.6.32 with proprietary ralink drivers for wifi. Suspend doesn't
work, sound doesn't work and reboot causes shutdown. I'd like to get some
newer kernel running, but I'm no kernel hacker, so naively compiled
kernels didn't work :)
I would like to see us have alternatives to the Debian xdeb-graph type
tools where we can visualize minimal dependencies for bootstrapping. I
believe there are several scripts floating around, and that styrene
might be able to provide some of what we're looking for...Jon?
Failing that, what other options do we have to get away from just
looking at the minimal buildroot package lists, etc.?