Bug#763021: di-netboot-assistant: support for use in a build environment
Package: di-netboot-assistant Version: 0.38a Severity: wishlist Related to #503359 which added support for running d-n-a as a non-privileged user, I would like support for running as part of a build environment that creates a root of d-i images to be used on a tftp server, usb stick, etc. My goal is to have this build environment in a git repo and have a user clone it on their system and do a build. dkg's original patch using a DI_NETBOOT_ASSISTANT_CONFIG environment variable was actually better in that regard since one could easily override it in build scripts. But I do also like the way #503359 was implemented to look for a ~/.di-netboot-assistant. But the other issue I am running into when trying to create this build environment is absolute paths for things like DL_CACHE and STATUS_LIB. Since I can't know what directory the build will be in, I need some way for these to be relative (or have to resort to complicated hacks). So how about this? 1) a way to override the "root" of d-n-a variables * if an environment variable is set (DNA_ROOT?), use that as the root for other variables, otherwise check for ~/.di-netboot-assistant and then /etc/di-netboot-assistant * if the variable was set or ~/.di-netboot-assistant was found have the following change to be relative to the root DISOURCELIST, DL_CACHE, STATUS_LIB, and possibly TEMPLATES, and TFTP_ROOT 2) a way to override just the config, like dkg's DI_NETBOOT_ASSISTANT_CONFIG and that would allow for other overrides in addition to the above Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927073338.80322...@taggart.lackof.org
Bug#762694: partman-partitioning: Partitions are not aligned
On Wed, Sep 24, 2014 at 04:04:01PM +0200, Vladislav Kurz wrote: > partitions created by debian installer are not aligned to > cylinders (MBR), or 1MiB (GPT). Could you please provide a partman log from a d-i run that fails to do this? (It should be in /var/log/installer/partman after installation.) As far as I knew I'd fixed all this a long time ago ... Please note that partitions should be aligned to 1MiB or more on MBR too. Regardless of the partition table format, cylinder alignment hasn't been necessary for a decade or two now, and it produces suboptimal performance on modern disks. There may of course still be fdisk-style tools that are behind the times on this, but that's their problem. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927083112.ga13...@riva.ucam.org
Bug#741601: marked as done (installation-report: Jessie/testing on IGEL 4200 thin-client)
Your message dated Sat, 27 Sep 2014 11:21:06 +0200 with message-id <20140927112106.3bf01538@s5.lokal> and subject line closing has caused the Debian Bug report #741601, regarding installation-report: Jessie/testing on IGEL 4200 thin-client to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 741601: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741601 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: installation-reports Version: 2.55 Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** - -- Package-specific info: Boot method: USB Image version: http://caesar.acc.umu.se/cdimage/weekly-builds/i386/iso-cd/debian-testing-i386-netinst.iso, 2014-03-10 Date: 2014-03-14, about 10:00 h to 12:30 h Machine: IGEL 4200 Partitions: Filesystem Type 1K-blocksUsed Available Use% Mounted on /dev/sdb5 xfs200 3087724 2467476 56% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs50516 628 49888 2% /run tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 395720 80395640 1% /run/shm /dev/sda1 xfs 482624 48140434484 10% /boot /dev/sdb6 xfs828 62836 8714892 1% /home none tmpfs4 0 4 0% /sys/fs/cgroup Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [o] Detect network card:[o] Configure network: [o] Detect CD: [o] Load installer modules: [o] Clock/timezone setup: [o] User/password setup:[o] Detect hard drives: [o] Partition hard drives: [o] Install base system:[o] Install tasks: [o] Install boot loader:[o] Overall install:[o] Comments/Problems: This was a default-installation including Desktop and print-server on my former print-server on external USB-key. XFCE was selected automatically (because of 512 MB RAM-size only?). The X-server-problem with the graphics-driver, that I found with Wheezy is obviously resolved now. I attach 'Xorg.0.log.xz'. The partitioning was done manually with two swap-partitions and /boot/ on the internal flash memory. VIA-C3 should be mostly similar to VIA-C7, except the CPU-frontend and -socket, but it does not support PAE, so the 486-kernel-version has to be used. There would be quite some performance-improvement, when building a single-core 686-kernel-image without PAE-support for this box. 800 MHz is fast enough for a headless nano-server. The box has two normal DDR-RAM-slots. - -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="8 (jessie) - installer build 20140310-00:13" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux testins 3.13-1-486 #1 Debian 3.13.5-1 (2014-03-04) i686 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8623 [Apollo CLE266] [1106:3123] lspci -knn: Subsystem: VIA Technologies, Inc. VT8623 [Apollo CLE266] [1106:3123] lspci -knn: Kernel driver in use: agpgart-via lspci -knn: 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] [1106:b091] lspci -knn: 00:10.0 USB controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) lspci -knn:Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:10.1 USB controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) lspci -knn: Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] lspci -knn: Ker
Processed: severity of 763005 is serious
Processing commands for cont...@bugs.debian.org: > severity 763005 serious Bug #763005 [installation-guide-amd64] installation-guide-amd64: website for wheezy leads to jessie installation guide Severity set to 'serious' from 'normal' > thanks Stopping processing here. Please contact me if you need assistance. -- 763005: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763005 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.14118189383177.transcr...@bugs.debian.org
Bug#610885: marked as done (default install fails on kfreebsd-amd64)
Your message dated Sat, 27 Sep 2014 13:33:30 +0100 with message-id <5426ae9a.70...@pyro.eu.org> and subject line Re: Bug#610885: default install fails on kfreebsd-amd64 has caused the Debian Bug report #610885, regarding default install fails on kfreebsd-amd64 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 610885: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610885 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: partman-base Version: 147 Severity: grave User: debian-...@lists.debian.org Usertags: kfreebsd Default install fails on kfreebsd-amd64 with the following error: The attempt to mount a file system with type swap in SCSI1, partition #5 (da0s5) at none failed. You may resume partitioning from the partitioning menu. Do you want to resume partitioning? It should be da0s2, not da0s5. It seems that partman is counting logical partitions starting with 5 as on Linux. A workaround is to disable swap in the default partition layout and enabling it manually after the install. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- Source-Version: 165 This was fixed in wheezy! Regards, -- Steven Chamberlain ste...@pyro.eu.org--- End Message ---
Bug#762007: Kernel command line handling change breaks d-i user-params functionality
On Wed, 2014-09-17 at 18:45 +0100, Ian Campbell wrote:
> Not sure what we can do about this. Perhaps choose another separator
> ("=="?) and make user-params support both?
Reading the kernel source it seems it only checks for exactly "--". So I
propose we support "---" in addition to "--", something like the
following (untested) patch.
diff --git a/user-params b/user-params
index 53677b5..2d41e05 100755
--- a/user-params
+++ b/user-params
@@ -14,7 +14,7 @@ for item in $(sed -e 's/[^ =]*="[^"]*[ ][^"]*"//g' \
# Remove trailing '?' for debconf variables set with '?='
var="${var%\?}"
- if [ "$item" = "--" ]; then
+ if [ "$item" = "--" ] || [ "$item" = "---" ]; then
inuser=1
collect=""
elif [ "$inuser" ]; then
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411822917.23482.6.ca...@hellion.org.uk
Bug#763073: partman-md places first line of mdadm.conf to wrong file
Package: partman-md
Version: 70
Severity: normal
Tags: patch
finish-install.d/65partman-md reads:
CF=/target/etc/mdadm/mdadm.conf
if ... then
mkdir -p /target/etc/mdadm
echo "# Autogenerated by partman-md. See mdadm.conf(5) for more details
on this file." > /etc/mdadm.conf
echo "DEVICE partitions" >> $CF
...
and all subsequent lines adds information to $CF.
But the very first line, the "Autogenerated.." header
line, is put into d-i filesystem, where it is not used.
The intention was, obviously, to put it to target
mdadm.conf, ie, to $CF.
Appended patch does just that. While at it, it also
replaces argument of mkdir to be ${CF%/*}, to keep
path info in only one place, in CF variable assignment
( ${var%pattern} construct works with dash too).
Thanks,
/mjt
--- partman-md/finish-install.d/65partman-md.orig
+++ partman-md/finish-install.d/65partman-md
@@ -2,8 +2,8 @@
CF=/target/etc/mdadm/mdadm.conf
if [ ! -s "$CF" ] && [ -e /proc/mdstat ] && \
grep ^md /proc/mdstat >/dev/null; then
- mkdir -p /target/etc/mdadm
- echo "# Autogenerated by partman-md. See mdadm.conf(5) for more details on this file." > /etc/mdadm.conf
+ mkdir -p ${CF%/*}
+ echo "# Autogenerated by partman-md. See mdadm.conf(5) for more details on this file." > $CF
echo "DEVICE partitions" >> $CF
if [ "$(udpkg --print-os)" = "kfreebsd" ]; then
mount -t linprocfs proc /target/proc
Bug#763072: debian-installer: Please add keyboard layout variant selection standard install
Package: debian-installer Severity: wishlist Tags: d-i Dear Maintainer, Would you please consider adding keyboard layout variant selection to the installation procedure. Ubuntu has had it for years and it's extremely useful for people who have accented characters in their names. I have been using the US International variant forever now and it's annoying to have to manually configure it every time I install a system. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 3.2.0-4-kirkwood Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Thanks in advance. Best regards, Philippe Clérié -- The trouble with common sense is that it is so uncommon. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOjuHfLvLYrGD+BAwp3Ad7hOM=8kzqfcpnq1jjg6qk9p25w...@mail.gmail.com
Bug#762618: debian-installer: amd64/i386 netboot/mini.iso has empty grub.cfg for EFI boot
Control: tag -1 +patch On Tue, 2014-09-23 at 20:29 +0100, Ian Campbell wrote: > While looking for an example to crib for arm64 I noticed that the amd64 > mini.iso has a grub cfg (used when booting on EFI) which doesn't contain any > menu entries. Booting on non-EFI would use the isolinux menus in the usual > way. > Looking at the code I expect this will apply to i386 too, although I've not > checked. I wrote a script to generate a grub.cfg for arm64. Since it was based on the grub.cfg which debian-cd produces for x86 it is pretty trivial to reuse it here. diff --git a/build/config/x86.cfg b/build/config/x86.cfg index d54ebcb..de903bd 100644 --- a/build/config/x86.cfg +++ b/build/config/x86.cfg @@ -265,6 +265,10 @@ arch_miniiso: x86_syslinux x86_grub_efi ln -f $(TEMP_KERNEL) $(TEMP_CD_TREE)/linux ln -f $(TEMP_INITRD) $(TEMP_CD_TREE)/initrd.gz + mkdir -p $(TEMP_CD_TREE)/.disk + echo "Debian GNU/Linux $(DEBIAN_VERSION) $(ARCH) - netboot mini.iso $(BUILD_DATE)"\ + > $(TEMP_CD_TREE)/.disk/info + # Use a non-empty character for beep by default to make sure the menu # is wide enough when beep is enabled. beep="_"; \ @@ -296,9 +300,12 @@ arch_miniiso: x86_syslinux x86_grub_efi set -e; \ mkdir -p $(TEMP_CD_TREE)/boot/grub/x86_64-efi; \ cp -a $(TEMP_GRUB_EFI)/efi.img $(TEMP_CD_TREE)/boot/grub/; \ - cat boot/x86/grub/grub-efi.cfg \ - | bootvars-subst KERNEL /linux \ + grub-gencfg \ + KERNEL /linux \ INITRD /initrd.gz \ + HEADER boot/x86/grub/grub-efi.cfg \ + -- \ + $(VIDEO_MODE) \ > $(TEMP_CD_TREE)/boot/grub/grub.cfg; \ cp -a $(GRUB_FONT) $(TEMP_CD_TREE)/boot/grub/font.pf2; \ cp -a $(TEMP_GRUB_EFI)/boot/grub/x86_64-efi/* \ diff --git a/debian/changelog b/debian/changelog index 9c10cc4..e435657 100644 --- a/debian/changelog +++ b/debian/changelog @@ -10,6 +10,7 @@ debian-installer (2014) UNRELEASED; urgency=low * Switch to installing Jessie by default on ARM64. * Build netboot mini.iso on ARM64. * Build cdrom flavour for ARM64. + * Add grub.cfg to netboot mini.iso for use on EFI systems (Closes: #762618). [ Cyril Brulebois ] * Deal with even more incompatible changes on the syslinux side by -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1411849825.3824.30.ca...@hellion.org.uk
Linux kernel ABI bump in testing: from 3.14-2 to 3.16-2
Linux kernel ABI bump in testing: from 3.14-2 to 3.16-2 Full summary: http://d-i.debian.org/kernel-summary.html#testing -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xxyd3-0005dn...@dillon.debian.org
Processed: Re: Bug#762618: debian-installer: amd64/i386 netboot/mini.iso has empty grub.cfg for EFI boot
Processing control commands: > tag -1 +patch Bug #762618 [src:debian-installer] debian-installer: amd64/i386 netboot/mini.iso has empty grub.cfg for EFI boot Added tag(s) patch. -- 762618: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762618 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b762618.14118498325776.transcr...@bugs.debian.org
Re: Artwork for jessie?
All: My thought is to put a couple gig of my brush studies on bitorrent, maybe with the ubuntustudio install iso, and then when my images show up in apps/desktops/whatever, I'd use the excuse to ask Larry Wall about the artistic license. RL/rl > Cyril Brulebois (2014-08-12): >> Jessie is approaching, it would be nice to know what's going to >> happen >> for this release. If there's no new artwork I suppose it's OK to >> stick >> to the current one, but stating that in advance of the freeze would >> be >> nice. :) > > Hi artwork people. > > Could you please tell us what's done, being done, to be done on the > artwork update front? We're currently preparing a d-i Jessie Beta 2 > release, and I'd like to know which packages I should be monitoring > for artwork updates when I'm preparing Jessie Beta 3. > > Mraw, > KiBi. > Peace, -- properclinic.com unclog courts go debian -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/76d76c8d4030d2088bf7433d4f40a89d.squir...@webmail.robertlink.org
Re: Time for Jessie Beta 2?
Le vendredi, 26 septembre 2014, 21.05:07 Cyril Brulebois a écrit : > I'll probably skip syslinux vs. multi-arch this time, mostly due to > lack of time and other large ongoing changes: let's see if we can get > debian-cd to cope with latest tasksel changes soon. I have a patch suite almost there, but it makes no sense to try squeeze it in Beta2 now. Let's push it early for Beta3 > > > → I'd like to know whether some bugs need special attention/fixes > > > > (besides what's in unstable already). > > > > I haven't looked at recent bugs lately but I think we might be > > missing at least a ttf-cjk-compact-udeb upload (which might explain > > some issues reported against debian-edu IIRC), and I failed to > > upload choose-mirror for the past release (Aurelien uploaded it 10 > > days ago though, to get updated arch lists). > > Since the kernel is now a candidate for migration, I'll probably start > urgenting more packages into testing during the weekend (all > l10n-only updates, for a start), try to figure out which packages to > additionally migrate, and freeze udeb-producing packages. Thanks for your work. Cheers, OdyX -- OdyX signature.asc Description: This is a digitally signed message part.
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-boot-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 (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-boot-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
Bug#763127: 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." 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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928012806.gh12...@einval.com
Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode
On Sun, Sep 28, 2014 at 02:28:06AM +0100, Steve McIntyre wrote: > 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." > > > > 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? Isn't it better to run this test in partman-efi's isinstallable script? Then if things are set up in the described way, grub-efi just won't be installed, but the normal grub will, and the system will continue to boot in BIOS fallback as before. It might make sense to give a warning or error message in case the described setup exists and an ESP partition is created in the partitioner, but other than that... -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928064811.ga6...@grep.be
