Re: [opensuse-arm] Re: Re : [opensuse-arm] Latest Chromebook images

2014-02-06 Thread Guillaume Gardet
Hi,


Le 06/02/2014 08:49, Josua Mayer a écrit :
> 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),

No, it is there to be included in /boot partition. Marcus, am I right?
But yes, we may remove vboot, etc. from PKG_BOOT_TAG. Dirk, Alex, are you OK 
with that?

> 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.

Initrd is big for 1st boot because we need to repartition SD card and thus 
embed some tools in initrd. Then, initrd is regenerated and should not be too 
big anymore.


Guillaume


>
> 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] Re: Re : [opensuse-arm] Latest Chromebook images

2014-02-06 Thread Alexander Graf

On 06.02.2014, at 11:58, Guillaume Gardet  wrote:

> Hi,
> 
> 
> Le 06/02/2014 08:49, Josua Mayer a écrit :
>> 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),
> 
> No, it is there to be included in /boot partition. Marcus, am I right?
> But yes, we may remove vboot, etc. from PKG_BOOT_TAG. Dirk, Alex, are you OK 
> with that?

We need them during the u-boot-install.sh phase. IIRC the way to get it 
available there was to make it PKG_BOOT_TAG. Right, Marcus?


Alex

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



Re: [opensuse-arm] Re: Re : [opensuse-arm] Latest Chromebook images

2014-02-06 Thread Guillaume Gardet

Le 06/02/2014 12:03, Alexander Graf a écrit :
> On 06.02.2014, at 11:58, Guillaume Gardet  wrote:
>
>> Hi,
>>
>>
>> Le 06/02/2014 08:49, Josua Mayer a écrit :
>>> 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),
>> No, it is there to be included in /boot partition. Marcus, am I right?
>> But yes, we may remove vboot, etc. from PKG_BOOT_TAG. Dirk, Alex, are you OK 
>> with that?
> We need them during the u-boot-install.sh phase. IIRC the way to get it 
> available there was to make it PKG_BOOT_TAG. Right, Marcus?

No, I added them in prjconf to pre-install them with:
Preinstall: vboot
Preinstall: gptfdisk

Otherwise, they were ot availaible.


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

2014-02-06 Thread Freek de Kruijf
Op woensdag 5 februari 2014 12:23:40 schreef u:
> 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.

I branched security:clamav as a subproject of my home project for 
openSUSE:Factory:ARM and did set three architectures: armv6l, armv7l and 
aarch64. It has build OK for the first two architectures, the last one is 
blocked. So what should I do next, apart from trying to use the build clamav 
on my Raspberry Pi?

-- 
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] Re: Re : [opensuse-arm] Latest Chromebook images

2014-02-06 Thread Guillaume Gardet

Le 06/02/2014 08:49, Josua Mayer a écrit :
> 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.

This may be caused by a bad DTB file. kernel-chromebook provide 
"/boot/exynos5250-snow.dtb" and we actually use "/boot/dtb/exynos5250-snow.dtb" 
from dtb-exynos5 package.

Try to replace the DTB file in /boot/dtb/ with the one from kernel-chromebook 
package.


Guillaume


> 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] clamav not available on openSUSE 13.1 repository for armv6hl

2014-02-06 Thread Guillaume Gardet

Le 06/02/2014 14:09, Freek de Kruijf a écrit :
> Op woensdag 5 februari 2014 12:23:40 schreef u:
>> 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.
> I branched security:clamav as a subproject of my home project for 
> openSUSE:Factory:ARM and did set three architectures: armv6l, armv7l and 
> aarch64. It has build OK for the first two architectures, the last one is 
> blocked. So what should I do next, apart from trying to use the build clamav 
> on my Raspberry Pi?
>

It have been fixed in security:clamav, and forwarded to Factory, so just try 
it. ;)
See: https://build.opensuse.org/package/show/openSUSE:Factory:ARM/clamav


Guillaume

-- 
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

2014-02-06 Thread Andreas Färber
Am 05.02.2014 12:34, schrieb 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.
[snip]

So is anything rebuilding the tracker packages? They are listed under
zypper up on 13.1 but they're uninstallable due to some 0.16.2 vs.
0.16.3 hickups for at least a week already...

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org



Re: [opensuse-arm] Re: Re : [opensuse-arm] Latest Chromebook images

2014-02-06 Thread Guillaume Gardet

Le 06/02/2014 12:06, Guillaume Gardet a écrit :
> Le 06/02/2014 12:03, Alexander Graf a écrit :
>> On 06.02.2014, at 11:58, Guillaume Gardet  wrote:
>>
>>> Hi,
>>>
>>>
>>> Le 06/02/2014 08:49, Josua Mayer a écrit :
 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),
>>> No, it is there to be included in /boot partition. Marcus, am I right?
>>> But yes, we may remove vboot, etc. from PKG_BOOT_TAG. Dirk, Alex, are you 
>>> OK with that?
>> We need them during the u-boot-install.sh phase. IIRC the way to get it 
>> available there was to make it PKG_BOOT_TAG. Right, Marcus?
> No, I added them in prjconf to pre-install them with:
> Preinstall: vboot
> Preinstall: gptfdisk
>
> Otherwise, they were ot availaible.

I just submitted requests for 13.1:Ports and Factory:ARM for JeOS which fixes 
initrd problem thanks to your idea.
I reused (and tested) your idea except for mrvl-firmware (not sure if we could 
remove boot_tag for this one or not).


Guillaume

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