Description of problem: I try to port Fedora 20 ARM to one of small systems - Mindspeed Comcerto 2000 mounted in WD My Cloud NAS. Out-of-the-box it has Debian with 3.2.26 kernel so we think that there will no problems... But Problems are: 1) Someone really think that each small board has Framebuffer? There was spent a lot of efforts to kick out plymouth and it's dependencies from MINIMAL spin! 2) there is no way to use initramfs so kernel contains (almost) all needed modules built-in. But tries to load firmware for modules fails without any diagnostics - "pfe_firmware_init: request firmware class_c2000.elf failed". There are some words about firmware in Documentation/firmware_class (and this works in debian!) but also there is "Userspace firmware loading is deprecated, will go away, and sometimes causes problems" in /usr/share/doc/systemd/README. Forgive me but inability to load firmware ALWAYS causes problems! May be refusal of firmware loading in x86 is form of progress but there are lots of anoter platforms! 3) "yum update" breaks off with a message about the lack of space: installing package fxload-2008_10_13-1.fc20.armv7hl needs 113MB on the / filesystem installing package crda-1.1.3_2014.06.13-1.fc20.armv7hl needs 113MB on the / filesystem installing package mdadm-3.3-7.fc20.armv7hl needs 114MB on the / filesystem installing package cryptsetup-1.6.4-1.fc20.armv7hl needs 113MB on the / filesystem installing package irqbalance-2:1.0.7-2.fc20.armv7hl needs 113MB on the / filesystem installing package jwhois-4.0-34.fc20.armv7hl needs 113MB on the / filesystem installing package vim-minimal-2:7.4.417-1.fc20.armv7hl needs 114MB on the / filesystem installing package traceroute-3:2.0.20-1.fc20.armv7hl needs 113MB on the / filesystem installing package dosfstools-3.0.26-1.fc20.armv7hl needs 114MB on the / filesystem installing package ed-1.10-1.fc20.armv7hl needs 113MB on the / filesystem Error Summary ------------- Disk Requirements: At least 117MB more space needed on the / filesystem. But there are more than 1G free! And after a time and some reboots update unexpectedly completed successfully :) 4) device is "network-only" so there is no any console outside. It does not cause trouble in Debian - sshd starts always, but Fedora (thanks to systemd) on slightest problem goes to emergency mode and device bricks out, so we have to open the box case and connect serial console. Again and again... PS. OpenWRT has started without any problems
(In reply to vde from comment #0) > Description of problem: > > I try to port Fedora 20 ARM to one of small systems - Mindspeed Comcerto > 2000 mounted in WD My Cloud NAS. Out-of-the-box it has Debian with 3.2.26 > kernel so we think that there will no problems... > > But Problems are: > > 1) Someone really think that each small board has Framebuffer? There was > spent a lot of efforts to kick out plymouth and it's dependencies from > MINIMAL spin! plymouth is not required by anything. Nor is a framebuffer support necessary. Can you be more specific about what is wrong? > 2) there is no way to use initramfs so kernel contains (almost) all needed > modules built-in. But tries to load firmware for modules fails without any > diagnostics - "pfe_firmware_init: request firmware class_c2000.elf failed". > There are some words about firmware in Documentation/firmware_class (and > this works in debian!) but also there is "Userspace firmware loading is > deprecated, will go away, and sometimes causes problems" in > /usr/share/doc/systemd/README. > Forgive me but inability to load firmware ALWAYS causes problems! May be > refusal of firmware loading in x86 is form of progress but there are lots of > anoter platforms! In Fedora systemd is compiled without userspace firmware loading support, and requires at least kernel 3.7 to function properly. If you're using kernel 3.2 then things will break. You can recompile systemd (up to version 216) with --with-firmware-path=... but this not supported by the distribution. > 3) "yum update" breaks off with a message about the lack of space: > > installing package fxload-2008_10_13-1.fc20.armv7hl needs 113MB on the / > filesystem > installing package crda-1.1.3_2014.06.13-1.fc20.armv7hl needs 113MB on the > / filesystem > installing package mdadm-3.3-7.fc20.armv7hl needs 114MB on the / filesystem > installing package cryptsetup-1.6.4-1.fc20.armv7hl needs 113MB on the / > filesystem > installing package irqbalance-2:1.0.7-2.fc20.armv7hl needs 113MB on the / > filesystem > installing package jwhois-4.0-34.fc20.armv7hl needs 113MB on the / > filesystem > installing package vim-minimal-2:7.4.417-1.fc20.armv7hl needs 114MB on the > / filesystem > installing package traceroute-3:2.0.20-1.fc20.armv7hl needs 113MB on the / > filesystem > installing package dosfstools-3.0.26-1.fc20.armv7hl needs 114MB on the / > filesystem > installing package ed-1.10-1.fc20.armv7hl needs 113MB on the / filesystem > > Error Summary > ------------- > Disk Requirements: > At least 117MB more space needed on the / filesystem. Those numbers show what is required *above* what is currently available. So if you have 1GB free, yum is saying that you need 1024+117 MB. Maybe something freed some space during or after the reboot. If free disk space reporting is broken, then this is most likely a kernel issue. Please report it upstream to the developers of the fs. > But there are more than 1G free! And after a time and some reboots update > unexpectedly completed successfully :) > > 4) device is "network-only" so there is no any console outside. It does not > cause trouble in Debian - sshd starts always, but Fedora (thanks to systemd) > on slightest problem goes to emergency mode and device bricks out, so we > have to open the box case and connect serial console. Again and again... Yes, sysvinit happilly ignores almost all errors. Systemd doesn't. > PS. OpenWRT has started without any problems I don't see anything actionable here for systemd developers.
>Can you be more specific about what is wrong? Somewhere near systemd-ask-password-plymouth.service there is checking for presense of /dev/fb0 and since it is not boot fails to emergency mode. "systemctl mask '*plymouth*'" helps. >requires at least kernel 3.7 to function properly Surprise... Device has some platform drivers not in kernel mainline so even update from 3.2.26 to latest 3.2.63 was quite difficult. Update to 3.7 is absolutely impossible. >Those numbers show what is required *above* what is currently available. You must be joking, if so why they not changes when i change amount of free space by hands? And moreover, you REALLY want to says that 1Gb free of 4Gb drive insufficient for "yum update"? >If free disk space reporting is broken, then this is most likely a kernel issue. But why "df -h" says about 1G free? This is definetly not fs but yum error. >Yes, sysvinit happilly ignores almost all errors. Systemd doesn't. And thus turns all soft errors to hard. Situation: There is a gas pipeline somewhere in Siberia. It has a lot of sensors and automation with small computers on Centos 6. All equipment is duplicated, so a single failure does not result in inability to boot, and can be seen and may be corrected via SSH. It means that systemd in case of *any* failure fails out to emergency mode, and thus we need to fly by helicopter to that point to see console? Thanks but not wants. >I don't see anything actionable here for systemd developers. bugzilla demanded to fill in the "component" field, such as guessing. I do not know which component of the problem, but they are just here: Fedora requires non-obvious tricks to port. Here - http://fedoraproject.org/wiki/Architectures/ARM - says that Fedora team interested in such porting, but probably i misunderstood.
(In reply to vde from comment #2) > >Can you be more specific about what is wrong? > > Somewhere near systemd-ask-password-plymouth.service there is checking for > presense of /dev/fb0 and since it is not boot fails to emergency mode. > "systemctl mask '*plymouth*'" helps. There might be bug here. You might want to file a bug against plymouth. > >requires at least kernel 3.7 to function properly > > Surprise... > > Device has some platform drivers not in kernel mainline so even update from > 3.2.26 to latest 3.2.63 was quite difficult. Update to 3.7 is absolutely > impossible. That's fine, but Fedora puts certain requirements on kernel versions and options. Probably all components can be made to work with this ancient kernel, but you have to compile some from source. This is how distributions work. > >Those numbers show what is required *above* what is currently available. > > You must be joking, if so why they not changes when i change amount of free > space by hands? And moreover, you REALLY want to says that 1Gb free of 4Gb > drive insufficient for "yum update"? It downloads the packages before doing the update. So if you have 3GB of installed packages, you might need 1.5GB to do an update, assuming 50% average compression. > >If free disk space reporting is broken, then this is most likely a kernel issue. > > But why "df -h" says about 1G free? This is definetly not fs but yum error. > > >Yes, sysvinit happilly ignores almost all errors. Systemd doesn't. > > And thus turns all soft errors to hard. > > Situation: > There is a gas pipeline somewhere in Siberia. It has a lot of sensors and > automation with small computers on Centos 6. All equipment is duplicated, so > a single failure does not result in inability to boot, and can be seen and > may be corrected via SSH. > It means that systemd in case of *any* failure fails out to emergency mode, > and thus we need to fly by helicopter to that point to see console? Thanks > but not wants. > > >I don't see anything actionable here for systemd developers. > > bugzilla demanded to fill in the "component" field, such as guessing. I do > not know which component of the problem, but they are just here: Fedora > requires non-obvious tricks to port. > > Here - http://fedoraproject.org/wiki/Architectures/ARM - says that Fedora > team interested in such porting, but probably i misunderstood. If you have specific and concrete issues, beyond Fedora not working with a Debian kernel from 4 years ago, than please file bugs for them, *one per issue*.
>beyond Fedora not working with a Debian kernel from 4 years ago why "not working" - working, but it took a lot of unnecessary efforts to overcome the artificial incompatibilities like dropped support of firmware loading. All this has been written after the successfull launch of Fedora on Comcerto 2000 board. Photo of - http://www.3dnews.ru/assets/external/illustrations/2014/08/11/825725/sm.Plata.600.JPG