Re: GRUB Error on 04-12 Images
Hi all,
I was installing from a USB thumb drive, which the installer
recongnized as 'sda', putting the first HD to 'sdb', and the second to
'sdc'. Once it is finished installing and the thumb drive has been
removed, however, it has no trouble booting from the first HD, now
recognized as 'sda', and the second as 'sdb'.
As for capitalization, I was typing everything out on my tablet, and it
autocorrected everything on its own, so I apologize for the confusion.
I'll try to copy syslog errors direct from the source in the future.
This GRUB "error" was a mistake on my part, so by all intents and
purposes, the installer is currently functioning fine. I'd say a more
pressing issue is that once xorg is installed, although still
functional, GRUB's background turns corrupted in appearance and
navigational performance becomes very slow to respond.
I apologize once again for any and all confusion. Thank you all for
your time.
Noah
On Mon, 2019-04-15 at 15:44 +0200, John Paul Adrian Glaubitz wrote:
> On 4/15/19 3:37 PM, Frank Scheiner wrote:
> > > Well, the above excerpt shows that the script tries to read an
> > > invalid
> > > path which might the result of one of the commands returning an
> > > error
> > > instead of a usable path. I haven't looked at the details yet.
> >
> > On second thought, the output prefixed with "Main-menu" is indeed
> > the
> > stderr output for the cat command in the (failing) check for the
> > mount
> > point requirement (see [1]). Not sure why it is printed after a
> > message
> > that should actually only come later. Maybe another typo or a
> > behaviour
> > of the installer environment I don't understand yet.
> >
> > [1]:
> > https://salsa.debian.org/frank-scheiner-guest/grub-installer/blob/support-grub-installs-on-newworld-powermacs-with-hfs-bootstrap/mk-hfs-bootstrap.sh#L20
> >
> > We can of course first check if the file we want to `cat` is
> > actually
> > there, but as the check will fail anyhow if it doesn't print the
> > exact
> > mount point we require, that might be overkill.
>
> We should also check whether it matches the regular expression of a
> valid
> device path.
>
> > > The point is that it should not try to read the path if the
> > > command before
> > > that failed.
> >
> > As said, I don't know why the `cat` stderr message is emitted after
> > the
> > exit message of `mk-hfs-boostrap.sh`.
>
> This can be a result of a redirect of stderr to stdout (i.e. 2 >&1).
>
> > > > > I assume that Noah typed that message instead of copying it
> > > > > (from the "string
> > > > > of numbers"), but that that "=dev=SDB=" looks very suspicious
> > > > > unless it is
> > > > > a copy-and-paste error. It definitely needs to be
> > > > > investigated.
> > > >
> > > > I'd say it's a copy-and-paste error and should read "=dev=sdb"
> > > > - also
> > > > because the identifier of the `mk-hfs-bootstrap.sh` output
> > > > starts with a
> > > > capital letter in what Noah wrote, and that is not the case in
> > > > the
> > > > source code.
> > >
> > > But "=dev=sdb" is not valid path specifier either unless I am
> > > missing
> > > something.
> >
> > It is, check `/var/lib/partman/devices` during an installation and
> > after
> > the partitioning step, e.g. for two disks it could look like this:
> >
> > ```
> > /var/lib/partman/devices # ls -la
> > drwxr-xr-x 4 root root 80 Apr 15 12:56 .
> > drwxr-xr-x 4 root root 380 Apr 15 12:57 ..
> > drwxr-xr-x 3 root root 160 Apr 15 12:56 =dev=sda
> > drwxr-xr-x 7 root root 240 Apr 15 12:57 =dev=sdb
> > ```
>
> Okay, that's really odd. I wonder where this comes from.
>
> > > > I see two options:
> > > >
> > > > * We either check that all requirements for the HFS bootstrap
> > > > partition
> > > > are met during the partitioning step and provide a dialogue
> > > > with the
> > > > requirements if not (like it was done for yaboot). Will only
> > > > work for
> > > > automatic partitioning (which still allows later user
> > > > changes!). You
> > > > already spoke about such an option.
> > >
> > > This needs to go in anyway to keep users from creating a broken
> > > partitioning setup when partitioning manually.
> > >
> > > > * Or we remove the last requirement (designated mount point is
> > > > `/boot/grub`) as described on [1]. Will work both for automatic
> > > > and
> > > > manual partitioning.
> > >
> > > I will have a closer look at the script again to figure out where
> > > the
> > > "=dev=sdb" comes from. That's clearly broken.
> >
> > See above.
>
> Yes, but where does that come from? It would be partman which
> produces
> such strange device names.
>
> Adrian
>
Reply to: