[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GRUB Error on 04-12 Images



On 4/15/19 15:27, John Paul Adrian Glaubitz wrote:
On 4/15/19 3:19 PM, Frank Scheiner wrote:
Mk-hfs-bootstrap: the HFS bootstrap partition couldn't be found. Cannot continue! Exiting.
Main-menu: cat: can't open /var/lib/partman/devices/=dev=SDB/string of numbers/mountpoint: no such file or directory
WARNING**: Configuring grub-installer failed with error code 1

Not sure, I'd say it behaves correctly:

In [1] I showed that one manually cannot create an HFS bootstrap
partition that is "marked" correctly for `mk-hfs-bootstrap.sh` to accept
it for use. I.e. the mount point requirement cannot be met when creating
the partition manually. This makes `mk-hfs-bootstrap.sh` exit with `1`
(see [2]), which in turn should make `grub-installer` exit with `1` (see
[3]), which it actually did.

But it could be that the message starting with "Main-menu: [...]" is
stderr fallout from `mk-hfs-bootstrap.sh`, so I maybe should direct
stderr to `/dev/null` in the command substitutions in the if clause
starting at [4]. OTOH I wonder why this would be printed out after the
message from "mk-hfs-boostrap.sh" which comes later.

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.


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`.

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
```


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.

Cheers,
Frank


Reply to: