wrong access rights for dpkg-deb after U-Boot build

[akifu]

I an new in building ARMBIAN. I have native:

'

Distributor ID: Ubuntu
Description:    Ubuntu 16.04.2 LTS
Release:        16.04
Codename:       xenial

 

with a nfs-mounted share on my NAS as working directory.

 

[ o.k. ] Building deb [ linux-u-boot-dev-bananapim2ultra_5.27_armhf.deb ]

dpkg-deb: Fehler: Control-Verzeichnis hat falsche Zugriffsrechte 770 (muss >=0755 und <=0775 sein) -> Sorry, I have German settings in my linux: I translate it corresponding:

                  Error: Control-Directory has wrong access rights 770 (must be >=755 and <= 775)
[ error ] ERROR in function compile_uboot [ common.sh:156 ]
[ error ] Building u-boot package failed

 

I can put a chmod -R command into common.sh but afterwards all updates will be denied.

It seems to be an easy issue maybe something around the build environment or s.th with the nfs - options in my mount-point.

 

 

[tkaiser]

12 hours ago, akifu said:

bananapim2ultra

 

Why? What do you expect? It won't work anyway. Fortunately for you NFS umask troubles already prevent you from further wasting time  

[gilles]

Hi I have the same trouble but I have not NFS mounting, everythings are local disk. I use Bash environement for windows 10 with xenial distribution. Do you have some advice ?

Thanks for your answer.

G*

[tkaiser]

1 hour ago, gilles said:

Do you have some advice ?

 

What about switching from an unsupported build system known to fail (Bash environement for windows 10) to any of the supported and working build systems listed here: https://docs.armbian.com/Developer-Guide_Build-Preparation/#what-do-i-need? 

 

(BTW: we need to remove 14.04 entirely since first problems occured even when just building kernel IIRC).

 

Using real virtualization with Virtualbox for example on any platform (including Linux) is highly recommended and when setting things up correctly even NFS isn't a problem any more (putting a 20 GB disk container on an NFS share will also greatly improve performance even with thin provisioning)

[akifu]

Have done as recommended. Now build-Env is VirtualBox with Xenial as guest and all build targets of Bananapi m2u(WIP) w/wo desktop or Jessy alone up to ubuntu-desktop is buildable. But no kind of image on sd-card is running. My only real experience with this kind of HW is legacy kernel V3.4.x so my first idea was to mount the image in loop to see what is inside. Indeed a rootfs is in but nothing else. I think s.th is missing to boot with the bootrom-code of the SOC which should be in the linear space of the sd-card at the beginning, but maybe the m2u can already boot ext4-FS already from Cold-Boot. All image I have seen until now are more or less 7GB or greater but even the Ubuntu-desktop version is only halfe in size. All other are not more than 2GB and they are definitly no .zip-archives.

Question: What is the next step when an image seems not running at all (no LED is blinking) is there any chance to see s.t. over UART com of the board at a phase where also u-boot is not running ? Is it better to use the .deb-files from a mounted USB-stick and install all components on this way?

[Igor]

WIP targets might not be done to the level that they boot. In any case, support for this board is very minimal and there is no much interest or activity. I can only delete the board out of config to save us answering that we cant help at this stage.

Wrote on mobile

[tkaiser]

31 minutes ago, akifu said:

Bananapi m2u(WIP)

Please tell us what you think 'WIP' could mean and how we can save you from wasting your time trying to get unsupported hardware running and us answering the same questions over and over again.

[akifu]

At the beginning I thought that all kind of open source projects are in basic a challange to get s.th running nevertheless it is easy or not. When a HW is easy to use then it must be a Windows PC or an Apple-Macintosh to compare with. The mentioned m2u is very new and I very understand that it is not perfect like it was at the beginning of the so famous RaspberryPI, now. As far as I can see all around is, that sunxi is working on mainline kernel also for R40 and also BPI delivers more and more.

My qustions are NOT going to to blame s.o. job, I ask to get information for first steps to develop and improve like everyone in the commutity. I am realistic enough to see that it is not possible to get the solutions to every problem for this kind of HW, but as it already has proved to run LINUX and ANDROID more or less stable (more less) it is time to think about it. I had very good experience with the LeMaker M2 w their 7"LCD with mali driver and self generated Kodi on it so why not continue with the m2u.

[martinayotte]

BTW, I've built a Armbian_5.27_Bananapim2ultra_Debian_jessie_dev_4.11.0-next-20170427.img image 2 days ago, and it is booting fine.

The only thing is that the WiFi AP6212 isn't in good shape yet : wlan0 could be activated, but the issue is that it doesn't receive response from DHCP request.

I think it is due to the fact that WL-WAKE is connected to AXP GPIO instead of PLx, and therefore the NMI is managed well.

 

[akifu]

OK, then it must be something easy to understand: Lets see to beginn systematic:

1. My Armbian_5.27_Bananapim2ultra_Debian_jessie_dev_4.11.0-next-20170427.img is (1.346.371.584 Bytes in size.

2. It has one partition

./Armbian_5.27_Bananapim2ultra_Debian_jessie_dev_4.11.0-next-20170427.img1      

2048 2629631  2627584  1,3G 83 Linux

nothing else.

3. I have used a sundisk ultra 32GB formated with SDFormater and used Win32DiskImager both under Windows 7.

4. I have replugged it in the Windows-PC and it could not use it at all (what wonder why) it has only a LINUX partition.

5. I have put it into the bananapim2u and replugged the power supply and nothing happens,

What is wrong ?

With the BPI -Images Debian Jessy or Ubuntu my HW-works, but as it is already known that s.th is wrong with the DDR-SDRAM-MenControllerConfig it is running 10-30 Minutes under memtester until it freezes.

[zador.blood.stained]

32 minutes ago, akifu said:

My qustions are NOT going to to blame s.o. job, I ask to get information for first steps to develop and improve like everyone in the commutity. I am realistic enough to see that it is not possible to get the solutions to every problem for this kind of HW, but as it already has proved to run LINUX and ANDROID more or less stable (more less) it is time to think about it. I had very good experience with the LeMaker M2 w their 7"LCD with mali driver and self generated Kodi on it so why not continue with the m2u.

For some reason you ignored @tkaiser's words

On 22.05.2017 at 10:48 AM, tkaiser said:

What do you expect? It won't work anyway.

and still are complaining that the image doesn't work.

 

First steps in developing for R40 and Armbian - go to https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix and wait first until R40 column appears in the table and then wait until at least third of the cells for it are marked light green and another third is marked bright yellow. Experience with other images on M2U or images on other boards certainly doesn't matter here.

 

5 minutes ago, akifu said:

What is wrong ?

That I still don't see a serial console log which is a prerequsite for saying that something "doesn't work" or "nothing happens", especially for targets marked as WIP.

 

1 hour ago, Igor said:

WIP targets might not be done to the level that they boot. In any case, support for this board is very minimal and there is no much interest or activity. I can only delete the board out of config to save us answering that we cant help at this stage.

And instead of doing release preparations we now have to think about putting extra dialogs and warnings for WIP targets and hope that this will help with avoiding wasted time with support requests for them.

[akifu]

Defintly nobody wants to have such useless warning messages. I only have a fact and need a hint to handle this as I am a beginner. A beginner in developing for Linux on SBCs as I am one for developping under vxVorks for Altera SoCs which is only little comparable and in my case I have a Lauterbach debugger to work with and as far as I know it is neither available on bananaPi nor on RaspberryPi so there must be an other way to do a board bringup from souce level. It is much easier to say that you have no idea what to do than this thread is finished very fast.

[martinayotte]

Did you plug a USB-TTL Serial adaptor to do debugging ?

You should see the login prompt without any problem.

That said, this image is WIP, WiFi still glitchy, and EMAC not yet implemented.

But that doesn't prevent Armbian for booting, so in the meantime, I'm using MT7601 USB dongle to get networking ...

 

[tkaiser]

7 hours ago, akifu said:

Defintly nobody wants to have such useless warning messages

 

Ok, so let's delete the WiP targets now (I just deleted 'my' .wip board). Better approach: Stop encouraging users rejecting reality (remove the dialog 'show wip targets', stop providing nightlies -- they are good for nothing except rising expectations and flooding the forum with the same questions over and over again).

 

@martinayotte: This here is not about encouraging a user to provide feedback on something that doesn't work yet (since the next questions will be: what about Mali, video and so on), this is about thinking about this project in a whole. At least I don't want to spend that much time on useless things any more.

[tkaiser]

8 hours ago, akifu said:

LeMaker M2 w their 7"LCD with mali driver and self generated Kodi on it so why not continue with the m2u

There has never been a 'LeMaker M2' and SinoVoip's M2 has no Mali but PowerVR instead (with this M2 neither 3D nor video acceleration works). If you were talking about M1 instead I fear you either don't care that much about details or missed that two different SoCs are WAY MORE IMPORTANT than a stupid hardware vendor trying to sell all his ABSOLUTELY INCOMPATIBLE boards with a similar name. Those Banana morons today sell M2, M2+, M2 Ultra, M2 Magic and soon also M2 Berry. Only Berry and Ultra are somewhat compatible since the Berry inherits shitty software and support situation from Ultra but will cause even more problems due to crappy Micro USB for DC-IN.

 

M2 = A31s, M2+ = H3, M2 Ultra/Berry = R40, M2 Magic = R16 (which is an A33 in reality, we're dealing with here even with 'marketing by obfuscation'). There you go as @zador.blood.stainedalready outlined: http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix

 

If the Armbian project wants to focus on something relevant we should stop supporting crappy hardware. But that's obviously just me and others seem to love threads like this.

 

Edit: My definition of 'Armbian project' was being the bridge between kernel developers and end users. Caring about settings and details, spending an insane amount of time on research/testing and optimizing details, collecting patches, assembly everything to an easy to use OS image that ships with sane defaults (performance and security) and receives upgrades. This was never about providing shitty OS images people can complain about (since this and that doesn't work yet but users don't want to understand -- that's the 'nightlies' situation currently. Now it seems if we don't provide nightlies for reasons for a board users expect to be somehow related with Armbian users start to mis-use the build system to try to create shitty OS image with it on their own. And ask even for support if they fail. And we even try to deal with this over and over again instead of re-thinking the whole approach)

 

 

[tkaiser]

Edited May 26, 2017 by tkaiser
Instead of 'fighting' against hardware vendors providing crappy hardware with wrong specifications it's better to simply give up on this. If Armbian wants to go Raspbian why not...