Re: PowePC sid_d-i daily builds are not happening...
On Sun, 31 May 2009, Steve McIntyre wrote: On Sat, May 30, 2009 at 02:01:24PM -0400, Rick Thomas wrote: On May 24, 2009, at 2:39 AM, Rick Thomas wrote: http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/arch-latest/powerpc/iso-cd/ says that This build finished at Mon May 18 22:27:07 UTC 2009. That's almost a week ago. I'd like to test a new sid installation on one of my Macs but until this is fixed, I can't. Any idea when it will be working again? This has not changed in the last week. It still says May 18th, 2009. What is wrong and what can we do to fix it? Sorry, no idea what was wrong but just as I went to look at the logs of the last build the latest one just succeeded. I gave the one from 2009-06-03 a try on PS3, and it's still missing some required modules (ps3rom (CD/DVD/BD), ps3disk (HDD), ps3_gelic (Ethernet)) [1], so I couldn't install it. I did manage to install something using http://people.debian.org/~wouter/d-i/powerpc/20090501-22:00/powerpc64/netboot/mini.iso `Unfortunately' I decided to give encrypted LVM a try. As it didn't install a kernel, initrd, and bootloader config [1], the install was rendered unbootable. First I tried to fix it manually: - Set up decryption and LVM from NFS root, and mount the file system - chroot to the mounted file system - install busybox-static from sid, to get a working grep [2] - install linux-image-2.6.29-2-powerpc64, which creates the initrd However, the initrd complains it cannot find the volume group, and drops into a shell after a while. From there, I can setup decryption and LVM and mount the file system manually, though. Am I missing some important step? Second, I tried to boot mini.iso in rescue mode, but it didn't detect any encrypted volumes, so I couldn't recover. IIRC, resuce mode worked fine when I tried it on my laptop (amd64) with encrypted LVM ca. one year ago. Perhaps there are other issues with encrypted LVM on ppc? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514055 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531600 With kind regards, Geert Uytterhoeven Software Architect Techsoft Centre Technology and Software Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Which kernels to include on ISOs? (Was: Re: Netboot Xen images for amd64)
On Friday 22 May 2009, Ian Campbell wrote: On Sat, 2009-04-18 at 12:49 +0200, Frans Pop wrote: Also note that adding the 686-bigmem kernel to CD images still has a rather high impact (as you'd need to add both the kernel udeb _and_ the regular kernel-image deb), which is rather undesirable for both the netinst CD and the regular CD1. In the first case because of the size increase it would cause [1], in the second case because it would push packages important for the desktop task off CD1. Even the DVD1 image is getting tight as we currently support installation of _all_ desktop environments from it. The margin for businesscard images depends mainly on the capacity of actual businesscard sized media. I've been thinking about this some more and I wonder if 486 + 686 is still the best option for DVD1 -- as opposed to 486 + 686-bigmem. Yes, I'm very sure it is. IMHO the set of machines which benefit from a 686 kernel but are unable to run a 686-bigmem kernel is already small and getting smaller. I reckon those machine would be fine with a 486 kernel anyway, the 686 optimisations don't buy you that much and SMP-but-non-PAE machine are an even smaller set (if such a thing even exists, I'm not sure). I'm afraid I quite strongly disagree with you on this. 1) 686-bigmem has a significant performance penalty for systems that don't need it (otherwise it would be a non-issue as the option would just be enabled in the generic -686 kernel). 2) I guestimate that 90% of systems that really need a -686 kernel have less memory than the limit supported by the generic -686 kernel. Random sample: I have three desktops and a laptop running 686, and none of them comes even close to that limit. 3) IIRC there are fairly significant differences between -486 and -686 performance on normal Pentiums and AMD boxes. 4) According to Linus, anybody who fits huge amounts of memory in normal Pentium systems is insane as the lowmem/highmem distinction will always continue to hurt you. 5) I would think that the set of machines you're aiming at is mostly 64-bit capable (the 32-bit segment can hardly be said to be growing). In that case they really should be running either the amd64 arch, or, if they really want a 32-bit userland, i386, but with the -amd64 kernel [0]! I expect that last would support Xen as well. IMO your argumentation is strongly colored by your own goals here. New machines these days already have 1-2G as a pretty basic minimum and And are 64-bit capable and thus shouldn't be using -686 at all! I predict that when squeeze arrives getting on for 4G will be a common default. A PAE kernel starts to become necessary around 3.5G anyway due to the PCI hole and even for machines with 3.5G of RAM you get things like NX support thrown in. The 686 kernel is still just an aptitude run away. *shrug* so is the -bigmem kernel [1]. A more important issue for me is that we should make sure to install the correct *generic* kernel for regular users and leave specialized kernels to experts. And now something slightly more constructive. Personally I would say that full CD and DVD are not even very interesting for Xen installs: their content is desktop oriented, so why download a lot of shite you're not going to be using anyway? Netinst and businesscard are much more relevant, but as explained earlier those have space restrictions. But there is one image that might exactly fit the bill: the i386/amd64/ppc multi-arch netinst CD. Current size (Lenny): 488MB. For that it does not matter if it would grow a bit, and it's targeted exactly at your users: (semi-)professional sysadmins. Only problem is that implementing adding Xen to just that image will require a fair few changes in debian-cd. In configuration, but I think also in code (you'll need to introduce a concept of variants within arches for D-I tasks). It'll not be trivial to implement that cleanly, though it should certainly be possible. I'm afraid that I have no real affinity with Xen (the current discussion on lkml rather amuses me TBH), so I don't think I'd work on that [2]. Cheers, FJP [0] Supporting automatic selection of the -amd64 flavor in D-I for i386 has never really been discussed. It would be interesting, but again the space limitations would have to be carefully considered. [1] Yes, I know, that doesn't work if you want to install Xen. [2] Though I would consider doing it for a suitable bounty. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
