Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #195619 > unrolled thread
| Started by | Kent West <westk@acu.edu> |
|---|---|
| First post | 2018-05-11 18:20 +0200 |
| Last post | 2018-05-15 01:10 +0200 |
| Articles | 20 on this page of 67 — 14 participants |
Back to article view | Back to linux.debian.user
USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 18:20 +0200
Re: USB Install Fails, Complains about CD-ROM Robert Menes <viewtiful.icchan@gmail.com> - 2018-05-11 18:40 +0200
Re: USB Install Fails, Complains about CD-ROM Rick Thomas <rbthomas@pobox.com> - 2018-05-12 01:10 +0200
Re: USB Install Fails, Complains about CD-ROM Kenneth Parker <sea7kenp@gmail.com> - 2018-05-12 03:40 +0200
Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-12 19:40 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-11 18:40 +0200
Re: USB Install Fails, Complains about CD-ROM Curt <curty@free.fr> - 2018-05-11 19:10 +0200
Re: USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 20:40 +0200
Re: USB Install Fails, Complains about CD-ROM songbird <songbird@anthive.com> - 2018-05-11 19:50 +0200
Re: USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 20:40 +0200
Re: USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 21:30 +0200
Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-11 22:00 +0200
Re: USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 22:20 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-11 22:40 +0200
Re: USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 23:00 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-12 00:00 +0200
Re: USB Install Fails, Complains about CD-ROM Brian <ad44@cityscape.co.uk> - 2018-05-12 12:30 +0200
Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-12 19:50 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-12 21:40 +0200
Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-13 10:20 +0200
Re: Block sizes in ISOs. was: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-13 11:30 +0200
UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-13 17:20 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-13 19:10 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-14 02:10 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-14 23:40 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-15 04:00 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM songbird <songbird@anthive.com> - 2018-05-14 12:40 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM Chris Ramsden <chris.ramsden@gmail.com> - 2018-05-14 14:40 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-14 16:00 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM Chris Ramsden <chris.ramsden@gmail.com> - 2018-05-14 17:00 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM songbird <songbird@anthive.com> - 2018-05-15 02:50 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM Stefan Monnier <monnier@iro.umontreal.ca> - 2018-05-14 15:20 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-14 16:40 +0200
Re: UEFI/"BIOS" booting "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-14 18:00 +0200
Re: UEFI/"BIOS" booting Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-14 23:50 +0200
Re: UEFI/"BIOS" booting "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-15 09:00 +0200
Re: UEFI/"BIOS" booting Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-16 00:20 +0200
Re: UEFI/"BIOS" booting Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-16 23:50 +0200
Re: UEFI/"BIOS" booting "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-17 13:00 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM Stefan Monnier <monnier@iro.umontreal.ca> - 2018-05-14 18:00 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-15 03:30 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-16 00:40 +0200
Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-18 20:40 +0200
Re: UEFI/"BIOS" booting Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-14 23:50 +0200
Re: UEFI/"BIOS" booting David Wright <deblis@lionunicorn.co.uk> - 2018-05-15 03:40 +0200
Re: UEFI/"BIOS" booting Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-16 00:40 +0200
Re: UEFI/"BIOS" booting mess-mate <eric.m.c.declerck@gmail.com> - 2018-05-16 15:20 +0200
Re: UEFI/"BIOS" booting David Wright <deblis@lionunicorn.co.uk> - 2018-05-18 20:50 +0200
Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-13 04:20 +0200
Re: USB Install Fails, Complains about CD-ROM Curt <curty@free.fr> - 2018-05-13 10:30 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-13 12:10 +0200
Re: USB Install Fails, Complains about CD-ROM Curt <curty@free.fr> - 2018-05-13 14:10 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-13 14:50 +0200
Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-13 19:00 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-13 20:20 +0200
Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-14 00:40 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-14 13:30 +0200
Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-14 16:50 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-14 18:20 +0200
Re: USB Install Fails, Complains about CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-14 20:10 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-14 22:10 +0200
Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-14 23:00 +0200
Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-15 01:20 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-15 09:10 +0200
Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-17 23:40 +0200
Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-18 08:50 +0200
Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-15 01:10 +0200
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-05-15 03:30 +0200 |
| Subject | Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM |
| Message-ID | <vPwWS-6P2-15@gated-at.bofh.it> |
| In reply to | #195731 |
On Mon 14 May 2018 at 11:56:11 (-0400), Stefan Monnier wrote:
> > Yes, documentation of firmware is almost unknown in my experience
> > (since probably 30 years ago). That's why I took the least invasive
>
> It's documented to the extent that it says "implements UEFI" and that
> UEFI is documented.
I can only speak for machines that I have access to. The earliest PCs
I remember came with booklets that had illustrations of the various
CMOS screens. Since then, I've usually had to transcribe the settings
manually into files that I archive (in case of battery failure etc.)
In this particular instance (the Lenovo), its PDF says:
How can I change the boot mode?
There are two boot modes: UEFI and Legacy Support. To change the boot
mode, start the BIOS setup utility and set boot mode to UEFI or Legacy
support on the boot menu.
and that's it, apart from implying that the Legacy mode is useful:
When do I need to change the boot mode?
The default boot mode for your computer is UEFI mode. If you need to
install a legacy operating system, such as Windows (that is, any operating
system before Windows 8), Linux or DOS, etc on your computer, you must
change the boot mode to Legacy support. The legacy operating system,
such as Windows, Linux or DOS, etc cannot be installed if you don't
change the boot mode.
> >> Same here (basically for the same reason: the behavior of the firmware
> >> and OS when faced with a disk that has both a GPT and an MBR partitions
> >> is largely unspecified and will vary depending on your system).
> > Eh? I've yet to see a GPT disk that didn't have a protective MBR.
>
> Exactly: what happens when a GPT disk has a real MBR (rather than a
> protective MBR) is "you're on your own".
As Thomas has just pointed out, there's no such thing. I didn't try
to read anything into your non-idiomatic use of the plural in "a disk
that has both a GPT and an MBR partitions". There will be any number
of partitions in the GPT, and just one in the MBR's partition table.
AIUI what's unspecified is what you choose to put in the code section
of the MBR. In my case, and probably for most people here, it will be
Stage 1 of Grub. And if one has any sense, that will be pointing to a
BIOS boot partition, which is one of the first things I set up on a
GPT disk so that I can use it in my old BIOS machines. It makes things
far more bullet-proof if Grub knows there's a safe place to put its
later Stages. I suspect that systems without ones are likely to be the
ones causes much of the reported trouble.
Where's the author's discussion of all this? My beef is that these
aspects are obfuscated with talk of magic code, magic space, magic
locations and "special sauce". That's the kind of stuff I'm placing in
*their* garbage, even if it doesn't make up 95%.
> >> It's easy to reconcile: he doesn't say your setup is impossible or can't
> >> work, he just recommends not to do that because you may encounter
> >> unexpected difficulties. E.g. in theory an upgrade to your firmware or
> >> to one of your OSes could break it, tho in practice you're probably OK
> >> at least until you move that setup to another machine with
> >> a different firmware.
> > Not sure what you mean here. It's a laptop: nowt's going nowhere.
>
> Take the disk out, put it in another machine (laptop or desktop, it
> doesn't matter).
At that point, I would assume windows is dead because it's not
licenced for its new home. At which point, a decision could be made
on the basis of whether the new machine could boot Grub through the
MBR. If that's not the case, then obviously one is going to have to
boot with UEFI from, say, a stick and grub-install in UEFI mode.
If that change is made correctly, the disk should be bootable in its new
location. In addition, if it were moved back to its original location,
it should now be possible to boot both windows and linux using EUFI mode.
But these are the issues I have been keen to avoid (successfully)
by booting in different modes for the two OSes. As I stated, there
was to be no disturbance of the windows system.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-05-16 00:40 +0200 |
| Subject | Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM |
| Message-ID | <vPQLT-1Gw-1@gated-at.bofh.it> |
| In reply to | #195753 |
Le 15/05/2018 à 03:23, David Wright a écrit : > > In this particular instance (the Lenovo), its PDF says: (...) > The default boot mode for your computer is UEFI mode. If you need to > install a legacy operating system, such as Windows (that is, any operating > system before Windows 8) This is so wrong. Windows has supported EFI since Vista. > AIUI what's unspecified is what you choose to put in the code section > of the MBR. In my case, and probably for most people here, it will be > Stage 1 of Grub. Note : "stage 1" is a GRUB legacy thing. GRUB 2 calls it "boot image". > And if one has any sense, that will be pointing to a > BIOS boot partition, which is one of the first things I set up on a > GPT disk so that I can use it in my old BIOS machines. It makes things > far more bullet-proof if Grub knows there's a safe place to put its > later Stages. I suspect that systems without ones are likely to be the > ones causes much of the reported trouble. Moreover, GRUB BIOS cannot be installed without embedding (in a BIOS boot partition or any other suitable location) when the /boot filesystem is anywhere else than a plain partition (LVM, RAID, crypto...) or a filesystem type which may move block around such as btrfs, defeating the hardcoded blocklists.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-05-18 20:40 +0200 |
| Subject | Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM |
| Message-ID | <vQSsi-5Zn-7@gated-at.bofh.it> |
| In reply to | #195779 |
On Wed 16 May 2018 at 00:35:33 (+0200), Pascal Hambourg wrote:
> Le 15/05/2018 à 03:23, David Wright a écrit :
> >
> >In this particular instance (the Lenovo), its PDF says:
> (...)
> > The default boot mode for your computer is UEFI mode. If you need to
> > install a legacy operating system, such as Windows (that is, any operating
> > system before Windows 8)
>
> This is so wrong. Windows has supported EFI since Vista.
I offer no defence of what Lenovo choose to write. What I do know is
that in order to make this laptop available to myself, I had to be
able to install linux without disturbing the Windows/GPT/UEFI setup
already present.
Reading the page at
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
would have been most discouraging, so I'm glad I didn't chance upon
it and, in the light of my experience, I consider some of *it* to be
garbage, a word it's happy to use to condemn 95% of what's written
about UEFI elsewhere on the internet.
But then, I also chose to ignore what's written in the Debian
Installation Guide §3.6.3:
"Booting from a disk with GPT is only possible in native UEFI mode".
> >AIUI what's unspecified is what you choose to put in the code section
> >of the MBR. In my case, and probably for most people here, it will be
> >Stage 1 of Grub.
>
> Note : "stage 1" is a GRUB legacy thing. GRUB 2 calls it "boot image".
I wasn't aware that the "Stage 1" name was eliminated. I don't find
"boot image" adding any clarity to the process. Anyway, someone needs
to tell https://en.wikipedia.org/wiki/GNU_GRUB which says:
Version 2 (GRUB)
Stage 1: boot.img is stored in the master boot record (MBR) or
optionally in any of the volume boot records (VBRs), and addresses
the next stage by an LBA48 address (thus, the 1024-cylinder
limitation of GRUB legacy is avoided); at installation time it is
configured to load the first sector of core.img.
> >And if one has any sense, that will be pointing to a
> >BIOS boot partition, which is one of the first things I set up on a
> >GPT disk so that I can use it in my old BIOS machines. It makes things
> >far more bullet-proof if Grub knows there's a safe place to put its
> >later Stages. I suspect that systems without ones are likely to be the
> >ones causes much of the reported trouble.
>
> Moreover, GRUB BIOS cannot be installed without embedding (in a BIOS
> boot partition or any other suitable location) when the /boot
> filesystem is anywhere else than a plain partition (LVM, RAID,
> crypto...) or a filesystem type which may move block around such as
> btrfs, defeating the hardcoded blocklists.
Agreed: that's why I'm making sure I add a BIOS boot partition to
any disk I convert from MBR to GPT, allowing it to be a candidate
for booting from.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-05-14 23:50 +0200 |
| Subject | Re: UEFI/"BIOS" booting |
| Message-ID | <vPtvY-4K0-9@gated-at.bofh.it> |
| In reply to | #195726 |
Le 14/05/2018 à 16:33, David Wright a écrit : > > "Don’t do UEFI-native installs to MBR-formatted disks, or BIOS > compatibility installs to GPT-formatted disks (an exception to the > latter is if your disk is, IIRC, 2.2+TB in size, because the MBR > format can’t handle disks that big – if you want to do a BIOS > compatibility install to a disk that big, you’re kinda stuck with > the BIOS+GPT combination, which works but is a bit wonky and > involves the infamous ‘BIOS Boot partition’ you may recall from > Fedora 17). > > I haven't been able to find anything infamous about the BIOS Boot > partition but it sounds as if the author had a bad experience at > sometime in the past which has affected their ability to view the > topic objectively. AFAICS the BIOS boot partition is a rather widely unknown topic. Actually a BIOS boot partition is not required for BIOS boot on GPT. It is only recommended or required in order to install GRUB in some situations. But GRUB is not the only available bootloader.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-05-15 03:40 +0200 |
| Subject | Re: UEFI/"BIOS" booting |
| Message-ID | <vPx6y-6RN-3@gated-at.bofh.it> |
| In reply to | #195741 |
On Mon 14 May 2018 at 23:39:06 (+0200), Pascal Hambourg wrote: > Le 14/05/2018 à 16:33, David Wright a écrit : > > > > "Don’t do UEFI-native installs to MBR-formatted disks, or BIOS > > compatibility installs to GPT-formatted disks (an exception to the > > latter is if your disk is, IIRC, 2.2+TB in size, because the MBR > > format can’t handle disks that big – if you want to do a BIOS > > compatibility install to a disk that big, you’re kinda stuck with > > the BIOS+GPT combination, which works but is a bit wonky and > > involves the infamous ‘BIOS Boot partition’ you may recall from > > Fedora 17). > > > >I haven't been able to find anything infamous about the BIOS Boot > >partition but it sounds as if the author had a bad experience at > >sometime in the past which has affected their ability to view the > >topic objectively. > > AFAICS the BIOS boot partition is a rather widely unknown topic. I'm happy to publicise it a little, then, and without using terms like infamous and wonky. > Actually a BIOS boot partition is not required for BIOS boot on GPT. > It is only recommended or required in order to install GRUB in some > situations. But GRUB is not the only available bootloader. No. It's difficult to divine which bootloaders the author is familiar with. My own experience of the last twenty years is limited to Lilo and Grub. I remember reading about coreboot some years ago, but I doubt I'm ever going to meet it. Are you suggesting others? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-05-16 00:40 +0200 |
| Subject | Re: UEFI/"BIOS" booting |
| Message-ID | <vPQLU-1Gw-5@gated-at.bofh.it> |
| In reply to | #195754 |
Le 15/05/2018 à 03:37, David Wright a écrit : > >> But GRUB is not the only available bootloader. > > No. > > It's difficult to divine which bootloaders the author is familiar with. > My own experience of the last twenty years is limited to Lilo and Grub. Same here. I would not trust LILO any more now because it uses hardcoded blocklists to read files, just like GRUB does when embedding is not possible, which is considered unreliable. > I remember reading about coreboot some years ago, but I doubt I'm ever > going to meet it. Are you suggesting others? AFAIK, Coreboot is a replacement for platform firmware (BIOS), not an installable boot loader. I have never used it, but it seems that syslinux supports GPT and EFI. Also I have read positive reports about rEFInd for EFI boot.
[toc] | [prev] | [next] | [standalone]
| From | mess-mate <eric.m.c.declerck@gmail.com> |
|---|---|
| Date | 2018-05-16 15:20 +0200 |
| Subject | Re: UEFI/"BIOS" booting |
| Message-ID | <vQ4vw-1E1-7@gated-at.bofh.it> |
| In reply to | #195780 |
On 16-May-18 00:23, Pascal Hambourg wrote: > Le 15/05/2018 à 03:37, David Wright a écrit : >> >>> But GRUB is not the only available bootloader. >> >> No. >> >> It's difficult to divine which bootloaders the author is familiar with. >> My own experience of the last twenty years is limited to Lilo and Grub. > > Same here. I would not trust LILO any more now because it uses > hardcoded blocklists to read files, just like GRUB does when embedding > is not possible, which is considered unreliable. > >> I remember reading about coreboot some years ago, but I doubt I'm ever >> going to meet it. Are you suggesting others? > > AFAIK, Coreboot is a replacement for platform firmware (BIOS), not an > installable boot loader. > > I have never used it, but it seems that syslinux supports GPT and EFI. > Also I have read positive reports about rEFInd for EFI boot. > Your're right. I've installed windows 10first a mont ago, after that last debian and rEFIND. All run smootless without any problem and at the first install. Of course, partitions on GPT and UEFI.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-05-18 20:50 +0200 |
| Subject | Re: UEFI/"BIOS" booting |
| Message-ID | <vQSBZ-62T-5@gated-at.bofh.it> |
| In reply to | #195780 |
On Wed 16 May 2018 at 00:23:43 (+0200), Pascal Hambourg wrote: > Le 15/05/2018 à 03:37, David Wright a écrit : > > > >>But GRUB is not the only available bootloader. > > > >No. > > > >It's difficult to divine which bootloaders the author is familiar with. > >My own experience of the last twenty years is limited to Lilo and Grub. > > Same here. I would not trust LILO any more now because it uses > hardcoded blocklists to read files, just like GRUB does when > embedding is not possible, which is considered unreliable. > > >I remember reading about coreboot some years ago, but I doubt I'm ever > >going to meet it. Are you suggesting others? > > AFAIK, Coreboot is a replacement for platform firmware (BIOS), Yes, that interested me because at the time I had a lot of (unpowerful) PCs dotted around, some relatively inaccessible. One of the attractions of coreboot was not having to sit in front of each machine editing CMOS screens. But AIUI it was designed for farms of the sort of PCs that were out of my league. > not an installable boot loader. I read somewhere that it could directly load linux instead of, say, Grub, but I don't know anything about the technicalities. > I have never used it, but it seems that syslinux supports GPT and EFI. I haven't knowingly used that since I had PCs that booted into DOS first, back in the last millennium. > Also I have read positive reports about rEFInd for EFI boot. One for the future, when I get my very own machine that's UEFI. At the moment my newest PCs are a 2008 BIOS laptop and a couple of 2006 desktops. The latter boot GPT disks fine. The laptop will have to live out the rest of its days configured as is, running jessie and wheezy; too much of it is broken for anything else to be installed. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Mike Kupfer <mkupfer@alum.berkeley.edu> |
|---|---|
| Date | 2018-05-13 04:20 +0200 |
| Message-ID | <vOOM9-5Kx-1@gated-at.bofh.it> |
| In reply to | #195619 |
Kent West wrote: > I have a Dell Latitude E7250 laptop. I'm trying to install Debian to it using a USB stick. [...] > The real problem is that after going through the first three or four > screens, the install halts, complaining about not being able to read > the CD-ROM. Yes, I ran into the same problem with my E7250, using a netinst image and a live image. When trying to boot the live image I noticed these messages on the console: usb 1-2: device descriptor read/64, error -110 ... usb 1-2: reset high-speed USB device number 2 using xhci_hcd I tried booting from a different USB port; that worked once, but on a subsequent attempt it failed with the same issue. I did eventually get Debian installed, using a convoluted process that I won't describe here because I suspect it's not relevant (see below). I'm afraid that once I got Debian installed, I never went back to figure out what was causing the earlier failures. After reading your posting, I tried again to create a live USB stick. I used cp to copy the image to /dev/sdb, and I ran sync afterwards. Same failure. I then tried using dd instead of cp, and I used a different USB port on my desktop to write to the USB stick. This time I could boot the live image. I checked kern.log, and it had usb 2-2: device descriptor read/64, error -110 but did not have the "reset" message. (And I notice that this time it's "usb 2-2" rather than "usb 1-2".) I tried to boot off the USB stick a second time, and this time I got the failure again. So I suspect the problem has to do with peculiarities of the E7250, rather than issues writing the USB stick. I have a copy of kern.log from the first (successful) boot, and I have the dmesg output from the second (failed) boot. If anyone wants to look at them, let me know. mike
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2018-05-13 10:30 +0200 |
| Message-ID | <vOUyd-Dx-1@gated-at.bofh.it> |
| In reply to | #195668 |
On 2018-05-13, Mike Kupfer <mkupfer@alum.berkeley.edu> wrote: > > usb 1-2: device descriptor read/64, error -110 > ... > usb 1-2: reset high-speed USB device number 2 using xhci_hcd > > I tried booting from a different USB port; that worked once, but on a > subsequent attempt it failed with the same issue. > I've mounted usb sticks that spontaneously 'umounted' themselves while producing similar I/O reset errors. Which might conceivably explain why the installer would begin asking for the cdrom; when it does so, whether the usb stick is mounted or not might be a clue. Then again, mounted or not, if it can't be read the distinction between mounted or unmounted is possibly of little import. Maybe someone could boot the installer and in the early stages effectuate a 'hard eject' of the thumb drive (by ripping it out by the roots) to observe the manner in which the installer reacts (does it ask for the insertion of the 'cdrom', or do tectonic plates shift along unsuspected fault lines, eliminating the user entirely)?
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2018-05-13 12:10 +0200 |
| Message-ID | <vOW70-1Eg-15@gated-at.bofh.it> |
| In reply to | #195670 |
Hi, Mike Kupfer wrote: > usb 1-2: device descriptor read/64, error -110 If we assume that 110 is a Linux errno, then this would be ETIMEDOUT 110 /* Connection timed out */ > usb 1-2: reset high-speed USB device number 2 using xhci_hcd That's what my USB attached DVD drives sometimes do after having gnawed a long time on a read error. > I have a copy of kern.log from the first (successful) boot, and I have > the dmesg output from the second (failed) boot. If anyone wants to look > at them, let me know. I am interested. Especially whether there are messages from the ISO 9660 filesystem driver. Curt wrote: > I've mounted usb sticks that spontaneously 'umounted' themselves while > producing similar I/O reset errors. > Which might conceivably explain why the installer would begin asking for > the cdrom; The messages quoted by Kent could well indicate that the "CD-ROM" was found but that rather a particular file was not readable or did not yield the expected checksum. It would be helpful if the error messages contained the name of the failing software and the particular kind of read problem. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2018-05-13 14:10 +0200 |
| Message-ID | <vOXZ8-2LE-21@gated-at.bofh.it> |
| In reply to | #195672 |
On 2018-05-13, Thomas Schmitt <scdbackup@gmx.net> wrote: > > Curt wrote: >> I've mounted usb sticks that spontaneously 'umounted' themselves while >> producing similar I/O reset errors. >> Which might conceivably explain why the installer would begin asking for >> the cdrom; > > The messages quoted by Kent could well indicate that the "CD-ROM" was found > but that rather a particular file was not readable or did not yield the > expected checksum. I was laboring under another erroneous impression for some reason, but looking back at the OP he did say that the installer complained about not being able to "read" the cdrom (not that there was none inserted). Of course there was never a cdrom to read in the first place (which could throw off lesser lights than some of you here in this forum), but I guess we know 'it' means the thumb drive (because it can't or doesn't care to distinguish between the two media). A verbatim quote from Ms. Installer might or might not be edifying. Perhaps it said something to this effect: "There was an error reading data from the CD-ROM. Please make sure it is in the drive. If retrying does not work, you should check the integrity of your CD-ROM." Apparently there is (or was) an option to check the integrity of the 'cdrom' at that point (read failure) in the installer. > It would be helpful if the error messages contained the name of the > failing software and the particular kind of read problem. Any gritty details would probably be in the logs. > > Have a nice day :) > > Thomas > > --
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2018-05-13 14:50 +0200 |
| Message-ID | <vOYBP-2ZF-1@gated-at.bofh.it> |
| In reply to | #195674 |
Hi, i wrote: > > The messages quoted by Kent could well indicate that the "CD-ROM" was > > found Curt wrote: > I was laboring under another erroneous impression for some reason, but > looking back at the OP he did say that the installer complained about > not being able to "read" the cdrom (not that there was none inserted). Possibly it was me who brought up the idea of "not found". That was because the started kernel needs to find the device with the ISO 9660 filesystem that contains the expected files outside the initrd. A good occasion for Linux not to like the USB stick after firmware and bootloader had no problem. But i began to doubt this theory when Kent (OP) pointed to the Askubuntu question as example of the messages he saw: https://askubuntu.com/questions/127398/usb-drive-install-of-ubuntu-12-04-server-fails-cant-find-components-from-cd-r > Of course there was never a cdrom to read [...] > I guess we know 'it' means the thumb drive > "There was an error reading data from the CD-ROM. [...]" Actually it should talk about the ISO 9660 filesystem of the installation medium. "CD-ROM" is sooo Y2K. Not modern any more and not yet retro. Saying "Please have all installation diskettes ready" - that would be stylish. Back to technical: It seems that a lower software layer bails out without specific error indication and a thus clueless upper layer tries to say something useful about this unspecific failure. Can it be that debian-installer should be more verbose ? For example with the description of its components ? https://packages.debian.org/en/stretch/anna says its purpose is to be not nearly apt, but to do nevertheless. > Apparently there is (or was) an option to check the integrity of the 'cdrom' > at that point (read failure) in the installer. I would love to believe this. But probably the best check is https://www.debian.org/CD/faq/#verify on the system which copied the ISO image onto the installation medium. > Any gritty details would probably be in the logs. Where should the next victim of this problem look ? (It is not very rare, as the web tells me via google.) Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Mike Kupfer <mkupfer@alum.berkeley.edu> |
|---|---|
| Date | 2018-05-13 19:00 +0200 |
| Message-ID | <vP2vM-5gI-7@gated-at.bofh.it> |
| In reply to | #195672 |
Thomas Schmitt wrote: > Mike Kupfer wrote: > > I have a copy of kern.log from the first (successful) boot, and I have > > the dmesg output from the second (failed) boot. If anyone wants to look > > at them, let me know. > > I am interested. Especially whether there are messages from the ISO 9660 > filesystem driver. (full files sent off-list) Hmm. The bad log has [ 7.015708] usbcore: registered new interface driver uas [ 25.552030] random: crng init done In the good log, there are several other messages in between: May 13 00:47:48 localhost kernel: [ 7.530496] usbcore: registered new interface driver uas May 13 00:47:48 localhost kernel: [ 8.552616] scsi 2:0:0:0: Direct-Access General UDisk 5.00 PQ: 0 ANSI: 2 May 13 00:47:48 localhost kernel: [ 8.555906] sd 2:0:0:0: [sdb] 15728640 512-byte logical blocks: (8.05 GB/7.50 GiB) May 13 00:47:48 localhost kernel: [ 8.559691] sd 2:0:0:0: [sdb] Write Protect is off May 13 00:47:48 localhost kernel: [ 8.562143] sd 2:0:0:0: [sdb] Mode Sense: 0b 00 00 08 May 13 00:47:48 localhost kernel: [ 8.562329] sd 2:0:0:0: [sdb] No Caching mode page found May 13 00:47:48 localhost kernel: [ 8.564222] sd 2:0:0:0: [sdb] Assuming drive cache: write through May 13 00:47:48 localhost kernel: [ 8.616686] sdb: sdb1 sdb2 May 13 00:47:48 localhost kernel: [ 8.618956] sd 2:0:0:0: [sdb] Attached SCSI removable disk May 13 00:47:48 localhost kernel: [ 8.842431] ISO 9660 Extensions: RRIP_1991A May 13 00:47:48 localhost kernel: [ 8.854480] loop: module loaded May 13 00:47:48 localhost kernel: [ 8.904560] squashfs: version 4.0 (2009/01/31) Phillip Lougher May 13 00:47:48 localhost kernel: [ 9.769518] ip_tables: (C) 2000-2006 Netfilter Core Team May 13 00:47:48 localhost kernel: [ 10.083646] random: crng init done The other thing I noticed when comparing the logs is that the initial USB-related messages are different, like the devices are being recognized in a different order. I don't know if that's significant or not. > It would be helpful if the error messages contained the name of the > failing software and the particular kind of read problem. I'm afraid I didn't record the exact messages that I got during my original attempts to install. With the live image failures that I'm getting now, the console messages are [ 30.010394] usb 1-1.2: reset high-speed USB device number 3 using ehci-pci BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) Unable to find a medium containing a live file system mike
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2018-05-13 20:20 +0200 |
| Message-ID | <vP3Lb-6cL-7@gated-at.bofh.it> |
| In reply to | #195682 |
Hi, Mike Kupfer wrote: > (full files sent off-list) Received. > Hmm. The bad log has > > [ 7.015708] usbcore: registered new interface driver uas > [ 25.552030] random: crng init done It is quite sparse from that point on: [ 29.034207] usb 1-2: reset high-speed USB device number 2 using xhci_hcd and then inactivity for 220 seconds which ended by unrelated messages. Before the message at 7.015708 the two logs show a short sequence of agreement: "Product", "Manufacturer", "SerialNumber". The USB device is not reported in the bad log as SCSI device sdX. In the good log this is done as "sdb" with partitions "sdb1" and "sdb2". Then the filesystem is detected [ 8.842431] ISO 9660 Extensions: RRIP_1991A A Rock Ridge enhanced ISO with partitions is probably a bootable isohybrid filesystem. So that's what we should expect to see. Both logs have the "error -110" and do not report the stick's serial number. The inactivity before both error messages was 3.5 to 4 seconds. The bad log has two suspicious lines before that range: [ 6.997775] usb 1-2: New USB device found, idVendor=abcd, idProduct=1234 [ 7.000181] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Looks much like phony default values. They are missing in the good log. Other kernel version ? So it could be that the USB stick does not answer to this inquiry within a short timeout threshold. But this seems not to hamper the further handling of the device in the good log. --------------------------------------------------------------------------- > With the live image failures that I'm getting now, the console messages > are > > [ 30.010394] usb 1-1.2: reset high-speed USB device number 3 using ehci-pci This seems to be the worst event better than the stick falling out of the USB socket. > BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash) > Enter 'help' for a list of built-in commands. > > (initramfs) Unable to find a medium containing a live file system This matches the bad log. The stick is not registred as SCSI device and thus not accessible for reading or writing data. We shall note that this is not what Kent West, the OP, reports for his problems. If his problem is hardware related, then it is more fuzzy than yours. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Mike Kupfer <mkupfer@alum.berkeley.edu> |
|---|---|
| Date | 2018-05-14 00:40 +0200 |
| Message-ID | <vP7ON-ay-5@gated-at.bofh.it> |
| In reply to | #195684 |
Thomas Schmitt wrote:
> The bad log has two suspicious lines before that range:
> [ 6.997775] usb 1-2: New USB device found, idVendor=abcd, idProduct=1234
> [ 7.000181] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> Looks much like phony default values.
> They are missing in the good log. Other kernel version ?
I'm not sure I understand the question. The good and bad logs are both
for the same kernel--they're different attempts to boot the same ISO
using the same USB stick.
> > BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
> > Enter 'help' for a list of built-in commands.
> >
> > (initramfs) Unable to find a medium containing a live file system
>
> This matches the bad log. The stick is not registred as SCSI device and
> thus not accessible for reading or writing data.
>
> We shall note that this is not what Kent West, the OP, reports for his
> problems. If his problem is hardware related, then it is more fuzzy
> than yours.
This prompted me to go back to try to reproduce the CD-ROM thing. And
yes, I can reproduce a failure that sounds like the one that was
originally reported. If I select the installer (rather than the live
image) when booting from the USB stick, it gets through the 3 i18n
screens (language, location, keyboard layout), pauses, and then brings
up a screen with
-----8<-----8<-----
[!!] Detect and mount CD-ROM
No common CD-ROM drive was detected.
You may need to load additional CD-ROM drivers from removable media,
such as a driver floppy. If you have such media available now, insert it
and continue. Otherwise, you will be given the option to manually
select CD-ROM modules.
Load CD-ROM drivers from removable media?
<Yes> <No>
----->8----->8-----
This may be related to device initialization by the BIOS. I believe
there's a warning about this in the installation guide somewhere. But
even with my BIOS set to "Thorough" initialization, I still can get this
failure. It seems harder to get a successful boot (installer or live
image) if the system has been on recently.
In any case, I suspect that my live image boot failures are due to the
same root cause as the installer failure.
mike
PS. The BIOS setting I'm referring to is POST Behavior/Fastboot. The
choices are Minimal, Auto, and Thorough, with Minimal being the default
IIRC.
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2018-05-14 13:30 +0200 |
| Message-ID | <vPjPX-7z6-1@gated-at.bofh.it> |
| In reply to | #195691 |
Hi, i wrote: > > [ 6.997775] usb 1-2: New USB device found, idVendor=abcd, idProduct=1234 > > They are missing in the good log. Other kernel version ? > The good and bad logs are both > for the same kernel--they're different attempts to boot the same ISO > using the same USB stick. Er. Suddenly i can see the "abcd" "1234" message in the good log too. Sorry for the confusion. Just to make it clear: Was this kernel loaded from the very same USB stick which it then cannot inquire properly and in some cases cannot read from ? > This prompted me to go back to try to reproduce the CD-ROM thing. And > yes, I can reproduce a failure that sounds like the one that was > originally reported. > [!!] Detect and mount CD-ROM > No common CD-ROM drive was detected. This does not match the complaint in the web to which Kent pointed us as example. The one by your machine is quite clear. The storage device with the ISO filesystem cannot be found by the kernel. In Kent's case it seems rather that some particular file cannot be read from the already found storage device. > This may be related to device initialization by the BIOS. If the kernel was loaded by the bootloader from that USB stick, then the subsequent failures in the kernel run could be caused by some bad state of the USB stick when the bootloader starts the kernel. If booting was done via EFI (and not Legacy BIOS mode) then we could ask at grub-devel@gnu.org, whether the problem is known in any way. (With BIOS mode we'd need to go to quite dead syslinux@zytor.com ) How does the stick behave if you plug it into a running GNU/Linux system ? Any problem messages in the log ? Is it usable as storage device ? Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Mike Kupfer <mkupfer@alum.berkeley.edu> |
|---|---|
| Date | 2018-05-14 16:50 +0200 |
| Message-ID | <vPmXw-Sr-15@gated-at.bofh.it> |
| In reply to | #195710 |
Thomas Schmitt wrote: > Hi, > > Just to make it clear: > Was this kernel loaded from the very same USB stick which it then cannot > inquire properly and in some cases cannot read from ? Yes. Oh, and I tried it again this morning, after the laptop had been off all night, and this time it worked (live image boot). I then tried rebooting and running the installer, and it failed in the usual place. > > [!!] Detect and mount CD-ROM > > No common CD-ROM drive was detected. > > This does not match the complaint in the web to which Kent pointed us > as example. Ah. Right. > > This may be related to device initialization by the BIOS. > > If the kernel was loaded by the bootloader from that USB stick, then > the subsequent failures in the kernel run could be caused by some bad > state of the USB stick when the bootloader starts the kernel. > > If booting was done via EFI (and not Legacy BIOS mode) then we could > ask at grub-devel@gnu.org, whether the problem is known in any way. > (With BIOS mode we'd need to go to quite dead syslinux@zytor.com ) I'm booting using EFI. > How does the stick behave if you plug it into a running GNU/Linux system ? > Any problem messages in the log ? Is it usable as storage device ? If I plug the stick into the laptop when it's running, the stick is mounted okay. I ran sum(1) on all the files, using "find ... -type f". I didn't see any problems in kern.log. I poked around with cd and ls a bit and didn't notice anything odd, but then I'm not familiar with the contents of a hybrid image ISO. Thanks for all your help on this. mike
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2018-05-14 18:20 +0200 |
| Message-ID | <vPomC-1Pl-1@gated-at.bofh.it> |
| In reply to | #195727 |
Hi, Mike Kupfer wrote: > I'm booting using EFI. So this could be a problem with GRUB about how it leaves the USB stick after having loaded kernel and initrd from it. The volatility of success and failure still gives me riddles. But if you can reproduce failure within a bearable number of tries, then it could be indeed a topic for grub-devel mailing list. > > How does the stick behave if you plug it into a running GNU/Linux system ? > > Any problem messages in the log ? Is it usable as storage device ? > If I plug the stick into the laptop when it's running, the stick is > mounted okay. [...] didn't notice anything odd, but then I'm not familiar > with the contents of a hybrid image ISO. They have about the best verification support you can wish for. https://www.debian.org/CD/faq/#verify proposes to learn the number of sectors /sbin/isosize -x <device> and to then compute the checksum of that amount of data dd if=<device> count=<sector count> bs=2048 | sha512sum which is to be compared with the .iso image's line in file SHA512SUMS from where you downloaded the ISO. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-05-14 20:10 +0200 |
| Message-ID | <vPq53-2SD-11@gated-at.bofh.it> |
| In reply to | #195732 |
On Mon 14 May 2018 at 18:13:08 (+0200), Thomas Schmitt wrote: > Hi, > > Mike Kupfer wrote: > > I'm booting using EFI. > > So this could be a problem with GRUB about how it leaves the USB stick > after having loaded kernel and initrd from it. > > The volatility of success and failure still gives me riddles. But if you > can reproduce failure within a bearable number of tries, then it could > be indeed a topic for grub-devel mailing list. I read it as meaning that the USB stick works as a live system (first boot), but not as an installer (second boot). Which makes me wonder about earlier discussions (maybe months ago) concerning whether installing Debian from a live stick can be problematical (though I don't remember the nature of the problems people had). I've never tried it. Cheers, David.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web