On 4/4/2013 16:03, Jon wrote:
check for
CONFIG_AUDITSYSCALL=y
Auditing was disabled completely. Enabled it and will retest.
Can't enable CONFIG_AUDITSYSCALL though, since:
config AUDITSYSCALL
bool "Enable system-call auditing support"
depends on AUDIT && (X86 || PPC || S390 || IA64 || UML ||
SPARC64 || SUPERH)
it won't enable on ARM in this (linux-2.6.35.9-armada370-1.0.2_gw)
kernel version.
J.
On Thu, Apr 4, 2013 at 2:27 PM, Jochen De Smet <[email protected]
<mailto:[email protected]>> wrote:
Making some progress on this, slowly...
After moving the USB driver from module to built-in, I was able to
make it find
the rootfs on the USB stick. First issue I see is this:
<28>systemd[1]: No control group support available, not creating
root group.
even though it's definitely enabled in the kernel:
[root@localhost ~]# zcat /proc/config.gz | grep CGROUP
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_CGROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
then there were a couple of systemd services failing:
<27>systemd[855]: Failed at step OOM_ADJUST spawning
/usr/lib/systemd/systemd-readahead: No such file or directory
<29>systemd[1]: systemd-udevd.service: main process exited,
code=exited, status=206/OOM_ADJUST
I managed to work around both of those by commenting out the
OOMScoreAdjust
parameter in their respective systemd config files.
Next thing was that I forgot to adapt fstab to point to the right
UUID for root.
And now I'm running into this:
<28>systemd[1]: dbus.service start request repeated too quickly,
refusing to start.
repeated a couple dozen times, then it seems to hang. Don't even
get the
emergency shell prompt I got through some of the failure above.
I'll try some more tinkering tonight, but if anyone had any ideas
I'll be happy
to hear them.
J.
On 4/1/2013 12:36, Jochen De Smet wrote:
On 3/29/2013 5:45, Peter Robinson wrote:
Hi Jochen,
What is the release architecture of Debian Squeeze? I
believe squeeze
is only built for ARMv4 which might be part of the chroot
issue. I
suspect it might be easier to use the kernel from debian
to boot
Fedora directly.
In theory the 3.8.3+ kernels in Fedora might work with it
but I don't
think it will because I don't believe everything needed
for the device
landed in the 3.8 kernel. I'm hoping the 3.9 kernel will
have enough
to support the marvell mvebu devices and hence we'll be
able to
support them out of the box for F-19. As the 3.9 kernel
comes together
you'll see more details on the list on how to test them on
F-18.
Peter
I actually started off trying with a 3.8.2 stock kernel, but
didn't get very far; then I switched
to the kernel at
https://github.com/MISL-EBU-System-SW/mainline-public.git,
which I think
got me a kernel that booted but wasn't able to get to the NAND
device.
I just tried copying the fedora rootfs to a USB stick and
booting with a root= argument, but it
seems to be unable to find the device at boot time even though
it does get automounted, so
I'm guessing some driver isn't built-in.
I've also tried grabbing the sources for their default kernel
and simply rebuilding, then booting
the kernel over the network, but again ended up with something
that couldn't read the NAND.
I'll play around some more with a recompiled kernel + USB
root, both their default one and the
mainline-public variety.
file /bin/ls on the squeeze binary shows:
/bin/ls: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18,
stripped
not sure if that's enough to tell you the architecture version.
J.
On Wed, Mar 27, 2013 at 12:48 AM, Jochen De Smet
<[email protected] <mailto:[email protected]>>
wrote:
I'm trying to get F18 running on the globalscale mirabox.
It comes preloaded with Debian Squeeze. As a first
step I've tried
downloading the generic
rootfs from the
https://fedoraproject.org/wiki/Architectures/ARM/F18/Remixes
page; I've
tried both the arm and armhfp versions, and even tried
an armv5 kirkwood
rootfs.
All of them behave the same. I unpack the rootfs into
/mnt/f18, and then try
to chroot into
it. The first two or three times I try it, it comes
back with either
"Illegal instruction" or
"Segmentation fault", but after a few times I
successfully get into the
chroot. Then for pretty
much every command inside it's the same thing. First
few times it runs it
fails with one of
the two errors above, then it starts working and
appears to keep working for
an indeterminate
amount of time.
I've tried to start rebuilding rpms from source in the
chroot but things
never work long enough
to get anything built.
I've also (and this part is probably off-topic) tried
building rpms from the
debian environment,
and that's failing because gcc gives an error when
explicitly compiling for
armv7:
$ gcc -c ui.c -march=armv7
ui.c:1: error: target CPU does not support ARM mode
Additionally, I've tried building gcc 4.8.0 from
source, and that errors out
with:
../.././gcc/config/arm/neon.md <http://neon.md>: In
function 'const char*
output_1551(rtx_def**, rtx)':
../.././gcc/config/arm/neon.md:3953:1: internal
compiler error: Illegal
instruction
[(set_attr "neon_type" "neon_shift_2")]
^
../.././gcc/config/arm/neon.md:3953:1: internal
compiler error: Segmentation
fault
cpuinfo below:
# cat /proc/cpuinfo
Processor : Marvell PJ4Bv7 Processor?? rev 1 (v7l)
BogoMIPS : 1199.30
Features : swp half thumb fastmult vfp edsp
vfpv3 vfpv3d16
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x1
CPU part : 0x581
CPU revision : 1
Hardware : Marvell Armada-370
Revision : 0000
Serial : 0000000000000000
Looking for any help on how to debug or how to proceed.
J.
_______________________________________________
arm mailing list
[email protected]
<mailto:[email protected]>
https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
[email protected] <mailto:[email protected]>
https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
[email protected] <mailto:[email protected]>
https://admin.fedoraproject.org/mailman/listinfo/arm
--
-Jon
_______________________________________________
arm mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/arm
