Re: "Bug" in Debian Installer?
On Fri 21 Apr 2023 at 23:05:53 (+0700), Max Nikulin wrote: > On 21/04/2023 11:26, David Wright wrote: > > On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote: > > > > > Opt-out variant for ESP sounds reasonable for me. However I am unsure > > > if it is possible to complete installation with no ESP at all. > > > > If you mean: to install Grub but not write to the ESP, > > No, I did not go so far. I wrote about partitioning screen. Understood; I wasn't sure. > It is > possible to select ESP partition and mark it "Do not use". My > expectation is that it should prevent installing grub to ESP. However > it is easy to forget about the "K" flag (partition will be used by > installer). I haven't tried removing all the flags to see what warning might result, and whether there would even be any attempt to install grub-* (the packages called grub-*, not writing grub.cfg or placing Grub code in NVRAM). It does help to have the grub packages available to make changes later. > My point is that if a partition is marked for usage as ESP then it is > not "without explicit notification and permission". Agreed: it reinforces/confirms the point that the user asked the d-i to install a Debian system. > > ┌─┤ [!] Install the GRUB boot loader ├──┐ > > Is it shown in the case of default debconf priority or it is necessary > to switch to "low"? IDK. As I said, "I think you can …", which I wrote because I think I did just that. (I was doing something very similar to what the OP was doing, using a PC with dual-booting Windows/Debian to install Debian onto a portable drive, without screwing up the dual-boot. > Frankly speaking, from this text it is unclear for me if the question > is related to putting files to EFI/debian or to creation of new > Boot NVRAM variable with possible modification of BootOrder. Sure. I was hacking, and keeping a close eye on VC4. (Using more is hard work compared with less.) > > │ The following other operating systems have been detected on this │ > > │ computer: Debian GNU/Linux 11 (bullseye) │ > > │ │ > > │ If all of your operating systems are listed above, then it should be │ > > │ safe to install the boot loader to your primary drive (UEFI │ > > │ partition/boot record). > > Side note. I do not think it is safe to install *Debian* boot loader > when another *Debian* is detected. It will overwrite > EFI/debian/grub.cfg and so will make earlier installed debian not > bootable. Either I missed something or it is fragile to manage grub > configuration shared by 2 independent debian (or other linux > distributions) systems. That's why I wrote about "playing tricks" below. Felix mentioned using GRUB_DISTRIBUTOR to avoid having the same name used twice. > > Bullseye had a misfeature where it would, even on a BIOS machine, > > solicit installing to the fallback location. > > Do you mean installing grub to EFI/BOOT (layout for removable > storage)? Yes. The nomenclature is very confusing IMO. > I have an almost 10 years old HP laptop with buggy firmware. > The easiest way to make linux bootable is to put grub into EFI/BOOT > (and remove fbx64.efi fallback binary that attempts to adjust Boot > and ignored BootOrder on each boot). It is possible to select any boot > entry from F9 menu, but by default it boots from EFI/BOOT/bootx64.efi. But this was a BIOS machine, so there's no UEFI/EFI. The buster d-i seemed not to realise that, even though it knew it had an MBR: ┌───┤ [!] Install the GRUB boot loader on a hard disk ├───┐ │ │ │ You need to make the newly installed system bootable, by installing │ │ the GRUB boot loader on a bootable device. The usual way to do this │ │ is to install GRUB on the master boot record of your first hard │ ↑↑ │ drive. If you prefer, you can install GRUB elsewhere on the drive, or │ │ to another drive, or even to a floppy. │ │ │ │ Device for boot loader installation:│ ┌──┤ [.] Install the GRUB boot loader on a hard disk ├──┐ │ │ │ It seems that this computer is configured to boot via EFI, but maybe │ │ that configuration will not work for booting from the hard drive. │ │ Some EFI firmware implementations do not meet the EFI specification │ │ (i.e. they are buggy!) and do not support proper configuration of │ │ boot options from system hard drives. │ │ │
Re: "Bug" in Debian Installer?
On 21/04/2023 11:26, David Wright wrote: On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote: Opt-out variant for ESP sounds reasonable for me. However I am unsure if it is possible to complete installation with no ESP at all. If you mean: to install Grub but not write to the ESP, No, I did not go so far. I wrote about partitioning screen. It is possible to select ESP partition and mark it "Do not use". My expectation is that it should prevent installing grub to ESP. However it is easy to forget about the "K" flag (partition will be used by installer). My point is that if a partition is marked for usage as ESP then it is not "without explicit notification and permission". ┌─┤ [!] Install the GRUB boot loader ├──┐ Is it shown in the case of default debconf priority or it is necessary to switch to "low"? Frankly speaking, from this text it is unclear for me if the question is related to putting files to EFI/debian or to creation of new Boot NVRAM variable with possible modification of BootOrder. │ The following other operating systems have been detected on this │ │ computer: Debian GNU/Linux 11 (bullseye) │ │ │ │ If all of your operating systems are listed above, then it should be │ │ safe to install the boot loader to your primary drive (UEFI │ │ partition/boot record). Side note. I do not think it is safe to install *Debian* boot loader when another *Debian* is detected. It will overwrite EFI/debian/grub.cfg and so will make earlier installed debian not bootable. Either I missed something or it is fragile to manage grub configuration shared by 2 independent debian (or other linux distributions) systems. Bullseye had a misfeature where it would, even on a BIOS machine, solicit installing to the fallback location. Do you mean installing grub to EFI/BOOT (layout for removable storage)? I have an almost 10 years old HP laptop with buggy firmware. The easiest way to make linux bootable is to put grub into EFI/BOOT (and remove fbx64.efi fallback binary that attempts to adjust Boot and ignored BootOrder on each boot). It is possible to select any boot entry from F9 menu, but by default it boots from EFI/BOOT/bootx64.efi. 2. On a laptop having ESP partitions on 2 disks, both ones are marked for usage as ESP. I am unsure if it causes installation error later or grub is installed on both ones (taking into account single /boot/efi mount point). I would assume not, as people complain about this as a single point of failure in UEFI booting. I haven't tried repeating "Install the GRUB boot loader" from the Main Menu, but I don't see why it shouldn't work. But I don't think that that would get you two entries in NVRAM without playing some tricks. On that HP laptop I manually installed grub to second ESP. The result is 2 indistinguishable entries in F9 boot menu. The text is taken from shim/BOOTX64.CSV, no other hints displayed.
Re: "Bug" in Debian Installer?
On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote: > Opt-out variant for ESP sounds reasonable for me. However I am unsure > if it is possible to complete installation with no ESP at all. If you mean: to install Grub but not write to the ESP, I think you can do this by saying Yes to: ┌─┤ [!] Install the GRUB boot loader ├──┐ │ │ │ The following other operating systems have been detected on this │ │ computer: Debian GNU/Linux 11 (bullseye) │ │ │ │ If all of your operating systems are listed above, then it should be │ │ safe to install the boot loader to your primary drive (UEFI │ │ partition/boot record). When your computer boots, you will be able to │ │ choose to load one of these operating systems or the newly installed │ │ Debian system.│ │ │ │ Install the GRUB boot loader to your primary drive? │ and Go Back to: ┌──┤ [!] Install the GRUB boot loader ├───┐ │ │ │ You need to make the newly installed system bootable, by installing │ │ the GRUB boot loader on a bootable device. The usual way to do this │ │ is to install GRUB to your primary drive (UEFI partition/boot │ │ record). You may instead install GRUB to a different drive (or │ │ partition), or to removable media. │ │ │ │ Device for boot loader installation: │ If there was already a working Grub on the disk, then it should be straightforward to boot by editing one of its menu entries. With anything less than that, it helps to be familiar with the Grub rescue prompt. > What may be considered as issues from my point of view: > 1. From the disks overview screen it is not immediately obvious that > installer is going to write to ESP partitions. If, by disks overview, you mean the screen quoted just above, then no, it is less obvious than ISTR in the past (up to buster), where MBR was explicitly mentioned on BIOS machines. Bullseye had a misfeature where it would, even on a BIOS machine, solicit installing to the fallback location. I don't know whether it was the presence of a GPT disk that caused this offer (I have no MBR disks to try out instead), or whether it was a belt and braces (suspenders) approach for mitigating buggy UEFI implementations. If you forget which mode you booted with, then sure-fire confirmation is given by # ls /sys/firmware/efi in VC2/VC3, which is present only for UEFI. (Doesn't count as obvious, though.) > 2. On a laptop having ESP partitions on 2 disks, both ones are marked > for usage as ESP. I am unsure if it causes installation error later or > grub is installed on both ones (taking into account single /boot/efi > mount point). I would assume not, as people complain about this as a single point of failure in UEFI booting. I haven't tried repeating "Install the GRUB boot loader" from the Main Menu, but I don't see why it shouldn't work. But I don't think that that would get you two entries in NVRAM without playing some tricks. Cheers, David.
Re: "Bug" in Debian Installer?
On 4/15/23 15:51, David Christensen wrote: > "Debian GNU/Linux UEFI Installer menu" -> "Install" On 18/04/2023 15:51, David Christensen wrote: On 4/17/23 21:47, David Wright wrote: As in "Permission to break an egg, sir"? Did not pressing Enter in reply to "Install" imply something? d-i modifying a disk without explicit notification and permission is unacceptable. d-i modifying NVRAM without explicit notification and permission is unacceptable. These modifications happen at the last installation steps, so they hardly could be considered as unintended at least in the case of default (not expert) install. I have tried bookworm RC1 netinst. "Detect disks" + manual partitioning detects existing ESP and selects it for ESP. I think, it is reasonable default action. I aborted installation, so I can say nothing concerning install grub stage. Perhaps, preparing disk for another machine, you did not expect that you have to create another EFI System Partition, to choose it to use as ESP and to explicitly tell installer that existing ESP should not be used. Opt-out variant for ESP sounds reasonable for me. However I am unsure if it is possible to complete installation with no ESP at all. What may be considered as issues from my point of view: 1. From the disks overview screen it is not immediately obvious that installer is going to write to ESP partitions. 2. On a laptop having ESP partitions on 2 disks, both ones are marked for usage as ESP. I am unsure if it causes installation error later or grub is installed on both ones (taking into account single /boot/efi mount point). Do you contribute to d-i? No, I do not. You may check if your case has been discussed on the installer mailing list or in the bug tracker. I am not sure that the topic starter faced the same issue as you are trying to rise since quite few details have been provided so far.
Re: "Bug" in Debian Installer?
On 18/04/2023 11:47, David Wright wrote: On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote: I have never seen a document that completely and accurately explains, in computer engineering and science terms, the design and implementation of the boot processes for Debian (or FreeBSD, or Windows, or macOS) for all the possible combinations of BIOS, UEFI, MBR, and GPT; including work-arounds such as "protective MBR", "BIOS Boot Partition", etc.. If anyone knows of such, please provide a citation. You might start with: https://www.rodsbooks.com/gdisk/whatsgpt.html The site by Roderick W. Smith contains a lot of invaluable information from "first hands" of a developer of a boot loader and of GPT fdisk. Sometimes however I had difficulties however to find details related to particular question. Concerning UEFI I have the following links in my notes: https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/ Adam Williamson. UEFI boot: how does that actually work, then? 2014-01-25 21:07 https://en.opensuse.org/openSUSE:UEFI About UEFI https://www.rodsbooks.com/linux-uefi/ Roderick W. Smith. Linux on UEFI: A Quick Installation Guide I do not think a document that "completely and accurately explains..." exists at all.
Re: "Bug" in Debian Installer?
On Tuesday 18 April 2023 12:47:44 am David Wright wrote: > > I have never seen a document that completely and accurately explains, > > in computer engineering and science terms, the design and > > implementation of the boot processes for Debian (or FreeBSD, or > > Windows, or macOS) for all the possible combinations of BIOS, UEFI, > > MBR, and GPT; including work-arounds such as "protective MBR", "BIOS > > Boot Partition", etc.. If anyone knows of such, please provide a > > citation. > > You might start with: > > https://www.rodsbooks.com/gdisk/whatsgpt.html > Thanks for that... It's clarified some things that I've been wondering about. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
Re: "Bug" in Debian Installer?
On 4/17/23 21:47, David Wright wrote: On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote: I have never seen a document that completely and accurately explains, in computer engineering and science terms, the design and implementation of the boot processes for Debian (or FreeBSD, or Windows, or macOS) for all the possible combinations of BIOS, UEFI, MBR, and GPT; including work-arounds such as "protective MBR", "BIOS Boot Partition", etc.. If anyone knows of such, please provide a citation. You might start with: https://www.rodsbooks.com/gdisk/whatsgpt.html Thank you for the link. I will expand my statement to: d-i should inform the user and obtain their permission before making changes to a computer. As in "Permission to break an egg, sir"? Did not pressing Enter in reply to "Install" imply something? d-i modifying a disk without explicit notification and permission is unacceptable. d-i modifying NVRAM without explicit notification and permission is unacceptable. Do you contribute to d-i? David
Re: "Bug" in Debian Installer?
On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote: > On 4/17/23 07:41, David Wright wrote: > > On Mon 17 Apr 2023 at 01:27:45 (-0700), David Christensen wrote: > > > On 4/16/23 22:08, Max Nikulin wrote: > > > > On 17/04/2023 09:18, David Christensen wrote: > > > > > On 4/16/23 03:41, Max Nikulin wrote: > > > > > > On 16/04/2023 05:51, David Christensen wrote: > > > > > > > When I moved the 2.5" SATA SSD to a homebrew Intel > > > > > > > DQ67SW computer and configured BIOS Setup: > > > > > > > > > > > > > > "Boot" -> "UEFI Boot" -> "Enable" > > > > > > > > > > > > > > The SSD would not boot. > > > > > > > > > > > > New boot entry usually should be created in such case from > > > > > > EFI Shell, > > > > > > > > I have realized that you may be confused by difference of MBR vs. > > > > UEFI behavior. For MBR it is enough to choose a disk to boot in > > > > BIOS, for UEFI it is necessary to add boot entries through EFI > > > > variables in firmware. Boot entry consists of disk, partition (EFI > > > > System partition) and path of an .efi file on this partition. > > > > > > > > If so, you may suggest an additional subsection to > > > > https://wiki.debian.org/UEFI#Troubleshooting_common_issues > > > > > > Are you saying that d-i modifies the CMOS settings of UEFI computers? > > > > I think the preferred name is NVRAM, but yes. > > So, in addition to modifying disks without notifying me or obtaining > my permission, d-i modified, or attempted to modify, NVRAM settings > without notifying me or obtaining my permission. When you run the d-i, there are steps that are generally irrevocable. Examples would be partitioning, writing random data for an encrypted filesystem, and writing the MBR. (If you boot the d-i from the hard disk itself, you have no medium with which to boot the machine when you screw up the MBR.) I don't think adding material to the ESP, or running efibootmgr are necessarily seen that way. > That is disappointing, but thank you for the information. > > > > > > > > > > > I later discovered that the first install created a > > > > > > > directory and put files into the Dell's ESP (!). I > > > > > > > did not select this, nor do I desire it. This is a > > > > > > > defect with d-i: > > > > > > > > > > > > Why do you think it is wrong? > > > > > > > > > > Because OS installers should not modify a disk unless the user > > > > > authorizes it. > > > > > > > > I agree if a computer is booted into MBR/BIOS/Compatibility mode > > > > or if expert install is selected. For regular UEFI install it is a > > > > trade-off since multiple OS loaders may coexist without conflicts. > > > > User should be asked if new OS should be booted by default > > > > (BootOrder), adding files to ESP is quite safe. > > > > > > d-i should always ask before writing to disk. > > > > You will certainly be used to this because of years of BIOS/MBR > > experience. There's always a question of where to install Grub > > because you might make another OS unbootable, or you might want > > Grub placed on a particular partition. > > > > With UEFI booting, that doesn't typically come into play, so to > > provoke your question, you'd probably need low priority/Expert > > Install, which I don't think you asked for. > > > I asked for "Install": > > On 4/15/23 15:51, David Christensen wrote: > > "Debian GNU/Linux UEFI Installer menu" -> "Install" AIUI, from the first menu, that gives you Priority=medium. > > > > > Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install > > > > > on February 2, 2020: > > > > > > > > > > Install GRUB into master boot record Yes > > > > > Device /dev/sda > > > > > > > > > > That was the proper way to do it. > > > > > > > > Am I right that it was not UEFI install? Certainly overwriting of > > > > MBR must be acknowledged by the user. > > > > > > The point is that d-i asked before writing to disk. > > > > Yes, it's MBR. > > > > > > > > > The SSD would not boot. > > > > I asked about the partitioning scheme earlier, but no response. > > > Here is the current system disk configuration. It should match the > failed installation, except that I added the fifth "scratch" partition > and file system later: > > 2023-04-17 14:21:39 root@taz ~ > # parted /dev/sda u s p free > Model: ATA INTEL SSDSC2CW06 (scsi) > Disk /dev/sda: 117231408s > Sector size (logical/physical): 512B/512B > Partition Table: gpt > Disk Flags: > > Number Start End Size File system Name Flags > 34s 2047s 2014s Free Space > 1 2048s 1953791s1951744s fat32ESPboot, > esp > 2 1953792s3907583s1953792s ext4 taz_boot > 3 3907584s5861375s1953792staz_swap_crypt > 4 5861376s29298687s 23437312s taz_root_crypt > 5 29298688s 117229567s 87930880s taz_scratch_crypt
Re: "Bug" in Debian Installer?
On 4/17/23 03:35, Max Nikulin wrote: My point is that UEFI and MBR install may have different behavior. You might underestimate role of implicit conventions and agreements. I used to think that d-i would inform me and get my permission before making changes to my computer. It is unfortunate that Debian has shattered that belief, but thank you for the information. David
Re: "Bug" in Debian Installer?
On 4/17/23 07:41, David Wright wrote: On Mon 17 Apr 2023 at 01:27:45 (-0700), David Christensen wrote: On 4/16/23 22:08, Max Nikulin wrote: On 17/04/2023 09:18, David Christensen wrote: On 4/16/23 03:41, Max Nikulin wrote: On 16/04/2023 05:51, David Christensen wrote: When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and configured BIOS Setup: "Boot" -> "UEFI Boot" -> "Enable" The SSD would not boot. New boot entry usually should be created in such case from EFI Shell, I have realized that you may be confused by difference of MBR vs. UEFI behavior. For MBR it is enough to choose a disk to boot in BIOS, for UEFI it is necessary to add boot entries through EFI variables in firmware. Boot entry consists of disk, partition (EFI System partition) and path of an .efi file on this partition. If so, you may suggest an additional subsection to https://wiki.debian.org/UEFI#Troubleshooting_common_issues Are you saying that d-i modifies the CMOS settings of UEFI computers? I think the preferred name is NVRAM, but yes. So, in addition to modifying disks without notifying me or obtaining my permission, d-i modified, or attempted to modify, NVRAM settings without notifying me or obtaining my permission. That is disappointing, but thank you for the information. I later discovered that the first install created a directory and put files into the Dell's ESP (!). I did not select this, nor do I desire it. This is a defect with d-i: Why do you think it is wrong? Because OS installers should not modify a disk unless the user authorizes it. I agree if a computer is booted into MBR/BIOS/Compatibility mode or if expert install is selected. For regular UEFI install it is a trade-off since multiple OS loaders may coexist without conflicts. User should be asked if new OS should be booted by default (BootOrder), adding files to ESP is quite safe. d-i should always ask before writing to disk. You will certainly be used to this because of years of BIOS/MBR experience. There's always a question of where to install Grub because you might make another OS unbootable, or you might want Grub placed on a particular partition. With UEFI booting, that doesn't typically come into play, so to provoke your question, you'd probably need low priority/Expert Install, which I don't think you asked for. I asked for "Install": On 4/15/23 15:51, David Christensen wrote: > "Debian GNU/Linux UEFI Installer menu" -> "Install" Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on February 2, 2020: Install GRUB into master boot record Yes Device /dev/sda That was the proper way to do it. Am I right that it was not UEFI install? Certainly overwriting of MBR must be acknowledged by the user. The point is that d-i asked before writing to disk. Yes, it's MBR. The SSD would not boot. I asked about the partitioning scheme earlier, but no response. Here is the current system disk configuration. It should match the failed installation, except that I added the fifth "scratch" partition and file system later: 2023-04-17 14:21:39 root@taz ~ # parted /dev/sda u s p free Model: ATA INTEL SSDSC2CW06 (scsi) Disk /dev/sda: 117231408s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 34s 2047s 2014s Free Space 1 2048s 1953791s1951744s fat32ESP boot, esp 2 1953792s3907583s1953792s ext4 taz_boot 3 3907584s5861375s1953792staz_swap_crypt 4 5861376s29298687s 23437312s taz_root_crypt 5 29298688s 117229567s 87930880s taz_scratch_crypt 117229568s 117231374s 1807s Free Space 2023-04-17 14:25:51 root@taz ~ # mount | egrep 'boot|mapper' | sort /dev/mapper/sda4_crypt on / type ext4 (rw,relatime,errors=remount-ro) /dev/mapper/sda5_crypt on /scratch type ext4 (rw,relatime) /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) /dev/sda2 on /boot type ext4 (rw,relatime) 2023-04-17 14:27:06 root@taz ~ # swapon NAME TYPE SIZE USED PRIO /dev/dm-1 partition 954M 0B -2 I'll hazard a guess that the second disk had no ESP on it, so the original installer set up a dual boot system for Windows and Debian by adding an entry to the original disk's ESP. No need to quiz the operator as there would be with a Windows MBR. When you took the second disk out, it was unbootable as there was no ESP on it. (That's my guess.) During the failed installation, d-i put the directory and files onto the primary disk: On 4/15/23 15:51, David Christensen wrote: > 2023-04-15 15:10:34 root@taz ~ > # ls -ld /mnt/nvme0n1p1/EFI/debian > drwxr-xr-x 2 root root 4096 Mar 16 22:19
Re: "Bug" in Debian Installer?
On Mon 17 Apr 2023 at 01:27:45 (-0700), David Christensen wrote: > On 4/16/23 22:08, Max Nikulin wrote: > > On 17/04/2023 09:18, David Christensen wrote: > > > On 4/16/23 03:41, Max Nikulin wrote: > > > > On 16/04/2023 05:51, David Christensen wrote: > > > > > When I moved the 2.5" SATA SSD to a homebrew Intel > > > > > DQ67SW computer and configured BIOS Setup: > > > > > > > > > > "Boot" -> "UEFI Boot" -> "Enable" > > > > > > > > > > The SSD would not boot. > > > > > > > > New boot entry usually should be created in such case from > > > > EFI Shell, > > > > I have realized that you may be confused by difference of MBR vs. > > UEFI behavior. For MBR it is enough to choose a disk to boot in > > BIOS, for UEFI it is necessary to add boot entries through EFI > > variables in firmware. Boot entry consists of disk, partition (EFI > > System partition) and path of an .efi file on this partition. > > > > If so, you may suggest an additional subsection to > > https://wiki.debian.org/UEFI#Troubleshooting_common_issues > > Are you saying that d-i modifies the CMOS settings of UEFI computers? I think the preferred name is NVRAM, but yes. > > > > > I later discovered that the first install created a > > > > > directory and put files into the Dell's ESP (!). I > > > > > did not select this, nor do I desire it. This is a > > > > > defect with d-i: > > > > > > > > Why do you think it is wrong? > > > > > > Because OS installers should not modify a disk unless the user > > > authorizes it. > > > > I agree if a computer is booted into MBR/BIOS/Compatibility mode > > or if expert install is selected. For regular UEFI install it is a > > trade-off since multiple OS loaders may coexist without conflicts. > > User should be asked if new OS should be booted by default > > (BootOrder), adding files to ESP is quite safe. > > d-i should always ask before writing to disk. You will certainly be used to this because of years of BIOS/MBR experience. There's always a question of where to install Grub because you might make another OS unbootable, or you might want Grub placed on a particular partition. With UEFI booting, that doesn't typically come into play, so to provoke your question, you'd probably need low priority/Expert Install, which I don't think you asked for. > > > Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install > > > on February 2, 2020: > > > > > > Install GRUB into master boot record Yes > > > Device /dev/sda > > > > > > That was the proper way to do it. > > > > Am I right that it was not UEFI install? Certainly overwriting of > > MBR must be acknowledged by the user. > > The point is that d-i asked before writing to disk. Yes, it's MBR. > > > > > The SSD would not boot. I asked about the partitioning scheme earlier, but no response. I'll hazard a guess that the second disk had no ESP on it, so the original installer set up a dual boot system for Windows and Debian by adding an entry to the original disk's ESP. No need to quiz the operator as there would be with a Windows MBR. When you took the second disk out, it was unbootable as there was no ESP on it. (That's my guess.) So you zeroed it and reinstalled. My experience, from having a mixed bag of BIOS/UEFI computers with GPT disks, has been to always create a BIOS Boot Partition (3MB, at the start, giving 4MB alignment for the rest of the drive), and always create a potential ESP ½GB immediately following. On a BIOS machine, it can make an extra swap as they have less memory anyway, but the disk is then suitable for conversion to a UEFI environment. With GPT, you don't have to worry about running out of primary partitions. I have one ESP-less laptop, dating from 2004, so I don't think I'll be moving its 60GB GPT disk into a different machine when it finally dies. I did convert one BIOS laptop to UEFI without even reinstalling its Debian, with encouragement from Felix. That was back in 2022-02 too. From the UEFI wiki: "Once the normal installation process has been completed, the second major component with UEFI support comes into play: grub-installer. It will install the grub-efi bootloader to the right location in the ESP and will use efibootmgr to register that bootloader with the firmware. On correctly-working systems, this should work without needing any user interaction. This module will automatically find the ESP and install its files in the right place, leaving no space for confusion on where boot files are saved (as can happen with MBR/MS-DOS systems)." Cheers, David.
Re: "Bug" in Debian Installer?
On 17/04/2023 15:27, David Christensen wrote: On 4/16/23 22:08, Max Nikulin wrote: On 17/04/2023 09:18, David Christensen wrote: On 4/16/23 03:41, Max Nikulin wrote: On 16/04/2023 05:51, David Christensen wrote: When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer ... The SSD would not boot. New boot entry usually should be created in such case from EFI Shell, I have realized that you may be confused by difference of MBR vs. UEFI behavior. For MBR it is enough to choose a disk to boot in BIOS, for UEFI it is necessary to add boot entries through EFI variables in firmware. Boot entry consists of disk, partition (EFI System partition) and path of an .efi file on this partition. Are you saying that d-i modifies the CMOS settings of UEFI computers? I am unsure concerning precise meaning of CMOS in this context. UEFI provides non-volatile storage. Kernel exposes it as /sys/firmware/efi/efivars/ . For boot specific variables there is the efibootmgr tool. To make firmware aware of a bootable .efi file it is necessary to save it location to a variable like Boot. The role of the BootOrder variable is to define in which order boot entries are tried. To make newly installed system bootable, the installer needs to call efibootmgr to adjust Boot and BootOrder variables. At least HP laptops have no menu entry to configure Boot variables (OK, single entry may be configured in a rather inconvenient way) and shipped without EFI shell. That is why if installer does not modify the variables, Debian is not bootable. I later discovered that the first install created a directory and put files into the Dell's ESP (!). I did not select this, nor do I desire it. This is a defect with d-i: Why do you think it is wrong? Because OS installers should not modify a disk unless the user authorizes it. I agree if a computer is booted into MBR/BIOS/Compatibility mode or if expert install is selected. For regular UEFI install it is a trade-off since multiple OS loaders may coexist without conflicts. User should be asked if new OS should be booted by default (BootOrder), adding files to ESP is quite safe. d-i should always ask before writing to disk. I am not motivated enough to try debian installer in a similar configuration, even in a VM. Could you, please, confirm that after manual partitioning no one was configured as a ESP to be mounted at /boot/efi? My expectations is the following. At the partitioning stage installer detects available ESP and if just single one is recognized it is configured by default as /boot/efi mount point. If this configuration option is not changed by the user, it is considered as acknowledgment to write files to the EFI/debian folder on this partition. I do not have strong opinion, but I consider it as acceptable that if expert install is not enabled then installer may write files to ESP. It simplifies procedure for regular installs. Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on Install GRUB into master boot record Yes Device /dev/sda Am I right that it was not UEFI install? Certainly overwriting of MBR must be acknowledged by the user. The point is that d-i asked before writing to disk. My point is that UEFI and MBR install may have different behavior. You might underestimate role of implicit conventions and agreements.
Re: "Bug" in Debian Installer?
On 4/16/23 22:08, Max Nikulin wrote: On 17/04/2023 09:18, David Christensen wrote: On 4/16/23 03:41, Max Nikulin wrote: On 16/04/2023 05:51, David Christensen wrote: When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and configured BIOS Setup: "Boot" -> "UEFI Boot" -> "Enable" The SSD would not boot. New boot entry usually should be created in such case from EFI Shell, I have realized that you may be confused by difference of MBR vs. UEFI behavior. For MBR it is enough to choose a disk to boot in BIOS, for UEFI it is necessary to add boot entries through EFI variables in firmware. Boot entry consists of disk, partition (EFI System partition) and path of an .efi file on this partition. If so, you may suggest an additional subsection to https://wiki.debian.org/UEFI#Troubleshooting_common_issues Are you saying that d-i modifies the CMOS settings of UEFI computers? I later discovered that the first install created a directory and put files into the Dell's ESP (!). I did not select this, nor do I desire it. This is a defect with d-i: Why do you think it is wrong? Because OS installers should not modify a disk unless the user authorizes it. I agree if a computer is booted into MBR/BIOS/Compatibility mode or if expert install is selected. For regular UEFI install it is a trade-off since multiple OS loaders may coexist without conflicts. User should be asked if new OS should be booted by default (BootOrder), adding files to ESP is quite safe. d-i should always ask before writing to disk. Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on February 2, 2020: Install GRUB into master boot record Yes Device /dev/sda That was the proper way to do it. Am I right that it was not UEFI install? Certainly overwriting of MBR must be acknowledged by the user. The point is that d-i asked before writing to disk. David
Re: "Bug" in Debian Installer?
On 17/04/2023 09:18, David Christensen wrote: On 4/16/23 03:41, Max Nikulin wrote: On 16/04/2023 05:51, David Christensen wrote: When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and configured BIOS Setup: "Boot" -> "UEFI Boot" -> "Enable" The SSD would not boot. New boot entry usually should be created in such case from EFI Shell, I have realized that you may be confused by difference of MBR vs. UEFI behavior. For MBR it is enough to choose a disk to boot in BIOS, for UEFI it is necessary to add boot entries through EFI variables in firmware. Boot entry consists of disk, partition (EFI System partition) and path of an .efi file on this partition. If so, you may suggest an additional subsection to https://wiki.debian.org/UEFI#Troubleshooting_common_issues I later discovered that the first install created a directory and put files into the Dell's ESP (!). I did not select this, nor do I desire it. This is a defect with d-i: Why do you think it is wrong? Because OS installers should not modify a disk unless the user authorizes it. I agree if a computer is booted into MBR/BIOS/Compatibility mode or if expert install is selected. For regular UEFI install it is a trade-off since multiple OS loaders may coexist without conflicts. User should be asked if new OS should be booted by default (BootOrder), adding files to ESP is quite safe. Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on February 2, 2020: Install GRUB into master boot record Yes Device /dev/sda That was the proper way to do it. Am I right that it was not UEFI install? Certainly overwriting of MBR must be acknowledged by the user.
Re: "Bug" in Debian Installer?
On 4/16/23 03:41, Max Nikulin wrote: On 16/04/2023 05:51, David Christensen wrote: I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst CD, booted the CD, and installed Debian: "Debian GNU/Linux UEFI Installer menu" -> "Install" ... "Partitioning method" -> "Manual" -> <2.5" SATA SSD> Perhaps at this point installer detected EFI system partition that was used to install grub: In the past, d-i "Install" would prompt me regarding GRUB. This time, it did not. ... When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and configured BIOS Setup: "Boot" -> "UEFI Boot" -> "Enable" The SSD would not boot. New boot entry usually should be created in such case from EFI Shell, by efibootmgr, etc. Some firmware allows to choose an .efi file (EFI/debian/shimx64.efi) to boot. I do not remember which grub or shim script creates EFI boot entry. I later discovered that the first install created a directory and put files into the Dell's ESP (!). I did not select this, nor do I desire it. This is a defect with d-i: Why do you think it is wrong? Because OS installers should not modify a disk unless the user authorizes it. Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on February 2, 2020: Install GRUB into master boot recordYes Device /dev/sda That was the proper way to do it. David
Re: "Bug" in Debian Installer?
On 16/04/2023 05:51, David Christensen wrote: I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst CD, booted the CD, and installed Debian: "Debian GNU/Linux UEFI Installer menu" -> "Install" ... "Partitioning method" -> "Manual" -> <2.5" SATA SSD> Perhaps at this point installer detected EFI system partition that was used to install grub: In the past, d-i "Install" would prompt me regarding GRUB. This time, it did not. ... When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and configured BIOS Setup: "Boot" -> "UEFI Boot" -> "Enable" The SSD would not boot. New boot entry usually should be created in such case from EFI Shell, by efibootmgr, etc. Some firmware allows to choose an .efi file (EFI/debian/shimx64.efi) to boot. I do not remember which grub or shim script creates EFI boot entry. I later discovered that the first install created a directory and put files into the Dell's ESP (!). I did not select this, nor do I desire it. This is a defect with d-i: Why do you think it is wrong? EFI system partition is designed to contain boot loaders from multiple vendors. A conflict may happen due to EFI/BOOT/bootx64.efi, but it is for removable media and for buggy firmware (as a workaround). # ls -l /mnt/nvme0n1p1/EFI/debian total 5892 -rwxr-xr-x 1 root root 108 Mar 16 22:19 BOOTX64.CSV -rwxr-xr-x 1 root root 84648 Mar 16 22:19 fbx64.efi Fallback should create boot entries listed in BOOTX64.CSV if some problem with boot is detected. I am unsure concerning changing boot order. However this file is invoked by shimx64.efi or grubx64.efi (loaded by shim) and I do not expect that shim is booted with no user action when a disk is installed into another computer. -rwxr-xr-x 1 root root 121 Mar 16 22:19 grub.cfg -rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi -rwxr-xr-x 1 root root 845480 Mar 16 22:19 mmx64.efi -rwxr-xr-x 1 root root 934240 Mar 16 22:19 shimx64.efi So, I agree that d-i "Install" choice has bug(s) when installing Debian into a computer with multiple storage devices. I do not think multiple storage devices is an issue. I suspect that you are not happy that by default Debian installer picked existing EFI system partition. Were you trying to prepare a disk for another computer? Did you created ESP on that disk and specified mount point? Anyway likely it is a reason to enable low priority configuration questions.
Re: "Bug" in Debian Installer? S.W.A.G.
7My reason for suggesting changing debconf priority to low was that perhaps additional questions might have uncovered some strangeness in the installer. It was not intended to fix this bug but only as a means to further analyze the bug. Apparently those on this list failed to understand but that's understandable since trolls don't attempt to think through future probable outcomes of other's proposed actions. -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Sun, 16 Apr 2023, Geert Stappers wrote: > On Sat, Apr 15, 2023 at 07:09:58PM -0400, rhkra...@gmail.com wrote: > > On Sat, Apr 15, 2023 at 03:37:54PM -0400, Greg Wooledge wrote: > > > On Sat, Apr 15, 2023 at 07:20:58PM +0200, Geert Stappers wrote: > > > > [1] I needed a websearch on S.W.A.G. Did find > > > > - Sharing Warmth Around the Globe > > > > - > > > > - > > > > > > > } Stopped searching upon > > > > Something We All Get (tired of hearing) > > > > > > I think it's either "Stupid Wild-Ass Guess" or "Silly Wild-Ass Guess". > > Yeah, I think it is. > > > > In my experience (and usage) it was "Scientific Wild Ass Guess". > > Acknowledge on scientific usage and scientific experience. > > > First appearance of S.W.A.G. in this thread was in a top post. > That made it a Silly Wild Ass Guess. > > Follow up message ( debconf/priority was not changed ) made > it a Stupid Wild Ass Guess. > > Back to "Sharing Warmth Around the Globe": > > Replying below previous text helps understanding each other. > > > Regards > Geert Stappers >
Re: "Bug" in Debian Installer? S.W.A.G.
On Sat, Apr 15, 2023 at 07:09:58PM -0400, rhkra...@gmail.com wrote: > On Sat, Apr 15, 2023 at 03:37:54PM -0400, Greg Wooledge wrote: > > On Sat, Apr 15, 2023 at 07:20:58PM +0200, Geert Stappers wrote: > > > [1] I needed a websearch on S.W.A.G. Did find > > > - Sharing Warmth Around the Globe > > > - > > > - > > > > > } Stopped searching upon > > > Something We All Get (tired of hearing) > > > > I think it's either "Stupid Wild-Ass Guess" or "Silly Wild-Ass Guess". Yeah, I think it is. > In my experience (and usage) it was "Scientific Wild Ass Guess". Acknowledge on scientific usage and scientific experience. First appearance of S.W.A.G. in this thread was in a top post. That made it a Silly Wild Ass Guess. Follow up message ( debconf/priority was not changed ) made it a Stupid Wild Ass Guess. Back to "Sharing Warmth Around the Globe": Replying below previous text helps understanding each other. Regards Geert Stappers -- Silence is hard to parse
Re: "Bug" in Debian Installer?
d-i makes no distinction between nvme and usb. Maybe another problem is the chosen installation destination might not be passed to the code that does the grub install. -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Sat, 15 Apr 2023, David Wright wrote: > On Sat 15 Apr 2023 at 15:51:46 (-0700), David Christensen wrote: > > On 4/15/23 02:36, Andrew Wood wrote: > > > Ive just used the Debian 11 installer ISO running from a USB stick > > > to do an install (AMD64/UEFI) on another USB stick to use as a > > > 'portable PC'. > > > > > > When it got to the Grub install stage I was expecting it to ask me > > > which disk I wanted Grub installed on as it has in the past but > > > instead it did not. > > > > > > When I came to reboot the PC I found not only had it put Grub on > > > the USB it had also put on the PCs NVMe SSD overwriting the > > > Windows bootloader on there. > > > > > > Surely it should have prompted which disk I wanted it on? I > > > thought it was only Windows that trashed other peoples bootloaders > > > ;) > > > > I recently had a similarly confusing experience with a Dell Precision > > 3630 with an NVMe PCIe SSD, Windows 10 Pro, and BIOS Setup configured > > as follows: > > > > "System Configuration" -> "SATA Operation" -> "AHCI" > > > > > > I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst > > CD, booted the CD, and installed Debian: > > > > "Debian GNU/Linux UEFI Installer menu" -> "Install" > > ... > > "Partitioning method" -> "Manual" -> <2.5" SATA SSD> > > ... > > What was the partitioning layout you used on this disk at that time? > > > In the past, d-i "Install" would prompt me regarding GRUB. This time, > > it did not. > > > > > > When d-i was complete, the computer could boot either Windows or > > Debian, with suitable BIOS Setup > > > > "General" -> "Boot Sequence" > > > > > > When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and > > configured BIOS Setup: > > > > "Boot" -> "UEFI Boot" -> "Enable" > > > > The SSD would not boot. > > > > > > I zeroed the SSD and installed Debian again. The SSD now works in > > both computers. > > > > > > I later discovered that the first install created a directory and put > > files into the Dell's ESP (!). I did not select this, nor do I desire > > it. This is a defect with d-i: > > > > 2023-04-15 15:10:34 root@taz ~ > > # ls -ld /mnt/nvme0n1p1/EFI/debian > > drwxr-xr-x 2 root root 4096 Mar 16 22:19 /mnt/nvme0n1p1/EFI/debian > > > > 2023-04-15 15:10:36 root@taz ~ > > # ls -l /mnt/nvme0n1p1/EFI/debian > > total 5892 > > -rwxr-xr-x 1 root root 108 Mar 16 22:19 BOOTX64.CSV > > -rwxr-xr-x 1 root root 84648 Mar 16 22:19 fbx64.efi > > -rwxr-xr-x 1 root root 121 Mar 16 22:19 grub.cfg > > -rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi > > -rwxr-xr-x 1 root root 845480 Mar 16 22:19 mmx64.efi > > -rwxr-xr-x 1 root root 934240 Mar 16 22:19 shimx64.efi > > > > > > So, I agree that d-i "Install" choice has bug(s) when installing > > Debian into a computer with multiple storage devices. > > Cheers, > David. > >
Re: "Bug" in Debian Installer?
On Sat 15 Apr 2023 at 15:51:46 (-0700), David Christensen wrote: > On 4/15/23 02:36, Andrew Wood wrote: > > Ive just used the Debian 11 installer ISO running from a USB stick > > to do an install (AMD64/UEFI) on another USB stick to use as a > > 'portable PC'. > > > > When it got to the Grub install stage I was expecting it to ask me > > which disk I wanted Grub installed on as it has in the past but > > instead it did not. > > > > When I came to reboot the PC I found not only had it put Grub on > > the USB it had also put on the PCs NVMe SSD overwriting the > > Windows bootloader on there. > > > > Surely it should have prompted which disk I wanted it on? I > > thought it was only Windows that trashed other peoples bootloaders > > ;) > > I recently had a similarly confusing experience with a Dell Precision > 3630 with an NVMe PCIe SSD, Windows 10 Pro, and BIOS Setup configured > as follows: > > "System Configuration" -> "SATA Operation" -> "AHCI" > > > I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst > CD, booted the CD, and installed Debian: > > "Debian GNU/Linux UEFI Installer menu" -> "Install" > ... > "Partitioning method" -> "Manual" -> <2.5" SATA SSD> > ... What was the partitioning layout you used on this disk at that time? > In the past, d-i "Install" would prompt me regarding GRUB. This time, > it did not. > > > When d-i was complete, the computer could boot either Windows or > Debian, with suitable BIOS Setup > > "General" -> "Boot Sequence" > > > When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and > configured BIOS Setup: > > "Boot" -> "UEFI Boot" -> "Enable" > > The SSD would not boot. > > > I zeroed the SSD and installed Debian again. The SSD now works in > both computers. > > > I later discovered that the first install created a directory and put > files into the Dell's ESP (!). I did not select this, nor do I desire > it. This is a defect with d-i: > > 2023-04-15 15:10:34 root@taz ~ > # ls -ld /mnt/nvme0n1p1/EFI/debian > drwxr-xr-x 2 root root 4096 Mar 16 22:19 /mnt/nvme0n1p1/EFI/debian > > 2023-04-15 15:10:36 root@taz ~ > # ls -l /mnt/nvme0n1p1/EFI/debian > total 5892 > -rwxr-xr-x 1 root root 108 Mar 16 22:19 BOOTX64.CSV > -rwxr-xr-x 1 root root 84648 Mar 16 22:19 fbx64.efi > -rwxr-xr-x 1 root root 121 Mar 16 22:19 grub.cfg > -rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi > -rwxr-xr-x 1 root root 845480 Mar 16 22:19 mmx64.efi > -rwxr-xr-x 1 root root 934240 Mar 16 22:19 shimx64.efi > > > So, I agree that d-i "Install" choice has bug(s) when installing > Debian into a computer with multiple storage devices. Cheers, David.
Re: "Bug" in Debian Installer?
On Saturday, April 15, 2023 03:37:54 PM Greg Wooledge wrote: > I think it's either "Stupid Wild-Ass Guess" or "Silly Wild-Ass Guess". In my experience (and usage) it was "Scientific Wild Ass Guess". -- rhk | No entity has permission to use this email to train an AI.
Re: "Bug" in Debian Installer?
On 4/15/23 02:36, Andrew Wood wrote: Ive just used the Debian 11 installer ISO running from a USB stick to do an install (AMD64/UEFI) on another USB stick to use as a 'portable PC'. When it got to the Grub install stage I was expecting it to ask me which disk I wanted Grub installed on as it has in the past but instead it did not. When I came to reboot the PC I found not only had it put Grub on the USB it had also put on the PCs NVMe SSD overwriting the Windows bootloader on there. Surely it should have prompted which disk I wanted it on? I thought it was only Windows that trashed other peoples bootloaders ;) Regards Andrew I recently had a similarly confusing experience with a Dell Precision 3630 with an NVMe PCIe SSD, Windows 10 Pro, and BIOS Setup configured as follows: "System Configuration" -> "SATA Operation" -> "AHCI" I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst CD, booted the CD, and installed Debian: "Debian GNU/Linux UEFI Installer menu" -> "Install" ... "Partitioning method" -> "Manual" -> <2.5" SATA SSD> ... In the past, d-i "Install" would prompt me regarding GRUB. This time, it did not. When d-i was complete, the computer could boot either Windows or Debian, with suitable BIOS Setup "General" -> "Boot Sequence" When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and configured BIOS Setup: "Boot" -> "UEFI Boot" -> "Enable" The SSD would not boot. I zeroed the SSD and installed Debian again. The SSD now works in both computers. I later discovered that the first install created a directory and put files into the Dell's ESP (!). I did not select this, nor do I desire it. This is a defect with d-i: 2023-04-15 15:10:34 root@taz ~ # ls -ld /mnt/nvme0n1p1/EFI/debian drwxr-xr-x 2 root root 4096 Mar 16 22:19 /mnt/nvme0n1p1/EFI/debian 2023-04-15 15:10:36 root@taz ~ # ls -l /mnt/nvme0n1p1/EFI/debian total 5892 -rwxr-xr-x 1 root root 108 Mar 16 22:19 BOOTX64.CSV -rwxr-xr-x 1 root root 84648 Mar 16 22:19 fbx64.efi -rwxr-xr-x 1 root root 121 Mar 16 22:19 grub.cfg -rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi -rwxr-xr-x 1 root root 845480 Mar 16 22:19 mmx64.efi -rwxr-xr-x 1 root root 934240 Mar 16 22:19 shimx64.efi So, I agree that d-i "Install" choice has bug(s) when installing Debian into a computer with multiple storage devices. David
Re: "Bug" in Debian Installer?
On Sat, Apr 15, 2023 at 07:20:58PM +0200, Geert Stappers wrote: > [1] I needed a websearch on S.W.A.G. Did find > - Sharing Warmth Around the Globe > - Sealed With A Gift > - Stolen Without A Gun > - So What? Another Giveaway? > - Sub-Watershed Advisory Group > - Some Women Are Great > - Souvenirs Wearables and Gifts > > Stop searching upon > Something We All Get (tired of hearing) I think it's either "Stupid Wild-Ass Guess" or "Silly Wild-Ass Guess".
Re: "Bug" in Debian Installer?
On Sat, Apr 15, 2023 at 06:24:34PM +0100, Andrew Wood wrote: > On 15/04/2023 18:20, Geert Stappers wrote: > > On Sat, Apr 15, 2023 at 11:02:02AM -0400, Jude DaShiell wrote: > > > On Sat, 15 Apr 2023, Geert Stappers wrote: > > > > On Sat, Apr 15, 2023 at 10:36:14AM +0100, Andrew Wood wrote: > > > > > > > > > > Surely it should have prompted which disk I wanted it on? > > > > > > > > Yes. And it does. Normally. > > > > > > > Priority of questions asked was not set to low in the > > > main menu. I routinely change that to low when doing a debian install and > > > preserve logs for future reference. Default priority if memory serves is > > > medium. > > > > Time will tell if original poster shares information > > on whether or not if priority for debian-install was changed. > > Nothing was changed. I dont even know what that is. Quoting debian-installer manual: debconf/priority (priority) This parameter sets the lowest priority of messages to be displayed. The default installation uses priority=high. This means that both high and critical priority messages are shown, but medium and low priority messages are skipped. If problems are encountered, the installer adjusts the priority as needed. If you add priority=medium as boot parameter, you will be shown the installation menu and gain more control over the installation. When priority=low is used, all messages are shown (this is equivalent to the expert boot method). With priority=critical, the installation system will display only critical messages and try to do the right thing without fuss. > Ive installed Debian on many systems over the past 12 years Acknowledge. > and have never altered a 'priority' in the installer. Make it possible to answer the question from the subject line. Groeten Geert Stappers -- Silence is hard to parse
Re: "Bug" in Debian Installer?
You've never seen debian main menu in the installer. That's selection 19 on that main menu and selection 21 helps big time with debugging since you choose that to save log files and selection 3 under that will save logs to /var/log/installer directory. Two ways to get to main menu. First and slowest is to hit < sign several times until the menu comes up once installer started. Second, use boot options and a enter i enter x enter I think will put you in the installer main menu when the installer comes up. I usually do a i s "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Sat, 15 Apr 2023, Andrew Wood wrote: > > On 15/04/2023 18:20, Geert Stappers wrote: > > Time will tell if original poster shares information > > on whether or not if priority for debian-install was changed. > > > Nothing was changed. I dont even know what that is. Ive installed Debian on > many systems over the past 12 years and have never altered a 'priority' in > the installer. > > >
Re: "Bug" in Debian Installer?
On 15/04/2023 18:20, Geert Stappers wrote: Time will tell if original poster shares information on whether or not if priority for debian-install was changed. Nothing was changed. I dont even know what that is. Ive installed Debian on many systems over the past 12 years and have never altered a 'priority' in the installer.
Re: "Bug" in Debian Installer?
On Sat, Apr 15, 2023 at 11:02:02AM -0400, Jude DaShiell wrote: > On Sat, 15 Apr 2023, Geert Stappers wrote: > > On Sat, Apr 15, 2023 at 10:36:14AM +0100, Andrew Wood wrote: > > > Ive just used the Debian 11 installer ISO running from a USB stick to do > > > an > > > install (AMD64/UEFI) on another USB stick to use as a 'portable PC'. > > > > > > When it got to the Grub install stage I was expecting it to ask me which > > > disk I wanted Grub installed on as it has in the past but instead it did > > > not. > > > > Way before "grub install" should have been asked > > > >On which disk to install > > > > > > > When I came to reboot the PC I found not only had it put Grub on the USB > > > it > > > had also put on the PCs NVMe SSD overwriting the Windows bootloader on > > > there. > > > > I do read "two devices were effected", I think it is the same error of > > > > > >On which disk to install > > > > > > > > > Surely it should have prompted which disk I wanted it on? > > > > Yes. And it does. Normally. > > > > A s.w.a.g. here. [1] > Priority of questions asked was not set to low in the > main menu. I routinely change that to low when doing a debian install and > preserve logs for future reference. Default priority if memory serves is > medium. Time will tell if original poster shares information on whether or not if priority for debian-install was changed. > > Please make it possible to reproduce what is encountered. > > Yeah, I would like to known what happened > > and I say right now there is not enough information to reproduce. So we might be able to answer the question "Bug" in Debian Installer? stated in the Subject line. Groeten Geert Stappers [1] I needed a websearch on S.W.A.G. Did find - Sharing Warmth Around the Globe - Sealed With A Gift - Stolen Without A Gun - So What? Another Giveaway? - Sub-Watershed Advisory Group - Some Women Are Great - Souvenirs Wearables and Gifts Stop searching upon Something We All Get (tired of hearing) -- Super Wacky And Great
Re: "Bug" in Debian Installer?
On 15/04/2023 14:12, Geert Stappers wrote: Way before "grub install" should have been asked On which disk to install I do read "two devices were effected", I think it is the same error of On which disk to install If you mean did it install Debian on the NVme ssd then no, the Windows paritition was not touched. I was able to restore the Windows bootloader from the Win 11 ISO command line and boot again. I could even boot Windows from the Grub menu having booted Grub from the USB, but with the USB removed the NVMe SSD just gave a Grub prompt.
Re: "Bug" in Debian Installer?
A s.w.a.g. here. Priority of questions asked was not set to low in the main menu. I routinely change that to low when doing a debian install and preserve logs for future reference. Default priority if memory serves is medium. -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Sat, 15 Apr 2023, Geert Stappers wrote: > On Sat, Apr 15, 2023 at 10:36:14AM +0100, Andrew Wood wrote: > > Ive just used the Debian 11 installer ISO running from a USB stick to do an > > install (AMD64/UEFI) on another USB stick to use as a 'portable PC'. > > > > When it got to the Grub install stage I was expecting it to ask me which > > disk I wanted Grub installed on as it has in the past but instead it did > > not. > > Way before "grub install" should have been asked > >On which disk to install > > > > When I came to reboot the PC I found not only had it put Grub on the USB it > > had also put on the PCs NVMe SSD overwriting the Windows bootloader on > > there. > > I do read "two devices were effected", I think it is the same error of > > >On which disk to install > > > > > Surely it should have prompted which disk I wanted it on? > > Yes. And it does. Normally. > > > Please make it possible to reproduce what is encountered. > Yeah, I would like to known what happened > and I say right now there is not enough information to reproduce. > > > Groeten > Geert Stappers >
Re: "Bug" in Debian Installer?
On Sat, Apr 15, 2023 at 10:36:14AM +0100, Andrew Wood wrote: > Ive just used the Debian 11 installer ISO running from a USB stick to do an > install (AMD64/UEFI) on another USB stick to use as a 'portable PC'. > > When it got to the Grub install stage I was expecting it to ask me which > disk I wanted Grub installed on as it has in the past but instead it did > not. Way before "grub install" should have been asked On which disk to install > When I came to reboot the PC I found not only had it put Grub on the USB it > had also put on the PCs NVMe SSD overwriting the Windows bootloader on > there. I do read "two devices were effected", I think it is the same error of On which disk to install > Surely it should have prompted which disk I wanted it on? Yes. And it does. Normally. Please make it possible to reproduce what is encountered. Yeah, I would like to known what happened and I say right now there is not enough information to reproduce. Groeten Geert Stappers -- Silence is hard to parse
"Bug" in Debian Installer?
Ive just used the Debian 11 installer ISO running from a USB stick to do an install (AMD64/UEFI) on another USB stick to use as a 'portable PC'. When it got to the Grub install stage I was expecting it to ask me which disk I wanted Grub installed on as it has in the past but instead it did not. When I came to reboot the PC I found not only had it put Grub on the USB it had also put on the PCs NVMe SSD overwriting the Windows bootloader on there. Surely it should have prompted which disk I wanted it on? I thought it was only Windows that trashed other peoples bootloaders ;) Regards Andrew
Re: Bug in Debian installer
於 2011年09月14日 02:45, Bob Proulx 提到: spp mg wrote: I install Debian(6.0.2.1 amd64) to a old HDD.This HDD has a lvm partition,it's creat by Fedora installer. I can't delete this lvm partition in intaller,it's display about lvm is busy... ,even if I delete all Logical Volume and restart installer. Finally, I delete lvm partition by other PC. It's a bug ,right? It sounds like it automatically started the lvm subsystem due to the presence of the lvm partitions. Does it give you the option to Configure LVM? I believe it should. If so then you can go into that menu and delete the lvm configuration there. Bob Hi,It has Configure the Logical Volume Manager,but it only has delete volume group I playback this problem in my virtual machine. First,choose Guided partitioning in partition disk step . Now,my disk partition look like this: -- LVM LG debian, LV root - 20.3 GB Linux device-mapper (linear) #1 20.3 GB f ext3 / LVM LG debian, LV swap_1 - 914.4 MB Linux device-mapper (linear) #1 914.4 MB f swap swap Virtual disk 1 (vda) - 21.5GB Virtio Block Device #1 primary 254 MB B f ext2 /boot #5 logical 21.2 GB k lvm -- Now,I want delete lvm(vda5),but it display partition in use .So I enter Configure the Logical Volume Manager this entry,and delete all volume group.But it still display partition in use,even if I restart installer. I know a only way can use this PC to solve problem. Enter the shell and use fdisk to delete lvm partition(vda5),and return partition disk step. But,this way is dirty,I think. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e708366.3030...@gmail.com
Re: Bug in Debian installer
sppmg wrote: 於 2011年09月14日 02:45, Bob Proulx 提到: spp mg wrote: I install Debian(6.0.2.1 amd64) to a old HDD.This HDD has a lvm partition,it's creat by Fedora installer. I can't delete this lvm partition in intaller,it's display about lvm is busy... ,even if I delete all Logical Volume and restart installer. I am unable to recreate your issue. That does not mean you have not found a problem. It means that I cannot reproduce your problem. It works okay for me. If I have an existing LVM configuration I am presented with a dialog screen saying that there is an existing LVM configuration which is about to be removed. Remove existing logical volume data? Selecting Yes removes it. Now,I want delete lvm(vda5),but it display partition in use .So I enter Configure the Logical Volume Manager this entry,and delete all volume group.But it still display partition in use,even if I restart installer. I am sorry but I am unable to recreate this problem. I do not see that behavior. This is the debian-user mailing list. You probably should take this problem directly to the debian-installer people. They have the domain knowledge for the problem. Bob signature.asc Description: Digital signature
Re: Bug in Debian installer
spp mg wrote: I install Debian(6.0.2.1 amd64) to a old HDD.This HDD has a lvm partition,it's creat by Fedora installer. I can't delete this lvm partition in intaller,it's display about lvm is busy... ,even if I delete all Logical Volume and restart installer. Finally, I delete lvm partition by other PC. It's a bug ,right? It sounds like it automatically started the lvm subsystem due to the presence of the lvm partitions. Does it give you the option to Configure LVM? I believe it should. If so then you can go into that menu and delete the lvm configuration there. Bob signature.asc Description: Digital signature
Bug in Debian installer
I install Debian(6.0.2.1 amd64) to a old HDD.This HDD has a lvm partition,it's creat by Fedora installer. I can't delete this lvm partition in intaller,it's display about lvm is busy... ,even if I delete all Logical Volume and restart installer. Finally, I delete lvm partition by other PC. It's a bug ,right? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajea0ztajdb3jp12kofhnlcortfee6jy81cvgukyrmp0ode...@mail.gmail.com
Re: Bug#593811: debian-installer: DHCP requests restart Livebox modem/router
In this bug's investigation, we might need help from other French users who have/use a Livebox from Orange. If you followup, please: - do it in English preferrably (if you can't, then I'll translate) - keep the bug CC'ed (593...@bugs.debian.org) Quoting Alain rpnpif (rpn...@free.fr): On Sat, Aug 21, 2010 at 11:24:18AM -0400, Christian PERRIER wrote: You may want to use a daily built net*boot* image. These are linked from http://www.debian.org/devel/debian-installer/. More specifically: i386: http://people.debian.org/~joeyh/d-i/images/daily/netboot/mini.iso amd64: http://d-i.debian.org/daily-images/amd64/daily/netboot/mini.iso Hi, I must fix the title : The Livebox always restarts when dhcp requests are made on the first time by installer ; the Livebox is not resetting as I wrote (it does not loss its settings restarting), but no matter, it is an important bug. ...in the Livebox, sure..:-) In order to debug this, you probably need to get logs from D-I (in /var/log/debian-installer on the installed system).and from the Livebox itself. I'am fairly sure that the meaningful logs are the Livebox ones. So, well, I'd suggest reporting this to Orange, particularly if you have no way to SSH into the Livebox. Have other French users been able to reproduce this? (not owning a Livebox myself, thankfully for me, I can't try reproducing/debugging this) It should be easy to reproduce the problem as it happens in the early phases of the installation process, before anything is written on disksso you can try on an installed machine without risks. It just needs booting an installation ISO (not a lenny ISO, but rather a daily build of D-I from http://www.debian.org/devel/debian-installersee the full bug log at http://bugs.debian.org/593811). signature.asc Description: Digital signature
Bug#260109: debian installer 2004 jul 16 report (pppoe,cdrw/dvd, xfree86,kernel,kde,gnome)
Olá, Sou novato com Debian e é a primeira vez que instalo. Tento ajudar a melhorar o debian-installer e postei um installation report LONGO e DETALHADO (#260109) na lista principal do assunto (em inglês) ( http://lists.debian.org/debian-boot/2004/07/mail4.html#01537 ). Separei em várias mensagens, para cada log file, problema e report. Estão todas consolidadas no link abaixo: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260109 Por gentileza, enfrento ainda vários problemas (até kernel errado foi instalado e terrível problema de lentidão nos ambientes gráficos) e preciso alguma orientação para resolvê-los. Também foi incluida uma mensagem com strings precisando correções. Como é um hardware que vendeu bem no Brasil, acredito ser do interesse da lista brasileira. Peço a gentileza de postarem respostas (que envolvam o debian-installer) na lista em inglês, pois beneficiará usuários mundiais e a equipe do debian-installer internacional também, além dos brasileiros. As outras perguntas não diretamente relacionadas ao instalador acredito sejam adequadas responder nesta lista aqui. Muito obrigado. André Felipe http://www.andrefelipemachado.hpg.ig.com.br/linux/index.html __ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br/
