Re: Adding ppc64el support in debian-cd
On Mon, Sep 22, 2014 at 10:47:10PM +0200, Aurelien Jarno wrote: On Mon, Sep 22, 2014 at 02:09:29PM +0100, Steve McIntyre wrote: On Mon, Sep 22, 2014 at 09:57:44AM -0300, Mauricio Faria de Oliveira wrote: On 09/22/2014 12:00 AM, Lennart Sorensen wrote: On Sun, Sep 21, 2014 at 06:19:43PM +0100, Steve McIntyre wrote: I'm adding support for new architectures at the moment. powerpc is one of the most awkward existing arches to add boot support for at the moment, due to the mess of older machines. I'm hoping that ppc64el is better, but I don't have much information to go on. What should we be doing to make bootable CD/DVD/USB images for ppc64el, please? Aurelien and Paulo know more about the bootable status/steps than me. I believe that w/ the grub2 and klibc uploads from this last weekend, it's almost there. There's powerpc-utils util-linux coming in from DELAYED in 2 days 5 days. OK, cool. Indeed bootable CD images are done with GRUB on ppc64el, but it is currently broken. debian-installer will provide a kernel, a vmlinux and a file called debian-cd_info.tar.gz containing the grub files. I have put an example of such a directory tree there: http://temp.aurel32.net/ppc64el/d-i/ The tarball should be decompressed in the root of the CD-ROM, while the kernel and initrd should be placed in the /install directory. The ISO image should be generated with the --chrp-boot argument. Beside that the default options of genisoimage should be used, there is no need to specify any strange HFS option like on powerpc (Note: I only tested that on a VM using SLOF, it will be nice if someone with access to bare metal can confirm that). Don't hesitate to ask more details if needed. I will tell you once GRUB is fixed and all these files are in place on d-i.debian.org. GRUB is now fixed, and the latest daily build of d-i does have the CDROM files available: http://d-i.debian.org/daily-images/ppc64el/daily/cdrom/ Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927080234.gc3...@hall.aurel32.net
Re: build interval for the weekly CDs (was: [RFC] d-i hd-media support for armhf)
On Sat, Sep 27, 2014 at 11:49:37PM +0200, Karsten Merker wrote: On Mon, Sep 22, 2014 at 12:17:23AM +0200, Karsten Merker wrote: I have started working on implementing hd-media support for the armhf platform in debian-installer. [snip] Attached is a first preliminary attempt at an implementation. The long list of kernel modules in the pkg-list is currently necessary for testing the code as the current weekly CD image contains modules for an older kernel, so the modules must for the moment be put into the initrd. This will of course be changed for the final version. I am working on a V2 of my hd-media support patch and would like to test it with a current weekly CD. I have therefore just looked at http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/ and it still shows the CD image from 2014-09-15, which is quite a few days older than a week. Is this intended or is there perhaps some problem with the CD-building process? Hi! The weekly builds happen every Monday normally, but this last Monday there were problems with the builds due to changes in tasksel. We've fixed things now, so the next set on Monday should hopefully work fine for you. If it's urgent, I can force a manual build - just let me know. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927221221.gf12...@einval.com
Re: build interval for the weekly CDs (was: [RFC] d-i hd-media support for armhf)
Karsten Merker mer...@debian.org (2014-09-27): On Mon, Sep 22, 2014 at 12:17:23AM +0200, Karsten Merker wrote: I have started working on implementing hd-media support for the armhf platform in debian-installer. [snip] Attached is a first preliminary attempt at an implementation. The long list of kernel modules in the pkg-list is currently necessary for testing the code as the current weekly CD image contains modules for an older kernel, so the modules must for the moment be put into the initrd. This will of course be changed for the final version. Hello, I am working on a V2 of my hd-media support patch and would like to test it with a current weekly CD. I have therefore just looked at http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/ and it still shows the CD image from 2014-09-15, which is quite a few days older than a week. Is this intended or is there perhaps some problem with the CD-building process? Presumably fallouts due to tasksel changes, which Steve only patched yesterday? Mraw, KiBi. signature.asc Description: Digital signature
Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode
Package: partman-efi Version: 47 Severity: important Tags: d-i Ad originally described in [1], but no bug was ever filed to match. #695048 is related, I think. Time to file a bug about this to help track work to fix it... We have a machine with both UEFI and BIOS-mode boot available, with an existing BIOS-mode Windows installation (e.g. Windows 7 in this case) *but* the machine is set up to try and boot UEFI first and *then* fall back to BIOS (for some reason). The existing Windows installation boots via the fallback, and the user has no reason to ever investigate this. However, d-i will happily boot in UEFI mode. When we get to partitioning, there is no EFI System Partition (ESP), as Windows isn't using one. We then get to either of two potentially bad cases: (a) the user shuffles partitions around and makes an ESP, installs the system OK including grub-efi. They then have a machine that will boot via UEFI to grub, but maybe will not be able to boot Windows. I've not tested this directly yet, but I can see this happening. To get to their existing Windows installation, the user will have to switch boot mode in the firmware setup - bad. (b) the user does not make an ESP, installs a system but grub-efi fails to install properly for that reason. I'm seeing bug reports that suggest this path does *not* necessarily give a clear error to the user, maybe in some cases no error at all. They reboot their newly-installed system and find it immediately goes into Windows with no sign of their new Debian installation at all. [1] https://lists.debian.org/debian-boot/2014/02/msg00080.html -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928010253.8641.22037.reportbug@tack.local
Re: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode
On Sun, Sep 28, 2014 at 02:02:53AM +0100, Steve McIntyre wrote: Package: partman-efi Version: 47 Severity: important Tags: d-i Ad originally described in [1], but no bug was ever filed to match. #695048 is related, I think. Time to file a bug about this to help track work to fix it... We have a machine with both UEFI and BIOS-mode boot available, with an existing BIOS-mode Windows installation (e.g. Windows 7 in this case) *but* the machine is set up to try and boot UEFI first and *then* fall back to BIOS (for some reason). The existing Windows installation boots via the fallback, and the user has no reason to ever investigate this. However, d-i will happily boot in UEFI mode. When we get to partitioning, there is no EFI System Partition (ESP), as Windows isn't using one. We then get to either of two potentially bad cases: (a) the user shuffles partitions around and makes an ESP, installs the system OK including grub-efi. They then have a machine that will boot via UEFI to grub, but maybe will not be able to boot Windows. I've not tested this directly yet, but I can see this happening. To get to their existing Windows installation, the user will have to switch boot mode in the firmware setup - bad. (b) the user does not make an ESP, installs a system but grub-efi fails to install properly for that reason. I'm seeing bug reports that suggest this path does *not* necessarily give a clear error to the user, maybe in some cases no error at all. They reboot their newly-installed system and find it immediately goes into Windows with no sign of their new Debian installation at all. [1] https://lists.debian.org/debian-boot/2014/02/msg00080.html I'm not 100% sure that partman-efi is the right package for the bug report, but it's as good as any. So, it's way past time to fix this particular bug. After a fair amount of playing with systems like this and discussing with folks, my proposed solution is: 1. Somewhere during initial partman setup (probably partman-efi?), we look to see if: (a) we're in UEFI mode (trivially true if we're in partman-efi); and (b) we have an existing set of partitions that are *not* set up for UEFI boot (can we use os-prober to get a list at this stage?) Look for an existing partition setup and maybe bootable flags, but no detectable EFI System Partition. 2. If the above is the case, warn the user: Your computer's firmware has started the installer in UEFI mode but there are existing Operating Systems already installed: * OS 1 * OS 2 ... These will not boot in UEFI mode. If you still wish to be able to boot one of these existing systems after installing Debian in UEFI mode, this will be difficult. Your best way forward is to reboot and restart the installer in 'BIOS compatibility mode'. You will need to reconfigure your computer's boot options to do this. If you wish to install Debian in UEFI mode and don't care about keeping the ability to boot one of the existing systems, continue. Go Back Continue If the user wants to continue, we could even suggest blanking the partition table(s) and starting again with GPT, but I don't think we currently have a blank partition table option exposed within d-i? What do people think of this plan? What have I missed? -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928012806.gh12...@einval.com
