[opensuse-arm] Re: Re : [opensuse-arm] Latest Chromebook images
Hi, I was trying something different to get the chromebook working: I found in the Images.wiwi.in, that a lot of packages are marked as PKG_BOOT_TAG and that way included in the initrd, suchas vboot, gptfdisk,mrvl-firmware, which shouldnt be needed for booting imo. I reduced those to just PKG_BOOT_TAG(u-boot-chromebook), PKG_BOOT_TAG(dtb-exynos5), which resulted in a smaller initrd that loaded without warnings. But then I get just a black screen after the kernel is (hopefully) started. In my opinion, this initrd is far too huge anyway, and I wonder why that is. Josua Mayer Am 05.02.2014 20:46, schrieb guillaume.gar...@free.fr: Hi, - Daniel Bischof a écrit : Hi, are the latest Chromebook images supposed to work? I tried the most recent Factory-ARM-XFCE-chromebook.armv7l-1.12.1-Build169.2 (of today) and got No. The problem is "ext2fs doesn't support tripple indirect blocks" which prevent to load all the initrd. I am working on upstream u-boot which could fix that. But it is not yet ready. :( Guillaume - ** File not found uEnv.txt Loading file "boot.scr" from mmc device 1:2 (lxboot) 2138 bytes read Running bootscript ... ## Executing script at 40007000 mmc_init err 0, time 101923 mmc0(part 0) is current deuice Loading file "boot/linux.vmx" from mmc deuice 0:2 (KERN-A) Failed to mount ext2 filesystem ... ** Bad ext2 partition or disk — mmc 0:2 ** mmc1 is current device Loading file "boot/linux.vmx" from mmc device 1:2 (lxboot) 3568304 bytes read Loading file "boot/initrd.uboot" from mmc device 1:2 (lxboot) ** ext2fs doesn't support tripple indirect blocks. ** ** Unable to read "boot/initrd.uboot" from mmc 1:2 ** Loading file "dtb/exynos5250—snow.dtb" from mmc device 1:2 (lxboot) 34150 bytes read ## Booting kernel from Legacy Image at 40007000 ... Image Name: Linux—3.4.0—2—chromebook Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3568240 Bytes = 3.4 MiB Load address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 4f00 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 156490936 Bytes = 149.2 MiB Load Address: Entry Point: Verifying Checksum ... Bad Data CRC Ramdisk image is corrupt or invalid mmc0(part 0) is current device ** Block device usb 0 not supported mmc1 is current device ** Block device usb 1 not supported (Re)start USB... USB: Register 1313 NbrPorts 3 [USB] usb_lowlevel_init:852 0 [USB] usb_lowlevel_init:852 1 USB EHCI 1.00 1 USB Device(s) found scanning bus for storage devices ... 0 Storage Device(s) found Tring USB on device ** Block device usb 0 not supported ** Block device usb 0 not supported SMDK5250 # - on initial boot. Same result with most recent 13.1 images. Best regards, --D.B. -- Daniel Bischof -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re : [opensuse-arm] Latest Chromebook images
Hi, - Daniel Bischof a écrit : > Hi, > > are the latest Chromebook images supposed to work? I tried the most recent > Factory-ARM-XFCE-chromebook.armv7l-1.12.1-Build169.2 (of today) and got No. The problem is "ext2fs doesn't support tripple indirect blocks" which prevent to load all the initrd. I am working on upstream u-boot which could fix that. But it is not yet ready. :( Guillaume > > - > ** File not found uEnv.txt > Loading file "boot.scr" from mmc device 1:2 (lxboot) > 2138 bytes read > Running bootscript ... > ## Executing script at 40007000 > mmc_init err 0, time 101923 > mmc0(part 0) is current deuice > Loading file "boot/linux.vmx" from mmc deuice 0:2 (KERN-A) > Failed to mount ext2 filesystem ... > ** Bad ext2 partition or disk — mmc 0:2 ** > mmc1 is current device > Loading file "boot/linux.vmx" from mmc device 1:2 (lxboot) > 3568304 bytes read > Loading file "boot/initrd.uboot" from mmc device 1:2 (lxboot) > ** ext2fs doesn't support tripple indirect blocks. ** > ** Unable to read "boot/initrd.uboot" from mmc 1:2 ** > Loading file "dtb/exynos5250—snow.dtb" from mmc device 1:2 (lxboot) > 34150 bytes read > ## Booting kernel from Legacy Image at 40007000 ... > Image Name: Linux—3.4.0—2—chromebook > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 3568240 Bytes = 3.4 MiB > Load address: 40008000 > Entry Point: 40008000 > Verifying Checksum ... OK > ## Loading init Ramdisk from Legacy Image at 4f00 ... > Image Name: Initrd > Image Type: ARM Linux RAMDisk Image (uncompressed) > Data Size: 156490936 Bytes = 149.2 MiB > Load Address: > Entry Point: > Verifying Checksum ... Bad Data CRC > Ramdisk image is corrupt or invalid > mmc0(part 0) is current device > ** Block device usb 0 not supported > mmc1 is current device > ** Block device usb 1 not supported > (Re)start USB... > USB: Register 1313 NbrPorts 3 > [USB] usb_lowlevel_init:852 0 > [USB] usb_lowlevel_init:852 1 > USB EHCI 1.00 > 1 USB Device(s) found > scanning bus for storage devices ... 0 Storage Device(s) found > Tring USB on device > ** Block device usb 0 not supported > ** Block device usb 0 not supported > SMDK5250 # > - > > on initial boot. Same result with most recent 13.1 images. > > > Best regards, > > --D.B. > -- > Daniel Bischof -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] Latest Chromebook images
Hi, are the latest Chromebook images supposed to work? I tried the most recent Factory-ARM-XFCE-chromebook.armv7l-1.12.1-Build169.2 (of today) and got - ** File not found uEnv.txt Loading file "boot.scr" from mmc device 1:2 (lxboot) 2138 bytes read Running bootscript ... ## Executing script at 40007000 mmc_init err 0, time 101923 mmc0(part 0) is current deuice Loading file "boot/linux.vmx" from mmc deuice 0:2 (KERN-A) Failed to mount ext2 filesystem ... ** Bad ext2 partition or disk — mmc 0:2 ** mmc1 is current device Loading file "boot/linux.vmx" from mmc device 1:2 (lxboot) 3568304 bytes read Loading file "boot/initrd.uboot" from mmc device 1:2 (lxboot) ** ext2fs doesn't support tripple indirect blocks. ** ** Unable to read "boot/initrd.uboot" from mmc 1:2 ** Loading file "dtb/exynos5250—snow.dtb" from mmc device 1:2 (lxboot) 34150 bytes read ## Booting kernel from Legacy Image at 40007000 ... Image Name: Linux—3.4.0—2—chromebook Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3568240 Bytes = 3.4 MiB Load address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 4f00 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 156490936 Bytes = 149.2 MiB Load Address: Entry Point: Verifying Checksum ... Bad Data CRC Ramdisk image is corrupt or invalid mmc0(part 0) is current device ** Block device usb 0 not supported mmc1 is current device ** Block device usb 1 not supported (Re)start USB... USB: Register 1313 NbrPorts 3 [USB] usb_lowlevel_init:852 0 [USB] usb_lowlevel_init:852 1 USB EHCI 1.00 1 USB Device(s) found scanning bus for storage devices ... 0 Storage Device(s) found Tring USB on device ** Block device usb 0 not supported ** Block device usb 0 not supported SMDK5250 # - on initial boot. Same result with most recent 13.1 images. Best regards, --D.B. -- Daniel Bischof
[opensuse-arm] [PATCH] Enable XENFS on ARMv7 & ARMv8 needed for running Xen hypervisor
Hi, If possible could you apply the attached patch to both Factory and 13.1 kernels? Many thanks, Andy 0001-Enable-XENFS-on-ARMv7-and-ARMv8.patch Description: Binary data
Re: [opensuse-arm] Please trigger rebuild of openSUSE:Factory:ARM > ImageMagick
On Mittwoch, 5. Februar 2014, 12:34:40 wrote Dirk Müller: > Hi Guillaume, > > > What is the advantage of your cron job vs an OBS auto trigger? > > Needed rebuild are triggered. No? > > The direct rebuild flag works different from the "cron job". The cron > job rebuilds packages that became uninstallable. The direct rebuild > rebuilds all direct dependencies of a changed package, which is > usually significantly more. Furthermore it is the "cron job" is the > same method that openSUSE Factory works. > > I agree with you that the "uninstallable rebuild" flag should be > implemented in OBS, but it is not. > > > With build-compare, there is no unneeded rebuilds, so it should be fine and > > would avoid some errors. > > build-compare is throwing away build results if they were determined > to "not matter". Which means the build power is already wasted. yes, but it reduces at least indirect builds. > build-compare reduces download/update time for someone using zypper up > / dup to keep his system fresh, it does not reduce the number of > rebuilds in our "local" build mode. > > > Greetings, > Dirk > -- Adrian Schroeter email: adr...@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Please trigger rebuild of openSUSE:Factory:ARM > ImageMagick
Hi Guillaume, > What is the advantage of your cron job vs an OBS auto trigger? > Needed rebuild are triggered. No? The direct rebuild flag works different from the "cron job". The cron job rebuilds packages that became uninstallable. The direct rebuild rebuilds all direct dependencies of a changed package, which is usually significantly more. Furthermore it is the "cron job" is the same method that openSUSE Factory works. I agree with you that the "uninstallable rebuild" flag should be implemented in OBS, but it is not. > With build-compare, there is no unneeded rebuilds, so it should be fine and > would avoid some errors. build-compare is throwing away build results if they were determined to "not matter". Which means the build power is already wasted. build-compare reduces download/update time for someone using zypper up / dup to keep his system fresh, it does not reduce the number of rebuilds in our "local" build mode. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] clamav not available on openSUSE 13.1 repository for armv6hl
Freek de Kruijf writes: > I played around on the OBS website branching security:clamav, but this one > did > not have a possibility to add the armv6l architecture. You'll need to add a new repository that points to openSUSE:Factory:ARM. For openSUSE:13.1:Update you are SOL, unfortunately, since it isn't set up to build for armv6l. Andreas. -- Andreas Schwab, SUSE Labs, sch...@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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] clamav not available on openSUSE 13.1 repository for armv6hl
Le 05/02/2014 11:49, Freek de Kruijf a écrit : > Op dinsdag 4 februari 2014 14:35:06 schreef Freek de Kruijf: >> Op dinsdag 4 februari 2014 13:49:18 schreef Andreas Schwab: >>> Freek de Kruijf writes: Please give me some hints, how to proceed and where and what to branch. >>> Once you have branched it you can additional architectures to the >>> project configuration in your branch. >> I want to build clamav for openSUSE 13.1, so should I branch openSUSE 13.1 / >> clamav? However there is no openSUSE:13.1:Update repository for armv6l to >> which I assume the result should be committed. >> >> This is because I am using the newest RaspberryPi image in a test Raspberry >> PI, which only has the openSUSE 13.1 oss repository. I could not find any >> additional repository. > I played around on the OBS website branching security:clamav, but this one > did > not have a possibility to add the armv6l architecture. At least I could not > find that possibility. I could find setting a repository to include armv6l, > but I could not find a way to branch clamav into that repository. So I need > some help to continue. > Have a look at 'osc branch --help' for info on how to branch a package into a given repo. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] clamav not available on openSUSE 13.1 repository for armv6hl
Op dinsdag 4 februari 2014 14:35:06 schreef Freek de Kruijf: > Op dinsdag 4 februari 2014 13:49:18 schreef Andreas Schwab: > > Freek de Kruijf writes: > > > Please give me some hints, how to proceed and where and what to branch. > > > > Once you have branched it you can additional architectures to the > > project configuration in your branch. > > I want to build clamav for openSUSE 13.1, so should I branch openSUSE 13.1 / > clamav? However there is no openSUSE:13.1:Update repository for armv6l to > which I assume the result should be committed. > > This is because I am using the newest RaspberryPi image in a test Raspberry > PI, which only has the openSUSE 13.1 oss repository. I could not find any > additional repository. I played around on the OBS website branching security:clamav, but this one did not have a possibility to add the armv6l architecture. At least I could not find that possibility. I could find setting a repository to include armv6l, but I could not find a way to branch clamav into that repository. So I need some help to continue. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Please trigger rebuild of openSUSE:Factory:ARM > ImageMagick
Le 04/02/2014 22:17, Dirk Müller a écrit : > Hi *, > >>> Could you, trigger rebuild of openSUSE:Factory:ARM > ImageMagick. >> done > Normally those manual rebuilds should not be necessary, as I have a > cron job running that does that. There was apparently an error around > ImageMagick now, hopefully fixed. What is the advantage of your cron job vs an OBS auto trigger? Needed rebuild are triggered. No? > >> yes at least direct dependencies. >> Is someone objecting in changing this? > Well, at least for armv7l we don't have the build power in doing so, > and since the rebuild script works just fine (normally), I didn't see > the need for rebuilding with direct dependencies. With build-compare, there is no unneeded rebuilds, so it should be fine and would avoid some errors. Just my 2 cents. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
