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

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

Can Grub Boot Through a USB Port on an Old PC?

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

Contents

  Can Grub Boot Through a USB Port on an Old PC? "Martin McCormick" <martin.m@suddenlink.net> - 2019-07-23 05:00 +0200
    Re: Can Grub Boot Through a USB Port on an Old PC? David Christensen <dpchrist@holgerdanske.com> - 2019-07-23 05:10 +0200
    Re: Can Grub Boot Through a USB Port on an Old PC? Patrick Bartek <nemommxiv@gmail.com> - 2019-07-23 05:40 +0200
    Re: Can Grub Boot Through a USB Port on an Old PC? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-07-23 07:20 +0200
      Re: Can Grub Boot Through a USB Port on an Old PC? "Martin McCormick" <martin.m@suddenlink.net> - 2019-07-23 17:40 +0200
        Re: Can Grub Boot Through a USB Port on an Old PC? Brian <ad44@cityscape.co.uk> - 2019-07-23 18:40 +0200
        Re: Can Grub Boot Through a USB Port on an Old PC? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-07-23 20:30 +0200
          Re: Can Grub Boot Through a USB Port on an Old PC? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-07-23 20:40 +0200
          Re: Can Grub Boot Through a USB Port on an Old PC? "Martin McCormick" <martin.m@suddenlink.net> - 2019-07-23 23:40 +0200
          Re: Can Grub Boot Through a USB Port on an Old PC? "Martin McCormick" <martin.m@suddenlink.net> - 2019-07-25 19:40 +0200
            Re: Can Grub Boot Through a USB Port on an Old PC? Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-25 20:20 +0200
              Re: Can Grub Boot Through a USB Port on an Old PC? Tixy <tixy@yxit.co.uk> - 2019-07-25 21:30 +0200
                Re: Can Grub Boot Through a USB Port on an Old PC? "Martin McCormick" <martin.m@suddenlink.net> - 2019-07-26 04:30 +0200
                  Re: Can Grub Boot Through a USB Port on an Old PC? Tixy <tixy@yxit.co.uk> - 2019-07-26 09:50 +0200

#211662 — Can Grub Boot Through a USB Port on an Old PC?

The PC is old enough that it can not natively boot via a serial
port but it might if grub knew about the bootable drive sitting
in one of the ports.

Thank you.

Martin McCormick

[toc] | [next] | [standalone]

#211663

On 7/22/19 7:53 PM, Martin McCormick wrote:
> The PC is old enough that it can not natively boot via a serial
> port but it might if grub knew about the bootable drive sitting
> in one of the ports.
> 
> Thank you.
> 
> Martin McCormick
> 

I have two Intel D865GBF motherboards (circa 2003) that can boot and run 
Stretch i386 when installed on a USB flash drive.


David

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

#211664

On Mon, 22 Jul 2019 21:53:12 -0500
"Martin McCormick" <martin.m@suddenlink.net> wrote:

> The PC is old enough that it can not natively boot via a serial
> port but it might if grub knew about the bootable drive sitting
> in one of the ports.

I had a computer from that era that couldn't.  Not wouldn't.  Couldn't.
Only boot devices were the hard drive and floppy.  Just because the USB
drive is bootable, doesn't mean the computer can boot off it. So, check
the user manual, if you can find one.

B

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

#211665

Le 23/07/2019 à 04:53, Martin McCormick a écrit :
> The PC is old enough that it can not natively boot via a serial
> port but it might if grub knew about the bootable drive sitting
> in one of the ports.

Do you mean that GRUB is installed on an internal drive ?
By default, GRUB relies on the BIOS disk services to access drives. But 
it also has native ATA and USB drivers which are not loaded by default. 
See the 'nativedisk' command.

Be aware that loading native drivers switches GRUB to a new different 
world : BIOS drives (hdX) will not be available any more and environment 
variables pointing at drives such as $root and $prefix will need to be 
updated with native drive names (ataX, usbX...).

Also, note that chainloading a bootloader (boot sector or ntldr) which 
relies on BIOS disk services will not work. Loading a kernel and 
initramfs should work if they include native USB drivers.

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

#211676

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
> Le 23/07/2019 à 04:53, Martin McCormick a écrit :

> Do you mean that GRUB is installed on an internal drive ?

Yes.

> By default, GRUB relies on the BIOS disk services to access drives. But it
> also has native ATA and USB drivers which are not loaded by default. See
> the 'nativedisk' command.
> 
> 
> 
> Be aware that loading native drivers switches GRUB to a new different 
> world
> : BIOS drives (hdX) will not be available any more and environment
> variables pointing at drives such as $root and $prefix will need to be
> updated with native drive names (ataX, usbX...).

Thanks again for the heads up.

> 
> Also, note that chainloading a bootloader (boot sector or ntldr) which
> relies on BIOS disk services will not work. Loading a kernel and initramfs
> should work if they include native USB drivers.

My thanks to all who responded.  In addition to your responses, I
later found a discussion  on one of the stackexchange sites
dealing with this same issue and was about to kick myself for
wasting everybody's time but it turned out every response touched
on a different aspect of the issue so it sounds like it will keep
me busy for awhile.

	It may turn out to be less of a headache to make it a
duel-boot system.  One boot would be the latest debian console
and the other would be Debian Wheezy as I have some PIC
microcontroller development tools that don't make in today's
world.

	This is a Dell Dimension motherboard with 1 GB of RAM and
a 600-MHZ Pentium which works very well in the command-line world
so I'll run it until the motherboard fries.  Yup! It's about 20
years old but no reason to trash it yet.

Martin WB5AGZ

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

#211683

On Tue 23 Jul 2019 at 10:37:46 -0500, Martin McCormick wrote:

> Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
> > Le 23/07/2019 à 04:53, Martin McCormick a écrit :
> 
> > Do you mean that GRUB is installed on an internal drive ?
> 
> Yes.
> 
> > By default, GRUB relies on the BIOS disk services to access drives. But it
> > also has native ATA and USB drivers which are not loaded by default. See
> > the 'nativedisk' command.
> > 
> > 
> > 
> > Be aware that loading native drivers switches GRUB to a new different 
> > world
> > : BIOS drives (hdX) will not be available any more and environment
> > variables pointing at drives such as $root and $prefix will need to be
> > updated with native drive names (ataX, usbX...).
> 
> Thanks again for the heads up.

I tried the nativedisk command of GRUB some years ago but cannot
recollect in any detail whether it solved my issue with three machines
unable to boot from a USB stick. I went back to using Plop with GRUB
either because nativedisk didn't help or because Plop is an easy to
implemennt solution.

  https://www.plop.at/

-- 
Brian.

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

#211685

Le 23/07/2019 à 17:37, Martin McCormick a écrit :
> 
> 	It may turn out to be less of a headache to make it a
> duel-boot system.  One boot would be the latest debian console
> and the other would be Debian Wheezy

If the system on the USB drive is GNU/Linux, you just need to put /boot 
on the internal drive so that GRUB can load them.

> as I have some PIC
> microcontroller development tools that don't make in today's
> world.

Did you consider chroot instead of multiboot ?

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

#211686

Le 23/07/2019 à 20:28, Pascal Hambourg a écrit :
> 
> If the system on the USB drive is GNU/Linux, you just need to put /boot 
> on the internal drive so that GRUB can load them.

Oops, my sentence was a bit incomplete.

You just need to put /boot on the internal drive so that GRUB can load 
the kernel image (vmlinuz) and the initramfs (initrd) from there.

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

#211695

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
> If the system on the USB drive is GNU/Linux, you just need to put /boot on
> the internal drive so that GRUB can load them.
> 
> 
> 
>     as I have some PIC
>     microcontroller development tools that don't make in today's
>     world.
> 
> 
> Did you consider chroot instead of multiboot ?

	Not until I read this message!

	I have used chroot a few times and know that the
directory is now the root of the jail you have made but I didn't
stop to think that this also means that while one is in that
jail, all the pathsare now relative to the bounds of the jail
including libraries and executables which also see only wheezy
libraries so any executables should be happy.  The binaries we
make with the assembler never execute on site but do so in the
tiny brains of the PIC processors.  The programming device
we use to flash the PIC eprom connects to a native serial port or
a usb-to-serial converter and if those work through the walls of
the jail, there should be no trouble.

	If the programmer still works, that is a winner and many
thanks.

Martin McCormick

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

#211733

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
> Did you consider chroot instead of multiboot ?

I have had some time to play with chroot and there is only 1
problem I have just discovered with everything else working
perfectly.

	What I did was use what would have been the wheezy boot
drive as follows:

	The only partition that could be used here was partition
1 which, on this system was /dev/sde1.

	I mounted /dev/sde1 to /mnt and used rsync to copy
everything it could including devices to /home/wheezy

rsync --devices -alHvbq /mnt/ /home/wheezy

	It appears to have done that and /dev/ttyUSB0 was there
so I tried to test it as user martin, not root as in "Safety,
first."

	When I tried to access the port, I got Permission denied
which means one isn't in the dialout group.  This always happens
if you forget to add yourself via usermod as root.

	I went backup to root while still in jail and commanded:

usermod -a -Gdialout martin

There was no complaint so I su'd back to martin and did groups martin.

	I was in all the groups one is put in by default when
creating a new account but no dialout.

	After trying a full logout from the jail, I did what
many criminals do and went right back in and tried groups martin
once again.

	No dialout and no complaint either.

	I did successfully compile a small PIC binary from source
with the old environment and compared it with a compile from 2016
and noticed that the binaries were different.  After saying a few
choice words, I checked a little further and noticed that both
were exactly the same size to the byte so I ran strings on each
binary and found or maybe rediscovered that gpasm which is the
PIC assembler puts a time and date stamp on each build you make
from source so I don't know for sure that the new build is
exactly the same but I would bet money it is.

	Anyway, usermod from jail fails quietly and I never get
added to dialout.

	Again thanks for the suggestion and any constructive
ideas are appreciated.

	Many thanks.

Martin McCormick

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

#211734

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

On Jo, 25 iul 19, 12:37:17, Martin McCormick wrote:
> 
> 	I mounted /dev/sde1 to /mnt and used rsync to copy
> everything it could including devices to /home/wheezy
> 
> rsync --devices -alHvbq /mnt/ /home/wheezy

You might want to try bind mounting /dev from the host system before 
chrooting.

mount -o bind /dev /home/wheezy/dev

/proc and /sys might also be needed for the chroot to work properly.

mount -t proc proc /home/wheezy/proc
mount -t sysfs sys /home/wheezy/sys


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#211735

On Thu, 2019-07-25 at 21:13 +0300, Andrei POPESCU wrote:
> On Jo, 25 iul 19, 12:37:17, Martin McCormick wrote:
> > 	I mounted /dev/sde1 to /mnt and used rsync to copy
> > everything it could including devices to /home/wheezy
> > 
> > rsync --devices -alHvbq /mnt/ /home/wheezy
> 
> You might want to try bind mounting /dev from the host system before 
> chrooting.
> 
> mount -o bind /dev /home/wheezy/dev
> 
> /proc and /sys might also be needed for the chroot to work properly.
> 
> mount -t proc proc /home/wheezy/proc
> mount -t sysfs sys /home/wheezy/sys
> 

I've used 'schroot' in the past for this sort of thing, let's you
configure what to mount and I believe either defaults or has examples
for the common things you're likely to need like /dev and /proc. I
don't remember the details as it's been quite some years since I used
it.

-- 
Tixy

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

#211738

Tixy <tixy@yxit.co.uk> writes:
> I've used 'schroot' in the past for this sort of thing, let's you
> configure what to mount and I believe either defaults or has examples
> for the common things you're likely to need like /dev and /proc. I
> don't remember the details as it's been quite some years since I used
> it.
	Thanks for this information.  I have installed schroot
as this seems to be the missing link I didn't know about.

	I knew one had to have all the resources turned on so to
speak and it looks like schroot  makes getting it right in this
century much more likely.

martin

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

#211745

On Thu, 2019-07-25 at 21:23 -0500, Martin McCormick wrote:
> Tixy <tixy@yxit.co.uk> writes:
> > I've used 'schroot' in the past for this sort of thing, let's you
> > configure what to mount and I believe either defaults or has
> > examples
> > for the common things you're likely to need like /dev and /proc. I
> > don't remember the details as it's been quite some years since I
> > used
> > it.
> 	Thanks for this information.  I have installed schroot
> as this seems to be the missing link I didn't know about.
> 
> 	I knew one had to have all the resources turned on so to
> speak and it looks like schroot  makes getting it right in this
> century much more likely.

This may, or may not, be useful to the sort of work you do, but I also
used it to run a Debian install for a different CPU, in my case an Arm
Debian install running on my x86 PC. I found that getting a PC to
emulate an Arm CPU was a lot quicker and more convenient than doing it
on the Arm single board computers I had. In such a setup, whilst the PC
is having to do lot's of extra works to emulate Arm instructions
for running user code, you are still using the PC's kernel, so disk i/o
is likely an order of magnitude or more faster, and you have available
all the PC's RAM, which is probably a lot more than the ARM board's.

If I remember correct, getting such a setup working was quite straight
forward. To be able to run foreign binaries I think you just need to
install package qemu-user-static and it's recommendation
binfmt-support, and after a quick google just now [1], there is
probably an emulation binary from that which needs copying into the Arm
chroot.

[1] https://wiki.debian.org/RaspberryPi/qemu-user-static

-- 
Tixy

[toc] | [prev] | [standalone]

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

csiph-web