January 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-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] armv6 images publish problem
by Guillaume Gardet 31 Jan '18

31 Jan '18

Hi, If you check the armv6 download area here: http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ You can see that there are problems: # *-raspberrypi images are outdated whereas newer images are build ok (openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv7l-2018.01.22-Build1.6.raw.xz has been built) # We have outdated *armv6-rootfs.armv6l* images AND newer *-armv6-rootfs.armv7l* images I think the publish script has some problem with *-raspberrypi and we should remove old rootfs images. I wanted to fill a bug but I do not know which category to use. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

[opensuse-arm] Repository for openSUSE Tumbleweed architecture aach64 is not kept up-to-date
by Freek de Kruijf 30 Jan '18

30 Jan '18

I filed a bug report with this subject as: https://bugzilla.opensuse.org/show_bug.cgi?id=1077011 I am using the image for the Raspberry Pi 3, which is available via OBS and which is build using the newest packages also available in OBS. This image should be available in the regular repository, also mentioned in the wiki. Also the newest packages should be available via the repository zypper uses to upgrade Tumbleweed, which is currently not the case. Can I be of any help with this? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 14

[opensuse-arm] Old ARM boards status
by Guillaume Gardet 26 Jan '18

26 Jan '18

Hi, I updated HCL pages on the wiki for ARM devices by removing links to images which are unavailable (12.x, 13.x, etc.) and by adding TW and 42.3 links when images are available. Two boards seem to be not supported anymore: * Efika MX : OBS 12.3 contrib project is now empty and there is no upstream support. * Highbank : OBS 12.3 contrib project is now empty. There is only u-boot-highbank package in hardware:boot. Should we remove those 2 wiki pages, or at least write that those boards are no more supported? If those boards are still supported, please tell me. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 2

[opensuse-arm] Serial line after booting Raspberry Pi 3 with Tumbleweed does not work
by Freek de Kruijf 25 Jan '18

25 Jan '18

I did put the image: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2018.01.19-Build3.3.raw.xz on a micro-SD card and booted the system with the serial line connected. I get some data on that serial line in the beginning, only after that nothing. Also a reboot shows some data, but I do not get a login prompt. I am able to connect via ssh to that system and use it. I found some information about not using /dev/ttyAMA0 because that one is used on the RPi3 for bluetooth, but /dev/ttyS0 should be used. I tried to start both with: "systemctl start getty(a)ttyAMA0.service" and "systemctl start getty(a)ttyS0.service" but the serial line does not work. How do I enable the use of the serial line. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

[opensuse-arm] RPi3 Leap image links broken
by Alexander Graf 24 Jan '18

24 Jan '18

Hi Adrian, We just had an openSUSE user report on IRC that the Leap 42.3 image links for the RPi3 are broken - and they indeed are: http://download.opensuse.org/ports/aarch64/distribution/leap/42.3/appliance… This is the link we provide on the web page. If you look at the directory, you will see that there is a properly built image: openSUSE-Leap42.3-ARM-JeOS-raspberrypi3.aarch64-2017.07.26-Build1.1.raw.xz but with full name indicating the build date. We usually have short links for those to allow links from the outside world. IIUC they get created in the publishing step, right? Funnily enough, we do have short links for "tbz" targets, but our "raw.xz" ones are all missing them. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 7

[opensuse-arm] Tumbleweed image for Raspberry Pi 2 contains a corrupt ext4 partition after first boot
by Freek de Kruijf 13 Jan '18

13 Jan '18

I used two images from repository: http://download.opensuse.org/ports/aarch64/tumbleweed/images/ namely: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2017.12.14-Build1.9.raw.xz openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2017.12.14-Build1.10.raw.xz The first one comes up properly. However "fdisk -l /dev/mmcblk0" shows: Disk /dev/mmcblk0: 7,5 GiB, 8068792320 bytes, 15759360 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: FDA566EC-2187-40A0-8357-DCB2E5B6F63D Device Start End Sectors Size Type /dev/mmcblk0p1 2048 411651 409604 200M Linux filesystem /dev/mmcblk0p2 413696 839683 425988 208M Linux filesystem /dev/mmcblk0p3 841728 14747670 13905943 6,6G Linux filesystem /dev/mmcblk0p4 14749696 15759326 1009631 493M Linux filesystem Strangely, "lsblk" shows: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 14,9G 0 disk ├─mmcblk0p1 179:1 0 200M 0 part /boot/efi ├─mmcblk0p2 179:2 0 14,2G 0 part / └─mmcblk0p3 179:3 0 485,7M 0 part [SWAP] While "parted -l" shows this: Model: SD 00000 (sd/mmc) Disk /dev/mmcblk0: 16,0GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 211MB 210MB fat16 vcboot 2 212MB 413MB 201MB ext4 lxboot legacy_boot 3 414MB 15,5GB 15,1GB lxroot 4 15,5GB 16,0GB 516MB linux-swap(v1) lxswap After the first boot the system behaves as if it has only three partitions, so like lsblk shows. However a reboot of this system shows an error message from script /boot/boot.scr about accessing something outside limits, I assume outside the second partition, and starts to try to boot from the network. The second image shows in the first boot lots of errors trying to start services. A reboot shows the same behavior as the first image. It looks like these images are not properly formatting the micro-SD card, and leave a corrupt ext4 partion on this card. I filed a bug report about this: https://bugzilla.opensuse.org/show_bug.cgi?id=1075094 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 8