February 2018 - openSUSE ARM - openSUSE Mailing Lists

[opensuse-arm] http://download.opensuse.org/ports/aarch64/debug/tumbleweed is missing
by Andreas Schwab 11 Mar '18

11 Mar '18

... and the last published snapshot is Build20170831. This may be related. Andreas. -- Andreas Schwab, SUSE Labs, schwab(a)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(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 4

[opensuse-arm] rock64
by Matwey V. Kornilov 10 Mar '18

10 Mar '18

Hello, I will receive my rock64 board soon. https://www.pine64.org/?page_id=7147 I would like to run some openSUSE on it. There are no upstream support but lets see what we could do. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 58

[opensuse-arm] Opensuse on Rock64
by Bill Merriam 28 Feb '18

28 Feb '18

I have spent many weeks getting Opensuse working on Rock64. I bought 5 of them with 4GB RAM and 32GB EMMC. They make great little computers. I thought others might like to know about this so they can work on these machines. First thing is I "cheated". I grabbed a debian stretch image from ayufan4 and went from there. https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.15 That image has 7 partitions containing the crazy rockchip boot process. I think the first partition is u-boot. Partition 6 is vfat and is where u-boot looks to load the the system from. It finds extlinux/extlinux.conf for boot instructions. It loads a kernel and an initrd and tells the kernel to look for the root file system with a label of linux-root. That is partition 7, which is ext4. I wrote a tumbleweed aarch64 root file system on partition 7 and installed ayufan4's patched 4.4 kernel there. That booted up pretty well (headless) with a serial console and I continued from there with ssh. I then got opensuse's current kernel from https://github.com/openSUSE/kernel I then merged ayufan4's mainline patches from https://github.com/ayufan-rock64/linux-mainline-kernel I was AMAZED that worked since I have very little experience with git or kernel patching. There was one conflict, which was easy to fix. I concatenated ayufan's kernel config with the opensuse config (are you allowed to do that?) and make menuconfig sorted it out. I turned on support for ceph and turned off support for various things like nvidia and Plan 9. After many days of running builds I got a configuration that worked. I did all that on the rock64. I ended up using -j1 with make because the compiler would seg fault otherwise. I built a binary RPM from this to make it easy to keep track of. The kernel and initrd end up in /boot on partition 7. I had to manually copy them to partition 6 and update the extlinux.conf file to point at the new files. You can't use symbolic links in a vfat. This kernel seems to work well. Ceph didn't work because there was a relocation error loading it's module. This is a known bug in gcc. I decided to build ceph into the kernel (instead of a module) and everything works. When I had everything working from a SDHC card I copied it to the EMMC. I also installed u-boot on the SPI flash using this procedure: https://github.com/ayufan-rock64/linux-build/releases/download/0.6.22/u-boo… Once you have a image on the emmc you have to install a jumper if you want to boot from a sdhc again. I got long jumpers to make it easy to do this. I now have opensuse running on all 5 rock64's and a ceph cluster on them. I put a usb3 enclosure on each machine with a SSD and a large spinning disk. This isn't very fast but it works. ayufan4 has done great work! He solicits a beer (via paypal) if you like his work. I will have to send him a few. I think he is in southern Italy. Do Italians have pizza with their beer? Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem
by Matwey V. Kornilov 28 Feb '18

28 Feb '18

Hi, I am faced the issue that recent JeOS builds cannot be read by u-boot: ls mmc 1:2 / Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** And then dtb files cannot be read from /boot partition. Even without dtb, EFI application cannot be read correctly here: reading efi/boot/bootaa64.efi MMC: block number 0x100008005 exceeds max(0x1dacc00) MMC: block number 0x100008005 exceeds max(0x1dacc00) Invalid FAT entry 6144 bytes read in 11 ms (544.9 KiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 02000000 ... Unknown Relocation off ffe type f ## Application terminated, r = 9223372036854775806 EFI LOAD FAILED: continuing... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 9

[opensuse-arm] I can't no longer connect by ssh
by victorhck 19 Feb '18

19 Feb '18

Hello! Today I made a zypper dup in my RaspberryPi 3 with Tw and that was what I get: zypper dup Recuperando los metadatos del repositorio openSUSE-Ports-Tumbleweed-repo-oss ..................................................................................[terminado] Construyendo el caché del repositorio openSUSE-Ports-Tumbleweed-repo-oss ......................................................................................[terminado] Cargando datos del repositorio... Leyendo los paquetes instalados... Calculando actualización de distribución... El siguiente paquete NUEVO va a ser instalado: raspberrypi-firmware-config El siguiente paquete va a ser ELIMINADO: raspberrypi-firmware-config-rpi3 Los siguientes 6 paquetes van a ser actualizados: libjemalloc2 openSUSE-release openSUSE-release-ftp raspberrypi-firmware yast2-core yast2-update El siguiente producto va a ser actualizado: openSUSE Tumbleweed 20180208-0 -> 20180218-0 After finished the installation I made a reboot, and now I can't connect via ssh by wifi It was removed the firmware-config-rpi3, and installed firmware-config ¿? any clue? do you need more information? 've phun! PS: I think this is my first post in this mailing list, sorry if I'm a bit newbie... -- ------------------- GPG Key: 0xcc742e8dc9b7e22a Fingerprint = 6FE2 3B1F AAC8 E5B7 63EA 88A9 CC74 2E8D C9B7 E22A Aprende a proteger la privacidad de tu correo: https://emailselfdefense.fsf.org/es/ Mi blog sobre openSUSE, GNU/Linux y software libre: https://victorhckinthefreeworld.com/

2 2

[opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7
by Matwey V. Kornilov 17 Feb '18

17 Feb '18

Hi, I am trying to run openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw using qemu. When I use qemu-system-aarch64 with 64-bit UEFI code aavmf-aarch64-code.bin then the only I see is the EFI console: UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820 EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18 UEFI v2.60 (EDK II, 0x00010000)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710 Mapping table FS0: Alias(s):HD1a0b:;BLK2: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004) BLK5: Alias(s): VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3) BLK0: Alias(s): VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F) BLK1: Alias(s): VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0) BLK3: Alias(s): VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004) BLK4: Alias(s): VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781) Press ESC in 1 seconds to skip startup.nsh or any other key to continue. FSOpen: Open '\startup.nsh' Success FSOpen: Open '\startup.nsh' Success FSOpen: Open '\startup.nsh' Success Shell> bootarm FSOpen: Open '\efi\boot\bootarm.EFI' Success FSOpen: Open '\efi\boot\bootarm.EFI' Success FSOpen: Open '\efi\boot\bootarm.EFI' Success FSOpen: Open '\efi\boot\bootarm.EFI' Success [Security] 3rd party image[0] can be loaded after EndOfDxe: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI. InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440 Unloading driver at 0x00000000000 Shell> Error Status: Unsupported (line number 1) As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and run 32-bit EFI executable. When I try to use qemu-uefi-aarch32.bin as firmware, then I see the following: Initialization of device cfi.pflash01 failed: failed to read the initial flash content As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but there are no other files in ovfm rpm package. What is the proper way to run JeOS-efi.armv7? Is it supposed to work in qemu? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 23

[opensuse-arm] Initrd.vmx too big
by Guillaume Gardet 16 Feb '18

16 Feb '18

Hi, I just tested the latest Tumbleweed image for my Beagleboard xM and the boot fails because the initrd is too big (209M uncompressed) for the RAM. I quick search shows that: * /usr/lib/python3.6/ is 36M. Do we really need python libs in initrd? * /usr/lib/sysimage/rpm is 19M. Not really useful I guess? * /usr/lib/grub2 is 27M. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 12

[opensuse-arm] Change to the rebuild behavior of openSUSE:Factory:ARM
by Dirk Müller 15 Feb '18

15 Feb '18

Hi, We had a couple of issues related to getting a new build of Factory into openqa recently. This was partially caused by ARM not able to catch up with the check in frequency of x86. To some extend this was bad luck (the critial long running build job hitting the slowest / misconfigured worker taking forever to finish) and to some extend we just can't keep up I guess. Over the last few days Alex and I have reconfigured the workers to be less overcommitted and redirecting more resource intensive jobs to the better performing variants. hopefully this helps with the overall build speed and gets us to catch up. In addition, there is a rebuild counter sync endless-loop issue that isn't fully understood yet, but apparently either aarch64 or armv7l were playing ping pong rebuilds with each other. we've stabilized that by disabling armv7l build temporarily (it is reenabled now). Last but not least as an experiment we've changed the source rebuild behavior. previously, Factory:ARM was directly using the sources from Factory, so whenever there was a source change there it immediately propagated to ARM. that contributed to rarely be able to finish a ftp tree build (because that one only starts when nothing else is building, and it takes a couple of hours to complete). without a ftp tree build, new DVDs are not entering openqa. So as an experiment we've switched to frozen links. this means we're linking sources from a particular level (0201 right now) of factory, and won't get automatic updates. That seems to work fine. unfortunately the "updating link" operation crashes the build service with an error 500, so we can't update anymore, and need an admin to fix that for us. The command to update the source state to build against is this: osc api -X POST '/source/openSUSE:Factory:ARM?cmd=freezelink' It needs to be run by someone who has maintainer rights in that project. currently it crashes though. Unfortunately I'll be out for a few days (vacation), so I hope alex or Andreas can figure out together with the OBS team on how to get that issue fixed. The plan is to add that into the totest manager, so that we're only taking source changes once when we just have handed off a build to openqa. this way we might not try to do every snapshot that x86 publishes, but if we were able to finish one, we take the next one from aarch64 (potentially skipping one or two interim ones on x86). this part isn't implemented yet though, I'll look at that end of next week. TIA, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 7

[opensuse-arm] Leap 15
by Bill Merriam 09 Feb '18

09 Feb '18

Is there any way to test Leap 15 on aarch64? Will aarch64 be there when 15 is released? Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] Out of memory problems with AArch64 workers
by Guillaume Gardet 04 Feb '18

04 Feb '18

Hi, In my OBS JeOS branch I cannot build AArch64 images because of early "out of memory" errors. I guess there is a problem with our AArch64 workers? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 4