Re: Debian Bookworm+ on Cavium ThunderX?
On 2024-04-17 16:37 +0200, Steffen Grunewald wrote: > On Mon, 2024-04-15 at 14:55:06 +0800, Paul Wise wrote: > > On Fri, 2024-04-12 at 09:28 +0200, Steffen Grunewald wrote: > > > > > Any attempt to boot a Bullseye (5.x) or Bookworm kernel (6.x) resulted in > > > an early kernel panic. > That's the really time-consuming part... > I'm kind of surprised that nobody else seems to use this hardware platform? I think I had one in the past. I may still have one in the pile. If I can find it I'll try to take a look at this, but I'm short of tuits, especuially until the time64 transition is over the hump. Is yours actual ThunderX or ThunderX2? I recall the former being more or less unobtanium. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-27 22:30 +, Thorsten Glaser wrote: > >OK, got those. but that's just binaries. It was the source changes I > >was looking for (or did I misunderstand and you didn't actually make > >any of those?), > > Yes, I did not make any source changes. These were the last binaries > from before the t64 transition (I downloaded the .deb files unchanged) > with just control.tar.xz/control changed to allow installation given > the relevant libraries were already rebuilt for t64. OK. I get it now. > > but actually having an openjdk binaries is very useful > >too to satisfy the self-dependency without more faff. > > Yes, that was their purpose. And it worked beatifully. Thanks. armhf and armel uploaded and accepted half an hour ago (armel built by Andrey Rakhmatullin) I'll try doing openjdk-20 next. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-27 15:27 +, Wookey wrote: > On 2024-03-26 22:28 +, Thorsten Glaser wrote: > > > I hacked that, and I tried to do armel and armhf as well but > > dak stopped me, whereas mini-dak was not as strict. > > What was the actual problem with uploading the images you built? Just > not having any corresponding source? Or something more complicated? Answering my own question: There have been a couple of new openjdk-17 uploads (latest is: 17_17.0.11~7ea-1) so Thorsten's bootstrap build (17.0.10+7-1) is out of date. But it does a great job of filling the self-dependency so I can build the current version. So I now have all the pieces (on armhf, not checked armel yet but hopefully it matches) Building now... Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-26 22:28 +, Thorsten Glaser wrote: > I hacked that, and I tried to do armel and armhf as well but > dak stopped me, whereas mini-dak was not as strict. What was the actual problem with uploading the images you built? Just not having any corresponding source? Or something more complicated? It seems to me you've done all the hard work - we just need to work out how to get those packages into the archive. Maybe that needs a rebuild with corresponding source? Although if we already have the source just making a new changes file with all the right piece in should be enough, should it not? or am I missing something? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-26 10:35 +, Simon McVittie wrote: > It seems that some of the dependency chains for packages that are still > waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the > default Java version for most architectures and Build-Depends on itself > (with an alternative dependency on openjdk-16, but that no longer exists). > evolution-data-server -> libphonenumber-dev is an example. > > Are the ARM or Java teams intending to re-bootstrap openjdk-17 somehow? I looked at this last week, but got stuck because openjdk-17's build-deps included graphviz which was also uninstallable and led to another blocked chain with ghostscript,cups and libgtk2 conflicting about their t64 status. Checking again now, apt still complains: The following packages have unmet dependencies: apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be installed libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be installed libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be installed But dose now says there is a solution, unlike last week. So it should be possible to get the dependencies in place (without unreasonable jiggery-pokery) and bootstrap it. I'll have another go tomorrow. > Or do maintainers of packages that build both a C/C++ library and Java > bindings from a single source package need to disable its Java bindings > on the affected architectures, either temporarily or permanently? Some of that might still be expedient, but hopefully we can get a t64 java soon and it won't be necessary. We have to do that sooner or later anyway. > openjdk-21 is in a similar situation, build-depending on itself, while > openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively. > Presumably once we have a single OpenJDK version that is installable, > it would be possible to step through 18,19,20,21 building each version > with the previous one. I presume the same, but don't actually know how old a java you can use to bootstrap each newer java. Is it always just one version? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Really enable -fstack-clash-protection on armhf/armel?
On 2023-11-24 01:34 +0100, Guillem Jover wrote: > On Thu, 2023-11-23 at 10:45:33 +0100, Matthias Klose wrote: > > it looks like enabling this flag on armel/armhf is a little bit premature. > > In Ubuntu, people tracked down segfaults due to this change in at least > > valgrind and gnutls, maybe more. > > If there's some missing support somewhere that might make this a > common thing instead of just affecting a handful of packages that > could simply disable the flags, and the Arm porters consider that > fixing that is not feasible in the short term, I guess it makes > sense to stop emitting the flag for the arm32 arches. Assuming this problem only affects some packages they can have their build flags adjusted in the short term. dpkg-buildflags makes this straightforward. And we can investigate and fix in the longer term. So I don't think we need to turn it off for the whole architecture unless we find loads of stuff that is broken. Are there any bugs reports on how to reproduce issues? I just tried building gnutls28 both with and without fstack-clash-protection. It is one test better with -fstack-clash-protection enabled: dtls/dtls-resume.sh -fstack-clash-protection enabled disabled TOTAL: 501 501 PASS: 461 460 SKIP: 20 20 XFAIL: 00 FAIL: 20 21 XPASS: 00 ERROR: 00 So that's worthy of investigation, but suggests there is a problem here which scp isn't making worse. Some additional info from Richard Earnshaw: --- Note that for valgrind, I suspect the problem is that it has not been updated for the following, relatively recent, relaxation in the AAPCS: 6.2.1.3 Stack probing In order to ensure stack integrity a process may emit stack probes immediately prior to allocating additional stack space (moving SP from SP_old to SP_new). Stack probes must be in the region of [SP_new, SP_old - 1] and may be either read or write operations. The minimum interval for stack probing is defined by the target platform but must be a minimum of 4KBytes. No recoverable data can be saved below the currently allocated stack region. Prior to this addition (2018Q4) all accesses below SP were forbidden, and I think that's what valgrind still implements. --- So that does sound like valgrind needs an update for this, and yes it would have been better if that wasn't a surprise. My initial feeling is that we should just fix that, rather than reverting at this stage, but I understand what Adrien says about the Ubuntu cycle being at a different point and this being a change that is causing trouble there. Clearly only doing a rebuild for arm64 and assuming armhf would be fine because the compiler team here said it would be was overly optimistic. Sorry about that. I see that this has already been reverted in Ubuntu dpkg, which seems like the right thing to do there for the time being. For debian we'll keep an eye on it, do a belated rebuild to see how much of a problem we really have, and then decide if we should revert it too until some stuff if fixed. We should have a better idea of whether to go back or forward farily soon. I look forward to some more details on what actually broke (other than valgrind) soon. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Removing dpkg arch definition for arm64ilp32?
On 2023-11-11 18:57 +0100, Guillem Jover wrote: > Hi! > > On Fri, 2023-10-27 at 20:17:21 -0400, Lennart Sorensen wrote: > > On Fri, Oct 27, 2023 at 02:29:30PM +0100, Steve McIntyre wrote: > > > Are either of those ports (armeb/arm64ilp32) actually useful / alive > > > at this point? > > > > Not that I have seen. I didn't think anything other than the IXP ever > > really used big endian and that's a long time ago. arm64ilp32 seems > > to serve less purpose than x32 did (and x32 doesn't seem to be doing > > much either). Certainly looks essentially dead at this point. > > While scanning the libc-alpha list recently I read [M] that arm64ilp32 > was never upstreamed in Linux nor glibc? If so, I think there's little > point in carrying the arch definitions in dpkg, and I guess that would > not make the cut if requested now (for reference this was requested in > bug #824742). Does anyone know whether it was ever used or it is being > used even if privately/internally somewhere? It was being used internally/developmentally for a while (at CISCO) but, as you observe, only with large kernel and toolchain patches. Various groups dragged their feet on this to disourage it becoming a thing we'd all have to maintain for years. I was doing the debian development at ARM at the time and the bootstrap was never completed. A few people (largely just CISCO) wanted it quite badly. Nearly everyone else thought it was not worth the maintenance effort. No-one has asked about it for quite a few years now (last mail Oct 2018) so I think we can assume that it is indeed dead and no-one would notice for years/ever if you removed it from dpkg. > For armeb, I assume it was properly upstreamed at the time, and it was > actually used, even if it's currently not in use (like arm) I see tons > of references in Sources files, and thus removing the arch definitions > for either of these would not be safe right now I think. It is obsolete. It probably doesn't work any more having been unused since the early days of the NSLU2/Sarge (circa 2006/2007). It might still have been in use till 2011ish?. As you say it should probably be removed from upstream sources before it is removed from dpkg. Interesting question on how much effort (if any) (and when) should be applied to tidying up stuff like this which is simply no longer in use. If/when 'arm' is removed 'armeb' should certainly go with it. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel
On 2023-10-27 14:29 +0100, Steve McIntyre wrote: > > Are either of those ports (armeb/arm64ilp32) actually useful / alive > at this point? No, but if someone did try to build a package for those it would be incorrect for dpkg to enable these flags. The chances of anyone actually doing that are pretty low, but correct code is a good thing. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: abel.debian.org is down
On 2023-09-05 08:23 +0200, Mathieu Malaterre wrote: > On Mon, Sep 4, 2023 at 6:00 PM Wookey wrote: > > > > Abel is now back up. > > Here is what I see on my side right now: > > [...] > debug1: Connecting to abel.debian.org [217.140.106.111] port 22. > debug1: connect to address 217.140.106.111 port 22: Connection timed out > ssh: connect to host abel.debian.org port 22: Connection timed out > > Could you do me another favor and double check on your side ? You are right. The power went off again (looks like 19:17 4th sept). I'm not sure why. Clearly something is not reliable as it only ran for about 3.5 hours. I've jiggled some cables and powered it back up again. It's working right now: $ ssh -J master.debian.org abel.debian.org Linux abel 4.19.0-21-armmp-lpae #1 SMP Debian 4.19.249-2 (2022-06-30) armv7l ... Welcome to abel.debian.org, the Debian armhf porterbox. Let's see if it stays up. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: abel.debian.org is down
On 2023-08-31 14:32 +0200, Mathieu Malaterre wrote: > > On 2023-08-31 14:21 +0200, Mathieu Malaterre wrote: > > > Could someone please check the status of abel.d.o. Seems to be down today: > > > > > > % ssh abel.debian.org > > > ssh: connect to host abel.debian.org port 22: Connection timed out > > > > Yes. I think that's my fault. > No rush. I'll try again sometime next week :) Abel is now back up. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: abel.debian.org is down
On 2023-08-31 14:21 +0200, Mathieu Malaterre wrote: > [cc me please] > > Hello, > > Could someone please check the status of abel.d.o. Seems to be down today: > > % ssh abel.debian.org > ssh: connect to host abel.debian.org port 22: Connection timed out Yes. I think that's my fault. I removed decommissioned Hoiby from the rack yesterday and the power cabled wobbled on abel caused a reset (that's just how the hardware is). I pressed the button to restart it, so it should have been OK, but apparently not. I'm not normally in the office (and thus server room) again until Monday, but if you would like to use the box before that I can go take a look this evening (it's a 10min bike ride). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Status of dpkg-shlibdeps tracking ARM object linkage ABI mismatches
On 2023-05-03 21:50 +0100, Steve McIntyre wrote: > If we're still seeing > issues in packages today, then maybe we might find some help from > Wookey or Emmanuel (who should both be reading this list!). I am, and have noticed this issue and put it on our list of things to look at. I was going to wait until I had something useful to say before replying :-) Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: buildd reliability
On 2023-03-26 12:25 +0200, Aurelien Jarno wrote: > The 3 arm64 boards running at ARM are pretty fine, we do not have any > issues with them, however they start to be old. > > On the other hand we have many issues with the Ampere servers hosted at > UBC and the Applied Micro servers hosted at Conova. All of them crash > regularly (a few times per week in total) and need a powercycle. In > addition the bullseye kernel does not work on Applied Micro servers, so > we are currently stuck with buster on them :(. OK. That's not good. Can you say which hardware those machines are? Our buildd database does not say what actual kit is in use (just the manufacturer), and I don't have rights to read the detailed buildd admin info on the UBC and conova sites. [ Aside: what would it take to put an extra field into our machine database to specify what hardware each machine was? It can sometimes be tricky to separate Model/motherboard/CPU as the required bit of info but it would be really useful to write something more detailed down both for issues like this and debugging. ] My guess is that all the Conova machine are Mustangs, and the UBC machines are emags? Is that right? Some enquiries tell me that both these machines types are reliable (although the mustangs are slow) at OBS and Yocto, so they can be OK, but there is certainly much faster kit available now (Ampere Altra). Is there a bug about the boot failure on the Applied Micro machines? I just failed to find one. If we know what hardware it is we can investigate, because that does seem like something that should be fixed. > > I'm sure we can get new arm64 buildds if we need them. > > Yes please. It's becoming urgent to get new ARM64 hardware to overcome > all those issues, and we (DSA) failed to find new hardware to buy at a > decent price. OK. I'll see what can be done. I see Altra servers are from $7000-$53000 on https://store.avantek.co.uk/arm-servers.html. What does DSA consider 'decent'? I guess we'd prefer the resilience of a couple of reasonable machines over one ridiculously manly one. A bit of configury on the Aventek site suggests that basic ARM Altra servers cost about twice as much as AMD ones for similar specs (cores/RAM/disk), but then the power consumption is less than half. I don't know how the performance actually compares for buildd purposes (nor what sort of spec we prefer in terms of nodes/cores/RAM/Disk/networkIF), but people describe the Altra's as 'fast'. I'll try and collect some more details to quantify that. Does Debian run to a policy on packages/Wh for buildds yet, I wonder (efficient hardware lowers emissions, for a given workload)? It's worth paying something for more power-efficient kit, possibly quite a lot for hardware like this that will run hard for years. Are we running debian CI on this hardware or is that all done in the cloud? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: buildd reliability, was: Is an ARM computer a good choice? Which one?
On 2023-03-25 13:46 +0800, Paul Wise wrote: > On Thu, 2023-03-23 at 23:33 +0000, Wookey wrote: > > > The arm64 servers debian uses for buildds are fine. > > DSA often complain on #debian-admin about how flaky they are and often > have to reset them, there were a few jokes about rebooting from cron, > also the release team arch qualifications have a note about this: > > * concerns-dsa: arm64/armhf/armel: yes: unstable and ageing hardware I still think that's referring to the 32-bit machines. I'm a buildd admin for those ports and the machines on this site and I'm not aware of problems with the 64-bit machines, and I don't get Nagios messages about them having gone down/back up, like I do about the armhf/armel hardware. Perhaps they are happenning but I'm not on the right alias/list so don't see them? I thought I was getting all monitoring messages for machines on this site So if there is an issue there we have a communications problem as well as a hardware problem. I'm sure we can get new arm64 buildds if we need them. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Is an ARM computer a good choice? Which one?
On 2023-03-21 11:17 +0800, Paul Wise wrote: > Not sure about ARM desktops. ARM servers seem problematic, IIRC the > arm64 ones Debian uses for buildds are unstable and the potential > replacements are way too expensive. Not sure of the status here. The arm64 servers debian uses for buildds are fine. We have a number of Ampere and Applied Micro boxes. You are probably thinking of the marvell 78000 32-bit hardware which is getting pretty old and somewhat flaky and has mostly been retired except for porter boxen. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Is an ARM computer a good choice? Which one?
On 2023-03-21 20:57 +0100, Lionel Élie Mamane wrote: > On Tue, Mar 21, 2023 at 01:21:04PM -0600, Gunnar Wolf wrote: > > > Nowadays, many people report good support with Lenovo's high-range ARM > > system, the Thinkpad X13S. > It has a trackpoint! Killer feature. It seems to have decent > performance; the press says it compares favourably to Intel's mobile > offering in December 2021 for less power draw, even though... really > slower than Apple M1 (like 2× to 2.5×...). But if it actually works > like right now (while GNU/Linux on Apple Silicon is still very, very > rough), and again, it has a trackpoint. The X13s is nice hardware, but AIUI there are still various things that need upstreaming to the mainline kernel before everything works properly. The one major downside you do need to be aware of is that you cannot run VMs - the machine boots linux in EL1 instead of EL2 so a hypervisor cannot get control at the right level. There is a proprietary BIOS mechanism for Windows to get hypervisor authority so VMs work fine on Windows. This is Qualcomm's fault, but they don't want to fix it. Lenovo do, so probably/hopefully some solution will become available eventually, but right now you are knackered on this front. > I think I've decided :) Thanks for the pointer! If the above is not a problem for you then it is indeed nice hardware. Asahi linux on Apple M1 hardware is also viable. It's also very nice hardware (faster than the x13 I believe), and the bootloader is not crippled. But Apple do not co-operate at all so everything is reverse-engineered. Which means currently most stuff works but power management is significantly lacking. I have the july 2022 release and it runs debian very nicely indeed, but the machine doesn't sleep - I have to reboot every time. And I have no GPU acceleration, although it's more than fast enough for my purposes anyway, but I guess it's not power-efficient doing software rendering. I understand that both those things are fixed with the current release. https://asahilinux.org/blog/ Those two machines are the only currently available candidates for decent performance laptops, just as good as X86. There are also expensive server-grade machines, and a range other devices which make adequate computers. like the Pi4, and various rockchip, allwinner, marvell etc devices. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: abi-compliance-checker and library transitions [Re: another attempt at Y2038]
On 2023-02-15 17:08 +, Wookey wrote: > On 2023-02-04 21:42 -0800, Steve Langasek wrote: > > Yes I think we should proceed with this analysis on debian to get a > better handle on just how many libraries we are looking at. OK. We have over 10,000 *-dev package in debian so this took a while, but I've now finished an initial pass. The results are: Total -dev packages: 10323 Time_t changes ABI: 329 LFS changes ABI: 580.6% ABI unchanged: 18405.6% Compilation failed: 1637 No headers in pkg: 3852 No library in pkg: 5086 total analysed: 10249 (note that the no-headers and no-libs categories are not exclusive - the other classifications are) Not quite sure where we lost 74 packages down the back of the sofa but at 0.7% it's noise. So we have about 5000 packages which can basically be ignored for this purpose: golang* (1943) librust* (1955) - source-only, no dynamic linking, no .so's in any package and libghc* (1065) - changes ABI at drop of hat (every new version) anyway. Of the remaining 5360, 5237 have .so files to check. Of those 329 change ABI and another 58 are not built with LFS currently so also change ABI due to that. That's 387 (7%). 34% are fine. And an annoyingly large 1637 (30%) did not build under Abi-compliance-checker to determine one way or the other. Assuming 7% of those are a problem that's another 114 packages. I've yet to determine how many of the 'no-libs/no-headers' packages actually expose an ABI we need to worry about. There will be some more, from stuff like boost and Qt. So the scale of the transition task in Debian is quite a lot bigger than in Ubuntu: Probably 400-500 packages. I've linked my lists on the wiki page. https://wiki.debian.org/ReleaseGoals/64bit-time I believe Steve L (who has done most of the heavy lifting on the script) is running a check too and will have some results soon. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: abi-compliance-checker and library transitions [Re: another attempt at Y2038]
On 2023-02-20 17:53 +0100, Diederik de Haas wrote: > On Monday, 20 February 2023 16:24:37 CET Arnd Bergmann wrote: > > On Wed, Feb 15, 2023, at 18:08, Wookey wrote: > > > On 2023-02-04 21:42 -0800, Steve Langasek wrote: > > >> On Thu, Oct 20, 2022 at 09:42:58PM -0700, Steve Langasek wrote: > > >> > > >> Does doing an ABI transition of ~113 libraries seem tractable to folks? > > > > > > It certainly provides evidence for the idea that this is not > > > completely intractable, which I think many people (including me) > > > worried was the case initially. > > > > When I did a similar analysis a few years ago using just pattern-matching > > on header files, the result was that more than half the total packages > > in Debian depended on at least one other package that needed an ABI > > transition, which in my mind made it unrealistic. > If you do it in the early stage of Trixie's dev cycle, would it still be > unrealistic? It may be a bumpy ride and take a while, but I don't see an > immediate issue with that. Sid may finally become Unstable again ;-P > > But *when* you do it, is quite relevant. If you/we are only a few months away > from the Trixie Freeze, then it's probably not a good idea. > But if we're 1-1.5 years before that, there's plenty of time to fix things. > > Or is that too simplistic on my part? No. I think that's reasonable. One thing we do have to worry about right now is that anything which has enabled LFS anytime in the last 15 years that rebuilds against a current gnulib will automatically get 64-bit time_t unless they explicitly turn it off. We may well have packages in the archive that have had this done to them without noticing, and clearly we don't want to do this in bookworm. I'm not quite sure what the best way to check for this is. Is there a place one can grep all buildlogs? AIUI gnulib is statically included in the build a-la autoconf so it probably only happens when a new upstream is pulled in with updated gnulib. BICBW. gnulib doesn't seem to do releases (last tag 9 years ago 'v0.1') so I'm not quite sure when this changed. Ah July 2021: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=m4/year2038.m4;h=2e4427e6fac10550c99748abebf31b61e6afda2b;hb=b9bf95fd0a6ab666b484b1e224321664f051f7fa So the module has existed since 2017, but only defaults on since mid 2021. I'm not sure what one should be looking for in build logs to set off the alarms. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: abi-compliance-checker and library transitions [Re: another attempt at Y2038]
dependencies. > Even when applying these fixes, I still had 8 library packages whose > headers I wasn't able to get to compile. So there's still quite a bit > of work to do here. > > - On this preliminary pass, I only included library packages that shipped > both headers and .so's, as this supposedly gives the best quality > results from a-c-c. To get a full list of ABI-breaking changes, > however, we need to include packages that ship only headers and not > .so's, to catch those libraries for which the .so is in a different > binary package (boost), and to catch plugin systems for executables > (apache). > > While I'm currently working on this using Ubuntu, the results are largely > applicable to Debian, and the script itself certainly is. Note however that > there are a couple of bugs in abi-compliance-checker that I've patched in > Ubuntu, bug #951076 and bug #1030540, which you would want to have fixed > before trying to run this analysis in Debian. Cc:ing the a-c-c maintainer > for awareness of this. I tried just running the script on debian and it tried 121 libraries before dying, and produced compatibility results for 71. So yes it needs some work to get useful numbers out. You just ran this on Ubuntu main, so there will be quite a lot more libraries in debian, I presume? > Does doing an ABI transition of ~113 libraries seem tractable to folks? It certainly provides evidence for the idea that this is not completely intractable, which I think many people (including me) worried was the case initially. > If > there's interest in moving forward on this, I'd say the next step should be > to take it to debian-devel for broader discussion/signoff. I would also > move my scripts into a git repository that folks can contribute to -- adding > the necessary overrides for a-c-c for each library, so we can get an > authoritative list of ABI breakages, is very parallelizable. Yes I think we should proceed with this analysis on debian to get a better handle on just how many libraries we are looking at. I would also still like suggestions/test cases for $stuff that we thing will/might break _other_ than library ABI transitions, which we at least know how to handle in general. So far there have not been many things suggested, my list of tests I can run to check has zero entries. That may be good sign (there just aren't that many), or it might be a bad sign (no-one knows/is checking). I have created a releasegoal page to discuss this transition in general, and collect relevant info: https://wiki.debian.org/ReleaseGoals/64bit-time I think it would be useful do a bit more work on the ABI checking and data-collecting (e.g. raspian input) before going to debian-devel, but not wait more than another week or two, because people are already switching, possibly without fully understanding the implications: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026204 Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: [Y2038] debian/armhf time64 build?
On 2022-10-02 16:23 +0200, Arnd Bergmann wrote: > On Sun, Oct 2, 2022, at 1:59 PM, Adrian Bunk wrote: > > > > More than 13k packages are currently Installed on x32 after having been > > natively built and (if they have) passing their build time tests. > > There is a minimal user base on x32, so I'm sure a lot of bugs > have gone unnoticed. Having 64-bit time_t on BSD and Windows > probably did more to find bugs, but there are still lots of > issues where neither of this would help. For instance: OK, rather later than planned, I have done a bootstrap of the bottom 154 debian packages (as of Jan 17th) i.e the set you get from here: http://snapshot.debian.org/archive/debian/20230117T215416Z/ (thanks to Helmut for the marvellous rebootstap making this mostly painless) for 'armhf': standard armhf, 'lfs' : armhf+ DEB_BUILD_OPTIONS=future+lfs 'tt' : armhf+ -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 DEB_BUILD_OPTIONS=future+lfs I'm trying to dump some ABI differences to see what _actually_ changes, but I've also just been randomly installing random tt packages in an armhf chroot to see what broke. 'nothing obvious' is my initial impression so far, so I'd welcome any suggestions for things which are easy to test that we might expect to break. (e.g translating the things below into commands I could type to check?) Suggestions for things further up the package stack will also be useful for the future. The packages for lfs and tt are in these repos: http://wookware.org/software/timet/ It's entirely possible that build flags have been ignored in places and some of these packages are not actually as advertised/intended - I'm still checking that. > - Any applications that use direct system calls with a 32-bit > time_t have to change to the correct replacement syscall. > This never had to be done on x32, because there is only one > such set of syscalls. A number of upstream packages already > got fixed for riscv32, but unfortunately some of those were > done in a way that is still broken for architectures that > have both the time32 and time64 versions. > Most commonly, this affects __NR_futex/SYS_futex, but there > are other syscalls needed elsewhere > > - Libraries using input_event structures on /dev/input/* > need to have an updated copy of the kernel headers. Most > upstream packages do now, but I'm sure there are some left. > > - Packages that rely on seccomp have to be updated to > allow both the old and new versions of system calls in their > whitelists > > - Anything that is written in a language other than C but > links to C libraries needs to be updated to use the new > data structure definitions. Some of these may have a special > case for x32, or they are just wrong. There are a lot of > python or rust libraries affected by this, and no obvious > answer. > > - Things that are written in a language other than C/C++ > but don't link to C libraries should keep working, but > will not be y2038 safe unless they also migrate to the > time64 interfaces by copying what glibc did. > > - Any package that currently relies on having a 32-bit > off_t/ino_t will break after being forced to update to > the 64-bit version, even if they don't care about > time_t. > > - Packages may hardcode the time_t/timeval/timespec > definition. If they use __kernel_long_t, they would > even work on x32, but break on any other 32-bit ABI. > > Arnd > Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: [Y2038] debian/armhf time64 build?
On 2022-09-29 12:24 +0200, Arnd Bergmann wrote: > On Thu, Sep 29, 2022, at 11:49 AM, Wookey wrote: > > On 2022-09-29 09:47 +0200, Arnd Bergmann wrote: > >> > >> I think the problem with using dpkg-buildflags is that it breaks > >> any user building their own applications against Debian provided > >> libraries, unless they remember to set the flag manually. > > > > Yes, but I'm talking about how to do a test rebuild. We set the > > dpkg-buildflags config to always use -D_TIME_BITS=64 in the build > > chroot, and build stuff. > > Right, that should work. In my 2020 experiment I did the opposite > and actually patched glibc to remove the time32 interfaces so > I could be really sure that everything would use the time64 > path, but clearly at least the core packages all use the > buildflags correctly. That is more reliable. We will keep the build logs so can check those with just grep, or more smartly with a modified blhc, for anything that did not in fact get the flag set. If it proves to be a problem then a patched glibc is obviously a sensible approach. > > Are you aware of anyone else having written up efforts around this > > (e.g. if the arch people have changed it already they presumably found > > a load of the things one might trip over). > > Adelie Linux has (had?) a great summary. I can't reach the wiki page > at the moment, but I found an archive copy at > > https://web.archive.org/web/20220301175235/https://wiki.adelielinux.org/wiki/Project:Time64 Cheers. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: [Y2038] debian/armhf time64 build?
On 2022-09-29 10:10 +0200, Arnd Bergmann wrote: > > Given that arch have > > it working it should be (?) as simple as setting some flags and > > doing a rebuild (and fixing whatever breaks). > > I was not aware of Arch linux using a time64 build. Sorry - that's me not reading properly. You wrote 'Alpine' and my brain read 'Arch'. I have just repeated the error in my last mail. The main ones > I know are Alpine Linux, Adelie Linux and OpenWRT, but those all > use musl-1.2, not glibc, and they have a much smaller set of packages. OK. We still have plenty of bugs to find then :-) Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: [Y2038] debian/armhf time64 build?
On 2022-09-29 09:47 +0200, Arnd Bergmann wrote: > On Thu, Sep 29, 2022, at 2:14 AM, Wookey wrote: > > I think the problem with using dpkg-buildflags is that it breaks > any user building their own applications against Debian provided > libraries, unless they remember to set the flag manually. Yes, but I'm talking about how to do a test rebuild. We set the dpkg-buildflags config to always use -D_TIME_BITS=64 in the build chroot, and build stuff. For the actual new arch we woud set this as a gcc default for the architecture as it's a significant part of the ABI. (and someone would have to run gcc with -D_TIME_BITS=32 to explicitly build something for the old abi (or use the gcc). > The flag is -D_TIME_BITS=64, and this can be set unconditionally > everywhere if that helps. Note that this implies -D_FILE_OFFSET_BITS=64, > i.e. you can't have 64-bit time_t without 64-bit off_t/ino_t/... > > As far as I understand, there are still a few libraries in Debian > that are built with 32-bit off_t in order to not break the traditional > ABI, > So with time64, there will be an ABI change both for the few > libraries that are currently using 32-bit off_t in addition to > those that use time_t/timeval/timespec > > This is also going to be hard for non-C languages with C bindings > (python, rust, ...) that have structure types hardcoded. Hmm. Yes that could be interesting. Are you aware of anyone else having written up efforts around this (e.g. if the arch people have changed it already they presumably found a load of the things one might trip over). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: [Y2038] debian/armhf time64 build?
On 2022-09-28 09:32 -0400, Jeffrey Walton wrote: > On Wed, Sep 28, 2022 at 3:24 AM Dominique MARTINET > wrote: > > ... > > Ugh, this is going to be a massive headache... > > Other distributions I've worked with (e.g. nixos) have a wrapper for gcc > > and clang that just enforce the flags they want the distro to be built > > with -- I don't think debian has anything like that, would that be > > easier to work with? My line of thinking is that there will only be a > > single place to fix instead of configure/cmake/meson and all hand-made > > build scripts that exist around here. > > Debian has dpkg-buildflags . Discussions about it show up when > discussing hardening, like [0]. > > [0] https://wiki.debian.org/Hardening#dpkg-buildflags Right, and just changing it and rebuilding works very well. I did this for PAC (pointer authentication) support last year. Very few packages do not correctly honour dpkg-buildflags. In fact the only issue was that I unconditionally changed it so it got issued by some packages (like migw) for the wrong-arch compiler (because they were cross-building). One should be a bit smarter to unconditionally set an _arch-specific_ flag. dpkg-buildflags has functionality for this. See patch at bottom of: https://lists.debian.org/debian-dpkg/2022/05/msg00022.html Presumably the 'use 64-bit time_t' flag is the same for all arches, but may only exist on 32-bit arches? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: [Y2038] debian/armhf time64 build?
On 2022-09-28 11:09 +0900, Dominique MARTINET wrote: > > As far as I'm aware, there haven't been any new public discussion since > that 2020 thread I mentioned it in the 'arm status' talk at debconf this year. -- has there been any new attempt I missed? I have been planning for a while to have a go at a bootstrap but have not actually done anything yet. It is rising up my list as 'most important task' (currently after 'fixing porterbox abel'). > I won't bring anything very useful to the table here: I'd be happy to > give some limited time, I'm glad to hear that there is some interest from others. > My naive opinion is that having a flag day and dealing with fallouts > might ultimately be the fastest way forward, but as there won't be any > safety check to detect incompatibility I don't think anyone will be > looking forward to the weird errors that will ensure for e.g. locally > compiled programs and whatsnot. We don't have a mechanism for a flag day SFAIK. We can't suddenly re-upload every package in the armhf archive. And people would still download new 64bit time_t packages into their existing armhf installations and (presumably) have everything break. It's a new ABI - we have to assume the breakage would be pretty bad. It would be nice to do it within the armhf archive but although we have mechanisms for core library transitions (like we did for libc5 to 6) a) this affects all arches so is a lot of churn for an issue only affecting one arch (or maybe all 32-bit arches, but I'm not sure how many of those other than arm (v7) will be around much longer? Given the nature of this change I'm not even sure this would work if we were up for the work, and I don't think we collectively are. > So that might be the first thing to think about again? A new debian arm ABI arch is definitely the easiest way to do this, as Arndt says. Having thought about it a bit, I suggest we just call it 'arm32' as in the future it will be useful to distinguish legacy 32-bit arm from arm64 (and maybe armv9 or whatever variants come in the future). And having just 'arm32' and 'arm64' arches will be quite pleasing for however long it lasts. Obviously bikeshedding about the name and triplet is the least important part of this. Andt Bergman wrote: > Last time, the discussion got stuck because that means introducing a > new target name for dpkg, which then requires a new target triplet > to allow a multiarch installation. This in turn requires additional > work for porting packages that need to know about the new target > triplet. I don't think we can solve this problem now, but should > postpone the inevitable debate about this until someone has done the > work of rebootstrapping a working armhf environment with the current > names. Agreed. And this was my plan. Just so we can check that stuff basically works before patching toolchain builds. Given that arch have it working it should be (?) as simple as setting some flags and doing a rebuild (and fixing whatever breaks). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: abel.d.o + gcc-12.x
On 2022-09-05 08:53 +0200, Mathieu Malaterre wrote: > Dear Debian arm porters, > > I have two requests: > > - Could someone please check the status of abel.d.o ? (*) It does not not boot any more after a kernel upgrade. This happened whilst I was on holiday so it's taken a while to get to it. It is now on my desk being looked at. > - One of gcc dev asked me to verify the status of a bug in gcc-12.x > branch. Are there any pre-build version of GCC 12.x package for > Debian/arm ? (**) Yes: 12.2.0 is in the archive: https://tracker.debian.org/pkg/gcc-12 https://buildd.debian.org/status/package.php?p=gcc-12 https://deb.debian.org/debian/pool/main/g/gcc-12/ Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1017961: mozjs102: Fails to build on armel
On 2022-08-25 11:34 +0100, Simon McVittie wrote: > On Tue, 23 Aug 2022 at 21:42:29 +0100, Simon McVittie wrote: > > I don't have a good picture of where this puts us on a scale from "it's > basically fine" to "armel users will report grave bugs in gjs-based > packages whenever they try to run them, because they're hopelessly > crashy". Does anyone have a better idea of whether these test failures > are ignorable or RC? Not really. I don't know much about how mozjs, not exactly what the test suite is testing. > I'm doing all this remotely on a porterbox, because my only armel > machine was de-supported in Debian 11 due to kernel size issues and > is headless anyway, I have some 32-bt armv7 hardware that can run a desktop so I'll fire those up and test this on there to see if it's obviously broken or not. I did try to get some feedback on whether armel should continue as a release architecture at my debconf talk this year but no opinion was expressed. I have no idea how many people would be affected but it's certainly true that upstreams are not that bothered about continuing to make things work on v5 so debian ends up noticing and fixing things. We could certainly save ourselves some work by relegating it to ports. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: On the existance of arm* porters
On 2022-08-25 17:30 +0100, Steve McIntyre wrote: > On Thu, Aug 25, 2022 at 09:15:07AM -0700, ` Vagrant Cascadian wrote: > >On 2022-08-25, Graham Inggs wrote: > > > >Apparently I am the only porter for armhf and arm64? I had assumed there > >would be someone else to fill the gaps in my skillset, but I guess > >not. > > Argh. I used to do this, but I don't have the time or the inclination > to step up any more. I'm very surprised to not see Wookey not list > himself, tbh. Yeah I should be on the list, but it looks like I wrote a reply to the 'call for porters' back in Decemeber, but stopped to look something up, got distracted and never actually sent it. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Debian Gnome versus Debian Cinnamon on UTM - M1 Mac
On 2022-08-16 09:19 +0200, FritzS GMX wrote: > Hi, > I installed UTM / QEMU on my M1 (ARM) Mac Mini, 16GB RAM, 2TB SSD, Monterey > 12.5 > > Ob Debian Cinnamon I get the message > »Please check graphics driver > Your system is currently running without video > hardware acceleration. > You may experience poor performance and high CPU utilization. > high CPU load.« > > On Debian Gnome I don’t get this message. What's wrong? Which graphic driver > missing in Cinnamon? There is no free driver for the M1 GPU yet (the Asahi project is working one) so the message is correct that unaccelerated graphics is being used. However in practie this seems to work pretty well. Glad to hear that Debian is installale on this hardware. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: armhf kernels on arm64 hardware
On 2022-07-15 13:40 -0400, gene heskett wrote: > On 7/15/22 12:16, Wookey wrote: > > > > Clearly one normally does not run foreign-arch kernels on hardware so > > we don't have to support it, and Ben is right to say 'this is not a > > bug'. > > > > On the other hand, if the armhf kernel does work on RPi4 with a few > > config options, and there is an actual use case, then the question is > > what is the downside of enabling the config options? > It, LinuxCNC, does indeed run on an armhf kernel built right on the pi > and has been since Jessie on a rpi3b. And it is now in debian: https://tracker.debian.org/pkg/linuxcnc > > Does this only work for the RPi4, or does it enable/prevent 32-bit kernels > > on other 64-bit machines? > No. It runs with the same armhf kernel on an rpi3b, but the 3b is dragging > its > tongue on the floor where the 4b has some leftover zip. Sorry. I meant other arm64 hardware than from broadcom (not other RPi flavours). I.e does enabling CONFIG_PCIE_BRCMSTB=y CONFIG_RESET_RASPERBERRY=y RESET_BRCMSTB_RESCAL=y Cause the kernel any issues on other platforms? > Because our latency-test results are better on armhf than on arm64, we use > armhf for its performance. OK. How much better? What sort of performance difference are we talking about? And how many other users care about this? Debian is a general-purpose OS and has to choose options that are generally useful or at least not generally harmful. One user with some interesting hardware can clearly install a new kernel built with specific options. The question from Debian's POV is how many other people want to use non-native arm kernels (and for what?). How many platforms is it relevant to? And if there is a downside, how many does that effect, and how/how much. You say the kernel is 'a few kB bigger'. How many kB? Kernel size has been critical on some armhf models in this past so even if that's the only cost, it's not necessarily negligible. We may have dropped all the platforms this was critical for by now, in which case perhaps a 'a few kB' doesn't matter. > > Do i386 kernels work on amd64 machines? > Different architecture. No relevance here. It's not entirely irrelevant. If it works on x86 then it's not entirely unreasonable for people to expect it to work on arm. We do strive for parity to the degree that it is possible and reasonable. If it doesn't work on x86 then that justification can't be used, and indeed strengthens the argument that 'just about nobody runs non-native kernels - if you want to, you are on your own'. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
armhf kernels on arm64 hardware
On 2022-07-15 18:42 +0800, Paul Wise wrote: > On Fri, 2022-07-15 at 12:04 +0200, Arnd Bergmann wrote: > > > If you see /other/ problems with the 64-bit kernel (using the > > same user space, kernel source and kernel config as the 32-bit > > kernel), please report those to the respective upstream kernel > > maintainers so we can fix those as well. > > Gene's complaint is unrelated to this thread, but it is that Debian > refuses to support running the 32-bit ARMMP kernel on 64-bit hardware, > specifically on the RaspberryPi 4b. There wasn't any justification from > Debian given in the bug reports, but it sounds like only build config > options are needed to be enabled, but Debian refuses to do that: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971059#12 > https://bugs.debian.org/981586 Ah thanks Paul. I was wondering why we were being accused of 'Debian abandonning armhf' when it was news to me, and I'm just writing the 'ARM ports status' talk for Debconf next week. Clearly one normally does not run foreign-arch kernels on hardware so we don't have to support it, and Ben is right to say 'this is not a bug'. On the other hand, if the armhf kernel does work on RPi4 with a few config options, and there is an actual use case, then the question is what is the downside of enabling the config options? Does this only work for the RPi4, or does it enable/prevent 32-bit kernels on other 64-bit machines? Do i386 kernels work on amd64 machines? Sounds like something that might be worth discussion at debconf next week. I'll mention it in the talk. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: src:exempi: fails to migrate to testing for too long: FTBFS on armel and armhf
On 2022-05-29 17:53 +0200, Paul Gevers wrote: > Hi, > > On Sat, 16 Apr 2022 00:21:46 +0200 Michael Biebl wrote: > > Dear arm porters, > > > > can you please take a look at this? > > Ping from the Release Team. This package is a key package (so the RC bug > can't be "fixed" by removal from testing). I did take a look at this, but the logs from different builds were quite confusing and it was not at all obvious what the actual problem was. I left it for a mo to deal with somthing easier... I have failed to get back to it so far, and won't for at least another month (on holiday away from computers). Ah, but I see Bernhard has fixed it in the meantime. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: [PATCH v2] arm64: compat: Implement misalignment fixups for multiword loads
On 2022-07-01 15:53 +0200, Ard Biesheuvel wrote: > The 32-bit ARM kernel implements fixups on behalf of user space when > using LDM/STM or LDRD/STRD instructions on addresses that are not 32-bit > aligned. > This feature is one of the remaining impediments to being able to switch > to 64-bit kernels on 64-bit capable hardware running 32-bit user space, > so let's implement it for the arm64 compat layer as well. > Note to cc'ees: if this is something you would like to see merged, > please indicate so. This stuff is unlikely to get in if there are no > users. Decent 32-bit arm hardware is thin on the ground these days. Debian still has some but it's getting old and flaky. Being able to build reliably on 64-bit hardware is important and useful. Unaligned accesses are much less of a problem than they used to be, but they can still happen, so having these fixups available is definitely a good thing. Debian runs its 32-bit buildds with alignment fixups turned on. It looks like the boxes still hit about 1 per day. We also do 32 bit builds on 64-bit kernels (in 32-bit userspaces) and it mostly works. We do have packages that fail on 64-bit kernels and have to be built on real 32-bit hardware, but I don't know how much of that would be fixed by this patch. Some, presumably. So yes, cheers for this. It is helpful in the real world (or at least it should be). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: armhf: abel.d.o hardware status ?
On 2022-06-29 15:13 +0200, Mathieu Malaterre wrote: > On Wed, Jun 29, 2022 at 2:48 PM Wookey wrote: > > What exactly is going wrong when you try to use valgrind? > > Well you should see something like this on abel.d.o: > > * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224#27 > > Basically anytime you build valgrind using gcc-11 or gcc-12 (debian > sid package), you get this weird illegal instruction: > > ``` > % ./vg-in-place > Illegal instruction > ``` I have a strong suspicion that this is neon-itis. The issue generally manifests as 'illegal instuction' (i.e a neon instruction is issued on hardware that isn't able to execute it). It has always been the case that software should not assume neon is present on v7 (because it isn't on all hardware), and most code gets this right, but I've recently seen gcc putting those instuctions into the startup code (where the C-environment is set up and variables allocated) which gets executed _before_ any functions checking for which HWCAPS to enable, and thus which code to run. You can check if a binary contains NEON instructions using readelf -A and look for Tag_Advanced_SIMD_arch: NEONv1 However just because its in the binary doesn't mean it's wrong. The binary may have been built using ifunc or other mechanisms to choose appropriate functions depending whether or not neon hardware is available. A simple check for whether this is your issue is just to run the same test on harris.debian.org. If it works OK there that strongly suggests you have a neon problem. Also if you run the program under gdb (on abel) and when it barfs do: (gdb) disassemble and look for instructions that start with 'v', like 'vmov.i32' that will confirm which instruction is tripping it up. This bug has an example of the problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998043 I got partway thorugh a long followup with some details of possible fixes some months ago but got sidetracked (and oh look it's been pending for 6 months already). The reason this has broken appears to be that gcc has changed the way the fpu is specified/defaulted, so neon _and_ fp are enabled by default if no specific fpu option is given. (i.e we just set -march=armv7). It used to be that -march=armv7 implied +nosimd. (or something like that - I never quite got to the bottom of it enough to be sure eactly what the right general or specific fix was). If you rebuild with -march=armv7-a+nosimd+nofp or -march=armv7-a+nosimd+fp you should be able to determine if being more explicit about the fp and simd(neon) instructions used makes it behave. It seems likely that you have hit this problem. I think this is the same thing too: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982794 (Firefox dying with illegal instruction on non-neon hardware) I _suspect_ that debian needs to change the default flags to actually say 'armv7+fp+nosimd' by default so that we get what we expect (and define as the base ISA) and it doesn't depend on what hardware the build was done on. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: armhf: abel.d.o hardware status ?
On 2022-06-29 08:54 +0200, Mathieu Malaterre wrote: > [cc me please] > > Dear armhf gurus, > > Could someone please confirm that abel.d.o hardware is almost like a > good old RaspberryPi Model 2B ? I am trying to understand why valgrind > is supposed to work on arm32/linux but fails miserably on abel.d.o. Abel is a marvell Armada 370/XP CPU (4 cores) in the form of an MV78460 dev board. Marvell have their own architecture licence so it's not an ARM (the company) design) It has these CPU features: half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae so that means it doesn't have neon, which would trip up code assuming that it doesn. It's also a v7 core. The RPi Model2B was oringally a Broadcom BCM2836 (quadcore Cortex-A7) and later (v1.2) was a BCM2837 (quadcore Cortex A53) (Both ARM (the company) core designs, but A53 is v8 and A7 is v7 ISA). So abel and the original RPi 2B are similar in that both are v7, 4-core CPUs. But they have different HWCAPS and microarchitectures. (And the later A53/BCM2837 is quite different with a 64-bit v8 CPU) I'm failing to find the /proc/cpuinfo or HWCAPS spec for the cortex A7, but it does have neon, so no they are not 'the same'. If you want to see if this is the issue, try the 'harris' porterbox, which is different v7 32-bit CPU (Freeescale i.MX53), but does have neon. What exactly is going wrong when you try to use valgrind? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU
On 2021-12-08 20:11 +, peter green wrote: > The result of this change is if you manually set "-march" then it > overrides the built-in defaults for both the CPU and FPU rather than > only overriding the CPU. OK. That explains some things I've been noticing recently. > The default -march value on Debian armhf is "armv7-a+fp". You should Shouldn't it be "armv7-a+nosimd+fp", because neon is not assumed to be present on armhf? All neon code has to be gated on a HWCAP check, so the default should exclude it. I recently found a case where gcc11 helpfully put a neon optimisation into the init code of a complilation unit (zeroing variables), which of course means the program crashes on started on non-neon hardware. To be fair it only did that with -mfpu=neon set, but I'm not sure that it can't happen with a default march=armv7-a+fp OK. I just checked and in fact it doesn't do this optimisation if built with -march=armv7-a+fp so I guess there is an implicit assumption that everything not listed is disabled? Do we actually know for sure or shall I try and find out from some compiler engineers? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Feedback from the community -> ARM
On 2021-06-12 11:57 +0100, Pete Batard wrote:
> As a matter of fact, starting with RPi3, the Raspberry Pi has been an
> official EDK2/UEFI platform for more than 2 years now.
> ... Debian could do itself a
> favour by embracing UEFI support for platforms that have it and at the same
> time try to set a clear delimiter of responsibilities ("ARM manufacturers,
> if you provide a working UEFI implementation for your platform to take care
> of the early boot code/custom kernel headaches, then we'll see what we can
> do to make our distribution work on it").
We have embraced UEFI and if it's available the installer should use it.
It is my understanding that the current (testing) vanilla debian
installer does boot on a UEFI Pi4 (after we fixed #985956). Is that
understanding wrong?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Re: OT: Huge Right to Repair Win for Consumers
On 2021-06-10 06:53 +0200, John Paul Adrian Glaubitz wrote: Are you just trolling? I find it very hard to believe that you actually support the thesis in your bizarre post. > If law initiatives also now want to take away the exclusive rights of > hardware designers > over their blueprints and hence the market advantage over competitors that > they took an > investment risk for, companies will lose the incentive to design and develop > new > products. The fact that people have been repairing cars for about a century without car companies all going bust or giving up on innovation is just one example illustrating that you are talking complete nonsense, possibly just to see how many irate emails you could generate. And yse there is no particular reason why hardware and software should be treated differently in this area, even though manufacturers love to do this. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: iMX8 support in debian
On 2021-03-25 15:12 +0100, Uwe Kleine-König wrote: > > Update: Wookey reported a bug and mentioned via irc that imx8 is missing. I > enabled a few settings (see https://deb.li/3fUTV) and I'm convinced that > only ARCH_MXC is not enough. That does look a lot more convincing. The info I found yesterday about other config options all talked only about imx4/5/6/32bit so I wasn't sure wich were relevent. There should be sensible configs in the Ubuntu and librem5 kernels configs. If anyone knows for sure please post on the bug https://bugs.debian.org/985862 > I don't know the plans for an updated kernel in bullseye, but if it helps > you (or us :-) I might be able to build the current state for you and > provide you a link. That could be useful. A build takes me 7 hours to build and 3 to upload at the moment. (I can fix that next week). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: iMX8 support in debian
On 2021-03-24 21:05 +, Wookey wrote: > On 2021-03-24 20:29 +0100, William Bonnet wrote: > > > > I own since a couple weeks a nitrogen iMX8 board I am currently using a > > kernel and image provided by the manufacturer. > > > > I would be really happy to help on this task and join the effort. Please > > how can i help you Wookey and Paul ? . > > Take the latest Debian kernel source: ( 5.10.24-1 ) > Change the debian/config/arm64 to enable imx8 > Build it and test that it works. OK. I built this last night. It built fine and work on the softiron I have here. If someone could install it on their imx8 board and test that would be great. I filed a bug. Please report success or failure there: https://bugs.debian.org/985862 The built packages will be here when the very slow upload finishes in about 1.5 hours: http://wookware.org/software/repo/ Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: iMX8 support in debian
On 2021-03-24 20:29 +0100, William Bonnet wrote: > > I own since a couple weeks a nitrogen iMX8 board I am currently using a > kernel and image provided by the manufacturer. > > I would be really happy to help on this task and join the effort. Please > how can i help you Wookey and Paul ? . Take the latest Debian kernel source: ( 5.10.24-1 ) Change the debian/config/arm64 to enable imx8 Build it and test that it works. I don't _think_ any more changes will be needed. Report the change you made and the results you found in a bug asking for IMX8 suport to be enabled in the kernel. I was trying to work out what the right config option was, and I think it's just CONFIG_ARCH_MXC=y (in debian/config/arm64/config Maybe there are some other drivers needed to make it useful? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
iMX8 support in debian
I discovered this week that iMX8 is not enabled in the debian kernels. Does anyone know why not? It seems a rather major omission, and too late to fix for bullseye now. Did just no-one ask? Or no-one get round to it? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Porter roll call for Debian Bullseye
On 2020-11-02 22:23 +0200, Graham Inggs wrote: > Hi > > We are doing a roll call for porters of all release architectures. If > you are an active porter behind one of the release architectures [1] > for the entire lifetime of Debian Bullseye (est. end of 2024), please > respond with a signed email containing the following before Friday, > November 27: > > * Which architectures are you committing to be an active porter for? arm64,armhf,armel > * Please describe recent relevant porter contributions. on-site support for buildds at arm. process day-to-day buildd requests give-backs) investigate missing arm support (e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711) investigate compiler issues and push to arm compiler team if appropriate (e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974058 ) run rebuilds across the arch occaisionally (currently planned for arm64 to test BTI support and armhf to test 64-bit timet release) > * Are you running/using Debian testing or sid on said port(s)? yes. I have three arm64 buildds (I did have an arm64 desktop until we all got sent home - it's now stuck in the office, but I should have an arm64 laptop from next week...) (thunderx, softiron, Ampere emag). and an assortment of armhf and armel devices including my home controller (armel, balloonboard) (odroid, hikey, arndale, cubietruck, qnap). My home server and mythtv backend was armhf until it croaked last month. An emergency x86 box has been stuffed in until I work out what's wrong with it/replace it. > * Are you testing/patching d-i for the port(s)? Yes. Added multiple console support for last release. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Help with an arm64 specific gcc internal error with polymake
On 2020-11-17 21:19 +, Dominic Hargreaves wrote: > Thanks for your work on this. As of today polymake has been uploaded > to use gcc-9 which doesn't have this problem, so the perl transition > has been unblocked. I don't understand how this works, because Alex was able to reproduce the all the way back to gcc6, and it's been in bugzilla since 2012. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91590 Still, immediate issue worked around and hopefully the compiler will get fixed one day. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Help with an arm64 specific gcc internal error with polymake
On 2020-11-17 20:11 -0400, David Bremner wrote: > Dominic Hargreaves writes: > > Thanks for your work on this. As of today polymake has been uploaded > > to use gcc-9 which doesn't have this problem, so the perl transition > > has been unblocked. Good plan. > I don't forsee having time (or skills) to debug the ICE, so I hope > someone has a better idea than dropping arm64 as a build arch for > polymake. gcc-snapshot works as well so there is something about gcc 10.2.0 that tickles this bug. Someone more compiler/c++ clueful than me at arm is bisecting to work out what's going on, so I am hopeful that we will understand this reasonably soon, and can hopefully just backport a fix into gcc-10. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Help with an arm64 specific gcc internal error with polymake
On 2020-11-14 16:33 +, Dominic Hargreaves wrote: > On Sat, Nov 14, 2020 at 03:08:14PM +0000, Wookey wrote: > > I have just tried it, and the file built OK, getting to a resident > > footprint of about 3.5G before completing. OK, reading the bug a bit more carefully, I see that you were getting this preprocessed file to build too. But the original .cc barfs. Very odd. The massive/scary c++ involved is way beyond my ken. I'll see if I can find someone smarter than me to work out what on earth is going on. > Thanks! I realised the new source-only policy for bullseye means this > probably wouldn't unblock the migration (unless the release team made > an exception) but it at least would give us an idea of how to move > forward. Right, and it's not working anyway. I have just reproduced exactly what you found, but demonstrated that the OOM killer seems very unlikely to be relevant. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Ampere EMAG
On 2020-11-15 01:03 +0100, Christian Kastner wrote: > On 11/14/20 4:08 PM, Wookey wrote: > > Yes. I have a 64Gb machine. (emag). > > I wasn't aware that the Ampere stuff was generally available, and now I > see that through a generous donation, they power our buildds [1]. > > Do these run an unmodified Debian? The machine I have has Ubuntu on it and it became remote (and thus inconvenient to re-image) back in March before I had time to test plain Debian. It just needed some firmware updates, but then ran standard Ubuntu. https://wiki.debian.org/InstallingDebianOn/Ampere/eMAG The firmware was not public at that time which was annoyingly unfree, but hopefully hardware now comes with those updates on it (or they have been published). > I'd like to run my own arm64 buildd, but basically I only found SBCs so > far, with the NVMe-capable ones having max 4GB RAM, and the Rpi 4 8GB > RAM but no NVMe. I'd like to have at *least* 16GB, and ideally 32GB or more. It's a very nice buildd for things that are parallelisable, with 32 cores. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Help with an arm64 specific gcc internal error with polymake
On 2020-11-14 14:30 +, Dominic Hargreaves wrote: > On Wed, Nov 11, 2020 at 10:12:19PM +, Dominic Hargreaves wrote: > > During the perl 5.32 transition we observed a build failure on arm64 which > > is reproducible on the porterbox and at lease three different buidds:: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974073 > Matthias theorized that this could be the OOM killer, which is why > it doesn't happen when built sequentially. > > Does anyone have access to a higher RAM machine than the buildds > and amdahl (11GiB) that could help test this theory (and maybe do a > porter upload to unblock the issue for the perl transition? Yes. I have a 64Gb machine. (emag). I have just tried it, and the file built OK, getting to a resident footprint of about 3.5G before completing. I'll try a polymake build/upload, and report back on the bug(s) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: cyrus-imapd: FTBFS on arm*, i386, mipsel, ppc64el and s390x
On 2020-05-12 01:04 +0200, John Paul Adrian Glaubitz wrote: > On 5/12/20 1:01 AM, John Paul Adrian Glaubitz wrote: > > On 5/11/20 11:56 PM, Xavier wrote: > >> Could someone help us here ? I forwarded this bug to upstream ([1]) but > >> didn't receive any response for now. > >> > >> (Cc to RFH bug) > > > > The problem here is va_list. On some architectures, the calling convention > > doesn't seem to allow comparing va_list against NULL due to the way va_list > > is implemented on a particular architecture. > Correction: The va_list problem seems to affect ARM architectures only. This is a classic 'porting to arm' issue which used to catch people out regularly 15 years ago because it was something where you could do technically incorrect things that worked fine on other architectures. It's a very long time since I saw something hit this issue. Thanks for the patch Adrian. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1
On 2020-04-12 12:18 +0200, Aurelien Jarno wrote: > The problem is not building a second > optimized glibc, but rather providing a safe upgrade as the optimized > and the non-optimized package have to be at the same version or one of > them has to be disabled. This has caused many system breakages overall. > > Also note that the mechanism allowing a safe upgrade *does* incur a > runtime overhead as every binary now has to test for the presence of > /etc/ld.so.nohwcap to detect a possible upgrade of the glibc in > progress. That's why we have disabled it on architecture not providing > an optimized library [1]. Can you explain how this works please? I'm not familiar with this and it seems like something worth understanding in this context. How often is each binary checking for this file, and what exactly does it indicate? And which binaries are checking? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Graphical installer on arm64 (netboot and cdrom)
On 2020-04-21 14:14 +0300, Alper Nebi Yasak wrote: > > IMO, the right answer is "tty0 not even being in /proc/consoles in this case > (where it should've also been the /dev/console) is a kernel bug". This is my opinion too, although I'm prepared to change it if someone can given a good reason why this behaviour is reasonable. Well done for posting a kernel patch to fix it. I hadn't noticed as I don't watch kernel stuff. However even if we get that sorted in due course we may in practice have to deal with kernels currently getting this wrong for many years so some bodging and heuristics in D_I may also be experient. One thought - can we just perhaps use /dev/console 'anyway' and that'll get us the right thing even when tty0 has not been properly enabled when it should have been? (I've forgotten how all this works and would need to go read the runes again, and most of my test platforms are currently not easily accessible...) > I tried to > write a patchset [1] a while back, but received no feedback except from > kbuild test bot saying it's broken (s/#elif/#else on the last patch). I > don't know if I did anything wrong or anything right at all. > > [1] > https://lore.kernel.org/lkml/44156595-0eee-58da-4376-fd25b634d...@gmail.com/T/ Hmm. I have no idea if you are doing this right either, but it all sounds plausible. I guess a reports with the s/#elif/#else fix is in order anyway, and that might prompt a response from someone with console clue. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Graphical installer on arm64 (netboot and cdrom)
On 2020-04-20 17:51 +0200, Marcin Juszkiewicz wrote: > W dniu 20.04.2020 o 17:38, Steve McIntyre pisze: > > Does /dev/tty0 show up in /proc/consoles in your setup? We might need > > to tweak that yet... > > ~ # cat /proc/consoles > ttyAMA0 -W- (EC p a) 204:64 What platform is this? The idea is that the kernel should know (better than DI) what the valid consoles are so we use that list (every 'enabled' console which is what the 'E' indicates). But you have a machine with no tty0, but it does have a framebuffer? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Architecture names
On 2020-04-16 18:35 -0400, Lennart Sorensen wrote: > On Thu, Apr 16, 2020 at 04:15:00PM -0500, Nate Bargmann wrote: > > It does seem strange to install the 'amd64' distro on my Intel Core > > boxes. As I was aware of the history behind the name it made sense. > > x86_64 is a bit more difficult to type but seems less ambiguous. Oh > > well. > > Too bad it has an underscore which isn't permitted in architecture names > in debian since it is the field separator in the package filename. :) We can deal with that. gcc and pkgconfig already have to when building cross-tools which have triplets in the name: pkg-config-x86-64-linux-gnu gcc-x86-64-linux-gnu binutils-x86-64-linux-gnu A simple substitution suffices. It does add another little bit of tiresome complication to the already horrible complicated rules files for gcc. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: The state of Arm64 on Raspberry Pi (and its Documentation
On 2020-04-16 19:57 +0100, peter green wrote: > Interestingly andriod seems to use arm64 for the "abi"* and > aarch64 for the "instruction set" I was hoping to avoid getting into all this because it's detail almost no-one needs to care about, but there are indeed separate names for the instruction set and the ABI and and the execution state and the microarchitecture and the elf layout, and if I try to type it in here without swotting up properly I'll get it wrong :-) Wikipedia is pretty good for a summary: https://en.wikipedia.org/wiki/ARM_Cortex-A32#32-bit_architecture Or for full detail: http://infocenter.arm.com/help/index.jsp?noscript=1 > * I am not an andriod expert, but an andiod "abi" seems to be > roughly equivilent to a Debian architecture. A debian architecture is essentially defined as an ABI (but also includes a baseline ISA than can shift over time). So yes that makes sense. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: The state of Arm64 on Raspberry Pi (and its Documentation
On 2020-04-16 19:43 +0200, deloptes wrote: > So what can the community rule out here. Is it aarch64 and arm64 the same or > not? yes, arm64 and aarch64 are different names for the same architecture. Linux (kernel) and debian/ubuntu (and Apple in IOS/LLVM) called it arm64. ARM corp called it aarch64. The glibc ABI triplet is aarch64-linux-gnu. These are all the same ABI/architecture. Apologies for the confusion. I was rather hoping more projects would use the obvious (and IMHO more user-friendly) arm64 name, rather than following the corporate steer, and in the early days it was hard to tell how this would go. But most have plumped for aarch64, so users are exposed to both names. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: The state of Arm64 on Raspberry Pi (and its Documentation
On 2020-03-31 16:24 +0200, Ralph Aichinger wrote: > In comparison to this Debian's Arm64 wiki page lists tons of > obsolete Arm64 hardware that is no longer available, but does > not document the one Arm64 system that is the easiest to buy > in shops very well, in my opinion. > > https://wiki.debian.org/Arm64Port It's a wiki - feel free to update it. > Is there some "official" Debian documentation on how to > install aarch64 Debian on the Pi 3 or 4 in an "official" (i.e. > diverging as little as possible from Debian standards) way? Yes: The Pi1,2,and 3 docs are linked from here: https://wiki.debian.org/InstallingDebianOn https://wiki.debian.org/RaspberryPi3 being the first arm64 hardware. I gather there is a Pi4, so if someone could do that it would be helpful. No doubt it could all do with some updating as I expect support has improved. > Does installing Debian on top of UEFI firmware work yet > in practice Yes it works pretty well. > https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4 > > or should I start from somewhere else? I do not need graphics, > a purely headless setup is fine by me. > > Is there some way for a somewhat experienced sysadmin to > help in documenting this stuff, trying out things, filing bugs, etc? Yep - get an account on the wiki and start editing. Or file bugs if things are actually broken, but working in say, Rasbian or ubuntu and we could fix it (i.e. it's not due to non-free blobs) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Graphical installer on arm64
On 2020-01-05 22:06 +0300, Alper Nebi Yasak wrote:
> I've been working on getting Debian installer to run on my chromebook
> (kevin) for a while and I've also tested Wookey's patches [1] for enabling
> the graphical parts. The inputs didn't work with just those udebs as
> reported then, but adding 'event-modules-${kernel:Version}' as well to the
> pkg-list fixed that for me.
Great that you've followed up on this. Thanks.
> Can anyone else test this on other arm64 machines? I'm pretty sure it would
> work, but I suspect chromebook hardware to be weird so my success might not
> be indicative of general success.
Sure. I'll test it on eMAG and ThunderX.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Re: Ampere upcoming donation
On 2019-12-12 17:53 +0100, Hector Oron wrote: > Hello, > > This is just a heads-up that Ampere has reached out to Debian and > they are willing to donate some ARM64 server hardware to Debian. > > Reference datasheet for machines: > - > https://amperecomputing.com/wp-content/uploads/2019/04/Lenovo_ThinkSystem_HR330A_PB_20190409.pdf > - > https://amperecomputing.com/wp-content/uploads/2019/04/Lenovo_ThinkSystem_HR350A_20190409.pdf > > Thoughts, comments? I have an eMAG desktop machine which probably contains the same/very similar server board. I've started a debian-on page for it, but there isn't much info there yet. With have quite a lot of info on these machines internally so can help if there are any issues. e.g. there are firmware/BMC updates (which are not yet currently public, and I've been agitating about that - hopefully you'll have them on-board already). It's capable hardware and proper server kit with UEFI and BMC etc, so we should like it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: ARMEL vs ARMHF
On 2019-09-24 08:26 -0400, Kelly Rogers wrote: > Hi, > Can you give me the description of both architectures? See the wiki (below) > Witch hardware is compatible for both? In general anything armv7 or newer. > Witch OS can install on them? > Thank you! This set of questions requires a long answer. Most of what you want to know should be on these pages: https://wiki.debian.org/ArmPorts armel: https://wiki.debian.org/ArmEabiPort armhf: https://wiki.debian.org/ArmHardFloatPort Come back with a more specific question if it's not covered there. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Serial console on buster images
On 2019-07-28 17:41 +0200, Rainer Dorsch wrote:
> Hi,
>
> can anybody tell if the buster armhf images automatically add a serial
> console
> (e.g. for the cubox-i) or if that is a manual step?
Are you talking about whilst running the installer, or for normal
booting after the installer has run?
For the installer - it will now try to run on all the consoles the
kernel has declared 'enabled' by default. Ideally that will be both
the serial console and a frame buffer console displayed on any
connected screen, but there are few guarantees as it depends on the
combination of the firmware (uboot or UEFI and the DTB) and the kernel
and what they discover/enable by default.
At the end of the install any discovered serial consoles will be added
to the init/systemd config so you _should_ get a serial console on
boot if the install process discovered, or manually configured, one.
You can find out what the kernel does by default with
cat /proc/consoles
(anything marked with 'E' in the brackets is enabled):
tty0 -WU (EC p )4:2 (on this machine)
If your ttymxc0 is being found and enabled by the kernel, but not set up by the
installer, then that's a bug and we should work out why not.
> If manual, I assume I have to take the SD card after the installation and
>
> in /etc/systemd/system/getty.target.wants
> # ln -s /lib/systemd/system/getty@.service getty@ttymxc0.service
>
> Is that correct?
Sorry, I've not yet groked systemd so I have no idea how that works.
> I addition I assume I need to add
>
> # cd
> # echo 'setenv bootargs ${bootargs} console=ttymxc0,115200' >
> etc/flash-kernel/
> ubootenv.d/ttymxc0
>
> But how do I run flash-kernel on a x86 system, which has mounted the card? Is
> there a better way to add the bootargs?
With uboot, I'm not sure there is any substitue from actually running
on the machine and setting the bootargs there using whatever mechanism
is supplied to stop the bootloader in uboot so you can fiddle. But
someone else may know better.
With grub and UEFI you cn edit the grub config to set the kernel boot args.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
libopencsd backport?
Marcin asked for a backport of libopencsd (coresight trace decoding via perf) to backports. The guidelines point out that a package should have a reasonable userbase: https://backports.debian.org/Contribute/#index2h3 I'm not quite sure that libopencsd qualifies yet. (popcon gvies 1 whole user :-) And you'd need a new kernel-tools too to get a working perf. And the one testing will be in stable in a couple of months or three anyway. Worth doing for the intervening few months? Does anyone else care? https://github.com/Linaro/OpenCSD https://tracker.debian.org/pkg/libopencsd Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Does ARMEL toolchain include NEON support?
On 2019-02-28 09:05 +, Ian Campbell wrote:
>
> To spell it out: the gist of this is that it isn't possible to provide
> a single arm binary which works well for both armel and armhf (which I
> think is what Jeff is trying/wants to do?).
Just to clarify: it's not possible to built a binary which works at
all on both armel and armhf. They are different ABIs ('architectures'
in Debian terminaology). Modulo things like qemu emulation or other
very carefully constructed binaries a binary is one ABI or the other,
working together with others on that basis. There are then separate
questions of what base ISA (instruction set) it is built to (v5, v7),
and to what degree it requires/supports optional features of the
hardware/ABI (neon, fpu, maverick etc).
> The advice here is to instead ship[0] two binaries -- one targetting v5
> (no neon etc, aka armel in Debian) and another targetting v7 (w/
> possible(? I forget what is optional) neon and other stuff aka armhf in
> Debian and other distros).
Right. And neon is optional on armhf. i.e software needs to work
without it (because it's not present on all v7 hardware), but should
also support it if it improves performance significantly for that
software.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Re: Multiple console support in d-i
OK. Steve stayed up very late last night checking that this worked OK on x86 and adding some useful logging (allowing for the fact that it needs to work before syslog is actually started). We've checked some more stuff today, including testing the matching finish-install functionality on full installs, and reverting my fancy inittab seddery to go back to simply appending which is more reliable and easier to understand. We are now confident that the 'use init' version is the superior (cleaner and more reliable) approach. That's all merged in the attached patches which we reckon are now ready for general use. I will do some more testing (to check I've not broken hurd - bsd doesn't seem to be built at the moment so there is nothing to break), and of course we are ready to prod it some more if we find this does actually cause unhelpful behaviour for anyone. I also need to check the docs which no doubt need a few updates. I've found a couple of other things whilst poking about in the D-I entrails. There is plenty of cruft from older ways of doing things, which of course tends to get ignored if it's not actually breaking things, largely due to chronic undermanning in D-I land. I'll file some bugs and patches. None of it is urgent, but worth noting before I forget. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ diff --git b/debian/changelog a/debian/changelog index a7c80c3..e23b91e 100644 --- b/debian/changelog +++ a/debian/changelog @@ -7,7 +7,11 @@ rootskel (1.127) UNRELEASED; urgency=medium [ Holger Wansing ] * Remove trailing whitespaces from changelog file, to fix lintian tag. - -- Samuel Thibault Fri, 08 Feb 2019 01:50:37 +0200 + [ Wookey ] + * Support multiple consoles - Run D-I on all enabled consoles + * Rename reopen-console to choose-consoles + + -- Wookey Fri, 22 Feb 2019 15:57:39 + rootskel (1.126) unstable; urgency=medium diff --git b/src/etc/inittab-hurd a/src/etc/inittab-hurd index a7b8a23..eeff7e2 100644 --- b/src/etc/inittab-hurd +++ a/src/etc/inittab-hurd @@ -2,10 +2,9 @@ # busybox init configuration for debian-installer # main rc script -::sysinit:/sbin/reopen-console /sbin/debian-installer-startup +::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup # main setup program -::respawn:/sbin/reopen-console /sbin/debian-installer # convenience shells tty2::askfirst:-/bin/sh diff --git b/src/etc/inittab-kfreebsd a/src/etc/inittab-kfreebsd index 748f19b..c328548 100644 --- b/src/etc/inittab-kfreebsd +++ a/src/etc/inittab-kfreebsd @@ -2,10 +2,9 @@ # busybox init configuration for debian-installer # main rc script -::sysinit:/sbin/reopen-console /sbin/debian-installer-startup +::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup # main setup program -::respawn:/sbin/reopen-console /sbin/debian-installer # convenience shells ttyv1::askfirst:-/bin/sh diff --git b/src/etc/inittab-linux a/src/etc/inittab-linux index a7b8a23..d7136e2 100644 --- b/src/etc/inittab-linux +++ a/src/etc/inittab-linux @@ -2,10 +2,7 @@ # busybox init configuration for debian-installer # main rc script -::sysinit:/sbin/reopen-console /sbin/debian-installer-startup - -# main setup program -::respawn:/sbin/reopen-console /sbin/debian-installer +::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup # convenience shells tty2::askfirst:-/bin/sh @@ -19,3 +16,6 @@ tty4::respawn:/usr/bin/tail -f /var/log/syslog # re-exec init on receipt of SIGHUP/SIGUSR1 ::restart:/sbin/init + +# main setup program +# Entries will be added here as the system starts up diff --git b/src/sbin/Makefile a/src/sbin/Makefile index dec554e..f1a4f5f 100644 --- b/src/sbin/Makefile +++ a/src/sbin/Makefile @@ -8,7 +8,7 @@ files_exec = \ debian-installer-startup \ shutdown \ init:init-$(DEB_HOST_ARCH_OS) \ - reopen-console:reopen-console-$(DEB_HOST_ARCH_OS) \ + choose-consoles:choose-consoles-$(DEB_HOST_ARCH_OS) \ steal-ctty ifeq ($(DEB_HOST_ARCH_OS),linux) diff --git b/src/sbin/reopen-console-hurd a/src/sbin/choose-consoles-hurd similarity index 61% rename from src/sbin/reopen-console-hurd rename to src/sbin/choose-consoles-hurd index 7f9b54e..bef2b73 100755 --- b/src/sbin/reopen-console-hurd +++ a/src/sbin/choose-consoles-hurd @@ -4,9 +4,9 @@ # corresponding to the console we are actually using. console= -if ! [ -f /var/run/console-device ]; then - tty > /var/run/console-device +if ! [ -f /var/run/console-devices ]; then + tty > /var/run/console-devices fi # Some other session may have it as ctty. Steal it from them -exec /sbin/steal-ctty $(cat /var/run/console-device) "$@" +exec /sbin/steal-ctty $(cat /var/run/console-devices) "$@" diff --git b/src/sbin/reopen-console-kfreebsd a/src/sbin/choose-consoles-kfreebsd similarity index 87% rename from src/sbin/reopen-console-kfreebsd rename to src/sbin/choose-consoles-kfreebsd index 6dec149..2dd292a 100755 --- b/src/sbin/reopen-console-kfreebsd +++
Re: Multiple console support in d-i
On 2019-02-21 00:55 +, Steve McIntyre wrote:
> Hey Wookey,
>
> Reviewing the code from your patches in sequence, I think the approach
> looks good *except* I think you've missed a patch or a commit or
> something.
>
> Trying to apply debian-installer-multiple-consoles.patch and
> rootskel-multiple-consoles-inittab.patch in sequence, there are patch
> failures. They clearly depend in that order for the changes in
> src/etc/inittab-linux, but the src/sbin/reopen-console-linux hunks
> don't match up. The last thing I want to do here is miss a line in the
> middle of fixing up by hand and break this... :-)
>
> Could you post a single patch against current HEAD with all of your
> changes rolled up please?
Well, there are two branches. The original implmentation and the 'use init'
implementation.
So attached are two independent (i.e. each is against rootskel HEAD) for those.
Original: rootskel-multiple-consoles2.patch
Init-based: rootskel-multiple-consoles-inittab3.patch
Use one or the other, not both.
The finish-install patch has to be separate because it's a different git repo.
Also included.
Required in either case.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
diff --git a/src/etc/inittab-linux b/src/etc/inittab-linux
index a7b8a23..437e208 100644
--- a/src/etc/inittab-linux
+++ b/src/etc/inittab-linux
@@ -5,7 +5,7 @@
::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
# main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
+::respawn:/sbin/reopen-console --all-consoles /sbin/debian-installer
# convenience shells
tty2::askfirst:-/bin/sh
diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux
index 3287dd0..e13bfa3 100755
--- a/src/sbin/reopen-console-linux
+++ b/src/sbin/reopen-console-linux
@@ -1,74 +1,68 @@
#!/bin/sh
# In order to give proper access to the tty, we need to locate the device
-# corresponding to the console we are actually using.
+# corresponding to each console we are actually using.
+
+# This script is run twice, once at sysinit to run the debian-installer-startup
+# rc scripts, and once to start the installer itself.
+# The first time it parses the consoles used, the second time they are read from files
+# The startup scripts need to be run just once (on one console) (not idempotent)
+# The installer is run on all the enabled consoles (using the --all-consoles option)
+
NL="
"
-console=
-if ! [ -f /var/run/console-device ]; then
- # If the kernel emitted a "handover" message, then it's the one
- case $(uname -r) in
- 2.6.2*|2.6.3[01]*)
- console="$(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console handover: boot \[.*\] -> real \[(.*)\]$/\2/p')"
- ;;
- 2.6.3[234567]*)
- console="$(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled, bootconsole disabled$/\2/p')"
- ;;
- *) # >= 2.6.38
- console_major_minor="$(get-real-console-linux)"
- console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
- console="${console_raw##*/}"
- ;;
- esac
-
- # Except if it is the wrong type...
- if [ "$console" ] && [ "$(console-type)" = serial ] && \
- expr "$console" : "tty[0-9]" >/dev/null; then
- console=
- fi
+if ! [ -f /var/run/console-devices ]; then
consoles=
- if [ -z "$console" ]; then
- # Retrieve all enabled consoles from boot log; ignore those
- # for which no device file exists
- for cons in $(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled/\2/p')
- do
- if [ -e "/dev/$cons" ]; then
-consoles="${consoles:+$consoles$NL}$cons"
- fi
- done
- # Only one console? Then we are good.
- if [ $(echo "$consoles" | wc -l) -eq 1 ]; then
- console="$consoles"
+ preferred=
+ # Retrieve all enabled consoles from kernel; ignore those
+ # for which no device file exists
+
+ kernelconsoles="$(cat /proc/consoles)"
+ for cons in $(echo "$kernelconsoles" | sed -n -r -e 's/(^.*) .*\((.*)\).*$/\1/p' )
+ do
+ status=$(echo "$kernelconsoles" | grep $cons | sed -n -r -e 's/(^.*) *.*\((.*)\).*$/\2/p' )
+ if [ -e "/dev/$cons" ] && [ $(echo "$status" | grep -o 'E') ]; then
+ consoles="${consoles:+$consoles$NL}$cons"
fi
- fi
+ # 'C' console is 'most prefered'.
+ if [ $(echo "$status" | grep -o 'C') ]; then
+ preferred="$cons"
+ fi
+ done
- if [ -z "$console" ]; then
- # Locate the last enabled console present on the command line
- for arg in $(cat /proc/cmdline); do
- case $arg in
- console=*)
-arg=${arg#console=}
-cons=${arg%%,*}
-if echo "$consoles" | grep -q "^$cons$"; then
- console=$cons
-fi
-;;
- esac
-
Re: Multiple console support in d-i
On 2019-02-21 00:55 +, Steve McIntyre wrote: > Hey Wookey, > > Reviewing the code from your patches in sequence, I think the approach > looks good *except* I think you've missed a patch or a commit or > something. > > Trying to apply debian-installer-multiple-consoles.patch and > rootskel-multiple-consoles-inittab.patch in sequence, there are patch > failures. They clearly depend in that order for the changes in > src/etc/inittab-linux, Yeah - I noticed after posting that one patch depended on the other, as opposed to them being independent, which wasn't what I meant to do. Sorry about that. > Could you post a single patch against current HEAD with all of your > changes rolled up please? Will do. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Multiple console support in d-i
On 2019-02-09 04:11 +, Wookey wrote: > Future work: > > All this faffage has made me realise that a better approach to all > this would probably be to get rid of all this 'steal-ctty' bodgery, > and use init to do it's job: it's designed to run multiple things on > multiple consoles, and deal with file handles and them failing etc. > > The catch is that to make this work we'd have to use sysinit: to run > the console-choosing code, then write a new inittab containing one > respawn:/sbin/debian-installer for each console instance, then HUP > init. This should do exactly the right thing (assuming that busybox > init isn't too thick to get HUPing right). OK. This does indeed work nicely and is a cleaner solution than what is currently in D-I. It probably works for hurd and bsd too assuming their init behaviour is similar? (I think kill -HUP 1 should do the same thing on all 3 kernels?) (anyone up for testing these?) So now inittab looks like: # main rc script ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup # main setup program tty0::respawn:/sbin/debian-installer ttyAMA0::respawn:/sbin/debian-installer (these lines added for whatever consoles are found) (and the rest as before - spare shells, tty4 for logging and restart stuff) Attached is a patch implementing this. It does rely on the inittab comment '# main setup program' existing in order to anchor the sed edit, so perhaps a comment should go in there so someone doesn't accidentally edit it in the future and break this code? Or we could just use a simple append (it's not aesthetic just putting them on the end but it does work fine), or just 'insert at line n'. Given the constrained environment I don't think it matters much - maintainability is probably the most important thing here. Steal-ctty is still present for the initial run of the debian-install-startup scripts but I suspect it's not actually needed. Anyone know if there was ever a good reason for running the rc scripts through this as well as doing so for the installer itself? This all works with netbook-gtk too (X starts on framebuffer, as before) Feedback on this patch is welcome. Note that my finish-install patch should be applied too if this one is used. Issues: The framebuffer console came up with some UTF-8 chars as blocks (ones not in 8859-1?). I've seen this before once with the old code then it went away again, so I'm not sure it's anything to do with these changes but it might be. The LANG=C.UTF-8, TERM=linux, TERM_TYPE=virtual, TERM_FRAMEBUFFER=yes, which seems reasonable. Clues welcome. fonts or TERM configuration? Further work: There is more tidying that could be done here, but some discussion is in order first. With things done this way 'reopen-console' is something of a misnomer as it only gets run once. 'choose-console' would be better. Or possibly something like 'initialise-installer' as it now chooses the consoles, calls the init-script runner and reinits to start the real installer. Perhaps a more logical split is choose-consoles: (OS-specific) 1) parses consoles, saves in /var/run files 2) runs debian-installer-startup debian-installer-startup: (OS-independent) 1) modifies inittab 2) runs startup scripts 3) HUPs init This seems a bit cleaner and better-named? Also is there any point having choose-console run $@ now there is only one thing it runs (debian-installer-startup)? The fly in this pointment is that there is one script that uses the existing /sbin/debian-installer-startup. That is debian-installer-launcher/debian-installer.sh which runs it in a live image chroot so moving the restart init there would be an unexpected change of interface. The desire to leave that interface alone results in this: choose-consoles: (OS-specific) 1) parses consoles, saves in /var/run files 2) modifies inittab 3) runs debian-installer-startup 4) HUPs init debian-installer-startup: (OS-independent) 1) runs startup scripts Which is essentially the existing patch, but renaming reopen-console -> choose-consoles currently we have: ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup but I suggest we just change it to: ::sysinit:/sbin/choose-consoles and choose consoles can explicitly run /sbin/debian-installer-startup This just makes it a bit more obvious how things work/fit together. Have I missed anything? Does anyone care about all this? Shall I just stop now (it's working fine) or tidy a bit more to make the names clearer and reduce the cruft further? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ commit 7b3718082645c2265f96b8349ae25a31f3bc73e3 Author: Wookey Date: Mon Feb 11 16:39:40 2019 + Use inittab to run multiple installers diff --git a/src/etc/inittab-linux b/src/etc/inittab-linux index 437e208..830ee94 100644 --- a/src/etc/inittab-linux +++ b/src/etc/inittab-linux @@ -5,7 +5,6 @@ ::sysinit:/sbin/reopen-console /sbin/debian-in
Re: Multiple console support in d-i
On 2019-01-19 11:08 +, Steve McIntyre wrote:
> On Sat, Jan 19, 2019 at 04:27:05AM +0000, Wookey wrote:
[Re: adding multiple console support to D-I, including changing
/var/run/console-device with one device line to be
/var/run/console-devices with 1 or more lines]
> >The only other place this affects is
> >packages/finish-install.d/90console which reads
> >/var/run/console-device when tidying up at the end in order to write
> >inittab entries for the used console device (serial, xen, etc).
So here is the patch for that so that the right file is looked in and
any serial devices are dealt with as before, alowing for the fact there
may be more than one console device listed.
This code is not well-tested yet, but I think it does the right
thing. Review welcome. I can't see any reason why running through this
more than once should change anything, but I could be missing something.
I note that there is a load of upstart support in here. Can anyone
thing of a reason to keep that? I suspect it should go. Happy to do that if we
agree.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
commit 2e238ab985eebd44f29cc7b5cd6b7cacc71d792e
Author: Wookey
Date: Fri Feb 15 01:50:44 2019 +
Update to deal with multiple consoles
diff --git a/finish-install.d/90console b/finish-install.d/90console
index bd2f528..0045046 100755
--- a/finish-install.d/90console
+++ b/finish-install.d/90console
@@ -38,72 +38,76 @@ case "$(udpkg --print-os)" in
hurd)
# TODO: detect VGA hurd console, and enable it in installed
# system.
- console=console
+ consoles=/dev/console
;;
*)
- console=$(cat /var/run/console-device)
- console=${console#/dev/}
+ consoles=$(cat /var/run/console-devices)
;;
esac
-if [ -f /target/etc/init/tty1.conf ]; then
- upstart_tty1=/target/etc/init/tty1.conf
- upstart_console () {
+for console in $consoles
+do
+ console=${console#/dev/}
+
+ if [ -f /target/etc/init/tty1.conf ]; then
+ upstart_tty1=/target/etc/init/tty1.conf
+ upstart_console () {
echo "/target/etc/init/$1.conf"
- }
-elif [ -f /target/etc/event.d/tty1 ]; then
- upstart_tty1=/target/etc/event.d/tty1
- upstart_console () {
+ }
+ elif [ -f /target/etc/event.d/tty1 ]; then
+ upstart_tty1=/target/etc/event.d/tty1
+ upstart_console () {
echo "/target/etc/event.d/$1"
- }
-else
- upstart_tty1=
-fi
-
-case "$console" in
-tty[A-Zu]*|duart*)
- log "Configuring init for serial console"
- consoletype=${console%%[0-9]*}
- ttyline=${console#$consoletype}
- ttyspeed=$(chroot /target stty --file /dev/$console speed)
- ttyterm="$TERM"
-
- flowctrlarg=""
- if uses_hw_flowcontrol $console; then
- flowctrlarg="-h "
+ }
+ else
+ upstart_tty1=
fi
- if [ -z "$ttyterm" ]; then ttyterm=vt100; fi
- if [ -z "$ttyspeed" ]; then ttyspeed=9600; fi
+ case "$console" in
+ tty[A-Zu]*|duart*)
+ log "Configuring init for serial console"
+ consoletype=${console%%[0-9]*}
+ ttyline=${console#$consoletype}
+ ttyspeed=$(chroot /target stty --file /dev/$console speed)
+ ttyterm="$TERM"
+
+ flowctrlarg=""
+ if uses_hw_flowcontrol $console; then
+ flowctrlarg="-h "
+ fi
- if [ -f /target/etc/inittab ]; then
- # Disable regular VTs
- if [ -z "$KEEP_VT" ]; then
+ if [ -z "$ttyterm" ]; then ttyterm=vt100; fi
+ if [ -z "$ttyspeed" ]; then ttyspeed=9600; fi
+
+ if [ -f /target/etc/inittab ]; then
+ # Disable regular VTs
+ if [ -z "$KEEP_VT" ]; then
sed -i -e "s/^\([1-6]\):/#\1:/" /target/etc/inittab
+ fi
+ # Enable serial console
+ sed -i -e "s/^#T0\(.*\)ttyS.*/T$ttyline\1$console $ttyspeed $ttyterm/" \
+ /target/etc/inittab
+ sed -i -e "s/^\(T$ttyline.*\) -8/\1/" /target/etc/inittab
+ sed -i -e "s/^\(T$ttyline.* \)-L/\1$flowctrlarg-L/" /target/etc/inittab
+ fi
+ if [ "$upstart_tty1" ]; then
+ sed -e "s/^\(exec.*getty \).*/\1-L $console $ttyspeed $ttyterm/" \
+ -e "s/tty1/$console/g" \
+ "$upstart_tty1" > "$(upstart_console "$console")"
+ sed -i -e "s/^\(exec.*\) -8/\1/" "$(upstart_console "$console")"
+ sed -i -e "s/^\(exec.*\)-L/\1$flowctrlarg-L/" "$(upstart_console "$console")"
+ fi
+ if [ "$(readlink /target/sbin/init)" = "/lib/systemd/systemd" ] ; then
+ chroot /target systemctl --no-reload --quiet enable serial-getty@"$console".service
fi
- # Enable serial console
- sed -i -e "s/^#T0\(.*\)ttyS.*/T$ttyline\1$console $ttyspeed $ttyterm/" \
- /target/etc/inittab
- sed -i -e "s/^\(T$ttyline.*\) -8/\1/" /target/etc/inittab
- sed -i -e
Re: Multiple console support in d-i
On 2019-02-09 04:11 +, Wookey wrote:
> On 2019-01-25 03:45 +0000, Wookey wrote:
>
> Attached is a patch which provides working multiconsole support for
> linux (not hurd or bsd, sorry).
>
> One bug I just noticed in the bit we did today is that the 'default'
> preferred console (for when one is not indicated by the kernel) avoids
> the existence-check for the /dev file, so that should be
> improved. It's not hard, but I'll resist doing it now and sending an
> untested patch :-)
OK. Updated version attached which is more robust about choosing the
'preferred' console.
I did some tests and discovered that, at least on thunderx, you get
slightly different behaviour WRT kernel command line options than the
old code, but I don't think it really matters.
Essentially the set of consoles is now 'those listed on the kernel
command line + whatever UEFI says is the default console'. Previously
you got 'whatever UEFI says is the default console, or the last one on
the kernel cmd line'. i.e the kernel no longer overrides the UEFI console,
it gets added. Now that D-I works on all provided consoles this doesn't
really matter much.
So on thunderx, for example, you get this:
default (nothing specified):
consoles: /dev/ttyAMA0
preferred: /dev/ttyAMA0
cmdline: console=tty0
consoles: /dev/tty0 /dev/ttyAMA0
preferred: /dev/tty0
cmdline: console=tty0 console=ttyAMA0
consoles: /dev/tty0 /dev/ttyAMA0
preferred: /dev/tty0
cmdline: console=ttyAMA0
consoles: /dev/ttyAMA0
preferred: /dev/ttyAMA0
Which all seems reasonable.
Testing this on some other machines/arches is the next thing to do, although
just checking what /proc/consoles shows tells you what should happen.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
diff --git a/src/etc/inittab-linux b/src/etc/inittab-linux
index a7b8a23..437e208 100644
--- a/src/etc/inittab-linux
+++ b/src/etc/inittab-linux
@@ -5,7 +5,7 @@
::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
# main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
+::respawn:/sbin/reopen-console --all-consoles /sbin/debian-installer
# convenience shells
tty2::askfirst:-/bin/sh
diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux
index 3287dd0..e13bfa3 100755
--- a/src/sbin/reopen-console-linux
+++ b/src/sbin/reopen-console-linux
@@ -1,74 +1,68 @@
#!/bin/sh
# In order to give proper access to the tty, we need to locate the device
-# corresponding to the console we are actually using.
+# corresponding to each console we are actually using.
+
+# This script is run twice, once at sysinit to run the debian-installer-startup
+# rc scripts, and once to start the installer itself.
+# The first time it parses the consoles used, the second time they are read from files
+# The startup scripts need to be run just once (on one console) (not idempotent)
+# The installer is run on all the enabled consoles (using the --all-consoles option)
+
NL="
"
-console=
-if ! [ -f /var/run/console-device ]; then
- # If the kernel emitted a "handover" message, then it's the one
- case $(uname -r) in
- 2.6.2*|2.6.3[01]*)
- console="$(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console handover: boot \[.*\] -> real \[(.*)\]$/\2/p')"
- ;;
- 2.6.3[234567]*)
- console="$(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled, bootconsole disabled$/\2/p')"
- ;;
- *) # >= 2.6.38
- console_major_minor="$(get-real-console-linux)"
- console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
- console="${console_raw##*/}"
- ;;
- esac
-
- # Except if it is the wrong type...
- if [ "$console" ] && [ "$(console-type)" = serial ] && \
- expr "$console" : "tty[0-9]" >/dev/null; then
- console=
- fi
+if ! [ -f /var/run/console-devices ]; then
consoles=
- if [ -z "$console" ]; then
- # Retrieve all enabled consoles from boot log; ignore those
- # for which no device file exists
- for cons in $(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled/\2/p')
- do
- if [ -e "/dev/$cons" ]; then
-consoles="${consoles:+$consoles$NL}$cons"
- fi
- done
- # Only one console? Then we are good.
- if [ $(echo "$consoles" | wc -l) -eq 1 ]; then
- console="$consoles"
+ preferred=
+ # Retrieve all enabled consoles from kernel; ignore those
+ # for which no device file exists
+
+ kernelconsoles="$(cat /proc/consoles)"
+ for cons in $(echo "$kernelconsoles" | sed -n -r -e 's/(^.*) .*\((.*)\).*$/\1/p' )
+ do
+ status=$(echo "$kernelconsoles" | grep $cons | sed -n -r -e 's/(^.*) *.*\((.*)\).*$/\2/p' )
+ if [ -e "/dev/$cons" ] && [ $(echo "$status" | grep -o 'E') ]; then
+ consoles="${co
Re: Multiple console support in d-i
On 2019-01-25 03:45 +, Wookey wrote: > So, unless anyone can see a problem with this approach, I'll finish > this off. Trying to do it with separate /var/run/consoles and > /var/run/extra-consoles files was getting very messy. OK. This took way longer than I hoped as it was not entirely trivial to get everything working. Attached is a patch which provides working multiconsole support for linux (not hurd or bsd, sorry). After getting the proc/console choosing code working nicely the installer was still mysteriously not working (nothing on consoles except debug) unless I let it respawn in which case it sort of worked (things appeared but input oddness and continuous respawning isn't much use to anyone). I was confused for a while as to what was going on but eventually worked it out. Just to recap: The objective here is to run D-I on all the enabled consoles, (and ideally not fiddle with the code any more than is needed). First step was upgrading the console parsing code to use /proc/consoles to get the list, noting the preferred console if there is one marked as such. The main complication is that reopen-consoles is run twice by init, once with debian-installer-startup and once with debian-installer: # main rc script ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup # main setup program ::respawn:/sbin/reopen-console /sbin/debian-installer The first run of reopen-console works out which consoles to use, and writes it in a file, (/var/run/console-devices), the second run just uses that file. debian-installer-startup is just a shell script that runs through all the debian-installer-startup.d rc scripts, like S01mount, S04countcpus-linux-hppa, S10syslog. debian-installer actually runs the installer, on the second invocation of reopen-consoles. So the original plan was just to run $@ (debian-installer) on the found consoles. But doing that for the rc scripts is not helpful. Most of it is idempotent, but you end up with two syslogs and two klogds and running it all twice on different consoles really isn't right. So I added an --all-consoles option to declare that we want something (/sbin/debian-installer in this case) run on all the consoles. # main rc script ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup # main setup program ::respawn:/sbin/reopen-console --all-consoles /sbin/debian-installer It's also worth noting that 'steal-ctty' cannot set the process as 'controlling tty' when two are run, because only one process can be controlling tty in a session. So I did add error checking to that (it had none before), but had to take it out again for the 'set ctty' IOCTL as it's correct for it to fail in the muti-console case. So what happens now is that the rc-scripts are run on the 'preferred' console (or the first console listed if none are marked preferred), then D-I is run on all of them. It does not return to init in this case (as previously discussed). This is an important improvement so despite it having ended up rather late in the day, I hope we can include this for buster. I'm happy to do more work on tidying up any breakage if we find any. Future work: All this faffage has made me realise that a better approach to all this would probably be to get rid of all this 'steal-ctty' bodgery, and use init to do it's job: it's designed to run multiple things on multiple consoles, and deal with file handles and them failing etc. The catch is that to make this work we'd have to use sysinit: to run the console-choosing code, then write a new inittab containing one respawn:/sbin/debian-installer for each console instance, then HUP init. This should do exactly the right thing (assuming that busybox init isn't too thick to get HUPing right). That is way cleaner and I'm happy to have a go at that, but it feels more intrusive and unless I'm very lucky it may take a while so I sugest we go with the above for now, as it works already. One bug I just noticed in the bit we did today is that the 'default' preferred console (for when one is not indicated by the kernel) avoids the existence-check for the /dev file, so that should be improved. It's not hard, but I'll resist doing it now and sending an untested patch :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ diff --git a/src/etc/inittab-linux b/src/etc/inittab-linux index a7b8a23..437e208 100644 --- a/src/etc/inittab-linux +++ b/src/etc/inittab-linux @@ -5,7 +5,7 @@ ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup # main setup program -::respawn:/sbin/reopen-console /sbin/debian-installer +::respawn:/sbin/reopen-console --all-consoles /sbin/debian-installer # convenience shells tty2::askfirst:-/bin/sh diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux index 3287dd0..32dfd24 100755 --- a/src/sbin/reopen-console-linux +++ b/src/sbin/reopen-console-linux @@ -1,74 +1,67 @@ #!/bin/sh # In order to give proper access to the tty, we need
Re: Multiple console support in d-i
On 2019-01-23 08:35 +, Ian Campbell wrote:
> On Wed, 2019-01-23 at 03:41 +0000, Wookey wrote:
> > Any idea how we should choose a D-I primary console when none of them
> > is marked 'preferred'? Or should D-i do away with the concept and try
> > to treat them all equally (which is a slightly more intrusive
> > change).
> Even if the bug were fixed it seems sensible to deal with this case,
> last one (with sufficient other flags set) seems like as good as
> anything...
OK. I've had 'fun with shell' getting this right and gone through a
couple of iterations.
After some thought, so far as I can see the 'preferred' console
concept is no longer useful once D-I runs on more than one. We don't
know which one the user is going to actually use, and the whole point
is that all the instances should work the same. We're not trying the
choose the 'right' console any more, just exposing the interface on
all the ones that (should) work.
The only reason for keeping it would be to keep the reopen-console
logic more like it currently is, so that the preferred console got to
replace the reopen-consoles process (via exec) and the others didn't
(becoming child processes of reopen-consoles dash instance). But you
end up with rather cleaner code if in fact you just run D-I on all enabled
consoles and treat them equivalently (as child processes). New version
(with debug still in) attached to show what I mean (or see below).
However this does lead to a question about D-I and inittab respawn logic.
Currently reopen-console ends with
exec D-I
so D-I replaces the process.
It is started with this inittab line:
::respawn:/sbin/reopen-console /sbin/debian-installer
Do we ever make use of D-I finishing in such a way that init finds the
process is gone and respawns? My assumption is that we don't want this
to happen, at least in general (otherwise the installer would restart
when you finished, rather confusingly). But perhaps there are error
cases when this is wanted?
The reason it matters is because it affects how the multiple D-Is on
different consoles should be started and what we should do when one
quits, or all quit.
My current code does this:
for cons in $(cat /var/run/console-devices)
do
# Some other session may have console as ctty. Steal it from them
( exec /sbin/steal-ctty $cons "$@" & )
done
#don't return to init
sleep infinity
Which just starts a D-I on all the consoles, then sits forever (to
stop init from re-running this code over and over). You _could_ have
some extra logic to make one special, and exec that one, and keep the
others as child-processes, but I'm not convinced that this achieves
anything (except complexity, and potentially confusingly different
behaviour between consoles), unless the respawning is important in
some way I have failed to grok so far?
(You'll note the above is rather nicer than my first effort with two
different /var/run/* files, and $console and $extraconsoles). Having
just the one 'consoles used' list file makes it all cleaner. (I've
fixed up finish-install/finish-install.d/90console to deal with more
than one console listed in that file too)
Possibly what we'd really like is that if you quit _any_ console D-I
instance then it would return and respawn, but a) I can't work out how
to do that (you can only exec one thing) and b) does it actually help?
So, unless anyone can see a problem with this approach, I'll finish
this off. Trying to do it with separate /var/run/consoles and
/var/run/extra-consoles files was getting very messy.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
#!/bin/sh
# In order to give proper access to the tty, we need to locate the device
# corresponding to each console we are actually using.
NL="
"
if ! [ -f /var/run/console-devices ]; then
consoles=
preferred=
# Retrieve all enabled consoles from kernel; ignore those
# for which no device file exists
kernelconsoles="$(cat /proc/consoles)"
for cons in $(echo "$kernelconsoles" | sed -n -r -e 's/(^.*)
.*\((.*)\).*$/\1/p' )
do
echo "cons in /proc/consoles: $cons"
status=$(echo "$kernelconsoles" | grep $cons | sed -n -r -e
's/(^.*) *.*\((.*)\).*$/\2/p' )
echo "console: $cons, status: $status"
if [ -e "/dev/$cons" ] && [ $(echo "$status" | grep -o 'E') ];
then
consoles="${consoles:+$consoles$NL}$cons"
fi
# 'C' console is 'most prefered'. Do we care?
if [ $(echo "$status" | grep -o 'C') ]; then
preferred="$cons"
fi
done
echo "after parsing, consoles set to: $consoles"
echo "after parsing, preferred is: $preferred"
Re: Multiple console support in d-i
On 2019-01-22 08:23 +, Ian Campbell wrote: > On Tue, 2019-01-22 at 04:31 +0000, Wookey wrote: > > On 2019-01-20 03:02 +, Ben Hutchings wrote: > > > Reading /proc/consoles is exactly what you should do. > > > > Checking this on a booted thunderx machine (with no explicit kernel cmdline > > options) it lists > > ttyAMA0 > > > > If I boot with explicit console=tty0 console=ttyAMA0 on the kernel cmdline > > then they both appear in /proc/consoles, AMA0 last > > > > If I boot with explicit console=tty0 on the kernel cmdline > > then they both appear in /proc/consoles, AMA0 still last > > Do the various flags not differ between the different cases? You are right. I wasn't taking note of those: E=enabled C=preferred console p=used for printk buffer a=safe to use when CPU is offline console=tty0 tty0 -WU (EC p )4:7 ttyAMA0 -W- (E p a) 204:64 console=ttyAMA0 tty0 -WU (E p )4:7 ttyAMA0 -W- (EC p a) 204:64 console=tty0 console=ttyAMA0 tty0 -WU (E p )4:7 ttyAMA0 -W- (E p a) 204:64 Any idea how we should choose a D-I primary console when none of them is marked 'preferred'? Or should D-i do away with the concept and try to treat them all equally (which is a slightly more intrusive change). Currently I use the one marked 'C' or the last one if none. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: arm64 graphical installer
On 2019-01-19 11:12 +, Steve McIntyre wrote: > [ Adding CC to debian-arm for interest ] > > On Sat, Jan 19, 2019 at 03:39:44AM +0000, Wookey wrote: > >I've done some work on getting the graphical installer going on arm64. > > \o/ > > >I was not able to demonstrate that the resulting build works fully, > >because when it tries to boot the kernel I get "Error: Invalid Magic > >number..., you need to load the kernel first". No idea why that's > >changed due to adding more module packages? Clues welcome. OK, this turned out to be 'pulled USB stick out before it was fully written' (forgot the fsync option). So in fact it does boot fine with lots of extra modules, but still no working keyboard/mouse input. For this fairly basic X server what is it expecting as input device? Is it using udev?, /dev/events?, libinput?, evdev? something else? (I'm a bit vague about how this fits together). It all works fine when I boot into X with standard debian. Comparing module lists and Xorg logs... on real debian its using 'driver libinput': [ 1411.187] (II) Using input driver 'libinput' for 'LITE-ON Technology USB NetVista Full Width Keyboard.' [ 1411.187] (**) LITE-ON Technology USB NetVista Full Width Keyboard.: always reports core events [ 1411.187] (**) Option "Device" "/dev/input/event2" [ 1411.187] (**) Option "_source" "server/udev" on D-I (netboot-gtk) we have: xserver-xorg-input-evdev-udeb udev-udeb libevdev2-udeb kbd-udeb x11-xkb-utils-udeb xkb-data-udeb input-modules uinput-modules usb-modules but not: xserver-xorg-input-libinput-udeb or libinput (which does not have udebs for any arch, so presumably not relevant) Is that expected? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Multiple console support in d-i
On 2019-01-20 03:02 +, Ben Hutchings wrote: > /proc/consoles shows everything on the global console_drivers list. > Every time a console is added to the list the kernel logs a message > with the format "%sconsole [%s%d] enabled\n". So these should match, > except that (1) it is also possible to unregister consoles, and reopen- > consoles doesn't account for that (2) the kernel log might have rolled > over so that reopen-console-linux doesn't see the messages. > > > Does it include any/all listed explicitly on the kernel command line? > > It's a bit more complicated than that. The kernel has a table of up to > 8 "preferred" console devices, which can be specified on the kernel > command, or through Device Tree or platform code, or by a hypervisor. > The device specified last (which usually means the last console= > argument on the command line) is the most preferred. > > If some preferred devices are specified, then console_drivers will > include all the console devices that are preferred *and* have been > found to exist, and the most preferred (if it exists) will be first. > > Otherwise, the kernel seems to enable the first console device found to > exist. > Reading /proc/consoles is exactly what you should do. Checking this on a booted thunderx machine (with no explicit kernel cmdline options) it lists ttyAMA0 If I boot with explicit console=tty0 console=ttyAMA0 on the kernel cmdline then they both appear in /proc/consoles, AMA0 last If I boot with explicit console=tty0 on the kernel cmdline then they both appear in /proc/consoles, AMA0 still last So /proc/consoles does indeed correspond to the set of enabled consoles listed by dmesg, however the last-listed on the cmdline is not necessarily the last in the list. Perhaps this is influenced by the device EFI specifies as the default console? What it doesn't do (which I was hoping for) is automagically note that there is a display attached (that could be used as a console) unless you tell it to look. Anyone know what would it take to make tty0 appear as a valid console on a thunderx machine without having to explicitly list it on the kernel command line? This is what we'd ideally like to happen. I've modified reopen-console-linux to use /proc/console and run D-I on all found. I'll test that on tue when back at suitable machine, and post here when it shows signs of working. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Multiple console support in d-i
On 2019-01-19 20:11 +, Ben Hutchings wrote: > On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote: > [...] > > * add lots more console= options to the grub.cfg for arm64 (to cover > >all the possibilities), then let d-i startup work out which devices > >exist from /proc/cmdlinge and spawn d-i on each. > [...] > > I think you should look in /proc/consoles, not /proc/cmdline. The > format is documented in > https://www.kernel.org/doc/Documentation/filesystems/proc.txt Interesting. Currently reopen-consoles does: if d-i console not already recorded set console using kernel 'handover' message (in dmesg) if running pre 2.6.38 kernel unless it's set to serial on a non-serial tty, in which case unset it make list of 'enabled consoles' from 1st 260k of dmesg if one matching device, then set as console if still not found (only) one, set to last one in kernel command line args if still not found one, default to /dev/console record chosen console fi start d-i on recorded console. I'm not entirely convinced that all this logic is actually needed/optimum, but I don't know the history of it. How exactly does /proc/consoles fit into that? The docs say it is "registered system consoles". Does that correspond to the same list of 'enabled consoles' the above is currently fishing out of dmesg? Does it include any/all listed explicitly on the kernel command line? My current code leaves all this alone and just records/uses all enabled consoles on the command line, not just the last one, but ideally we'd autodetect and/or hardcode all the sensible available consoles and run on them. If 'read /proc/consoles (and check the devices exist)' does this, then that sounds very sensible. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On 2018-11-27 21:19 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió: > > prepare dual stack packages that use the symbols file magic from > > Ubuntu, rebuild all the reverse-dependencies, and identify all those > > packages which are libraries and which end up with a dependency only on the > > GL version of the package instead of a dependency on GL | GLES. > > > > A fair amount of compile time required to do this analysis, but relatively > > little human time. > > As long as the human behind it has a way to simply trigger this rebuilds > automatically. I think Ubuntu has by using launchpad. We in Debian don't > (please prove me wrong!). On my current machine that would take > approximately... a couple of months. Without using it for anything else. > > Of course, if anyone feels like doing it... :-) I've been talking to people about this awkward situation, and it seems to me that to do this properly either we have a good translation layer (GL->GLES, and probably GLES->Vulkan too in longer term) or we have dual stacks available. I think it's worth investing some effort in determining how practical these routes are, and the above is something I think is within my capabilities. I'm not overflowing with tuits, but I do think this is important so I'm prepared to spend some cycles on it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On 2018-11-23 23:10 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió: > > > > My main desktop is now an arm64 machine with an nvidia PCI graphics > > card. These are fairly new (and currently expensive), but I have > > reason to believe there is more of this sort of thing coming, and > > laptop-format machines. > > Well, that's at very least an interesting data point. So yes, they exist, but > they are new and expensive. Can I assume that this means most of our arm64 > users do not yet get to them? Not yet, no although I think you can just buy one (Gigabyte ThunderXstation) now. But Machiato-bin exists with working PCI and you can buy one (https://wiki.debian.org/InstallingDebianOn/Marvell/MACCHIATOBin), and nvidia-based hardware is available and supports GL (Jetson TX1) (https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1). There is more hardware coming which will support GL, so it is definately not as simple as 'available hardware is all GLES'. (Perhaps someone has made a list in this long thread). > > I recall Linaro doing some work on this back > > when it started (to make it easier to switch between GL and > > GLES). Possibly that work never actually got done, just talked out. > > It would really help, indeed. OK. It seems that this project was started, but not completed due to a lack of interest at the time (2012) (people just started using GLES on dev boards/phones). It's here: https://code.launchpad.net/glproxy And here is the spec: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Specs/1105/GLProxy Perhaps it is worth resurrecting this project if it would let us acheive the nirvana of runtime selection between GL and GLES, thus making everyone happy. Jammy Zhou cc:ed can say how much was/wasn't done. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote: > Hello, > > - Qt is tied to either Desktop or GLES: yes > > > > So we need to pick one. The question is then which one will benefit our > > users > > most. > > > > So far I personally know 0 people with an arm64 board with PCI slots, while > > I > > know many with arm64 boards with hardware GLES support. My main desktop is now an arm64 machine with an nvidia PCI graphics card. These are fairly new (and currently expensive), but I have reason to believe there is more of this sort of thing coming, and laptop-format machines. I need to investigate this further, but changing from GL to GLES just at the moment where desktop hardware starts to make inroads could be a big own goal on arm64. I recall Linaro doing some work on this back when it started (to make it easier to switch between GL and GLES). Possibly that work never actually got done, just talked out. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: D-Link DNS-323 support dropped in Debian stretch
On 2018-03-26 19:36 +0900, Roger Shimizu wrote: > [ loop debian-kernel ML ] > > > The question is whether it deserves the effort, not only creating the > new flavour, but also maintaining it during the whole buster period. > So I want to know how many active users for D-Link DNS and QNAP devices now? I've just acquired a DNS-320, which I plan to use for some years. That seems to be one generation newer than the 323 IIUC (kirkwood vs Orion). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: screenblanker vs login
On 2018-02-05 12:12 -0500, Gene Heskett wrote: > How do I shut the screenblanker off on an arm64. It's no different on arm than any other arch SFAIK. This is probably a debian-user question really. > I have looked around in the xfce menu's looking for blanker timing and > such, but they aren't there. xset gets reset to its defaults , which is > way too fast, on a reboot. > > So how do I completely disable this so I can actually get something done? > 450 seconds is not enough to get logged in even. You can set screen blank times for XFCE in 'Settings'->'Power Manager', 'Display tab. or run xfce4-power-manager-settings. There you can set times, or just tell it not to blank or power-down at all. It is possible that you _also_ have something like xscreensaver installed, whcih may be trying to manage the screen too. You can just uninstall that. > And nothing related to ssh works until xfce is up and running. The openssh dameon is independent of the desktop and will start first. If you don't start the desktop ssh should still work. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: aptitude is blowing up again.
On 2018-02-03 11:46 -0500, Gene Heskett wrote: > greetings all; > > I very carefully selected docs, x11, kde and xfce to be installed on > this rock64. That was something over 2000 packages when I hit the g. Seems a lot, but X and two desktops is a lot of stuff. Using --no-install-recommends is one way to install way less stuff. (In the GUI untick "Install recommended packages automatically " under 'Options'). I always do this for build-dependencies. Possibly not such a good idea for a desktop but it should work. Why are you installing two desktops if you don't want 'too much' stuff? I just tried using a bare, current unstable chroot. Installing x11, kde, and xfce (sudo aptitude install xserver-xorg xfce4 task-kde-desktop) is 1792 packages 3907 MB unpacked). Without recommends (sudo aptitude --without-recommends install xserver-xorg xfce4 task-kde-desktop) it's 1005 packages, 1993 MB unpacked Doing it in the curses interface gets the same results, showing me that xserver-xorg is +67MB, xfc4 +1682MB, task-kde-desktop +3810MB, so X is much lighter wieght than a desktop. xfce4 desktop is half the weight of a kde desktop. Now I did just check that on this x86 machine, but it really shouldn't be materially different on arm64. > So how _do_ you control this application? Aptitude is marvellous. I'm not sure why you are having trouble with it. It has a nice interface that make exploring dependencies very easy - you can add and remove stuff easily, and it's good at doing tricky resolving. It certainly used to be a lot better than apt in this regard, although I think they are nearly equivalent again these days. And you can choose whether to use cli or curses. > I'm at this point, ready to re-write that image to a 64GB sdcard, and > spend days using apt to pull stuff I need in one package at a time. I > know you cannot remove a package with it, because its interpretation of > dependencies will leave you with an unbootable, destroyed system. Its > done that to me several times already. Nonsense. If you want to report bugs you are going to need to be specific, about 'before' status, and 'after' status. If aptitude is really messing up arm64 systems just because you asked to remove packages then that's not good. But without enough info to reproduce nothing much can be done. > So when do we get a default, just works, does _only_ what you ask it to, > text/ncurses based package manager with a bare bones arm64 install? > Something you can actually build a working system with? I use aptitude all the time, for many years, on arm and x86. It has _very_ rarely screwed up. It's actually quite good at _unscrewing_ a machine with a messed-up mixed set of packages. Are you mixing repositories (like stable and unstable?). Be very careful if doing that. An incredibly useful tip is to change the default aptitude display to include the suite name: change (in 'preferences') 'display format' from: %c%a%M%S %p %Z %v %V to %c%a%M%S %p %Z %t %v %V (IMHO this should be the default for everyone). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Anyone using stretch/buster/sid on ARMv4t ?
On 2017-11-07 11:48 +0100, W. Martin Borgert wrote: > On 2017-11-07 11:08, Julien Cristau wrote: > > Keeping armel on life support for 2 more > > years is a significant drain on DSA and our hosters, for questionable > > benefit. > > I agree, that this support comes not for free, but the benefit > is not questionable to me: There is still relevant hardware > around which can run "armel", but not "armhf". *If* there are > enough developers and build machines, there is no reason to drop > the architecture prematurely. I can't see any relevance for > ARMv4t anymore, however. Agreed. I too have armv5 hardware in daily use runing Debian (it's my house controller (solar, heating, MVHR)). For reasons of hardware additions, (but also because it works just fine), I have no desire to change it before it dies. For this use-case a proper 'stable' distro is very attractive, so being relegated to 'unstable only' in ports is less than ideal. I'm very happy if people mark problematic packages that no longer build for armv5 as 'notforus' if no-one steps up to fix them in a timely fashion, but killing the architecture because some upstreams no-longer care about v5 seems like a baby/bathwater scenario. It would be nice if we had some way to either relax the migration rules so old somewhat-maintained architectures like this didn't get in the way of others, or if there was some way of having 'stable' (or at least testing) for arches relegated to ports. Liberal use of 'notforus' would help a lot with the 'not getting in the way' part, or a way of reverting the 'used to build on this arch once so we're not going to ignore it' bit in the package migration rules. If upstream has given up and said 'we don't support that any more' then it's quite reasonable for Debian to do the same. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: how to distinguish armel and armhf at runtime?
On 2017-09-22 21:57 +0200, Uwe Kleine-König wrote: > Hello, > > for the package sparse I have to distinguish armel and armhf. The reason > is that sparse parses system headers and so has to know which cpp > symbols to define. Usually it uses uname -m to distinguish platforms but > that isn't suitable to tell armel and armhf apart. > > For armhf I need to define __ARM_PCS_VFP but that must be absent on armel. > > For upstreaming a fix it would be great if the test would not be Debian > specific. > > Any ideas? It's just an ABI difference, not a difference in the kernel or hardware, so you have to look at the files run. So asking gcc or the glibc in use is one correct way to do it. gcc -dumpmachine will tell you what triplet applies. I assume that works on non-debian machines too: armhf: arm-linux-gnueabihf armel: arm-linux-gnueabi For building things in a debian context, normally the right thing to do is just rely on the compiler to DTRT for the arch targetted. (As opposed to trying to work out yourself both what arch is in use and what the right corresponding set of runes is). Not least because the correct set of runes changes over times. gcc will get this right (i.e set the correct options for the ABI and for debian), for both compiling and cross-compiling. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Cannot build OpenGL application on Qt5 on armel/hf
On 2017-09-18 23:50 +0200, John Paul Adrian Glaubitz wrote: > > Looking at the rules file of qtbase-opensource-src, it's obvious where this > regression comes from, namely from the fact that qtbase-opensource-src is > configured to use OpenGL ES instead of proper desktop OpenGL on armel > and armhf [3]. > > Does anyone know whether there is a way to address this issue on armel/hf > or do I have to disable virtualjaguar on these architectures? AIUI openGL ES is used on 32-bit ARM because that's what the GPU drivers target/support. I presume this hasn't changed (although I understand that for latest OpenGL the Desktop and ES specs got merged to some common set). So I guess anything that uses GL stuff outside the ES API won't actually work on 32-bits arm anyway so there is not much point building it there. But my understanding of the graphics stack is weak so I could well be out-of-date or otherwise confused. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Bug#873866: tophat: Please add arm64
On 2017-09-04 10:06 +0200, Andreas Tille wrote: > Hi Edmund, > > On Thu, Aug 31, 2017 at 07:37:38PM +0100, Edmund Grimley Evans wrote: > > It seems to be possible to build this package on arm64. > > Is there any reason why it would not work on arm64? > > It might be that tophat builds on other architectures but it Depends > bowtie2 | bowtie and these are only available on the explicitly > specified architectures. I could add these to Build-Depends to make > this more clear but I'm tempted to close this bug if you agree. It seems to me that if something builds (or just probably builds) on architectures then we should not restrict architectures just because of dependencies. The package will sit in 'dep-wait' until the build-dep becomes available (which might be a very long time, but that doesn't do any harm). This makes it obvious that this package is not known to be a problem on other arches - the build-dependency is the issue. Now in this case bowtie is already built for arm64, so your reasoning for the arch restriction seems to be out of date. https://buildd.debian.org/status/package.php?p=bowtie=sid So, no I don't think you should just close this. In fact I still can't see any reason not to let this build on arm64, (and ppc64el and s390x, and ppc64 and sparc64, all of which have bowtie already built). So in fact I think you should just remove the arch restriction. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: ARM Ports BoF: armel in buster
On 2017-08-11 15:04 +0300, Adrian Bunk wrote: > If none of the curent armel porters want to continue working on armel > for buster that is OK, I still have v5 hardware running my house and thus am keen to see it maintained. And it's not simple to upgrade to a new box as it's got heating-control hardware attached. So I've not lost interest. (It's currently still running 'arm', not 'armel', which of course is no longer upgraded because we stopped maintaining it. It'd be nice to have it less than 6 years out of date sometime.) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Help need with build failure of ceph 10.2.5-2 on armel
On 2016-12-26 22:52 +0100, Gaudenz Steinlin wrote: > > Hi > > The build of the most recent version of ceph fails on armel[1]. As far > as I understand the log, the first failure (a bit above the end of the > log) is because armel does not support NEON (-mfpu=neon) despite the > configure check for this succeeding. > > The autotools based build system uses the following check: > AX_CHECK_COMPILE_FLAG(-mfpu=neon, ax_cv_support_neon_ext=yes, []) > > Is it correct that for armel NEON has to be disabled or this there a way > to support NEON instructions on armel? You cannot assume neon is present on armel hardware, and more significantly its use is not supported by the ABI. I presume the check is testing the build machine, which is not relevant in this case. (The same machines build armel and armhf, IIRC and are relatively modern, so at least some of them have neon available). Neon must be disabled on armel. If a piece of software cannot do this, and requires neon unconditionally then it is not suitable for armel. > And how could I fix the above test to correctly disable NEON for > armel. The check for neon is 'correct' in the narrow sense that it determines whether the installed compiler can run with this flag set. This should fail the same way it does later when the build is tried - I don't know why it isn't. Explicitly checking for the combination of '-mfpu-neon -mfloat-abi=softp' should have the desired effect (give an error at test time so it doesn't try to build the extra plugin). It's not clear why this is not already the effective test. Patching the build to simply not use -mfpu=neon (nor check for it) will result in a non-neon build on armel as the armel gcc defaults are correct. Note that neon may not be present on armhf machines either, so building with an alternate fallback code path (run-time determined) there is correct, but you'll generally get away with it, as most machines do in fact have this unit. We probably have a lot of software not dealing with this properly. > AFAICS the build failure appears if a source file uses > "#include ". > > AFAIU the build tries to build a plugin with NEON instructions to be > used depending on runtime detection. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Problem with arm64: mcmodel=large and fPIC
On 2016-12-15 15:41 +, Wookey wrote: > On 2016-12-15 15:16 +, Alastair McKinstry wrote: > > gfortran -c -O2 -mcmodel=large -O2 -fdefault-real-8 > > -fconvert=little-endian -frecord-marker=4 -I/usr/include par_mod.f90 > > f951: sorry, unimplemented: code model 'large' with -fPIC > > > > Notice that fPIC is not set on the command line. > > Any ideas on how to proceed? > > I believe that the compiler default was recently changed to be fPIC on > several arches, including arm64, which is presumably why you have > started seeing this. I guess we should either turn fPIC off for this > build or teach gfortran to deal with this 'large' model. This is the transition I had in mind: https://wiki.debian.org/Hardening/PIEByDefaultTransition And if I understand https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_PIE_.28gcc.2Fg.2B-.2B-_-fPIE_-pie.29 properly, this (PIE) is effectively setting -fPIC on all binaries, not just shared libraries, which have been doing it for some time. But I could just be confused here and this is a complete red herring. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Problem with arm64: mcmodel=large and fPIC
On 2016-12-15 15:16 +, Alastair McKinstry wrote: > Hi, > > I'm the maintainer of a package 'flexpart' which is no longer building > on arm64. > > https://buildd.debian.org/status/package.php?p=flexpart > The problem is that I need mcmodel=large, and I now get: > > gfortran -c -O2 -mcmodel=large -O2 -fdefault-real-8 > -fconvert=little-endian -frecord-marker=4 -I/usr/include par_mod.f90 > f951: sorry, unimplemented: code model 'large' with -fPIC > > Notice that fPIC is not set on the command line. > Any ideas on how to proceed? I believe that the compiler default was recently changed to be fPIC on several arches, including arm64, which is presumably why you have started seeing this. I guess we should either turn fPIC off for this build or teach gfortran to deal with this 'large' model. The first is presumably much easier. The second more correct in the long term. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Installing ntopng:armhf on arm64
On 2016-12-13 20:19 +, Phil Endecott wrote:
> Wookey wrote:
> > Yes. ntopng-data is missing a
> > Multi-Arch=foreign
> > line in it's control file. Add one and rebuild it and you should be in
> > business.
>
> Thanks for your optimism Wookey! Unfortunately there's more.
Yeah I did think about a) actually testing this theory and b) pointing
out that it might just immediately get you to the next problem :-) but
I was busy and a quick look at deps sugested that you had a fighting
chance :-)
> $ apt-get source ntopng-data
> $ nano debian/control (add Multi-Arch: foreign for ntopng-data)
> # apt-get build-dep --host-architecture armhf ntopng-data
> ...
> The following packages have unmet dependencies:
> builddeps:ntopng:armhf : Depends: coffeescript:armhf but it is not
> installable
> Depends: libpcap-dev:armhf but it is not installable
>
> Both coffeescript and libpcap-dev are architecture=all packages which
> should maybe/possibly/probably have Multi-Arch=foreign.
Right, and if one has access to an armhf machine, such a debian
porterbox, one can just build the modified ntopng package nativaly and
avoid the typical 'computing story of woe' below.
> But I suspect these are actually only needed to build the ntopng package
> (i.e. the binaries), not ntopng-data. I install some other build-deps
> and try:
>
> $ dpkg-buildpackage --build=all --jobs=3 --no-check-builddeps
>
> Confusingly, "build=all" here doesn't mean build everything! It is
> supposed to mean build the architecture=all packages. This doesn't
> work as I hope though; it starts by doing some ./configures which are
> clearly checking for architecture-specific things - including the missing
> arm64 luajit. It ends up with make recursively disappearing up its
> own backside.
Right, because that's building for arm64
> So it looks like I will have to patch coffeescript and libpcap-dev, and
> then build ntopng-data for armhf.
>
> $ apt-get source coffeescript
> $ nano debian/control (add Multi-Arch: foreign in 3 places)
> # apt-get build-dep coffeescript
> $ dpkg-buildpackage --jobs=3
> # dpkg -i coffeescript_1.10.0~dfsg-1_all.deb
>
> OK
>
> $ dpkg -L libpcap-dev
> /.
> /usr
> /usr/share
> /usr/share/doc
> /usr/share/doc/libpcap-dev
> /usr/share/doc/libpcap-dev/changelog.Debian.gz
> /usr/share/doc/libpcap-dev/changelog.gz
> /usr/share/doc/libpcap-dev/copyright
>
> That should clearly be Multi-Arch=foreign - right? - so:
No because libpcap-dev depends on libpcap0.8-dev which is
arch-specific so when something depends on libpcap-dev it wants to get
the right architecture version of libpcap0.8-dev, so they should both
be MA:same and arch:any, as explained in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820829
>
> dpkg: error processing archive
> /tmp/apt-dpkg-install-B3DAh9/45-libcurl4-gnutls-dev_7.50.1-1_armhf.deb
> (--unpack):
> trying to overwrite shared '/usr/bin/curl-config', which is different from
> other instances of package libcurl4-gnutls-dev:armhf
>
> Comparing libcurl4-gnutls-dev_7.50.1-1_armhf.deb and
> libcurl4-gnutls-dev_7.50.1-1_arm64.deb,
> they both have /usr/bin/curl-config and those files do differ; they include
> architecture-specific paths:
>
> < if test "X${prefix}/lib/arm-linux-gnueabihf" != "X/usr/lib" -a
> "X${prefix}/lib/arm-linux-gnueabihf" != "X/usr/lib64"; then
> <CURLLIBDIR="-L${prefix}/lib/arm-linux-gnueabihf "
> ---
> > if test "X${prefix}/lib/aarch64-linux-gnu" != "X/usr/lib" -a
> > "X${prefix}/lib/aarch64-linux-gnu" != "X/usr/lib64"; then
> >CURLLIBDIR="-L${prefix}/lib/aarch64-linux-gnu "
>
> How is multiarch supposed to cope with that?
Yes - those foo-config programs are a major pain for multiarch and
cross-building.
You have hit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731998
> OK! Try to build ntopng-data again, something like:
>
> $ dpkg-buildpackage --host-arch=armhf --target-arch=armhf --build=all --jobs=3
>
> I'm not at all sure about those architecture options. I'd be happy to
> either build using a "native" armhf compiler, or a "cross" arm64-hosted,
> armhf-target compiler. It seems most promising with just --host-arch-armhf,
> which seems to be cross-compiling; it gets this far:
>
> checking for arm-linux-gnueabihf-gcc... no
>
> Presumably this is because the build-deps assume build-essential, which
> doesn't include the cross-compiler. (Is there a "cross build essential"
> package?)
yes. install crossbuild-essentia
Re: Installing ntopng:armhf on arm64
On 2016-12-12 18:36 +, Phil Endecott wrote: > Hi Everyone, > > On an ODROID-C2 arm64 (stretch) device, I just tried to install ntopng; this > doesn't work because of the luajit issues described in bug #818616. Until > that > gets sorted I thought I'd try the armhf version; I have set up this > device to support armhf but I've not used it much: > > # apt-get install ntopng:armhf > .. > The following packages have unmet dependencies: > ntopng:armhf : Depends: ntopng-data:armhf (= 2.2+dfsg1-2) but it is not > installable > > > I can install ntopng-data manually, and it installs various architecture=all > packages that it depends on. But I still get the same message when I try to > install ntopng:armhf. > > Is this because perhaps one or other of those packages has broken multi-arch > tags, or something? Yes. ntopng-data is missing a Multi-Arch=foreign line in it's control file. Add one and rebuild it and you should be in business. The point here is that ntopng-data:arm64 should satisfy the ntopng:armhf packages dependency on 'ntopng-data' (because it's arch all and it's just data) but it's forgotten to say so. We are in the middle of the long process of adding this metadata to all packages. please file a bug about it with the trivial patch. I thought there was a reminder to packagers about this recently added to the pts page, but I don't see it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On 2016-12-07 15:53 +, Steve McIntyre wrote: > On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote: > >I'm ARM porter on armel/marvell (orion5x/kirkwood). > >Stretch will be frozen and released soon, which makes me bit depressed, > >because it means armel will be dropped out of unstable/testing as the > >conclusion of Cape Town BoF. > > > >> Possible future options for armel: > >> > >> * Partial armel architecture? > >> > >>We've talked about this in the past for various architectures, but > >>nobody has stepped up to work on it. The vast majority of the > >>outstanding armel use cases are going to be in headless servers so > >>we could maybe drop the desktop tasks and dependencies and keep > >>things like web server / mail server tasks that are much simpler. > >>Downside: There's no clear plan for how to create/maintain a > >>partial architecture, let alone how to release one. Potentially > >>huge amount of work needed. We can do poor-mans partial arch by just being fairly agressive about disabling armel for packages that are broken or not suitable. Not very clever or efficient, but it is easy to do and requires no infra or tooling changes at all. So long as someone is volunteering for that (easy but unexciting) work that could work. Obviously something fancier and more centralised/general would be 'better' but it requires a different skill-set and realistically will probably take a long time. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
X on Tegra/Nouveau with Jetson-TK1
So, I have installed a Jetson TK1 and updated
https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TK1 with a
few ifs and buts, but essentially that works very nicely with the stretch
installer.
So now I want working X to run a TV frontend in. This looks to be
rather less 'ready'. Before I flail about too much is there anyone here
that's already messed with this and worked out which bits are needed?
Currently I get
gbm: failed to open any driver (search paths
/usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
gbm: Last dlopen error: /usr/lib/dri/tegra_dri.so: cannot open shared object
file: No such file or directory
failed to load driver: tegra
I'm not sure where that is supposed to come from.
from startx
CONFIG_DRM_TEGRA_STAGING=y is set in the kernel, which is a good start.
libdrm-tegra0 is installed, which contains:
/usr/lib/arm-linux-gnueabihf/libdrm_tegra.so.0
Can I use xserver-xorg-video-nouvea or is there an
xserver-xorg-video-tegra that needs building from something? Or does
tegra only work with wayland? Or...what...?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Re: postgis failing to build on arm64 only
On 2016-10-13 15:56 +0200, Bas Couwenberg wrote: > On 2016-10-13 15:52, Bas Couwenberg wrote: > >On 2016-10-13 15:48, Wookey wrote: > >> > >>OK. Yep, just rebuilding gdal (and installing the resulting > >>libgdal-dev, libgdal20), fixes the postgis configure. > > Can you schedule a dep-wait for libgdal-dev (>= 2.1.1+dfsg-5) to retry to > postgis build? OK. Did that and it's now built OK. So that all remains a bit of a mystery why it broke for arm64 but, well, I think we'll just have to leave it as 'C++ linking, timing, goat entrails'... Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: postgis failing to build on arm64 only
On 2016-10-12 18:57 +0100, Wookey wrote: > On 2016-10-11 08:16 +0200, Sebastiaan Couwenberg wrote: > > > > Seems to me that the issue is probably actually in gdal, rather > > > than postgis, although why the configure behaviour has changd > > > remains a mystery. > > > > The configure behaviour is weird indeed. On the other architectures > > "none required" remains the result for this test. > > I looked at the actual configure stuff for this and couldn't really > grok when that came out as the result. > > > The CryptoPP symbols seem to have changed with the recent update of > > libcrypto++ from 5.6.3-8 to 5.6.4-1. Which did not create this problem > > on the other architectures though. > > > > Perhaps rebuilding gdal with the new libcrypto++ on arm64 will be > > sufficient to fix this issue? > > That seems quite likely. It might just be the senstivity of C++ > symbols to compiler changes. Unfortunately so far as I know one can't > test such a thing on the porter boxes (because there is no way to > unstall the local gdal you just built due to lack of root rights). > > So I have got my local arm64 box going again and will test this theory > tomorrow (home time now). OK. Yep, just rebuilding gdal (and installing the resulting libgdal-dev, libgdal20), fixes the postgis configure. I'll schedule a binNMU. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: postgis failing to build on arm64 only
On 2016-10-11 08:16 +0200, Sebastiaan Couwenberg wrote: > > Seems to me that the issue is probably actually in gdal, rather > > than postgis, although why the configure behaviour has changd > > remains a mystery. > > The configure behaviour is weird indeed. On the other architectures > "none required" remains the result for this test. I looked at the actual configure stuff for this and couldn't really grok when that came out as the result. > The CryptoPP symbols seem to have changed with the recent update of > libcrypto++ from 5.6.3-8 to 5.6.4-1. Which did not create this problem > on the other architectures though. > > Perhaps rebuilding gdal with the new libcrypto++ on arm64 will be > sufficient to fix this issue? That seems quite likely. It might just be the senstivity of C++ symbols to compiler changes. Unfortunately so far as I know one can't test such a thing on the porter boxes (because there is no way to unstall the local gdal you just built due to lack of root rights). So I have got my local arm64 box going again and will test this theory tomorrow (home time now). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: postgis failing to build on arm64 only
rAbstractPolicy, CryptoPP::OFB_ModePolicy> >::Seek(unsigned long long)' so some symbols are missing from the gdal library. Some crypto functions? gdal uploads to unstable were 09-03 and 09-07 last working postgis build was 10-03 (2.3.0+dfsg-2) configure in that said "checking for library containing GDALAllRegister... none required" sugesting that the offending test was skipped? Any idea why that might be? same for -1 on 09-26 looking at other arches that seems to be the 'normal' text. So this is all rather odd. gdal doesn't seem to have changed since working -1 and -2 builds, but now the test is giving different results. comparing the OK -2 build log and failed -3 build log there isn't much changed in the environment that seems likely to be relevant, but the autoreconf behaviour of debhelper has changed a bit we used to get: debian/rules build-arch dh_testdir dh_prep -s dh_prep: -s/--same-arch is deprecated; please use -a/--arch instead dh_autoreconf autoconf dh_autotools-dev_updateconfig now we get: dh build-arch --with autotools_dev,autoreconf dh_testdir -a dh_update_autotools_config -a dh_autotools-dev_updateconfig -a debian/rules override_dh_autoreconf make[1]: Entering directory '/«BUILDDIR»/postgis-2.3.0+dfsg' dh_autoreconf autoconf make[1]: Leaving directory '/«BUILDDIR»/postgis-2.3.0+dfsg' debian/rules override_dh_auto_configure make[1]: Entering directory '/«BUILDDIR»/postgis-2.3.0+dfsg' OK, that's not an actual change in the rules file so probably a red herring. Checking the gdal arm64 build log, it says cryptopp=yes There is no obvious complaining about that going wrong. So, looking at the configure test. 'non-required' comes from: for ac_lib in '' gdal; do if test -z "$ac_lib"; then ac_res="none required" It's not clear to me if in the past this test has in fact been skipped, but it no longer is, and so we are noticing some underlying issue for the first time. installing the dbgsym package for libgdal20, shows that GDALAllRegister does exist. But for some reason the cryptoPP functions (which postgis may not care about?) have a problem. Anything to do with C++ symbols always makes me come out in hives... Seems to me that the issue is probably actually in gdal, rather than postgis, although why the configure behaviour has changd remains a mystery. It's now way past bedtime so this'll have to do for now. Hopefully this will help someone. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Any armhf/armel Kodi users?
On 2016-10-06 16:13 +0200, Balint Reczey wrote: > Hi, > > I'm wondering if there is anyone using the armhf/armel kodi packages on > Debian testing/unstable. I have a plan to, (on a cubietruck) but I don't actually use them at the moment. > The last update broke the build for armhf/armel in experimental and I'm > about to fix it but report from someone actually using the built > packages would be nice. > > I have no HW for testing the builds apart from amd64 VMs. I guess I could try and test it if no-one else with a working set-up volunteers. > PS: Please CC me, I'm not on the list. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Gigabyte MP30-AR1
On 2016-09-12 19:41 +0100, Phil Endecott wrote: > The Ubuntu mini.iso installer from here: > > > http://ports.ubuntu.com/ubuntu-ports/dists/yakkety/main/installer-arm64/current/images/netboot/ > > also works, with a 4.4.0 kernel: > ACPI is disabled: > > [0.083487] ACPI: Interpreter disabled. > > It must be using the device tree and surviving whatever bugs it has. Interesting. Phil, could I persuade you to file a bug against debian-installer with the info and logs you have collected (or just the mails in this thread). It just helps avoid this issue getting lost. > If this seems to work I may keep this kernel and try to convert the base > filesystem from Ubuntu to Debian; that should be easy, right??! It's do-able, but you may have to fight apt/dpkg quite hard, and it can be quite hard to tell when you've actually expunged al the ubuntuness :-) Check /etc/debian-version /etc/os-release and /etc/dpkg/origins/debian all have debian info rather than ubuntu info them get debian versions of all the packages dpkg -l reports, then apt install --reinstall them all (or use dpkg -i to ram them in). I have done this before (on arm64) and it worked. You may need some --force-* to get it to play. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Gigabyte MP30-AR1
On 2016-09-12 09:03 +0200, Hector Oron wrote: > Hello, > > 2016-09-09 19:29 GMT+02:00 Phil Endecott <spam_from_debian_...@chezphil.org>: > > > EFI stub: Booting Linux Kernel... > > ConvertPages: Incompatible memory types > > EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied > > EFI stub: Using DTB from configuration table > > Which BMC firmware are you using? AFAIK there is a broken DTB in the > manufacturer's firmware therefore using ACPI boot is recommended, > however it is not supported until 4.7 kernel series, and then you'll > find #834505 (TL,DR; needs to enable ACPI and relocate initramfs > within first 32GB of RAM address space). To expand on this a little. EUFI provides both DTB and ACPI if both are present. In this case the ACPI info is 'more correct' than the DTB info, but the kernel will prefer to use DTB info if it is present. Centos may be choosing to explicitly prefer the ACPI in their kernel? You can test this (on a 4.7 series kernel) by doing acpi=force on the kernel boot command line. Does doing that make it boot phil? If so then that suggests that the above is indeed the issue. If that is the problem, then the underlying issue here is a combination of the manufacturer providing a duff DTB and the preference of ARM kernel (people) for DTB over ACPI. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Gigabyte MP30-AR1
On 2016-09-10 03:16 +0100, Phil Endecott wrote: > I've tried various different Debian installer images with the same result; > I'll look at what Linaro / Ubuntu / etc. have next. (Suggestions?) > > More important question - where are the people who understand this stuff? > Debian-EFI? Linaro? APM? Gigabyte? This list is a pretty good start. We have plenty of debian and UEFI expertise here. No-one I know actually has one of these boards (except you now, and some guy as Fosdem who said that he had got one working). We are quite keen to get to the bottom of what needs to change in the Debian kernel/installer to have this machine supported. I don't actually know where the experts on this specific board are. I guess there must be someone at Gigabyte who knows. But if the centos kernel works then that's a Clue . Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
