[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Install CD, locks up computer system.



On Thu, 14 Jan 2021 12:20:44 +0100
Pierre-Elliott Bécue <peb@debian.org> wrote:

> Le mercredi 13 janvier 2021 à 16:19:40-0500, brian.hood@hotmail.com a
> écrit :
> > I am being run around in circles trying to get assistance.  I am
> > being redirected by individuals and WEB pages having "ALL THE
> > ANSWERS" and not needing to know the facts.
> > 
> > It is clear that I have encountered a serious and destructive
> > problem.
> > 
> > 
> > I have installed the "debian-10.7.0-amd64-DVD-1.iso" to a USB drive
> > connected to a Lenovo T420 which was running Windows 10 Pro.
> > 
> > The system boots to Windows 10 on the C: drive with the option of
> > booting to another device if I press F12 at booting.
> > 
> > I use F12 to boot to the CD Drive, "debian-10.7.0-amd64-DVD-1.iso".
> > I installed as Debian to an attached USB external drive. I used the
> > standard non graphical installer. Installation
> > proceeded fine, I accepted all defaults and did not install any
> > additional software/drivers.  After 'Install System' the installer
> > opened the CD Drive and asked me to reboot.  The "Install Grub"
> > never came up.
> > 
> > I rebooted and got the bios Boot Menu that would come up when I
> > pressed F12 came up without my pressing F12.  The boot device list
> > now has "debian" now added to the top of the boot menu.  None of
> > the items in the list boot their respective devices.
> > 
> > 
> > The Menu Reads:
> > 
> > 	debian
> > 	Windows Boot Manager
> >         ATA HDD0: WDC WD3200BEKT-08PBMT1
> > 	USB HDD: FUJISTU MHV2080AH
> > 	ATAPI CD0: Optiarca DVD RW AD-7710H
> > 
> > item ATA...
> > 	is my Drive containing the all the Windows 10 system,
> > including the Windows Boot Manager
> > 
> > item USB...
> > 	is my external drive containing the newly installed Debian
> > 10
> > 
> > item ATAPI...
> > 	in my CD Drive
> > 
> > 
> > Additional Notes:
> > 
> > I have used the same process to install Debian version 2 through 8
> > to secondary drives.
> > 
> > Nothing in documentation that I have come across indicates that
> > this "new" debian would alter the "bios" boot menu or in anyway
> > effect the Windows 10 operating systems drive.  By right it had no
> > business doing so automatically.
> > 
> > I can see no reason for some-one to believe that this would happen.
> > 
> > This is a very destructive problem.
> > 
> > I am looking at $200.00 cost to have new system installed and the
> > loss of everything on my Windows 10 System.
> > 
> > I am retired on a disability pension.  My background is system
> > logistics. This install has altered the existing bios/Windows 10
> > System without notification.  This directly violates the standards
> > set for Debian installs.

No, an additional operating system *must* 'alter' something or it will
never boot. Windows does not contain any provision for running any
other operating system but itself. It is necessary for a new operating
system to hijack the boot process, or at least to amend the BIOS boot
list to place itself as highest priority, and it will then offer Windows
as an option at boot time.
> > 
> > Please, forward this to anyone that might be able to provide
> > assistance.
> > 
> > I would like help, direction as to how to reinstate the original
> > boot sequence for my computer.

Have you tried the BIOS boot key of your computer? I have a problem
where my computer will not boot to its default BIOS entry, but using
the boot key I can choose to boot to Windows. If that works for you,
it's not the answer, but it's a workaround to get Windows running.

> > 
> > I believe the only party capable of addressing this issue is the
> > team or person that setup the Debian installer for this CD.

That is possibly true, at least if they either are or can talk to the
stretch installer team (see below). 
> > 
> > PS:  This is a new problem and therefore there is no documentation
> > in the historical archives that could possible address this issue.  
> 
> Dear Brian,
> 
> For these matters, the debian-user mailing list is the right place to
> go.
> 
> Indeed, the Community Team is a team which is here to handle
> interactions between members of the Debian Community that go wrong,
> and tries to have the Debian Code of Conduct followed by the members
> of the community in their interactions.
> 
> For convenience, I cc-ed the list here.
> 
> As for your specific matter, Windows 10 being an UEFI system, Debian
> installation has to accomodate for this, and if you used the basic
> installer, it did indeed attempt to install grub and create the
> specific entry. Probably something went south there.
> 
> If you indeed tried to boot "Debian", and it failed, I'd guess it's
> because, while the grub binary is on the uefi part of your main disk
> along with the windows bootloader and other potential stuff, the grub
> configuration is on your external drive which is not yet seen properly
> when you hit the "debian" entry choice (which is the one you should
> use, as grub will also allow you to boot windows 10), but it's a wild
> guess.
> 
> I'll let some users to chime in, as I admit I'm not the best to help
> people debug such issues over mail. :/ But I'll keep an eye.
> 
>

No solution, but a (long) datum:

Buster does seem to have a UEFI issue. About two years ago I bought an
Acer Windows 10 netbook. I wasn't really bothered about Windows,
especially 10, so I didn't take any real precautions. I just bought
another hard drive (the Windos ssd is hardwired, but there was room for
another drive) and did a netinstall of stretch, which was then stable.

To my surprise, it all worked as hoped for. Booting started grub, which
offered stretch and Windows in its menu. I kept Windows 10, and have
used it frequently since.

All went well for about 18 months. It was time to upgrade my server to
buster, but it occurred to me that I could run something of a test by
upgrading the netbook first. So I did that, and it mostly went
smoothly, except the computer no longer booted. Not to *anything*, it
would just repeatedly show an error message for about a tenth of a
second, then reboot. Not a grub error message, I've seen all of them at
some time or other. I tried hitting the BIOS boot menu key, and found it
would boot to Windows that way. It refused to boot to /dev/sda, which
is the new drive.

The machine will, with the aid of the BIOS boot menu, boot to the
buster installation medium. I can then chroot to the hard drive
installation. I then spent a couple of weeks finding out about UEFI,
renaming and moving files around in /boot/efi, as advised by Mr Google,
frequently trying to reinstall grub, all to no avail. My best effort so
far is to find that the BIOS honours the EFI NextBoot command, but not
DefaultBoot. I can edit the EFI boot list with efibootmgr, and I can
set the next boot to be from grub. The machine then reboots perfectly.

If I run buster, I can then use efibootmgr to select Debian on next
boot. I now leave the machine in permanent standby, and just wake it up
when I need it. It will reboot once to grub but then I have to remember
to set NextBoot again. Windows 10 does not offer an easy way to set
NextBoot (surprise, surprise) so if I boot it then I need to go back to
the rescue medium to get back into buster. Setting DefaultBoot with
efibootmgr achieves nothing: my choice is listed at the time as the
default boot entry, but the BIOS resets this to /dev/sda, which it
refuses to boot. Even if I replace the /dev/sda entry 0 with a copy of
the Debian entry, that still gets reset at the next boot.

I eventually got fed up with this and did a clean installation of
buster to /dev/sda. Guess what, no change whatever. So stretch was able
to install to an empty hard drive in such a way as to allow /dev/sda to
boot (the / is /dev/sda4) but for some reason buster cannot. The BIOS
was booting from its preferred /dev/sda (note that this drive
designation did not exist until I put the drive in after purchase, so
it's not hard-coded) and that managed to start grub. On installation,
presumably stretch put something vital somewhere in /dev/sda, something
which buster deleted but did not then replace with its own version. Or
maybe it did replace it, but buster's version doesn't work. 

I realise the BIOS is at fault for not permitting user setting of
DefaultBoot, but as far as I can see there is no fix, and I never
needed to do that with stretch anyway. I did ask for help here, but did
not get any reply, so I assume nobody else knows enough about UEFI
booting to help.

-- 
Joe


Reply to: