Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #274015 > unrolled thread

Grub menu entry for a system on a second drive.

Started bypeter@easthope.ca
First post2024-10-24 22:50 +0200
Last post2024-11-03 03:50 +0100
Articles 11 on this page of 31 — 9 participants

Back to article view | Back to linux.debian.user


Contents

  Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-24 22:50 +0200
    Re: Grub menu entry for a system on a second drive. Felix Miata <mrmazda@earthlink.net> - 2024-10-24 23:00 +0200
    Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 05:30 +0200
      Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-25 17:50 +0200
        Re: Grub menu entry for a system on a second drive. Joe <joe@jretrading.com> - 2024-10-25 18:10 +0200
          Re: Grub menu entry for a system on a second drive. Max Nikulin <manikulin@gmail.com> - 2024-10-25 18:40 +0200
          Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-25 21:00 +0200
            Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 21:20 +0200
              Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-25 22:50 +0200
                Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-11-10 02:30 +0100
                  Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-11-12 05:00 +0100
        Re: Grub menu entry for a system on a second drive. Greg Wooledge <greg@wooledge.org> - 2024-10-25 18:50 +0200
        Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 20:20 +0200
    Re (2): Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-25 18:40 +0200
      Re: Grub menu entry for a system on a second drive. Felix Miata <mrmazda@stanis.net> - 2024-10-25 20:00 +0200
        Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 21:10 +0200
          Re: Grub menu entry for a system on a second drive. Felix Miata <mrmazda@stanis.net> - 2024-10-25 22:50 +0200
          Re: Grub menu entry for a system on a second drive. Felix Miata <mrmazda@stanis.net> - 2024-10-26 06:00 +0200
            Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-26 07:10 +0200
      Re: Re (2): Grub menu entry for a system on a second drive. Tim Woodall <debianuser@woodall.me.uk> - 2024-10-25 23:40 +0200
        [solved, partly] Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-27 05:20 +0100
          Re: [solved, partly] Re: Grub menu entry for a system on a second  drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-27 16:00 +0100
            Re: [solved, partly] Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-27 19:50 +0100
              Re: [solved, partly] Re: Grub menu entry for a system on a second  drive. Greg Wooledge <greg@wooledge.org> - 2024-10-28 12:10 +0100
                Re: [solved, partly] Re: Grub menu entry for a system on a second  drive. Greg Wooledge <greg@wooledge.org> - 2024-11-01 12:10 +0100
              Re: [solved, partly] Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-28 17:30 +0100
              Re: [solved, more] Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-11-02 16:10 +0100
                Re: [solved, more] Re: Grub menu entry for a system on a second  drive. David Wright <deblis@lionunicorn.co.uk> - 2024-11-04 05:50 +0100
                  Re: [solved, more] Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-11-10 04:00 +0100
                Re: [solved, more] Re: Grub menu entry for a system on a second  drive. Dan Purgert <dan@djph.net> - 2024-11-04 13:50 +0100
            Re: [solved, partly] Re: Grub menu entry for a system on a second  drive. Max Nikulin <manikulin@gmail.com> - 2024-11-03 03:50 +0100

Page 2 of 2 — ← Prev page 1 [2]


#274086 — [solved, partly] Re: Grub menu entry for a system on a second drive.

Frompeter@easthope.ca
Date2024-10-27 05:20 +0100
Subject[solved, partly] Re: Grub menu entry for a system on a second drive.
Message-ID<JC2UV-4uwu-1@gated-at.bofh.it>
In reply to#274060
Tim & all,

    From: Tim Woodall <debianuser@woodall.me.uk>
    Date: Fri, 25 Oct 2024 22:35:50 +0100 (BST)
> It's possibly not reading the grub.cfg you think it is reading.  I've
> hit this problem before - IIRC grub uses the grub.cfg from the *first*
> place it finds one - this can even be a partition (or in my case a LV)
> that is not used anywhere on any system.

That's it!  The working system is in (hd0,gpt1) and update-grub2 was 
updating (hd0,gpt1)/boot/grub/grub.cfg. Grub2 was displaying the menu 
according to (hd0,gpt2)/boot/grub/grub.cfg which hadn't changed since
an earlier installation.

Therefore booted into (hd0,gpt1), as usual, and execute "grub-install 
/dev/sda". The fresh grub refers to (hd0,gpt1)/boot/grub/grub.cfg 
which has the stanza from (hd0,gpt1)/etc/grub.d/40_custom as intended.

After that, a further problem.  The grub ls command didn't show the 
USB attached drive containing the Void Linux system.  A Web search 
found mention of grub command nativedisk which I added.  

cat /etc/grub.d/40_custom
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
#
menuentry "Void linux"{
  insmod part_gpt
  insmod ext2
  echo 'Grub is running nativedisk to allow access to a USB store.'
  nativedisk
  echo 'These disks are accessible.'
  ls
  echo 'Setting root part.'
  set root='(usb2,gpt6)'
  echo 'Booting Linux.'
  linux /boot/vmlinuz-6.6.56_2 root=UUID=e5c7eb47-8d4c-49da-9038-09c27e8e8990 ro
  echo    'Loading ramdisk.'
  initrd  /boot/initramfs-6.6.56_2.img
}

The USB attached drive was then reported by grub2 ls.  Then another 
problem.  Appears the drive doesn't respond quickly enough for the 
linux command to succeed.  Grub2 shows this.
...
Booting Linux.
error: error communication with USB Mass Storage device.
Loading ramdisk.
error: you need to load the kernel first.

Press any key to continue...

A bug in grub2 nativedisk?  The USB 2.0 adapter is too slow?  Replace 
with a USB 3 adapter?

This setup is needed only to configure the USB connected system. When 
working, the drive will be installed in another machine. Currently 
speed isn't required.  Any ideas for a software solution?  

Thanks,                 ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]


#274094 — Re: [solved, partly] Re: Grub menu entry for a system on a second drive.

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2024-10-27 16:00 +0100
SubjectRe: [solved, partly] Re: Grub menu entry for a system on a second drive.
Message-ID<JCcUh-4Beu-3@gated-at.bofh.it>
In reply to#274086
On Sat 26 Oct 2024 at 20:55:11 (-0700), peter@easthope.ca wrote:
> Tim & all,
> 
>     From: Tim Woodall <debianuser@woodall.me.uk>
>     Date: Fri, 25 Oct 2024 22:35:50 +0100 (BST)
> > It's possibly not reading the grub.cfg you think it is reading.  I've
> > hit this problem before - IIRC grub uses the grub.cfg from the *first*
> > place it finds one - this can even be a partition (or in my case a LV)
> > that is not used anywhere on any system.
> 
> That's it!  The working system is in (hd0,gpt1) and update-grub2 was 
> updating (hd0,gpt1)/boot/grub/grub.cfg. Grub2 was displaying the menu 
> according to (hd0,gpt2)/boot/grub/grub.cfg which hadn't changed since
> an earlier installation.

That earlier installation is presumably the bookworm that
wrote (hd0,gpt2)/boot/grub/grub.cfg with the Grub deb12u1,
which I pointed out in my first post, but wasn't confirmed
by your follow-up.

> Therefore booted into (hd0,gpt1), as usual, and execute "grub-install 
> /dev/sda". The fresh grub refers to (hd0,gpt1)/boot/grub/grub.cfg 
> which has the stanza from (hd0,gpt1)/etc/grub.d/40_custom as intended.
> 
> After that, a further problem.  The grub ls command didn't show the 
> USB attached drive containing the Void Linux system.  A Web search 
> found mention of grub command nativedisk which I added.  

I don't know anything about nativedisk or the distinctions between
various types of driver.

> cat /etc/grub.d/40_custom
> #!/bin/sh
> exec tail -n +3 $0
> # This file provides an easy way to add custom menu entries.  Simply type the
> # menu entries you want to add after this comment.  Be careful not to change
> # the 'exec tail' line above.
> #
> menuentry "Void linux"{
>   insmod part_gpt
>   insmod ext2
>   echo 'Grub is running nativedisk to allow access to a USB store.'
>   nativedisk
>   echo 'These disks are accessible.'
>   ls
>   echo 'Setting root part.'
>   set root='(usb2,gpt6)'
>   echo 'Booting Linux.'
>   linux /boot/vmlinuz-6.6.56_2 root=UUID=e5c7eb47-8d4c-49da-9038-09c27e8e8990 ro
>   echo    'Loading ramdisk.'
>   initrd  /boot/initramfs-6.6.56_2.img
> }
> 
> The USB attached drive was then reported by grub2 ls.  Then another 
> problem.  Appears the drive doesn't respond quickly enough for the 
> linux command to succeed.  Grub2 shows this.
> ...
> Booting Linux.
> error: error communication with USB Mass Storage device.
> Loading ramdisk.
> error: you need to load the kernel first.
> 
> Press any key to continue...
> 
> A bug in grub2 nativedisk?  The USB 2.0 adapter is too slow?  Replace 
> with a USB 3 adapter?
> 
> This setup is needed only to configure the USB connected system. When 
> working, the drive will be installed in another machine. Currently 
> speed isn't required.  Any ideas for a software solution?  

AIUI Grub needs to be small in order to fit in the nooks and cranies
where it secretes itself (unless you give it a BIOS Boot Partition).
I imagine that when Grub is installed, it makes sure it provides the
modules needed to communicate with all the partitions that it will
need to when it is asked to boot them, and perhaps no more.

But if you install Grub without running os-prober, it might not know
to add the appropriate modules in Void's menuentry. So I would try
booting into Grub, selecting the Void menuentry, typing E, and adding
insmod lines for usb… modules there are, before you exit and
type Return. Perhaps filesystem modules too.

OTO you could just let os-prober run when you build Grub and let it
do the job for you. Is there any reason why you don't want to run
os-prober? Sorry, I'm repeating myself.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]


#274103 — Re: [solved, partly] Re: Grub menu entry for a system on a second drive.

Frompeter@easthope.ca
Date2024-10-27 19:50 +0100
SubjectRe: [solved, partly] Re: Grub menu entry for a system on a second drive.
Message-ID<JCguS-4Dse-11@gated-at.bofh.it>
In reply to#274094
    From: David Wright <deblis@lionunicorn.co.uk>
    Date: Sun, 27 Oct 2024 09:56:45 -0500
> That earlier installation is presumably the bookworm that
> wrote (hd0,gpt2)/boot/grub/grub.cfg with the Grub deb12u1,
> which I pointed out in my first post, but wasn't confirmed
> by your follow-up.

Yes, the multiple details have confused me.

> I don't know anything about nativedisk or the distinctions between
> various types of driver.

The only documantation I've found is here.
https://www.gnu.org/software/grub/manual/grub/grub.html#nativedisk

"firmware disk drivers" means drivers in the machine BIOS?
"native ones" means drivers in Grub?
"native disk drives" appears to be a typo.  I read it as "native disk drivers".

Grub2 documentation needs work.

> OTO you could just let os-prober run when you build Grub and let it
> do the job for you. Is there any reason why you don't want to run
> os-prober? Sorry, I'm repeating myself.

A search of "os-prober security" finds several pages.  os-prober is 
disabled by default in Archlinux and other respected distributions.

For interest, I enabled os-prober again in /etc/default/grub and ran 
grub-install /dev/sda.  lsblk reports the USB connected /dev/sdc6 
where Void is installed.  Nevertheless the only stanza in 
/boot/grub/grub.cfg for Void is from my entry in 
/etc/grub.d/40_custom.  Os-prober tried and failed.

A bug in os-prober?  A problem with the HDD?  A problem with the 
SATA-USB2 adapter? A bug in grub2?

An interesting observation is that the USB-connected Void system boots 
with no snags when selected directly in the BIOS.  To me, that 
suggests a problem in grub2 or os-prober.

Rather than spend more time investigating, will put the HDD in the 
target machine and work there.  Remove some of the complications.

Regards,                ... P.


-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]


#274120 — Re: [solved, partly] Re: Grub menu entry for a system on a second drive.

FromGreg Wooledge <greg@wooledge.org>
Date2024-10-28 12:10 +0100
SubjectRe: [solved, partly] Re: Grub menu entry for a system on a second drive.
Message-ID<JCvNf-4QKV-3@gated-at.bofh.it>
In reply to#274103
On Sun, Oct 27, 2024 at 22:42:15 -0500, David Wright wrote:
> type
>   set -x
> before you run os-prober and
>   set +x
> afterwards, and track what it does.

os-prober is a script, so that won't work as written.  You'd either
need to modify os-prober (change the second line from "set -e" to
"set -ex" for example) and then run it; or do something like:

    script
    set -x
    source /usr/bin/os-prober
    exit

(That assumes your interactive shell is bash.)

[toc] | [prev] | [next] | [standalone]


#274230 — Re: [solved, partly] Re: Grub menu entry for a system on a second drive.

FromGreg Wooledge <greg@wooledge.org>
Date2024-11-01 12:10 +0100
SubjectRe: [solved, partly] Re: Grub menu entry for a system on a second drive.
Message-ID<JDXHr-5SSj-5@gated-at.bofh.it>
In reply to#274120
On Thu, Oct 31, 2024 at 23:10:22 -0500, David Wright wrote:
> On Mon 28 Oct 2024 at 07:08:12 (-0400), Greg Wooledge wrote:
> > On Sun, Oct 27, 2024 at 22:42:15 -0500, David Wright wrote:
> > > type
> > >   set -x
> > > before you run os-prober and
> > >   set +x
> > > afterwards, and track what it does.
> > 
> > os-prober is a script, so that won't work as written.  You'd either
> > need to modify os-prober (change the second line from "set -e" to
> > "set -ex" for example) and then run it; or do something like:
> > 
> >     script
> >     set -x
> >     source /usr/bin/os-prober
> >     exit
> > 
> > (That assumes your interactive shell is bash.)
> 
> I see what you mean. I guess one could make the shell explicit
> and then set x with:
> 
>   script
>   bash -x /usr/bin/os-prober
>   exit
> 
> (I can't remember where I saw that construction.)

Yeah, that would actually be better, because it doesn't assume anything
about your interactive shell.  Even better still would be
"sh -x /usr/bin/os-prober", since it's a #!/bin/sh script, not a bash
script.

[toc] | [prev] | [next] | [standalone]


#274131 — Re: [solved, partly] Re: Grub menu entry for a system on a second drive.

Frompeter@easthope.ca
Date2024-10-28 17:30 +0100
SubjectRe: [solved, partly] Re: Grub menu entry for a system on a second drive.
Message-ID<JCAMV-4TQK-1@gated-at.bofh.it>
In reply to#274103
    From: David Wright <deblis@lionunicorn.co.uk>
    Date: Sun, 27 Oct 2024 22:42:15 -0500
> Well, it could be because Void apparently isn't a glibc OS.

Thanks.  Haven't thought about that.

> You could check /usr/lib/os-probes/mounted/90linux-distro
> to see whether the first test would succeed. Or a lazy way:
> type
>   set -x
> before you run os-prober and
>   set +x
> afterwards, and track what it does. You'd probably want to
> capture the output as it could be voluminous; it looks for
> linux systems just about last.

You've lost me there.  Which first test?  Where is "set"?  

> Well, it's presumably not Grub, as you say you can boot Void
> from your handcrafted menuentry once you've booted into the
> correct grub.cfg.

The handcrafted Void stanza allowed booting 2 or 3 times.  In at 
least a dozen other instances it failed and Grub returned to the menu.

> BTW I forgot to mention, your Grub ls command, which you reported
> on earlier, will fail to see the Void OS because there's no
> insmod part_gpt command in the grub.cfg until you press Return
> on the Void menuentry. So that's ok for booting the Void entry,
> but up until that moment, Grub can't read GPT partition tables
> without the part_gpt. So type an  insmod part_gpt  command first,
> if you need to type  ls.

ls is in the stanza in 40_custom.
  ...
  nativedisk
  echo 'These disks are accessible.'
  ls
  echo 'Setting root part.'
  set root='(usb2,gpt6)'
  echo 'Booting Linux.'
  linux ...
The grub commands are executed one by one; correct?  (usb2,gpt6)
should appear in the output of ls before 'set root ...' is executed.

>> Rather than spend more time investigating, will put the HDD in the 
>> target machine and work there.

I hadn't realised there was one.

Yes.  I brought the disk from the "Void machine" and connected, via  
a USB 2.0 adapter, to a Debian system at home.  Here, installed
Void and worked on configuration.  Soon the "Void disk" will return 
to the "Void machine".

> BTW I assume your second disk, being GPT, has a BIOS Boot partition?

Correct.

> Or is this target machine going to boot with UEFI, in which case
> you need an EFI partition. 

The disk also has an EFI partition.  I couldn't make EFI boot succeed.   
Therefore set the "hidden" flag on the EFI part and fell back to BIOS 
boot.

> I think moving disks between differently
> booting machines can be "fun"; it's why my own disks typically have
> both a BIOS Boot partition and an EFI partition. The former is only
> 3MB and ends at sector 8191; the latter can be borrowed for swap
> in MBR machines.

Installing and configuring Void at home is convenient.  Will soon see what 
happens when the disk is in the machine where it belongs.

Thx,                        ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]


#274240 — Re: [solved, more] Re: Grub menu entry for a system on a second drive.

Frompeter@easthope.ca
Date2024-11-02 16:10 +0100
SubjectRe: [solved, more] Re: Grub menu entry for a system on a second drive.
Message-ID<JEnVg-6912-7@gated-at.bofh.it>
In reply to#274103
    From: peter@easthope.ca
    Date: 27 Oct 2024 11:26:12 -0700
> Rather than spend more time investigating, will put the HDD in the 
> target machine and work there.  Remove some of the complications.

Happened to connect a USB hub before dealing with the Void drive.  
Noticed the USB socket where the Void drive was connected had a black 
plastic contact carrier and another socket had a blue carrier. Blue is 
USB 3.  Black isn't?  So plugged the USB adapter with the Void drive 
into the blue socket.  Voila; Grub was able to boot the Void system 
reliably. Spent the better part of a day investigating when a USB plug 
just needed moving.  =8~/

In case anyone is interested, these topics remain.

* Why does the ThinkCentre have differing USB sockets?

* With the adapter labeled USB 2.0, why is plugging in USB 3 necessary 
to boot the external system?

* The Grub2 manual could explain more about USB and the nativedisk 
command. In fact, the manual needs work in many places.

Regards,                   ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]


#274263 — Re: [solved, more] Re: Grub menu entry for a system on a second drive.

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2024-11-04 05:50 +0100
SubjectRe: [solved, more] Re: Grub menu entry for a system on a second drive.
Message-ID<JEXcl-6uEZ-1@gated-at.bofh.it>
In reply to#274240
On Sat 02 Nov 2024 at 07:46:33 (-0700), peter@easthope.ca wrote:
>     From: peter@easthope.ca
>     Date: 27 Oct 2024 11:26:12 -0700
> > Rather than spend more time investigating, will put the HDD in the 
> > target machine and work there.  Remove some of the complications.
> 
> Happened to connect a USB hub before dealing with the Void drive.  
> Noticed the USB socket where the Void drive was connected had a black 
> plastic contact carrier and another socket had a blue carrier. Blue is 
> USB 3.  Black isn't?  So plugged the USB adapter with the Void drive 
> into the blue socket.  Voila; Grub was able to boot the Void system 
> reliably. Spent the better part of a day investigating when a USB plug 
> just needed moving.  =8~/
> 
> In case anyone is interested, these topics remain.
> 
> * Why does the ThinkCentre have differing USB sockets?

Well, the anecdote above suggests that one reason might be to offer
reliable ports for plugging USB2 devices into.

Using a USB2 device on USB3 slows the interface tenfold. I don't know
whether neighbouring USB3 sockets' speed can influence each other,
which would mean not mixing USB2 and USB3 devices on such sockets.

One obvious reason might be cost: USB3 sockets are more complex,
with 9 connections rather than 4, and there's the necessity to
support compatibility with USB2.

> * With the adapter labeled USB 2.0, why is plugging in USB 3 necessary 
> to boot the external system?

Who knows. You've got, what, a SATA disk connected to an adapter
connected to a hub connected to oldish computer? Or is the hub
separate? IDK. Anyway, are all these connectors in good condition?
Perhaps the sockets are a bit worn. Perhaps the compatibility
switching is unreliable. Perhaps it's mobo or firmware related.

I've got, or had, computers with USB ports that don't work with,
or boot from, certain sticks, and computers that only boot from
sticks in certain ports. It's par for the course.

> * The Grub2 manual could explain more about USB and the nativedisk 
> command. In fact, the manual needs work in many places.

Maintainers may need feedback about what and where needs attention.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]


#274435 — Re: [solved, more] Re: Grub menu entry for a system on a second drive.

Frompeter@easthope.ca
Date2024-11-10 04:00 +0100
SubjectRe: [solved, more] Re: Grub menu entry for a system on a second drive.
Message-ID<JH6lb-7S6U-3@gated-at.bofh.it>
In reply to#274263
The ThinkCentre has one blue and one black, as in the 2nd photo here.
https://en.wikipedia.org/wiki/USB#System_design

> * With the adapter labeled USB 2.0, why is plugging in USB 3 necessary 
> to boot the external system?

    From: David Wright <deblis@lionunicorn.co.uk>
    Date: Sun, 3 Nov 2024 22:43:19 -0600
Who knows. You've got, what, a SATA disk connected to an adapter ...

Correct.

> ... is the hub separate? 

Yes.  The hub is only for keyboard, mouse and charging a phone or 
camera.

Anyway, are all these connectors in good condition?

I'd need to investigate.  With the setup working now, examination of 
connectors is a low priority.

I've got, or had, computers with USB ports that don't work with, or 
boot from, certain sticks, and computers that only boot from sticks in 
certain ports. It's par for the course.

OK, thanks.

> Maintainers may need feedback about what and where [grub2 doc] needs 
> attention.

Added to my list.

                                         ... P.
                                         
-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]


#274281 — Re: [solved, more] Re: Grub menu entry for a system on a second drive.

FromDan Purgert <dan@djph.net>
Date2024-11-04 13:50 +0100
SubjectRe: [solved, more] Re: Grub menu entry for a system on a second drive.
Message-ID<JF4GR-6zct-1@gated-at.bofh.it>
In reply to#274240

[Multipart message — attachments visible in raw view] — view raw

On Nov 02, 2024, peter@easthope.ca wrote:
>     From: peter@easthope.ca
>     Date: 27 Oct 2024 11:26:12 -0700
> > Rather than spend more time investigating, will put the HDD in the 
> > target machine and work there.  Remove some of the complications.
> 
> Happened to connect a USB hub before dealing with the Void drive.  
> Noticed the USB socket where the Void drive was connected had a black 
> plastic contact carrier and another socket had a blue carrier. Blue is 
> USB 3.  Black isn't?  So plugged the USB adapter with the Void drive 
> into the blue socket.  Voila; Grub was able to boot the Void system 
> reliably. Spent the better part of a day investigating when a USB plug 
> just needed moving.  =8~/
> 
> In case anyone is interested, these topics remain.
> 
> * Why does the ThinkCentre have differing USB sockets?

USB3 is (was) expensive, so it's a cost-reducing thing.  People didn't
have all that much in the way of USB-3 devices, so why bother making
every port USB-3?

> 
> * With the adapter labeled USB 2.0, why is plugging in USB 3 necessary 
> to boot the external system?

USB3-only drive?  Error in the BIOS settings to only allow USB3 booting?

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

[toc] | [prev] | [next] | [standalone]


#274244 — Re: [solved, partly] Re: Grub menu entry for a system on a second drive.

FromMax Nikulin <manikulin@gmail.com>
Date2024-11-03 03:50 +0100
SubjectRe: [solved, partly] Re: Grub menu entry for a system on a second drive.
Message-ID<JEyQF-6fER-3@gated-at.bofh.it>
In reply to#274094
On 27/10/2024 21:56, David Wright wrote:
> On Sat 26 Oct 2024 at 20:55:11 (-0700), peter@easthope.ca wrote:
>> A Web search
>> found mention of grub command nativedisk which I added.
> 
> I don't know anything about nativedisk or the distinctions between
> various types of driver.
[...]
>>    nativedisk
>>    set root='(usb2,gpt6)'

I have tried the nativedisk command on a laptop configured to boot using 
UEFI. With default efidisk, ls reports hd0, hd1, hd2. After nativedisk 
they become usb0, ahci0, ahci1. When a USB stick is not inserted, hd0 is 
an internal hard drive. It seems nativedisk allows to make smaller a 
chance to use a wrong drive. Search for a specific UUID should be even 
more reliable.

I agree that nativedisk description in the GRUB manual is obscure.

In my case there is "Fast boot" config option in the firmware setup. It 
should be disabled to reliably boot from USB.

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user


csiph-web