Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-02-26 Thread Vincent Lefevre 
On 2019-02-26 15:20:10 +, Colin Watson wrote:
> On Tue, Feb 26, 2019 at 04:01:33PM +0100, Vincent Lefevre wrote:
> > On 2019-02-26 12:44:41 +, Colin Watson wrote:
> > > Of course, the grub-pc maintainer script doesn't know either.  All it
> > > has available to it is a /dev/disk/by-id/ path that no longer points to
> > > a disk.  The case I had in mind when writing that code, and I think
> > > almost certainly the overwhelmingly common case, is where the disk in
> > > question has been removed; the edge case that we have here is where the
> > > disk in question is still installed but its supposedly fixed ID has
> > > changed.
> > 
> > But note that even in the case where the disk has been removed, it
> > could also be a temporary removal (either physical, or virtual, with
> > VM's). So, it is also important to preserve the information in this
> > case.
> 
> It's moot, since I think it winds up essentially the same as the work I
> did for your bug.

Yes, I think that the fix is OK in practice (for whatever cause
of an "orphan" /dev/disk/by-id/ path). Thanks.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-02-26 Thread Colin Watson 
On Tue, Feb 26, 2019 at 04:01:33PM +0100, Vincent Lefevre wrote:
> On 2019-02-26 12:44:41 +, Colin Watson wrote:
> > Of course, the grub-pc maintainer script doesn't know either.  All it
> > has available to it is a /dev/disk/by-id/ path that no longer points to
> > a disk.  The case I had in mind when writing that code, and I think
> > almost certainly the overwhelmingly common case, is where the disk in
> > question has been removed; the edge case that we have here is where the
> > disk in question is still installed but its supposedly fixed ID has
> > changed.
> 
> But note that even in the case where the disk has been removed, it
> could also be a temporary removal (either physical, or virtual, with
> VM's). So, it is also important to preserve the information in this
> case.

It's moot, since I think it winds up essentially the same as the work I
did for your bug.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-02-26 Thread Vincent Lefevre 
On 2019-02-26 12:44:41 +, Colin Watson wrote:
> Of course, the grub-pc maintainer script doesn't know either.  All it
> has available to it is a /dev/disk/by-id/ path that no longer points to
> a disk.  The case I had in mind when writing that code, and I think
> almost certainly the overwhelmingly common case, is where the disk in
> question has been removed; the edge case that we have here is where the
> disk in question is still installed but its supposedly fixed ID has
> changed.

But note that even in the case where the disk has been removed, it
could also be a temporary removal (either physical, or virtual, with
VM's). So, it is also important to preserve the information in this
case.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-02-26 Thread Colin Watson 
FWIW, the debconf bug that cut off the message has been fixed (in
1.5.70, although it required a follow-up fix in 1.5.71).

On Sat, Jan 19, 2019 at 11:49:54AM +0100, Vincent Lefevre wrote:
> On 2019-01-12 13:33:35 +, Colin Watson wrote:
> > I can see the argument that it might be convenient to have configuration
> > that effectively says "install to this device if it exists, otherwise
> > continue anyway"; but such a configuration may mean that the GRUB image
> > on disk that you might in fact attempt to boot from will end up being
> > incompatible with the rest of /boot/grub/ and thus cause a failure to
> > boot even though the postinst pretended everything is fine!
> > Disregarding this kind of configuration error can have grave
> > consequences of its own.  In any case, even if it might be convenient to
> > have such a configuration, I won't accept that part of the issue as a
> > grave bug.
> 
> I meant that the issue was that the user may not have remember
> or even known where GRUB was installed (this was my case, and
> I could find the information just because I keep track of the
> changes of config.dat). This makes the problem unfixable without
> risking to erase some data.

Of course, the grub-pc maintainer script doesn't know either.  All it
has available to it is a /dev/disk/by-id/ path that no longer points to
a disk.  The case I had in mind when writing that code, and I think
almost certainly the overwhelmingly common case, is where the disk in
question has been removed; the edge case that we have here is where the
disk in question is still installed but its supposedly fixed ID has
changed.

I think what I'm going to do here is as follows: if the answer to
grub-pc/install_devices_disks_changed is empty, then don't copy it to
grub-pc/install_devices (and still do the usual thing of asking if
you're really sure that you don't want to install GRUB to any devices).
This will have the effect that if you don't positively select a new disk
to install to, as in your case, then the old configuration information
will remain untouched and the same question will be asked again the next
time grub-pc is configured.

This isn't completely ideal: it's a little bit hacky, and it would be
nice if the description of grub-pc/install_devices_disks_changed
explained this workflow (but it's really too late to be introducing new
translatable text for buster at this point).  However, it's the best
realistic solution I can think of, it's a pretty small change, and I
expect this edge case to continue to be rare in any event.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-01-19 Thread Vincent Lefevre 
On 2019-01-12 13:33:35 +, Colin Watson wrote:
> On Sat, Jan 12, 2019 at 02:11:25PM +0100, Vincent Lefevre wrote:
> > On 2019-01-12 10:36:02 +, Colin Watson wrote:
> > > The ID changing is presumably the systemd bug you mentioned, and that
> > > seems to be the grave part of this.
> > 
> > Actually, I think that the fact that grub-pc changes the configuration
> > and loses the previous one is a grave bug too (even though it is
> > caused by the udev bug). There should have been a way for the user to
> > keep the previous configuration so that nothing gets broken due to
> > temporary issues.
> 
> I'm not at all sure that I agree.  The configuration in question exists
> in order to tell the postinst which devices it should run grub-install
> on.  If the device does not exist, it obviously isn't possible to run
> grub-install on it.
> 
> I can see the argument that it might be convenient to have configuration
> that effectively says "install to this device if it exists, otherwise
> continue anyway"; but such a configuration may mean that the GRUB image
> on disk that you might in fact attempt to boot from will end up being
> incompatible with the rest of /boot/grub/ and thus cause a failure to
> boot even though the postinst pretended everything is fine!
> Disregarding this kind of configuration error can have grave
> consequences of its own.  In any case, even if it might be convenient to
> have such a configuration, I won't accept that part of the issue as a
> grave bug.

I meant that the issue was that the user may not have remember
or even known where GRUB was installed (this was my case, and
I could find the information just because I keep track of the
changes of config.dat). This makes the problem unfixable without
risking to erase some data.

> Note that temporary issues of this kind are extremely rare; this is the
> first of its kind that I can recall hearing about.  By contrast, it's
> quite common for people to accidentally end up with a boot sector that
> they thought was being updated when it in fact wasn't.  It makes a lot
> more sense for the GRUB maintainer scripts to prioritise dealing with
> the latter situation than the former.  So I'm happy to try to improve
> the way the maintainer scripts responded here, but not in a way that
> results in silently ignoring missing devices.
> 
> If the dialog box hadn't been cut off in a way that made it non-obvious
> that GRUB needed you to select devices to install to, I don't think you
> would have ended up in this situation.

I don't think so. I think that I would have chosen to let the new
version of GRUB uninstalled for the moment (just like what I actually
did), because I did not know where to install it. Same loss of
information. The only difference would have been that the message
would have been clearer.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-01-18 Thread François Revol 
Hi,
I also got this message and after an hour and more than 20 opened
Firefox tabs of searching where in the GRUB configuration files it could
be I ended up digging the package files to discover it was in debconf.

I think this should be documented on the wiki page at least…

And probably this message should list the existing values to give a clue.

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-01-12 Thread Colin Watson 
On Sat, Jan 12, 2019 at 02:11:25PM +0100, Vincent Lefevre wrote:
> On 2019-01-12 10:36:02 +, Colin Watson wrote:
> > The ID changing is presumably the systemd bug you mentioned, and that
> > seems to be the grave part of this.
> 
> Actually, I think that the fact that grub-pc changes the configuration
> and loses the previous one is a grave bug too (even though it is
> caused by the udev bug). There should have been a way for the user to
> keep the previous configuration so that nothing gets broken due to
> temporary issues.

I'm not at all sure that I agree.  The configuration in question exists
in order to tell the postinst which devices it should run grub-install
on.  If the device does not exist, it obviously isn't possible to run
grub-install on it.

I can see the argument that it might be convenient to have configuration
that effectively says "install to this device if it exists, otherwise
continue anyway"; but such a configuration may mean that the GRUB image
on disk that you might in fact attempt to boot from will end up being
incompatible with the rest of /boot/grub/ and thus cause a failure to
boot even though the postinst pretended everything is fine!
Disregarding this kind of configuration error can have grave
consequences of its own.  In any case, even if it might be convenient to
have such a configuration, I won't accept that part of the issue as a
grave bug.

Note that temporary issues of this kind are extremely rare; this is the
first of its kind that I can recall hearing about.  By contrast, it's
quite common for people to accidentally end up with a boot sector that
they thought was being updated when it in fact wasn't.  It makes a lot
more sense for the GRUB maintainer scripts to prioritise dealing with
the latter situation than the former.  So I'm happy to try to improve
the way the maintainer scripts responded here, but not in a way that
results in silently ignoring missing devices.

If the dialog box hadn't been cut off in a way that made it non-obvious
that GRUB needed you to select devices to install to, I don't think you
would have ended up in this situation.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-01-12 Thread Colin Watson 
On Sat, Jan 12, 2019 at 02:00:36PM +0100, Vincent Lefevre wrote:
> On 2019-01-12 10:36:02 +, Colin Watson wrote:
> > The rest of the bug is figuring out why the dialog box was
> > malformed. Perhaps it's because the long ID of /dev/dm-0 caused it
> > to overflow, and debconf somehow decided to display an oversized
> > dialog rather than truncating or wrapping or whatever? That seems to
> > me to be a debconf bug rather than something that should be worked
> > around in grub-pc, though.
> 
> I'm wondering. The paragraphs that came before the text with the
> long ID were wrapped. Was this wrapping done by grub-pc or debconf?
> If the former, I assume that it is grub-pc's responsibility to do
> the wrapping.

The wrapping is done by debconf.  I think this must be a debconf bug,
but I'll need to do some experimentation.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-01-12 Thread Vincent Lefevre 
On 2019-01-12 10:36:02 +, Colin Watson wrote:
> The ID changing is presumably the systemd bug you mentioned, and that
> seems to be the grave part of this.

Actually, I think that the fact that grub-pc changes the configuration
and loses the previous one is a grave bug too (even though it is
caused by the udev bug). There should have been a way for the user to
keep the previous configuration so that nothing gets broken due to
temporary issues.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-01-12 Thread Vincent Lefevre 
On 2019-01-12 10:36:02 +, Colin Watson wrote:
> >   * grub-pc doesn't let me install GRUB (I assume the new version)
> > while this was normally needed.
> >   * The change in config.dat seems to imply that GRUB changed the
> > configuration in my back.
> 
> grub-pc.postinst detected that the disk's ID changed, and offered you a
> choice of devices to install to instead since when the ID changes it has
> no safe way to proceed automatically.  You didn't select any of those
> devices, perhaps because most of the checkbox was cut off, and so there
> was nothing further that grub-pc.postinst could do except warn you about
> the situation.

Indeed, since the checkbox was cut off and the corresponding
information wasn't in the message text either, I did not know
that there was something to select.

> The ID changing is presumably the systemd bug you mentioned, and that
> seems to be the grave part of this.

I suppose that this part has now been fixed:

systemd (240-3) unstable; urgency=medium
[...]
  * libudev-util: Make util_replace_whitespace() read only len characters.
Fixes a regression where /dev/disk/by-id/ names had additional
underscores.
[...]
 -- Michael Biebl   Wed, 09 Jan 2019 18:40:57 +0100

> The rest of the bug is figuring out why the dialog box was
> malformed. Perhaps it's because the long ID of /dev/dm-0 caused it
> to overflow, and debconf somehow decided to display an oversized
> dialog rather than truncating or wrapping or whatever? That seems to
> me to be a debconf bug rather than something that should be worked
> around in grub-pc, though.

I'm wondering. The paragraphs that came before the text with the
long ID were wrapped. Was this wrapping done by grub-pc or debconf?
If the former, I assume that it is grub-pc's responsibility to do
the wrapping.

Also note that enlarging the terminal window and having the dialog
redisplayed (by going to the next message and back) did not solve
the issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-01-12 Thread Colin Watson 
Control: found grub-pc/2.02+dfsg1-9

On Sat, Jan 12, 2019 at 02:06:47AM +0100, Vincent Lefevre wrote:
> Control: severity -1 grave
> 
> Raising to grave since:

I'm marking this as present in the version in testing (even though I'm
not entirely convinced it's a bug in the GRUB packaging at all), because
none of this has changed at all since the version in testing and so it
doesn't need to block migration of an upload that fixes two other RC
bugs while we investigate this one.

>   * grub-pc doesn't let me install GRUB (I assume the new version)
> while this was normally needed.
>   * The change in config.dat seems to imply that GRUB changed the
> configuration in my back.

grub-pc.postinst detected that the disk's ID changed, and offered you a
choice of devices to install to instead since when the ID changes it has
no safe way to proceed automatically.  You didn't select any of those
devices, perhaps because most of the checkbox was cut off, and so there
was nothing further that grub-pc.postinst could do except warn you about
the situation.

The ID changing is presumably the systemd bug you mentioned, and that
seems to be the grave part of this.  The rest of the bug is figuring out
why the dialog box was malformed.  Perhaps it's because the long ID of
/dev/dm-0 caused it to overflow, and debconf somehow decided to display
an oversized dialog rather than truncating or wrapping or whatever?
That seems to me to be a debconf bug rather than something that should
be worked around in grub-pc, though.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-01-11 Thread Vincent Lefevre 
On 2019-01-12 01:49:10 +0100, Vincent Lefevre wrote:
> Text is missing on the left. Moreover, I don't know why I get such
> a message (I haven't changed anything).

For the message itself, it is probably a consequence of this bug:

  https://github.com/systemd/systemd/issues/11264

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-01-11 Thread Vincent Lefevre 
Control: severity -1 grave

Raising to grave since:
  * grub-pc doesn't let me install GRUB (I assume the new version)
while this was normally needed.
  * The change in config.dat seems to imply that GRUB changed the
configuration in my back.

On 2019-01-12 01:49:10 +0100, Vincent Lefevre wrote:
> Package: grub-pc
> Version: 2.02+dfsg1-10
> Severity: important
> 
> When upgrading the grub packages, I got the following message:
> 
> ─┤ Configuring grub-pc 
> ├
> RUB boot loader was previously installed to a disk that is no
> r present, or whose unique identifier has changed for some reason.
>  important to make sure that the installed GRUB core image stays in
> with GRUB modules and grub.cfg. Please check again to make sure
> GRUB is written to the appropriate boot devices.
> 
> u're unsure which drive is designated as boot drive by your BIOS,
>  often a good idea to install GRUB to all of them.
> 
>  it is possible to install GRUB to partition boot records as well,
> ome appropriate partitions are offered here. However, this forces
> to use the blocklist mechanism, which makes it less reliable, and
> fore is not recommended.
> 
> install devices:
> 
> ] /dev/dm-0 (511850 MB; LVM PV RaDD9Y-cDSq-kdoy-fYKY-9eP0-kLkp-M1wVYw on 
> /dev/dm
> ] /dev/sda (512110 MB; MTFDDAK512MAY-1AE1ZABHA___)
> ] - /dev/sda1 (254 MB; /boot)
> ] /dev/dm-1 (49 MB; zira--vg-root)
> 
> 
>  

After doing , I got another message, and the only thing I could
do was to continue without installing GRUB (otherwise, I was sent
back to the above message). The config.dat file changed in the
following way, which seems wrong:

 Name: grub-pc/install_devices
 Template: grub-pc/install_devices
-Value: /dev/disk/by-id/ata-MTFDDAK512MAY-1AE1ZABHA_15060EBA71EE
+Value: 
 Owners: grub-pc
 Flags: seen
 Variables:
  CHOICES = /dev/dm-0 (511850 MB; LVM PV RaDD9Y-cDSq-kdoy-fYKY-9eP0-kLkp-M1wVYw 
on /dev/dm-0), /dev/sda (512110 MB; MTFDDAK512MAY-1AE1ZABHA), - /dev/sda1 (254 
MB; /boot), /dev/dm-1 (49 MB; zira--vg-root)
  RAW_CHOICES = /dev/disk/by-id/dm-name-sda5_crypt, 
/dev/disk/by-id/ata-MTFDDAK512MAY-1AE1ZABHA_15060EBA71EE, 
/dev/disk/by-id/ata-MTFDDAK512MAY-1AE1ZABHA_15060EBA71EE-part1, 
/dev/disk/by-id/dm-name-zira--vg-root
 
 Name: grub-pc/install_devices_disks_changed
 Template: grub-pc/install_devices_disks_changed
+Value: 
 Owners: grub-pc
+Flags: seen
+Variables:
+ CHOICES = /dev/dm-0 (511850 MB; LVM PV RaDD9Y-cDSq-kdoy-fYKY-9eP0-kLkp-M1wVYw 
on /dev/dm-0), /dev/sda (512110 MB; MTFDDAK512MAY-1AE1ZABHA___), - /dev/sda1 
(254 MB; /boot), /dev/dm-1 (49 MB; zira--vg-root)
+ RAW_CHOICES = /dev/disk/by-id/dm-name-sda5_crypt, 
/dev/disk/by-id/ata-MTFDDAK512MAY-1AE1ZABHA15060EBA71EE, 
/dev/disk/by-id/ata-MTFDDAK512MAY-1AE1ZABHA15060EBA71EE-part1, 
/dev/disk/by-id/dm-name-zira--vg-root
 
 Name: grub-pc/install_devices_empty
 Template: grub-pc/install_devices_empty
-Value: false
+Value: true
 Owners: grub-pc
+Flags: seen

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

2019-01-11 Thread Vincent Lefevre 
Package: grub-pc
Version: 2.02+dfsg1-10
Severity: important

When upgrading the grub packages, I got the following message:

─┤ Configuring grub-pc ├
RUB boot loader was previously installed to a disk that is no
r present, or whose unique identifier has changed for some reason.
 important to make sure that the installed GRUB core image stays in
with GRUB modules and grub.cfg. Please check again to make sure
GRUB is written to the appropriate boot devices.

u're unsure which drive is designated as boot drive by your BIOS,
 often a good idea to install GRUB to all of them.

 it is possible to install GRUB to partition boot records as well,
ome appropriate partitions are offered here. However, this forces
to use the blocklist mechanism, which makes it less reliable, and
fore is not recommended.

install devices:

] /dev/dm-0 (511850 MB; LVM PV RaDD9Y-cDSq-kdoy-fYKY-9eP0-kLkp-M1wVYw on /dev/dm
] /dev/sda (512110 MB; MTFDDAK512MAY-1AE1ZABHA___)
] - /dev/sda1 (254 MB; /boot)
] /dev/dm-1 (49 MB; zira--vg-root)


 

Text is missing on the left. Moreover, I don't know why I get such
a message (I haven't changed anything).

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/zira--vg-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda1 /boot ext2 rw,relatime,block_validity,barrier,user_xattr,acl,stripe=4 
0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="${saved_entry}"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
7b3de7fd-236a-47f6-bb85-64831a06ca1f
else
  search --no-floppy --fs-uuid --set=root 7b3de7fd-236a-47f6-bb85-64831a06ca1f
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=1024x768 640x480
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=POSIX
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
7b3de7fd-236a-47f6-bb85-64831a06ca1f
else
  search --no-floppy --fs-uuid --set=root 7b3de7fd-236a-47f6-bb85-64831a06ca1f
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=keep
export linux_gfx_mode
menuentry 'Debian GNU/Linux, with Linux 4.19.0-1-amd64' --class debian --class 
gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.19.0-1-amd64-advanced-30a1ad7d-49ca-4b60-91d5-58f6f63d1c8e' {
savedefault
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1