check for CONFIG_AUDITSYSCALL=y
On Thu, Apr 4, 2013 at 2:27 PM, Jochen De Smet <[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<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]> >>> 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 >>>> [email protected] >>>> https://admin.fedoraproject.**org/mailman/listinfo/arm<https://admin.fedoraproject.org/mailman/listinfo/arm> >>>> >>> >> ______________________________**_________________ >> arm mailing list >> [email protected] >> https://admin.fedoraproject.**org/mailman/listinfo/arm<https://admin.fedoraproject.org/mailman/listinfo/arm> >> > > ______________________________**_________________ > arm mailing list > [email protected] > https://admin.fedoraproject.**org/mailman/listinfo/arm<https://admin.fedoraproject.org/mailman/listinfo/arm> > -- -Jon
_______________________________________________ arm mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/arm
