[fedora-arm] F18 on mirabox

Thu Apr 4 20:03:15 UTC 2013

check for

CONFIG_AUDITSYSCALL=y

On Thu, Apr 4, 2013 at 2:27 PM, Jochen De Smet <jochen.arm at 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 at 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/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 <jochen.arm at 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 at lists.fedoraproject.org
>>>> https://admin.fedoraproject.**org/mailman/listinfo/arm<https://admin.fedoraproject.org/mailman/listinfo/arm>
>>>>
>>>
>> ______________________________**_________________
>> arm mailing list
>> arm at lists.fedoraproject.org
>> https://admin.fedoraproject.**org/mailman/listinfo/arm<https://admin.fedoraproject.org/mailman/listinfo/arm>
>>
>
> ______________________________**_________________
> arm mailing list
> arm at lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/arm<https://admin.fedoraproject.org/mailman/listinfo/arm>
>

-- 

-Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/arm/attachments/20130404/6aa7ca98/attachment-0001.html>