David writes:
> Your lack of success is because the the command you used has designed
> behaviour to install the grub bootloader to the boot sector of
> /dev/sdd, and also install the grub files you listed into the current
> system /boot/grub (which was not on sdd at the time). That is the
> reaso
On Mon, 30 Nov 2020 at 14:53, Martin McCormick wrote:
> I typed sudo grub-install /dev/sdd. It ran for a few
> seconds, announced that grub was installed without any errors and
> exited.
> After looking at /dev/sdd1/grub and seeing no updated
> date stamps, I had a sinking feeling and looked a
I am going to respond to one of my earlier posts as it doesn't
help things at all to spread misinformation which I am guilty of,
here.
"Martin McCormick" writes:
> I appear to be using grub, not grub2.
No. It's grub2. Old Grub is now grub-legacy and is
probably a dead fly on s
Dan Ritter writes:
> Here's what you can do:
>
> On a good system, mount your drive. Let's pretend that it's
> recognized as /dev/sdg, and you have a /boot on /dev/sdg1 and
> a root partition on /dev/sdg2.
>
> ls -al /dev/disk/by-partuuid/| grep sdg
>
> will get you the partition UUIDs for that
Dan Ritter writes:
> in /boot/grub/menu.lst
>
> serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
> terminal serial
>
> (yes, that's two lines)
>
> I hope that helps.
>
> If you want the option of either serial or console access,
> replace the second line with
>
> terminal --timeout=
On Sat, Nov 21 2020 at 05:04:30 PM, "Martin McCormick"
wrote:
> Felix Miata writes:
>> Save yourself many keystrokes by using the symlinks in the root directory
>> instead
>> of the long-winded full version-named /boot/vmlinuz-4.19.0-5-686-pae
>
> This is wonderful to know and in the root o
Martin McCormick composed on 2020-11-21 17:04 (UTC-0600):
> I haven't found any uuid's that are different although I
> first thought I had as I looked at some links which had uuid's
> but they were good when I looked at the actual partition. It's
> easy to go down a rabbit hole if one doesn
Martin McCormick wrote:
> I appear to be using grub, not grub2. One of the
> articles I found had an example of how to use grub rescue that all
> works except, of course, for the actual booting of the kernel.
>
> There's an extra little wrinkle in that, as a computer
> warier who hap
Felix Miata writes:
> Save yourself many keystrokes by using the symlinks in the root directory
> instead
> of the long-winded full version-named /boot/vmlinuz-4.19.0-5-686-pae
This is wonderful to know and in the root or / directory of this
disk, there is
initrd.img, initrd.img.old, vmlinu
Martin McCormick composed on 2020-11-21 12:49 (UTC-0600):
> I appreciate the good suggestions I have gotten from
> several of you so far.
Save yourself many keystrokes by using the symlinks in the root directory
instead
of the long-winded full version-named /boot/vmlinuz-4.19.0-5-686-pae..
I did some duckduckgo-ing about grub rescue and found useful
things but am still dead in the water.
I appear to be using grub, not grub2. One of the
articles I found had an example of how to use grub rescue that all
works except, of course, for the actual booting of the kernel.
T
Dan Ritter writes:
> Here's what you can do:
>
> On a good system, mount your drive. Let's pretend that it's
> recognized as /dev/sdg, and you have a /boot on /dev/sdg1 and
> a root partition on /dev/sdg2.
>
> ls -al /dev/disk/by-partuuid/| grep sdg
>
> will get you the partition UUIDs for that
On Mon, Nov 16, 2020, 2:32 PM John Boxall wrote:
> You might be running in to the problem that the blkid that is expected
> may be changed during boot. As I am running into a similar problem on a
> system I upgraded to buster from stretch, this link might help:
>
>
> https://www.thegeekdiary.com/
On Tue, 17 Nov 2020 at 05:58, Martin McCormick wrote:
> If I look at grub.cfg and /etc/default/grub, everything
> looks as if it should work but it doesn't.
> Is there a safe way to mount this drive, possibly using
> chroot, re-run grub-config and get the drive bootable again?
Yes
Martin McCormick wrote:
> I have a usb device that lets one mount IDE and SATA
> drives that are outside the system so I pulled the sata drive
> which is the boot drive for the now dead system and plugged it in
> to the usb converter.
>
> the drive breezes through fsck and looks perfe
You might be running in to the problem that the blkid that is expected
may be changed during boot. As I am running into a similar problem on a
system I upgraded to buster from stretch, this link might help:
https://www.thegeekdiary.com/inconsistent-device-names-across-reboot-cause-mount-failure
I have goofed, I think. There is a serca-2000-vintage Dell
Optiplex that has been working fine up to yesterday when I did
the usual apt-get update followed by the apt-get upgrade on
buster. The update and upgrade appeared to work.
One of the things that got visited was grub and it was
th
17 matches
Mail list logo
