Re: unbreaking LibreOffices tests on at least release architectures
On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote: >Hi, > >Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: >> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: >> > Also note I am not talking about the debian-ports architectures. Those I >> > forgot and I have no problems making them stay into "testsuite ran but >> > results ignored" set. >> Why did you send this mail exclusively to debian-ports then? > >I (obviously) wrongly assumed that this was the magic address which >duplicates to every port. > >Must have misremembered. It still does - I got this copy via the debian-arm list... -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: Grub, UEFI Secure Boot and netboot - help!
On Mon, Jun 10, 2019 at 04:35:33PM +0100, Colin Watson wrote: >On Mon, Jun 10, 2019 at 04:15:22PM +0100, Steve McIntyre wrote: >> >> The prefix variable is very much a single value, yes. It's used and >> dereferenced all over the place inside grub as a single const char >> *. Not something I'm about to play with! > >It'd be totally possible to make the grubnet memdisk try multiple >prefixes: there's already a memdisk that looks in a couple of locations >under $prefix for grub.cfg, so it could separate it into a list and try >each one until it finds something usable. > >However, that approach embeds the debian-installer path even in images >that have nothing to do with d-i; so I think on balance I prefer the >idea of adding another d-i-specific image. Steve is working on that >now. Yup. Simple changes. \o/ >> >It's been a long time since I've played with any of this but I have a >> >vague recollection of once upon a time using (or trying to use, maybe >> >I'm remembering a failed experiment) a memdisk (builtin to the grub >> >image) containing an initial config file which then was a bit more >> >flexible about chaining to the next thing. I can't find any evidence >> >of that setup in any of the places I thought it might be related to >> >though :-/ >> >> Right. That's how various other things work - it's how we control >> things for CD boot, for example. But network boot is a slightly >> different configuration. It's simply a single binary rather than a FAT >> image containing the binary and config. > >Moot given the above, but this isn't actually true - search for >grub-netboot.cfg and memdisk-netboot.fat in build-efi-images. I sit corrected. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Re: Grub, UEFI Secure Boot and netboot - help!
Hi Ian, On Mon, Jun 10, 2019 at 02:32:23PM +0100, Ian Campbell wrote: >On Mon, 2019-06-10 at 03:37 +0100, Steve McIntyre wrote: >> Any other suggestions on what we could do? Let me know what you >> think... > >Is signing an extra, d-i specific, grubnetXX.efi image out of the >question? Oh, that's a thought. Possibly, I guess. Minor tweaks to the grub packaging and to the d-i build. That's probably the easiest route, in fact! Colin - how does that sound for you? >Is the hard coded prefix a single prefix or is there a possibility of >searching a list? The prefix variable is very much a single value, yes. It's used and dereferenced all over the place inside grub as a single const char *. Not something I'm about to play with! >It's been a long time since I've played with any of this but I have a >vague recollection of once upon a time using (or trying to use, maybe >I'm remembering a failed experiment) a memdisk (builtin to the grub >image) containing an initial config file which then was a bit more >flexible about chaining to the next thing. I can't find any evidence >of that setup in any of the places I thought it might be related to >though :-/ Right. That's how various other things work - it's how we control things for CD boot, for example. But network boot is a slightly different configuration. It's simply a single binary rather than a FAT image containing the binary and config. -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Grub, UEFI Secure Boot and netboot - help!
On Mon, Jun 10, 2019 at 11:17:52AM +0200, John Paul Adrian Glaubitz wrote: >Hi Steve! > >On 6/10/19 4:37 AM, Steve McIntyre wrote: >> 1. Update the docs to mention this - this is a new thing needed to >> get netboot working with Buster. It's *currently* inconsistent, >> as ia64 and armhf (as non-SB arches) are still using the old >> prefix setting. For the sake of consistency (in docs etc.), I >> propose to also update the d-i build for those arches to use the >> same prefix. But I acknowledge that will break existing >> setups. :-( >> >> 2. Alternatively, we could tweak the netboot prefix setting as built >> by grub. I'm worried that this may also break things for some >> users. Do we assume (can we?) that all our grub netboot users are >> installer users (so we could use /debian-installer/$ARCH/grub)? >> If so, that might be a way to go. But is it a valid assumption? >> We'd be forcing all our grub netboot binaries to only sensibly >> work for d-i, and that worries me too. > >I don't have a strong opinion here regarding GRUB on ia64. netboot with GRUB >on ia64 is currently untested on ia64, so I'm fine with breaking changes as >long as the configuration is kept in sync - where possible - with the other >EFI architectures and in a working state. ACK, thanks for the quick response. It was specifically ia64 that I was worried about here in (1) above, hence my deliberate CC. armhf in Debian has only very recently gained UEFI support, so there's no release history to worry about. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: Grub, UEFI Secure Boot and netboot - help!
On Mon, Jun 10, 2019 at 11:08:35AM +0200, Domenico Andreoli wrote: >On Mon, Jun 10, 2019 at 03:37:41AM +0100, Steve McIntyre wrote: ... >> I can see a couple of options here, but I'm not sure either of them >> are good. Comments would be most welcome! >> >> 1. Update the docs to mention this - this is a new thing needed to >> get netboot working with Buster. It's *currently* inconsistent, >> as ia64 and armhf (as non-SB arches) are still using the old >> prefix setting. For the sake of consistency (in docs etc.), I >> propose to also update the d-i build for those arches to use the >> same prefix. But I acknowledge that will break existing >> setups. :-( > >These are two options: > > 1a. docs update (does not break anything) > 1b. d-i build update (might break something) >> >> 2. Alternatively, we could tweak the netboot prefix setting as built >> by grub. I'm worried that this may also break things for some >> users. Do we assume (can we?) that all our grub netboot users are >> installer users (so we could use /debian-installer/$ARCH/grub)? >> If so, that might be a way to go. But is it a valid assumption? >> We'd be forcing all our grub netboot binaries to only sensibly >> work for d-i, and that worries me too. >> >> Any other suggestions on what we could do? Let me know what you >> think... > >Is this question for Buster or Buster+x? Those solutions requiring a >change in grub (and a new signature from M$) are not be ok for Buster. This is definitely for Buster. Changes in *Grub* are fine - we sign that ourselves. It's updated versions of Shim that are problematic. >For Buster I find acceptable only 1a. I prefer a sub-optimal solution >now to an improved solution later, especially under release. > >For Buster+x, is it possible to make grub search multiple prefixes? I think it would be quite a big change... -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Grub, UEFI Secure Boot and netboot - help!
Hey folks, We have a bit of a problem with PXE booting Grub in Buster, as shown in #928750: * On all supported arches, we *used* to generate a Grub netboot image inside d-i, with a prefix setting of "debian-installer/$arch/grub". The prefix is important, as it's how Grub finds its config file, modules etc that it loads. Things are still like this in Stretch. * In Buster, we can no longer do this on arches which support Secure Boot. To keep the SB signature, we now re-use the existing signed binaries that have come directly from the Grub build (and the Debian signing infrastructure). There's just one minor problem with this - this means that we're stuck with the hard-coded prefix baked into the grubnetXXX.efi binary. This is currently set to "/grub", and this means that to get a functional amd64 (say) PXE installation working the user has to add a "/grub" symlink on their TFTP server, something like: /grub -> /debian-installer/amd64/grub (assuming that /debian-installer is the root of the netboot tree). I can see a couple of options here, but I'm not sure either of them are good. Comments would be most welcome! 1. Update the docs to mention this - this is a new thing needed to get netboot working with Buster. It's *currently* inconsistent, as ia64 and armhf (as non-SB arches) are still using the old prefix setting. For the sake of consistency (in docs etc.), I propose to also update the d-i build for those arches to use the same prefix. But I acknowledge that will break existing setups. :-( 2. Alternatively, we could tweak the netboot prefix setting as built by grub. I'm worried that this may also break things for some users. Do we assume (can we?) that all our grub netboot users are installer users (so we could use /debian-installer/$ARCH/grub)? If so, that might be a way to go. But is it a valid assumption? We'd be forcing all our grub netboot binaries to only sensibly work for d-i, and that worries me too. Any other suggestions on what we could do? Let me know what you think... -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Re: Bug#927562: Updating the elilo-installer Uploaders list
On Sat, Apr 20, 2019 at 09:03:05PM +0200, John Paul Adrian Glaubitz wrote: > >> On Apr 20, 2019, at 8:44 PM, Tobias Frost wrote: >> >> Source: elilo-installer >> Version: 1.34 >> Severity: minor >> User: m...@qa.debian.org >> Usertags: mia-teammaint >> >> We are tracking their status in the MIA team and would like to ask you >> to remove them from the Uploaders list of the package so we can close >> that part of the file. > >elilo-installer can actually be removed as elilo is no longer part of >the archive (although I actually created an updated 3.16 package >which I could upload). > >GRUB actually works fine on ia64 and I’m going to switch it over by >patching grub-installer and partman-auto once Buster has been >released (I avoid pushing any Ports-related changes during freeze). > >I’ll file a removal request later. There are also remnants of elilo >references in debian-installer and debian-cd. Nod, it's definitely time that elilo went away. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Re: debian-installer now available in Ports
On Wed, Apr 12, 2017 at 01:55:08PM +0100, Steven Chamberlain wrote: >John Paul Adrian Glaubitz wrote: >> Thus, I was wondering whether any volunteers would be willing to help >> building >> ISO images for the various architectures. > >I'm already doing this for kfreebsd-amd64, but only the jessie-kfreebsd >suite: >http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_jessie-kfreebsd/lastBuild/console >and I had to patch debian-cd before it worked. (Didn't yet find time to >file bugs or submit those patches). Please post them! >I could probably set up similar jobs for kfreebsd-* sid now. > >> It's not necessary to run debian-cd on the same architecture as the >> target architecture of the ISO images. Exactly. There are sometimes difficulties with the tools needed to set up boot files etc., but they tend to be portable. >I did not even realise that. So I will add kfreebsd-i386 next. > >I expect there might be problems trying to build linux arches from a >kfreebsd host. But we should try to find out, and then maybe fix it. We were happily building kfreebsd-* images from a Linux host, so I'd expect it to work OK. I've offered before: I don't have the time personally to work on building ports images, but I'm more than happy to help other people getting them building on our official infrastructure... -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Time to change the debian-ports list?
On Wed, Jul 22, 2015 at 05:38:17PM +0200, Wouter Verhelst wrote: On Fri, Jul 17, 2015 at 01:40:20PM +0100, Steve McIntyre wrote: On Thu, Sep 11, 2014 at 12:51:29PM +0100, Steve McIntyre wrote: On Wed, Sep 10, 2014 at 07:01:00PM +, Thorsten Glaser wrote: Alexander Wirt dixit: Could you please (technically) summarize what needs to be done from listmaster side? 1. Remove whatever debian-po...@lists.debian.org is right now 2. Create a new debian-po...@lists.debian.org mailing list which works just like the other regular lists 3. Announce the new debian-po...@lists.debian.org so that people can subscribe to it; document that there is no longer an address to reach *all* ports but that people should eMail the individual ports’ lists (and cross-post if needed, but only to the amount needed), and that the new debian-po...@lists.debian.org instead is a mailing list for discussion about a) debian-ports.org infrastructure b) porting Debian in general c) questions related to setting up a Debian port, including wanna-build, buildd, etc. That seems like a bad idea to me, tbh. There will be people who won't notice that the meaning of debian-ports@ has changed, and who will try to use it with its old meaning. If there are problems with the current meaning of debian-ports, can't we just retire the old alias and create a list under a different name? Is there much point to that? I've not heard anybody at all speak up in favour of the existing behaviour. If anybody does use try to use it that way in future, the new list will most likely be the best place for their mail to go... -- Steve McIntyre, Cambridge, UK.st...@einval.com I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. -- Charlie Stross -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150722170456.gc5...@einval.com
Re: Time to change the debian-ports list?
On Thu, Sep 11, 2014 at 12:51:29PM +0100, Steve McIntyre wrote: On Wed, Sep 10, 2014 at 07:01:00PM +, Thorsten Glaser wrote: Alexander Wirt dixit: Could you please (technically) summarize what needs to be done from listmaster side? 1. Remove whatever debian-po...@lists.debian.org is right now 2. Create a new debian-po...@lists.debian.org mailing list which works just like the other regular lists 3. Announce the new debian-po...@lists.debian.org so that people can subscribe to it; document that there is no longer an address to reach *all* ports but that people should eMail the individual ports’ lists (and cross-post if needed, but only to the amount needed), and that the new debian-po...@lists.debian.org instead is a mailing list for discussion about a) debian-ports.org infrastructure b) porting Debian in general c) questions related to setting up a Debian port, including wanna-build, buildd, etc. That's exactly it, yes. Thanks. :-) Hi Alexander et al,, Could we make a start on this please? More discussions on the d-ports expander today have reminded me how annoying the current setup is. -- Steve McIntyre, Cambridge, UK.st...@einval.com ...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver. -- Daniel Pead -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150717124020.ga13...@einval.com
Ports pages need updating on www.d.o
Hi folks, I've been trying to help out a bit with the port pages (under https://www.debian.org/ports/), starting with the ARM ports. We could really do with updating a lot of the information here - it's so old it's starting to smell bad! I've removed some of the older details (e.g. hardware support) that used to be under https://www.debian.org/ports/arm and replaced them with pointers to the wiki now. My reasoning here is that the wiki is more easily updated for more dynamic content like this, plus it's much easier for the wider community to contribute that way. I'd suggest that most of the other port pages would be better organised like this too, but that's a decision for porters to make for themselves. We also need to work on some of the other content around here. For example, the top-level ports page is still listing the ports from Wheezy rather than Jessie. Please take a look. In the webwml source, there's even a file to list maintainers for the various port pages. Until I touched it today, it hadn't been modified since 2005. It's clearly not very useful at the moment! -- Steve McIntyre, Cambridge, UK.st...@einval.com I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150428223702.go21...@einval.com
Re: Time to change the debian-ports list?
On Wed, Sep 10, 2014 at 07:01:00PM +, Thorsten Glaser wrote: Alexander Wirt dixit: Could you please (technically) summarize what needs to be done from listmaster side? 1. Remove whatever debian-po...@lists.debian.org is right now 2. Create a new debian-po...@lists.debian.org mailing list which works just like the other regular lists 3. Announce the new debian-po...@lists.debian.org so that people can subscribe to it; document that there is no longer an address to reach *all* ports but that people should eMail the individual ports’ lists (and cross-post if needed, but only to the amount needed), and that the new debian-po...@lists.debian.org instead is a mailing list for discussion about a) debian-ports.org infrastructure b) porting Debian in general c) questions related to setting up a Debian port, including wanna-build, buildd, etc. That's exactly it, yes. Thanks. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014095129.gg14...@einval.com
Re: Time to change the debian-ports list?
On Fri, Sep 05, 2014 at 06:39:10PM +0100, Steve McIntyre wrote: Hi folks, I believe the existing debian-ports setup (as an exploder pointing to all the different port lists) is not working well at all. It's a confusing setup to many people, which leads to lots of cross-list noise that's probably not warranted. Some of the traffic is also clearly meant to be discussing the debian-ports setup itself rather than individual ports, and that's also off-topic for those ports that are in the main archive. So, I propose: * Remove the confusion: turn debian-ports into a separate *normal* mailing list, announce it and let people subscribe to it as they see fit normally. This would be specifically for discussions about ports.debian.org and architectures hosted there. * Explicitly do *not* add another exploder to replace the old address: instead, *if* we want something to cover this use case, add a new list that interested people can subscribe to. Maybe debian-cross-ports or debian-architectures or something. Please feel free to suggest a better name! If such a list were to be set up, we could/should encourage existing architecture porters to sign up there too. Thoughts? Any dissenting opinions? Listmasters - are you happy to change things like I propose? -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with Valor: Centurion represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud. -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910150520.go24...@einval.com
Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)
On Wed, Oct 02, 2013 at 04:07:25PM +0100, Wookey wrote: +++ Niels Thykier [2013-10-02 09:45 +0200]: Hi, The final results are in: Summary table: Arch || DDs || NMs/DMs || Other || Total ---++-++-++---++-- armel || 3 || 0 || 1 ||4 armhf || 3 || 1 || 2 ||6 armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve McIntyre (DD) armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McIntyre (DD) I am surprised not to see Riku Voipio and Hector Oron on this list as I know they help manage the buildds and Riku signs uploads. I don't know if they are trying to escape, or just being too slack to send mail :-) arm64: Wookey (DD), Steve McInture (DD) There are other DDs working on this too (Doko and Riku particularly), but again they are probably trying to avoid getting any more formal responsibilities. :-) *grin* I guess so... -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131002151044.gk14...@einval.com
Help with Wheezy CD testing on Saturday
Hi folks, As we're expecting to release this Saturday (4th May) and I'm going to be preparing the CDs and DVDs to go with the release, it would be lovely if we have some volunteers to help test the images. We have been doing testing of the daily, weekly and Release Candidate images as they're produced, but it would be nice to get more coverage in the testing, especially: * non-PC architectures * more obscure combinations of options like partitioning, filesystems etc. * different desktops with differing package sets I've started a wiki page at https://wiki.debian.org/Teams/DebianCD/ReleaseTesting/Wheezy and I'll be filling in more details there in the next couple of days, including some specific configurations that I'd like to see tested. If you can help us test on Saturday, please take a look and join me in #debian-cd where we'll be coordinating. Cheers, -- Steve McIntyre, Cambridge, UK.st...@einval.com Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs. -- Matt Mackall -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130502012910.gb28...@einval.com
DPL teams review 2008
multiple times where appropriate, once per team, but *excluding* teams for maintenance of individual packages) a. What teams do you work on? Are you an official member of those teams? b. How well do you think those teams are performing, in terms of getting things done? How are daily/regular tasks dealt with? And how about less common, one-off things? c. How do members of your teams communicate with each other about what they're working on? And how do they (as individuals or as a team) communicate with people outside of the team? Do you feel they coordinate well? d. Are there enough resources for your teams to do their jobs well? If not, what's missing? e. Anything else you'd like to mention? 3. Other teams -- a. What contact, if any, do you (as an individual) have with other teams? How well does that contact work? b. How well do your team(s) interact with other teams? c. If you have any issues in (a) or (b), how would you suggest to fix them? d. Any other observations about the various teams in Debian? === Other stuff === That's the list of things I'm hoping to learn more about from this review of teams. Of course, I'm sure there are many other things in Debian that you'd like to ask or tell me about. By all means, talk to me about them - I see it as part of my job to listen and do what I can to help. But please keep those separate from this survey - it'll help me to avoid my head exploding in all directions... :-) -- Steve McIntyre, Debian Project Leader [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Re: Re: Re: HP i2000 install problems
On Tue, Nov 14, 2006 at 11:15:55PM +0100, Dennis Grevenstein wrote: On 11/14/06, Steve McIntyre [EMAIL PROTECTED] wrote: OK, same problem then. I had to install woody, then build a custom kernel too. I'll dig out my patch for you if you like. sure. Just send me the patch. Attached. I finally found out what the problem was. I tried booting the potato install cd, but that failed too, so I tried updating the firmware from cdrom. It's now at 1.30 and it boots the 3.1r3 netinst.iso without problems. Cool. I've updated the firmware on mine too, and hopefully stock kernels will work too next time I try. :-) -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Who needs computer imagery when you've got Brian Blessed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: HP i2000 install problems
[EMAIL PROTECTED] wrote: Hi, I've recently obtained an i2000. Dual 800MHz first generation Itanium with 2GB RAM and about 80GB of diskspace on three SCSI disks. It's currently running HP-UX 11.22, so I know the machine works. This is my fastest system with room for more internal disks, so I thought about letting it do some server tasks. I tried the debian-3.1r3 netinst.iso and the debian-testing netinst.iso. Both won't boot any kernel successfully. I always get a kernel panic of some sort or it just freezes. I have tried all available kernels on these CDs. I read some documentation and found that some Itanium1 systems have problems booting Linux when the firmware is not recent. My system has 1.17. I could upgrade to 1.30, but you need a freaky LS120 floppy to install the update (more than 10 year old DEC Alpha can boot their firmware update from cdrom, so I certainly wonder why it was chosen to be that way on the I2000). Before I buy a useless LS120 I would like to know more about this. Is it really possible that the kernel won't even boot when the firmware is a bit too old? I've got an i2000 with a very similar-sounding problem. See #304267 for more details. I still have problems with standard kernels, but with a simple patch I've got a 2.6.17 kernel running happily on it now. How far does yours get before hanging? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Who needs computer imagery when you've got Brian Blessed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: HP i2000 install problems
On Tue, Nov 14, 2006 at 07:11:33PM +0100, Dennis Grevenstein wrote: On 11/14/06, Steve McIntyre [EMAIL PROTECTED] wrote: OK, same problem then. I had to install woody, then build a custom kernel too. I'll dig out my patch for you if you like. sure. Just send me the patch. Attached. BTW: Does anyone know where to get a woody cdrom image? I started looking in the usual places, but it seems all gone. They've been archived, but they're still about: http://cdimage.debian.org/cdimage/archive/images/3.0_r6/ia64/ We're hoping to keep them around for a while yet. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. --- linux-2.6.17.3/arch/ia64/kernel/mca.c~ 2006-06-30 18:37:38.0 +0100 +++ linux-2.6.17.3/arch/ia64/kernel/mca.c 2006-10-18 21:29:46.0 +0100 @@ -1773,6 +1773,8 @@ IA64_MCA_DEBUG(%s: CMCI/P setup and enabled.\n, __FUNCTION__); +return 0; + #ifdef CONFIG_ACPI /* Setup the CPEI/P vector and handler */ cpe_vector = acpi_request_vector(ACPI_INTERRUPT_CPEI); signature.asc Description: Digital signature
Re: Bug#304267: RC3 netinst fails at boot on ia64
reassign 304267 kernel-image-2.6.8-2-itanium-smp thanks On Wed, Apr 13, 2005 at 12:51:18AM +0100, Steve McIntyre wrote: On Tue, Apr 12, 2005 at 04:09:13PM -0400, Joey Hess wrote: Steve McIntyre wrote: ACPI: PCI interrupt :01:00.0[A] - GSI 19 (level, low) - IRQ 52 GSI 56 (level, low) - CPU 1 (0x0300) vector 53 ACPI: PCI interrupt :01:0f.0[A] - GSI 56 (level, low) - IRQ 53 GSI 57 (level, low) - CPU 0 (0x) vector 54 ACPI: PCI interrupt :02:0f.0[A] - GSI 57 (level, low) - IRQ 54 GSI 55 (level, low) - CPU 1 (0x0300) vector 55 ACPI: PCI interrupt :03:00.0[A] - GSI 55 (level, low) - IRQ 55 perfmon: version 2.0 IRQ 238 perfmon: Itanium PMU detected, 14 PMCs, 18 PMDs, 4 counters (32 bits) in all cases it stops dead and will not respond any further. It sounds like the hardware is resetting at this point - the IDE floppy and the CD drive both make a churning noise similar to that at initial POST, and the VGA display blanks. FWIW, here's the same bit of the (net)boot sequence of d-i with 2.6 on my xp1000: PCI-APIC IRQ transform: (20:01.0 INTA) - CPU 0x vector 54 PCI-APIC IRQ transform: (20:01.1 INTB) - CPU 0x vector 55 PCI-APIC IRQ transform: (20:02.0 INTA) - CPU 0x vector 56 PCI-APIC IRQ transform: (80:00.0 INTA) - CPU 0x vector 57 HWP0001 SBA at 0xfed0; pci dev 00:1e.0 HWP0001 IOC at 0xfed01000; pci dev 00:1d.0 HWP0002 PCI LBA _BBN 0x00 at 0xfed2; pci dev 00:1c.0 HWP0002 PCI LBA _BBN 0x20 at 0xfed22000; pci dev 20:1e.0 HWP0002 PCI LBA _BBN 0x40 at 0xfed24000; pci dev 40:1e.0 HWP0002 PCI LBA _BBN 0x60 at 0xfed26000; pci dev 60:1e.0 HWP0002 PCI LBA _BBN 0xc0 at 0xfed2c000; pci dev c0:1e.0 HWP0003 AGP LBA _BBN 0x80 at 0xfed28000; pci dev 80:1e.0 IOC: reserving 512Mb of IOVA space at 0x6000 for agpgart IOC: zx1 2.2 HPA 0xfed01000 IOVA space 1024Mb at 0x4000 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket perfmon: version 1.5 IRQ 238 perfmon: 14 PMCs, 18 PMDs, 4 counters (32 bits) PAL Information Facility v0.5 EFI Variables Facility v0.06 2002-Dec-10 Total HugeTLB memory allocated, 0 Starting kswapd VFS: Disk quotas vdquot_6.5.1 Hugetlbfs mounted. devfs: v1.12c (20020818) Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x0 Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). This is well before init starts, so it looks like entirely a kernel problem, I think it should be reassigned to an appropriate kernel package. That's fair, yes. I managed to get woody installed last night and I upgraded the system to sarge from there successfully. The system runs fine with the woody kernel (2.4.17-mckinley-smp), but all of the sarge kernels I've tried fail in a similar way during boot: kernel-image-2.4.27-2-itanium-smp 2.4.27-7 kernel-image-2.4.27-2-mckinley-smp 2.4.27-7 kernel-image-2.6.8-2-itanium-smp 2.6.8-12 kernel-image-2.6.8-2-mckinley-smp 2.6.8-12 which seems odd. The (woody) 2.4.17-mckinley-smp kernel is what I'm stuck with for now. Quite a way on now... I'm reassigning this to the itanium-smp 2.6 kernel in sarge, as that's the kernel I've finally found the time to debug. All of the ia64 kernels in sarge fail to boot on the SMP HP i2000 workstation I have. The machine used to be caballero.d.o; I don't know if it's a standard machine or not, as I don't know much about the history of the machine. What I _have_ found by trial and error with printk is that the lockup I'm seeing (in 2.6.8 at least, 2.4.27 may be different) is somewhere in (or under) ia64_mca_late_init(). By simply adding an early return from that function (before the #ifdef CONFIG_ACPI block), I can make the kernel boot fine. I don't know very much about ia64_mca_late_init() - I'm assuming/hoping it's nothing to do with Micro Channel Architecture! -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] This dress doesn't reverse. -- Alden Spiess -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#306308: xearth: FTBFS: Missing Build-Depends on 'xutils'
On Mon, Apr 25, 2005 at 03:54:58PM -0700, Steve Langasek wrote: On Mon, Apr 25, 2005 at 07:21:34PM +0200, Andreas Jochens wrote: Package: xearth Version: 1.1-10 Severity: serious Tags: sarge When building 'xearth' in a clean 'testing' chroot, I get the following error: dh_clean debian/rules build dh_testdir # Add here commands to configure the package. xmkmf make: xmkmf: Command not found make: *** [configure-stamp] Error 127 The new version in sid fixes this by adding the missing Build-Depends on xutils in debian/control. Non-free package, needs manual builds on ia64, m68k, s390 -- any volunteers? ia64 build in incoming now. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] We don't need no education. We don't need no thought control. signature.asc Description: Digital signature
Re: Bug#304267: RC3 netinst fails at boot on ia64
On Wed, Apr 13, 2005 at 10:40:24AM +1000, Ian Wienand wrote: On Wed, Apr 13, 2005 at 12:51:18AM +0100, Steve McIntyre wrote: Now I'm looking at the console with this kernel running, I'm seeing a constant spew of messages like kernel unaligned access to 0xe0007a295fbc, ip=0xe4983aa0 sc1236(0,200699b8,200493a0,c309) sc1236(0,20540200,0,205776d0) sc1236(0,0,3,0) sc1254(0,8fffbd00,0,2033dd70) sc1236(0,20308200,0,2033f6d0) sc1254(0,8fffbd00,0,2033dd70) sc1236(0,20308200,0,2033f6d0) sc1254(0,8fffbd00,0,2033dd70) sc1236(0,20308200,0,2033f6d0) sc1254(0,8fffbd00,0,2033dd70) sc1236(0,20308200,0,2033f6d0) sc1254(0,8fffbd00,0,2033dd70) sc1236(0,20308200,0,2033f6d0) scrolling up the screen. Naively, I'm guessing this may suggest hardware problems on this machine. Any suggestions, guys? No, that's from running a 2.4 kernel with modern libc's ... the kernel is telling you something is trying to make unimplemented system calls. Nothing will break, but at this stage you're best off running a 2.6 series kernel anyway. Cool, thanks. At least the hardware (probably) doesn't have problems then. I just need to work out why the machine won't boot any current sarge kernel, either 2.4.27 or 2.6.8. That's the worrying thing atm... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? signature.asc Description: Digital signature
Re: Bug#304267: RC3 netinst fails at boot on ia64
On Tue, Apr 12, 2005 at 04:09:13PM -0400, Joey Hess wrote: Steve McIntyre wrote: ACPI: PCI interrupt :01:00.0[A] - GSI 19 (level, low) - IRQ 52 GSI 56 (level, low) - CPU 1 (0x0300) vector 53 ACPI: PCI interrupt :01:0f.0[A] - GSI 56 (level, low) - IRQ 53 GSI 57 (level, low) - CPU 0 (0x) vector 54 ACPI: PCI interrupt :02:0f.0[A] - GSI 57 (level, low) - IRQ 54 GSI 55 (level, low) - CPU 1 (0x0300) vector 55 ACPI: PCI interrupt :03:00.0[A] - GSI 55 (level, low) - IRQ 55 perfmon: version 2.0 IRQ 238 perfmon: Itanium PMU detected, 14 PMCs, 18 PMDs, 4 counters (32 bits) in all cases it stops dead and will not respond any further. It sounds like the hardware is resetting at this point - the IDE floppy and the CD drive both make a churning noise similar to that at initial POST, and the VGA display blanks. FWIW, here's the same bit of the (net)boot sequence of d-i with 2.6 on my xp1000: PCI-APIC IRQ transform: (20:01.0 INTA) - CPU 0x vector 54 PCI-APIC IRQ transform: (20:01.1 INTB) - CPU 0x vector 55 PCI-APIC IRQ transform: (20:02.0 INTA) - CPU 0x vector 56 PCI-APIC IRQ transform: (80:00.0 INTA) - CPU 0x vector 57 HWP0001 SBA at 0xfed0; pci dev 00:1e.0 HWP0001 IOC at 0xfed01000; pci dev 00:1d.0 HWP0002 PCI LBA _BBN 0x00 at 0xfed2; pci dev 00:1c.0 HWP0002 PCI LBA _BBN 0x20 at 0xfed22000; pci dev 20:1e.0 HWP0002 PCI LBA _BBN 0x40 at 0xfed24000; pci dev 40:1e.0 HWP0002 PCI LBA _BBN 0x60 at 0xfed26000; pci dev 60:1e.0 HWP0002 PCI LBA _BBN 0xc0 at 0xfed2c000; pci dev c0:1e.0 HWP0003 AGP LBA _BBN 0x80 at 0xfed28000; pci dev 80:1e.0 IOC: reserving 512Mb of IOVA space at 0x6000 for agpgart IOC: zx1 2.2 HPA 0xfed01000 IOVA space 1024Mb at 0x4000 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket perfmon: version 1.5 IRQ 238 perfmon: 14 PMCs, 18 PMDs, 4 counters (32 bits) PAL Information Facility v0.5 EFI Variables Facility v0.06 2002-Dec-10 Total HugeTLB memory allocated, 0 Starting kswapd VFS: Disk quotas vdquot_6.5.1 Hugetlbfs mounted. devfs: v1.12c (20020818) Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x0 Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). This is well before init starts, so it looks like entirely a kernel problem, I think it should be reassigned to an appropriate kernel package. That's fair, yes. I managed to get woody installed last night and I upgraded the system to sarge from there successfully. The system runs fine with the woody kernel (2.4.17-mckinley-smp), but all of the sarge kernels I've tried fail in a similar way during boot: kernel-image-2.4.27-2-itanium-smp 2.4.27-7 kernel-image-2.4.27-2-mckinley-smp 2.4.27-7 kernel-image-2.6.8-2-itanium-smp 2.6.8-12 kernel-image-2.6.8-2-mckinley-smp 2.6.8-12 which seems odd. The (woody) 2.4.17-mckinley-smp kernel is what I'm stuck with for now. (cc to debian-ia64 at this point) As far as I can tell from the docs, I have a machine that should be using itanium rather than mckinley kernels. I don't know how much difference there is from one to the other, but FWIW the woody installer gave me a mckinley kernel that runs. Now I'm looking at the console with this kernel running, I'm seeing a constant spew of messages like kernel unaligned access to 0xe0007a295fbc, ip=0xe4983aa0 sc1236(0,200699b8,200493a0,c309) sc1236(0,20540200,0,205776d0) sc1236(0,0,3,0) sc1254(0,8fffbd00,0,2033dd70) sc1236(0,20308200,0,2033f6d0) sc1254(0,8fffbd00,0,2033dd70) sc1236(0,20308200,0,2033f6d0) sc1254(0,8fffbd00,0,2033dd70) sc1236(0,20308200,0,2033f6d0) sc1254(0,8fffbd00,0,2033dd70) sc1236(0,20308200,0,2033f6d0) sc1254(0,8fffbd00,0,2033dd70) sc1236(0,20308200,0,2033f6d0) scrolling up the screen. Naively, I'm guessing this may suggest hardware problems on this machine. Any suggestions, guys? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] There's no sensation to compare with this Suspended animation, A state of bliss signature.asc Description: Digital signature
