On 01/27/2016 08:29 PM, Guillaume Gardet wrote:

Le 27/01/2016 15:46, Alexander Graf a écrit :

...

On 01/27/2016 10:17 AM, Guillaume Gardet wrote:

...

Hi,

All armv6l (raspberry pi) images hang after a call to kpartx. See: https://build.opensuse.org/package/live_build_log/devel:ARM:Factory:Contrib:...

Local (chroot) build is ok, so I guess this is a qemu problem?

Any idea how to fix that ?

It's a udev problem. Spawning udev in qemu-linux-user doesn't work, because we don't allow NETLINK sockets to get created. However, after udev fails to start, it doesn't clean up properly after itself and the hinting file libudev then uses to determine whether udev is running still exists, so device mapper (kpartx) tries to talk to it and waits forever.

Hannes cooked up a patch for this a while back that we were testing locally, but somehow now every build hangs for 2 minutes. I don't think anyone debugged this further.

Could be nice if we could find a way to fix/workaround it.

Why did it work previously?

Can't you open a bugzilla for this? That's far easier for tracking and debugging. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

I've added a modified patch, let's see how it goes. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 01/02/2016 00:11, Dirk Müller a écrit :

HI Andreas,

...

I've added a modified patch, let's see how it goes. Success!! Thanks a ton!

+1 :D Good job! Guillaume

Greetings, Dirk

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 01.02.2016 um 14:51 schrieb Freek de Kruijf:

I tried the image build today on Feb 1st 2016 in the repository below:

openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build369.1.raw.xz

using a connected HDMI device. But the HDMI device did not even detect a living connection. I never found a working image, since I started testing on 2015-07-17, in:

http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...

The last bootable image from:

http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...

was openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build330.10.raw.xz downloaded 2015-08-06. This one is upgradable to the latest Tumbleweed version, provided that you copy the files in /boot/dtb-4.4.0-1/ to /boot/dtb/ before a reboot.

I told you on Dec 20th: http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ And I have now deleted devel:ARM:Factory:Contrib:RaspberryPi:upstream project to leave no doubt that it should no longer be used. Hopefully it will disappear from the download server soon. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 01.02.2016 um 15:53 schrieb Michael Ströder:

Andreas Färber wrote:

...

I told you on Dec 20th:

http://download.opensuse.org/ports/armv6hl/tumbleweed/images/

Quoting myself: "the download [location] will change to: http://download.opensuse.org/ports/armv6hl/tumbleweed/images/" http://lists.opensuse.org/opensuse-arm/2015-12/msg00050.html

I tried to follow your advice but there were no *.raw.xz files at that time.

As you can see, I announced the new location where he would find new images once they get published and now thanks to Andreas they did. Also I asked Freek to stop reporting a black screen and to get himself a cheap serial cable, which he is also still conveniently ignoring with his message today. I invested time in cleanups, put the information out there in a thread initiated by Freek, so I totally have a right to be offended if he ignores the information and advice he received. Further I had repeatedly said that if you guys care about a Contrib repository, such as RaspberryPi2, then you need to update and clean it up yourselves. Guess how many people did since then.

So before blaming people who are willing to test the stuff you should check yourself whether everything is in place.

I did, and they are there - if you don't see them, it may be a mirror problem outside of the control of the people on this list. nebadon has been one of the very few people that were willing to re-test stuff when we actually made changes and asked for testers on opensuse-arm IRC channel. Also, guess how many people bothered to build their own Raspberry Pi 1 image with osc while the OBS builds were broken, despite a lengthy how-to I posted. At times it feels like some people operate write-only. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 01.02.2016 um 18:05 schrieb Freek de Kruijf:

Op maandag 1 februari 2016 16:26:06 schreef Andreas Färber:

...

Am 01.02.2016 um 15:53 schrieb Michael Ströder:

...

Andreas Färber wrote:

...

I told you on Dec 20th:

http://download.opensuse.org/ports/armv6hl/tumbleweed/images/

Quoting myself:

"the download [location] will change to:

http://download.opensuse.org/ports/armv6hl/tumbleweed/images/"

http://lists.opensuse.org/opensuse-arm/2015-12/msg00050.html

...

I tried to follow your advice but there were no *.raw.xz files at that time. As you can see, I announced the new location where he would find new images once they get published and now thanks to Andreas they did.

Also I asked Freek to stop reporting a black screen and to get himself a cheap serial cable, which he is also still conveniently ignoring with his message today. I invested time in cleanups, put the information out there in a thread initiated by Freek, so I totally have a right to be offended if he ignores the information and advice he received.

I don't think it is the proper way to use a serial cable to test images for the Raspberry Pi 1. There used to be, and still is, an image that, when the RPi1 was connected to a HDMI device, showed the booting procedure right from the start. I am not capable to debug anything that has to do with the basic booting. So a serial cable is a no go for me.

...

Further I had repeatedly said that if you guys care about a Contrib repository, such as RaspberryPi2, then you need to update and clean it up yourselves. Guess how many people did since then.

...

So before blaming people who are willing to test the stuff you should check yourself whether everything is in place.

I am not blaming anybody. I sit silently till a new image arrives, I test it as far as I find useful and report my findings. I do not expect anything from anybody. I am still able to build a Raspberry Pi 1 and 2 system with openSUSE Tumbleweed from older images that suite my needs.

For the record: I was not suggesting that every user of openSUSE always use a serial cable and in particular not as main user interface. Rather, I have been asking in the case of a black screen to also check the serial output, to be able to file a more useful bug report. After all it's a single-board computer with pin headers and lots of Web pages describing how to do it, so I do consider that a reasonable request. Alternatively, as Alex has said to Jimmy, early reports would help us narrow down the source of a problem - i.e. knowing that update of package A broke X would give a better starting point for investigations. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 04.02.2016 um 00:52 schrieb Freek de Kruijf:

Op woensdag 3 februari 2016 22:55:58 schreef Andreas Färber:

...

For the record: I was not suggesting that every user of openSUSE always use a serial cable and in particular not as main user interface. Rather, I have been asking in the case of a black screen to also check the serial output, to be able to file a more useful bug report. After all it's a single-board computer with pin headers and lots of Web pages describing how to do it, so I do consider that a reasonable request.

A request I can not honor.

It rather seems you refuse to. You must have bought an HDMI cable and a Micro USB cable, so why is a TTL UART cable any different. The cheapest I could find in .de is 3.95 EUR (no free shipping though): http://www.pollin.de/shop/dt/NzU3NzkyOTk-/Bausaetze_Module/Entwicklerboards/... And this one is apparently quite widespread in the US at 9.95 USD: https://www.adafruit.com/products/954 Another month passed, so you could've ordered some from China by now... Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi Andreas,

Further I had repeatedly said that if you guys care about a Contrib repository, such as RaspberryPi2, then you need to update and clean it up yourselves. Guess how many people did since then.

Well, normally the responsibility of fixing something is with the one who broke it.. I appreciate all the cleanups that have been done in JeOS, but I think its unfair to shoot the messenger when things are broken..

I did, and they are there - if you don't see them, it may be a mirror problem outside of the control of the people on this list.

Could you please update the wiki page accordingly (https://en.opensuse.org/HCL:Raspberry_Pi )? Thanks a lot in advance, Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi Andreas,

Actually I think it is unfair of users to expect that SUSE engineers must be the ones to fix things if random boards break

I don't think anyone was calling for a "suse engineer". Users were asking for the openSUSE ARM contributors to take a look at the regression. I don't think anyone excluded "non-SUSE" people from looking at the problem and fixing it. And I'm not writing with a SUSE email here on this list...

At FOSDEM Michal and a visitor indicated the latest downstream kernel for the Raspberry Pi 2 were 4.1 based, whereas we have a 3.14 based kernel

Thanks for pointing out a completely irrelevant detail, my completely irrelevant correction follows: We have an image with 3.18 (Contrib:RaspberryPi2, working) and 4.1 (Contrib:RaspberryPi2:Staging, not working yet) kernel.

- one that apparently no one remembers how it was created

Maybe the person who created the kernel, who is listed as maintainer, and who has a git repo which accepts PRs knows how though. Oh and BTW: The kernel was not the problem of the image.

Mainly the convenience stuff around Kiwi images, that I am not an expert on, "constantly" breaks in one way or another.

Right, which is not a problem per se, because we're all humans and we make mistakes. Common practices like peer reviewing changes or respecting maintainership definitions can help though.

None of us on this list updated/broke systemd however, so that left us with no one responsible reading the armv6l complaints here.

I don't see many people complaining at all. I do see a group of people caring enough to report issues though, and I'm personally very happy to see that they care about something that I care about as well. BTW. systemd was just preventing the image from rebuild, the image was broken by other changes since it still doesn't work, and I'd guess it is reasonable to assume that somebody reading this list would find the motivation to debug and fix the issue and feel motivated since there is somebody else _as_ _well_ interested in getting that done.

If you, Dirk, want to monitor Raspberry Pi issues on this list

I don't even own a Raspberry Pi, Andreas, but even then, I'm fixing packages for armv6 because there are people caring about them being working. if there are issues reported that I can fix given time, motivation and knowledge, more often than not I'm fixing them. I don't monitor for them though, and I generally don't reply to emails that don't motivate me or where I don't have something to contribute to that motivates the sender. I also don't read new emails here within two minutes and respond within 10 minutes though, as I have a demanding day job that requires me to focus on other stuff. So it can easily take a day or even a week for me to read the email, and I don't have time every weekend to fix stuff, so it can take even longer until I get around doing something about it. In my opinion we can greatly improve the experience though by not doing major restructurings of the way how our images work without properly staging those changes, testing them through from the beginning until the end and giving others with more knowledge in how things work a chance to peer review them prior them being merged. Please note that I didn't say that I don't appreciate cleanups or long-overdue refactorings.

welcome to - late last year it felt like I was left alone with replying here at times...

I typically don't have a lot of desire to read through email threads that have a stack of replies already from here up to the moon when I take a look at my email folder. I also lost my motivation at some point 10 years ago to correct anyone who is wrong on the internet (https://xkcd.com/386/). Not replying though doesn't mean that I don't read the mailing list, and I would love to continue enjoying that going forward. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi Ludwig,

Could you please dump the bits of your brain that knows about the openSUSE pi2 specialities to https://en.opensuse.org/HCL:Raspberry_Pi2 ? :-)

https://en.opensuse.org/HCL:Raspberry_Pi2#Contributing Please note that this is not a whole lot relevant as I'm playing currently with removing the downstream kernel since the support in 4.5-rc1 doesn't look too bad right now.

...

The kernel was not the problem of the image. Just curious, what was it then? :-)

It was a whole stack of bugs I think, a combination of "cleanups" in the u-boot boot.script that removed the workaround for a quirk. Two bugs were I believe generic armv7 bugs (hwinfo --storage panicing the kernel, mmc_block module not being loaded by anything anymore, I couldn't figure out how that broke yet, but I saw it in the arndale image as well). Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Dirk, Am 04.02.2016 um 23:45 schrieb Dirk Müller:

...

Actually I think it is unfair of users to expect that SUSE engineers must be the ones to fix things if random boards break

I don't think anyone was calling for a "suse engineer". Users were asking for the openSUSE ARM contributors to take a look at the regression. I don't think anyone excluded "non-SUSE" people from looking at the problem and fixing it. [...]

The people that took action here - myself, Alex, Andreas - all are, and we're less than the users asking. If everyone non-SUSE waits for someone else instead of pushing up their sleeves then there's no progress, that's all I was saying.

...

At FOSDEM Michal and a visitor indicated the latest downstream kernel for the Raspberry Pi 2 were 4.1 based, whereas we have a 3.14 based kernel

Thanks for pointing out a completely irrelevant detail, my completely irrelevant correction follows: We have an image with 3.18 (Contrib:RaspberryPi2, working) and 4.1 (Contrib:RaspberryPi2:Staging, not working yet) kernel.

Let's be fully correct then: It's 3.18.14!

...

- one that apparently no one remembers how it was created

Maybe the person who created the kernel, who is listed as maintainer, and who has a git repo which accepts PRs knows how though.

Then why weren't you answering when people asked about it. I'm not the one you need to tell, I don't really care. It could be documented a) in the spec file, b) in the package or project description. And some README.txt file in the repository might be a useful feature for people accessing it directly from the Wiki etc.

The kernel was not the problem of the image.

The problem is a) people _call_ it an openSUSE image despite not having an openSUSE kernel, and b) users keep comparing openSUSE to Raspbian and blaming openSUSE for the Raspberry Pi Foundation and Broadcom not working with the kernel community properly. If graphics are slow in the mainline kernel then that's not our fault and people should contribute to improving that there; otherwise doing a KMP against our kernel for that driver specifically would be better than offering a whole alternative kernel for laziness. Whenever there's two (or more) download locations we can be sure that someone will choose the wrong one, therefore we need to limit choices. The Contribs had packages violating OBS rules wrt binary userspace programs, misusing SUSE-Firmware license, failing for a long time, adding non-essential contrib packages to the official JeOS, ... do I need to go on? I don't understand why we still have Contrib:RaspberryPi. I would've deleted it when the download location discussion came up again had not Guillaume recently updated raspberrypi-userland.

...

Mainly the convenience stuff around Kiwi images, that I am not an expert on, "constantly" breaks in one way or another.

Right, which is not a problem per se, because we're all humans and we make mistakes. Common practices like peer reviewing changes or respecting maintainership definitions can help though.

Then you could start with giving me a chance to review kernel config changes and not changing them behind my back and, without asking me first, dropping options that I invested time to make consistent! No notifications are being sent when -rc1 has been checked in (last time I checked it was upstream but not in master) or when someone pushes changes. Sometimes SRs are ignored for weeks, then someone submits and accepts their own and tells everyone else to rebase them despite seeing no issue with them. Review and times we work on things never are in sync. Other times SRs get accepted quicker than I can re-review my own diff. Also we will never get u-boot or dtb-source updated in Factory if we keep superseding each other's SRs rather than waiting while an in-flight one goes through Staging and Factory review. Missing links is a recurring pain point that some of us maintainers can't remedy ourselves. And may I remind you that there is no devel project set for JeOS. Not that it would help with the armv7l build power problems with existing images not getting rebuilt within two weeks. Part of the official OBS workflow is also using Submit Requests and not committing to Contrib projects directly, which then leaves me and other people without change notifications. Please Don't Do That. Yes, a lot of things can be done to improve the situation. Some others are limited by our build power unfortunately. Yet others could use some better support on the osc (branch) side.

...

None of us on this list updated/broke systemd however, so that left us with no one responsible reading the armv6l complaints here.

I don't see many people complaining at all. I do see a group of people caring enough to report issues though, and I'm personally very happy to see that they care about something that I care about as well.

There's been at least a handful of people complaining about Raspberry Pi images specifically, I can't help you if you didn't see that. Including a cascade of self-replies by one such user that the image was still not working - obviously if no one works on it it would be surprising if it suddenly worked again. Including someone setting deadlines until when he needs a working image. Now if you want to blame me for some of the causes, say it clearly. * Had people not piled up packages in Contrib:RaspberryPi I wouldn't have needed to spend time cleaning them up (raspberrypi-firmware,pihwm). => Give less people maintainer access, reject optional packages and let them go through the usual review processes outside the ARM team. * Same if someone had been thinking earlier about updating a running system rather than piling up stuff in the JeOS image initialization only (raspberrypi-firmware-branding-openSUSE, /boot/vc). => Put BeagleBoard alsa config into alsa (Takashi can help get that upstream if needed), create individual *-branding-openSUSE packages for dracut configs. May involve splitting configs by boot media. * Would Kiwi simply put any files installed to /boot in one partition, we wouldn't need to patch Kiwi again and again (/dtb-*, /boot/vc). * Would we have Staging Rings for ARM then dtb-source and u-boot changes would not arrive via Factory accept without being tested against JeOS. Limited by build power and patience. * Would JeOS actually have build-time checks and fail when files are not in the expected location, some breakages would've been easier to spot (/boot/vc). * Would we stage dtb-source from Kernel:linux-next through Kernel:HEAD to Base:System we could test some additions much earlier (dtb-meson8b). Downside is such branches would silently break whenever someone changes Base:System. Similar merge problems exist for Contrib JeOS branches. * Would we have an archive of known working Tumbleweed images then temporary image breakages wouldn't be as severe. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 04.02.2016 um 13:57 schrieb Dirk Müller:

Could you please update the wiki page accordingly (https://en.opensuse.org/HCL:Raspberry_Pi )?

I don't spot a Tumbleweed section to be updated there, only 13.1 and 13.2 sections. Speaking of which, I did backport my JeOS /boot/vc changes to 13.1 and 13.2, but I'm afraid that Kiwi backports may be needed there, too. 13.1 Contrib has an old copypac version, 13.2 none. https://build.opensuse.org/package/show/devel:ARM:13.1:Contrib:RaspberryPi/k... https://build.opensuse.org/project/show/devel:ARM:13.2:Contrib:RaspberryPi In general I think it's a bad idea to link Factory or devel packages into stable releases - it makes them highly unstable. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Op maandag 1 februari 2016 15:42:25 schreef Michael Ströder:

Freek de Kruijf wrote:

...

The last bootable image from:

http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Ra spberryPi:/upstream/images/

was openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build330.10.raw.xz downloaded 2015-08-06. This one is upgradable to the latest Tumbleweed version, provided that you copy the files in /boot/dtb-4.4.0-1/ to /boot/dtb/ before a reboot.

For the records: IIRC openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build333.2.raw.xz from the URL above worked too. I can re-test with an old copy if needed.

Found today that I have a perfect working SD card in my desktop, but when I use it in my Raspberry Pi 1B it does nothing. So my earlier messages about a black screen are caused by this failing SD card, which I kept using to do my tests. So it is quite possible that Build333.2 will work. I tested again Build330.10, which also works with another SD card. Using that another SD card I tried openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build373.3.raw.xz from http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ It initially boots, so no black screen anymore. but it gives the error message: Initramfs unpacking failed: write error Can't find udev daemon -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Op woensdag 10 februari 2016 13:44:11 schreef Alexander Graf:

...

Am 10.02.2016 um 13:08 schrieb Freek de Kruijf : Using that another SD card I tried openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build373.3.raw.xz from http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ It initially boots, so no black screen anymore. but it gives the error message: Initramfs unpacking failed: write error Can't find udev daemon

This is probably because we no longer use ramfs as the rootfs type, since setting that breaks the image on second boot.

I see 3 realistic options out of this:

1) Patch the kernel to use ramfs by default instead of tmpfs when ram is less than 2G.

2) Add another layer of abstraction and move the initrd fs into an actual file system we loop mount. This is how the installer initrd works.

3) Patch kiwi to add fstype=ramfs on first boot only.

Tried Build374.2 from the above repository today. Same initial error message. After that other error messages than previously. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Op dinsdag 16 februari 2016 11:18:46 schreef Freek de Kruijf:

Op vrijdag 12 februari 2016 23:28:43 schreef Freek de Kruijf:

...

Op woensdag 10 februari 2016 13:44:11 schreef Alexander Graf:

...

...

Am 10.02.2016 um 13:08 schrieb Freek de Kruijf : Using that another SD card I tried openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build373.3.raw. xz from http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ It initially boots, so no black screen anymore. but it gives the error message: Initramfs unpacking failed: write error Can't find udev daemon

This is probably because we no longer use ramfs as the rootfs type, since setting that breaks the image on second boot.

I see 3 realistic options out of this: 1) Patch the kernel to use ramfs by default instead of tmpfs when ram is

less than 2G.

2) Add another layer of abstraction and move the initrd fs into an actual

file system we loop mount. This is how the installer initrd works.

3) Patch kiwi to add fstype=ramfs on first boot only.

Tried Build374.2 from the above repository today. Same initial error message. After that other error messages than previously.

Tried JeOS Build375.2 from 2016-02-16. Needed to change boot.script, but same result as with Build374.3.

Tried Build375.4. Needed to add rootfstype=ramfs, NOT fstype=ramfs as given above, to the boot line. After that, NO error messages anymore. After a while the system hangs with a message about a reboot, however the lights about an Ethernet connections are on, but it did not get an IP address. Inspection of the partitions on the SD card shows that a fourth swap partition has been added at the end of SD card and the third partition has been extended, so all the memory on the card is available for data. PROBLEM is that after power down and power up nothing happens. The HDMI device connected does not get a signal, so it still shows no connected device. Also the lights of the Ethernet port remain dark. Something on the SD card does not indicate a bootable device anymore. Putting back the image on the SD card and making the change in boot.script and the mkimage command gives an active device again. It shows an initial boot and a second boot, showing Tux. At the end, the message about a reboot, which does not happen. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org