check for
CONFIG_AUDITSYSCALL=y
On Thu, Apr 4, 2013 at 2:27 PM, Jochen De Smet <jochen.arm(a)leahnim.org>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<https://github.com/MISL-EBU-System-SW/ma...;,
> 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 <jochen.arm(a)leahnim.org>
>> 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<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**: 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
>>> arm(a)lists.fedoraproject.org
>>>
https://admin.fedoraproject.**org/mailman/listinfo/arm<https://admin.f...
>>>
>>
> ______________________________**_________________
> arm mailing list
> arm(a)lists.fedoraproject.org
>
https://admin.fedoraproject.**org/mailman/listinfo/arm<https://admin.f...
>
______________________________**_________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/arm<https://admin.f...