Grub boot error with Deepin

Other than 35_deepin_gfxmode, everything seems exactly like the 'standard' manjaro grub.
I don't know what's in that 35_deepin_gfxmode that can override the usual 10_linux. I hope the authors of that (but your grub packages are manjaro's) grub know why they need to have that extra '35_deepin_gfxmode. It is never a good thing to mishmash up grub.d (that's the problem with grub-customizer). Even some distro modifications (of grub) are exasperating (like Fedora's) but at least their mechanism is consistent and we can know what to expect and can handle them.

You can take a look at 35_deepin_gfxmode (and I wonder where this comes from) but at best I can guess (without certainty - I am not a coder) what this tries to do. Maybe you can do better. Hopefully, some manjaro developer working on deepin can tell us.

I don't use deepin though I had tried the original non-distro version when it was new. Have never tried any deepin since.

But off-hand (and I don't like doing this (off-hand thingy), this 35_deepin_gfxmode seems 'wrong', like our 01_menu_auto_hide (not offhand - I tested thoroughly).

So, with this 35_deepin_gfxmode, I cannot say with certainty, what you should do.
If you have a 'pure' manjaro grub, at least I can be more certain.

I can be rash and tell you to remove 35_deepin_gfxmode and do the 'standard way' but I am still not sure if your other things (like 10_linux) are the 'standard' manjaro 10_linux.

That's saying a lot and I can appear too careful but unless I am sure (like shim keys are microsoft keys), I'd rather not take my chance with other people's system.

But tell us if what you do results in. Cheers.

Thank you so much @gohlip .
My Manjaro grub so far, it hasn't failed since the last changes.

Just for you to know here are the contents of some deepin grub files:

/etc/default/grub.d/10_deepin.cfg

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT DEEPIN_GFXMODE=\$DEEPIN_GFXMODE"

/etc/grub.d/35_deepin_gfxmode

#!/bin/sh
cat << EOF
insmod deepin_gfxmode
deepin_gfxmode
EOF
# ls /boot/grub/i386-pc/ | grep deepin
(no output)
# ls /boot/grub/i386-pc/
acpi.mod
adler32.mod
affs.mod
afs.mod
ahci.mod
all_video.mod
aout.mod
archelp.mod
ata.mod
at_keyboard.mod
backtrace.mod
bfs.mod
biosdisk.mod
bitmap.mod
bitmap_scale.mod
blocklist.mod
boot.img
boot.mod
boottime.mod
bsd.mod
bswap_test.mod
btrfs.mod
bufio.mod
cacheinfo.mod
cat.mod
cbfs.mod
cbls.mod
cbmemc.mod
cbtable.mod
cbtime.mod
chain.mod
cmdline_cat_test.mod
cmosdump.mod
cmostest.mod
cmp.mod
cmp_test.mod
command.lst
configfile.mod
core.img
cpio_be.mod
cpio.mod
cpuid.mod
crc64.mod
cryptodisk.mod
crypto.lst
crypto.mod
cs5536.mod
ctz_test.mod
datehook.mod
date.mod
datetime.mod
diskfilter.mod
disk.mod
div.mod
div_test.mod
dm_nv.mod
drivemap.mod
echo.mod
efiemu32.o
efiemu64.o
efiemu.mod
ehci.mod
elf.mod
eval.mod
exfat.mod
exfctest.mod
ext2.mod
extcmd.mod
f2fs.mod
fat.mod
file.mod
font.mod
freedos.mod
fshelp.mod
fs.lst
functional_test.mod
gcry_arcfour.mod
gcry_blowfish.mod
gcry_camellia.mod
gcry_cast5.mod
gcry_crc.mod
gcry_des.mod
gcry_dsa.mod
gcry_idea.mod
gcry_md4.mod
gcry_md5.mod
gcry_rfc2268.mod
gcry_rijndael.mod
gcry_rmd160.mod
gcry_rsa.mod
gcry_seed.mod
gcry_serpent.mod
gcry_sha1.mod
gcry_sha256.mod
gcry_sha512.mod
gcry_tiger.mod
gcry_twofish.mod
gcry_whirlpool.mod
gdb.mod
geli.mod
gettext.mod
gfxmenu.mod
gfxterm_background.mod
gfxterm_menu.mod
gfxterm.mod
gptsync.mod
gzio.mod
halt.mod
hashsum.mod
hdparm.mod
hello.mod
help.mod
hexdump.mod
hfs.mod
hfspluscomp.mod
hfsplus.mod
http.mod
iorw.mod
iso9660.mod
jfs.mod
jpeg.mod
keylayouts.mod
keystatus.mod
ldm.mod
legacycfg.mod
legacy_password_test.mod
linux16.mod
linux.mod
load.cfg
loadenv.mod
loopback.mod
lsacpi.mod
lsapm.mod
lsmmap.mod
ls.mod
lspci.mod
luks.mod
lvm.mod
lzopio.mod
macbless.mod
macho.mod
mda_text.mod
mdraid09_be.mod
mdraid09.mod
mdraid1x.mod
memdisk.mod
memrw.mod
minicmd.mod
minix2_be.mod
minix2.mod
minix3_be.mod
minix3.mod
minix_be.mod
minix.mod
mmap.mod
moddep.lst
modinfo.sh
morse.mod
mpi.mod
msdospart.mod
mul_test.mod
multiboot2.mod
multiboot.mod
nativedisk.mod
net.mod
newc.mod
nilfs2.mod
normal.mod
ntfscomp.mod
ntfs.mod
ntldr.mod
odc.mod
offsetio.mod
ohci.mod
part_acorn.mod
part_amiga.mod
part_apple.mod
part_bsd.mod
part_dfly.mod
part_dvh.mod
part_gpt.mod
partmap.lst
part_msdos.mod
part_plan.mod
part_sun.mod
part_sunpc.mod
parttool.lst
parttool.mod
password.mod
password_pbkdf2.mod
pata.mod
pbkdf2.mod
pbkdf2_test.mod
pcidump.mod
pci.mod
pgp.mod
plan9.mod
play.mod
png.mod
priority_queue.mod
probe.mod
procfs.mod
progress.mod
pxechain.mod
pxe.mod
raid5rec.mod
raid6rec.mod
random.mod
rdmsr.mod
read.mod
reboot.mod
regexp.mod
reiserfs.mod
relocator.mod
romfs.mod
scsi.mod
search_fs_file.mod
search_fs_uuid.mod
search_label.mod
search.mod
sendkey.mod
serial.mod
setjmp.mod
setjmp_test.mod
setpci.mod
sfs.mod
shift_test.mod
signature_test.mod
sleep.mod
sleep_test.mod
spkmodem.mod
squash4.mod
strtoull_test.mod
syslinuxcfg.mod
tar.mod
terminal.lst
terminal.mod
terminfo.mod
test_blockarg.mod
testload.mod
test.mod
testspeed.mod
tftp.mod
tga.mod
time.mod
trig.mod
tr.mod
truecrypt.mod
true.mod
udf.mod
ufs1_be.mod
ufs1.mod
ufs2.mod
uhci.mod
usb_keyboard.mod
usb.mod
usbms.mod
usbserial_common.mod
usbserial_ftdi.mod
usbserial_pl2303.mod
usbserial_usbdebug.mod
usbtest.mod
vbe.mod
verifiers.mod
vga.mod
vga_text.mod
video_bochs.mod
video_cirrus.mod
video_colors.mod
video_fb.mod
videoinfo.mod
video.lst
video.mod
videotest_checksum.mod
videotest.mod
wrmsr.mod
xfs.mod
xnu.mod
xnu_uuid.mod
xnu_uuid_test.mod
xzio.mod
zfscrypt.mod
zfsinfo.mod
zfs.mod
zstd.mod

As you pointed out, there is no deepin_gfxmode module in /boot/grub/i386-pc
I think not only it is safe to remove 35_deepin_gfxmode from /etc/grub.d but we should.
But you can try it and if something breaks, you can put it back (move it to somewhere else).
If you do that, make sure you comment out that DEEPIN_GFXMODE= in /etc/default/grub and do 'update-grub'.

Oh, as for reiserfs, this file system is listed in /boot/grub/x86_64-efi/fs.lst and /boot/grub/i386-pc/fs.lst. So it should be something that grub recognizes.

On boot, (sometimes) I still get the error message:

diskfilter writes are not supported.
(something like) can't write outside of 'hd0'

but now it does not have the:

file /boot/grub/i386-pc/deepin_gfxmode.mod
not found.
can't find command deepin_gfxmode.

The grub error: can't write outside of 'hd0' is something that I already had (sometimes) before this manjaro-architect Manjaro reinstall. But I never had diskfilter writes are not supported.

And also I never had the Grub error of:

error: unknown filesystem
grub rescue>

One change that I have done (during this last Manjaro reinstall) was changing my filesystem from ext4 (this was the filesystem of my Manjaro before this reinstall) to reiserfs (now all is reiserfs).

When I do grub-install ... it says:

...
nothing to be done
...

Because of this, can't this (grub behaviour) happened during my manjaro-architect grub reinstall, and my grub still have the information that my pc filesystem is ext4 (it is not, it is reiserfs now)?

Thank you so far for the help @gohlip

PS:

I found something that may be relevant.
I don't know if on /etc/default/grub my UUID of this line:

...
GRUB_CMDLINE_LINUX="cryptdevice=UUID=34a.......:cryptroot"
...

is correct. How can I check if this UUID is not wrong @gohlip ? Which command can give me the UUID that should be there, for me to check manually?

Not sure about encrypted. This is two ways for normal cases

blkid
inxi -Dpuo
# blkid
/dev/mmcblk1p1: UUID="812d1...." TYPE="crypto_LUKS" PARTUUID="1e...."
/dev/mapper/cryptroot: UUID="vPwO-3...." TYPE="LVM2_member"
/dev/mapper/vg-root: UUID="295e...." TYPE="reiserfs"
/dev/mapper/vg-home: UUID="7185...." TYPE="reiserfs"

(I have changed the UUID values above because I don't know if showing them may be a security risk)

which UUID above should I have in my /etc/default/grub (on the GRUB_CMDLINE_LINUX= line - see my post above) @AgentS ?

Better check Archwiki for encryption/LUKS setup on Grub.

It has to do with grubenv. I wrote:

First uncomment out ‘GRUB_SAVEDEFAULT’ and set 'GRUB_DEFAULT=0'
Then clean out grubenv as follows.

sudo rm /boot/grub/grubenv
sudo grub-editenv /boot/grub/grubenv create
sudo grub-editenv - set boot_success=0

Reminder, especially with our grub, make sure you have

GRUB_TIMEOUT_STYLE=menu

Not related to issue, but GRUB_TIMEOUT=0 is not good. Make that at least 5.

As for cryptroot uuid, - (oh, first I don't use encryption) - uuid before and after decryption are different. The decrypted UUID can be found at /etc/crypttab. You can check there.

This file only lists one UUID that is of the home partition. The root partition isn't listed :confused: .

Maybe this error is because my UEFI is on BIOS Legacy mode, because one time I tried to install Manjaro (like 5 years ago), the Manjaro Deepin didn't load with UEFI (on my PC - Acer Aspire E11). So then, my only solution was to put the UEFI in BIOS Legacy and haven't changed yet...

  1. Is there a possibility that Manjaro Deepin Grub may have improved (because 5 years UEFI didn't work) and UEFI in my PC may be working now? (I have posted this error, long time ago, in Uefi doesn't boot - it is the same PC :wink: )

  2. Or is it best to do what you have told me in the last post? (I'm a bit afraid, that it may mess up my grub)?

  3. Also, I have set up GRUB_TIMEOUT=0 because I don't want to have a grub menu on boot. Is there a way to set GRUB_TIMEOUT=5 and still not be presented with a grub menu on boot?

Thanks

Are you sure your root partition is encrypted? Perhaps @torvic can help here. I don't use encryption and he can tell where you can find the decrypted root UUID.

I personally (and I know I'm the minority) think that encryption should only be for data partitions and not put into fstab. It's okay that many will disagree with me. It's just a reminder to have a handy backup boot in case your bootloader fails. Not easy to boot a failed bootloader in an encrypted system. See my post above somewhere how to get a backup bootloader.

Yes, I realized you are in bios-legacy, not uefi; and that was due to the problem with your tied-in system to windows. But since it is working well in bios-legacy and there are no real benefits in uefi, I don't see any reason why you would want to try out uefi now (with the tied-in system you have).

Yes. Set

GRUB_TIMEOUT_STYLE=hidden

Again, GRUB_TIMEOUT=5 (or more) because if you want to to go to grub (to add parameter to resolve problems, for example) you can still press (keep tapping) 'esc' key to do it.
I personally like GRUB_TIMEOUT_STYLE=countdown - it shows a small countdown and you know (instead of guessing and missing it) when you can press 'esc' to go to grub. And you can have timeout at 3 instead of the minimum 5 I suggested. And it looks nice.

I need some more testing to see if everything is working right (with my GRUB).
I have done all the steps above (include the regeneration of grubenv).

1.

I still get the message: diskfilter writes are not supported. Press any key to continue... . But it doesn't keep me from booting. I believe this has nothing to do with LUKS encryption and something to do with the LVM that is inside LUKS.

2.

My GRUB_DEFAULT is set to 0 and I have uncommented GRUB_SAVEDEFAULT, but I wonder, should GRUB_SAVEDEFAULT be set to true or false @gohlip ? (right now I have it set to true)

In keeping updated my last post, I have set GRUB_SAVEDEFAULT=false.

Thank to this thread I not longer that this grub error messages.

diskfilter writes are not supported.

and

file /boot/grub/i386-pc/deepin_gfxmode.mod
not found.
can't find command deepin_gfxmode.

But I still want to tackle this last grub error that I get sometimes (and I never did get before) that is something like this:

error: unknown filesystem
Entering rescue mode...
grub rescue>

Suggestions? (I'm open to dd the disk grub boot record and resintalling grub - I guess I can do this without a live distro, inside my OS; but don't know how to do it. Maybe this could help? have no idea)

If we uncomment it out, the default is unset, meaning 'false'.
But I prefer to just uncomment it out.

‘GRUB_SAVEDEFAULT’

If this option is set to ‘true’, then, when an entry is selected, save it as a new default entry for use by future runs of GRUB. This is only useful if ‘GRUB_DEFAULT=saved’; it is a separate option because ‘GRUB_DEFAULT=saved’ is useful without this option, in conjunction with grub-set-default . Unset by default. This option relies on the environment block, which may not be available in all situations (see Environment block).

And at the 'Environment Block' section (grubenv)

For safety reasons, this storage is only available when installed on a plain disk (no LVM or RAID), using a non-checksumming filesystem (no ZFS), and using BIOS or EFI functions (no ATA, USB or IEEE1275).

So as I said, we shouldn't set grubenv for encryption, and in your case, LVM too.
But you said you've cleared it. Perhaps you need to look at your ‘GRUB_SAVEDEFAULT’. This also makes an entry in grubenv.

Now we've got this out of the way, have we removed (move it to another place) '35_deepin_gfxmode' from /etc/grub.d ? Looking at what it is in there, it also makes an entry in grubenv. Furthermore, as you noted, there is no deepin_gfxmode module in /boot/grub/i386-pc/. It should be removed.

As to reinstalling grub, at this stage, we do not need to do this yet. But if you do need to do it, there's a write up under [If grub is really messed up]without much hassle. But whatever you do, I think, now with more certainty after we've seen '35_deepin_gfxmode', that it should be removed.

[edit] - note that manjaro does not make a new /etc/default/grub if there is an existing one. It may make one under grub.pacnew which will not be used. I am not sure about /etc/grub.d but still best not to assume it will override the old one especially you have 35_deepin_gfxmode

$ cat /etc/grub.d/35_deepin_gfxmode 
#!/bin/sh
#cat << EOF
#insmod deepin_gfxmode
#deepin_gfxmode
#EOF

this should do it.

In the meantime I have reinstalled Grub using manjaro-architect. I think this was a mistake (only read your last post after reinstalling it :confused: )

I will do now (from my installed Manjaro):

update-grub
grub-mkconfig -o /boot/grub/grub.cfg
grub-install /dev/mmblk1

I dont know if (on grub-install) /dev/mmblk1 is the right device, or if should be /dev/mapper/vg-root
this is my lsblk:

NAME          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
mmcblk1       179:0    0 29,1G  0 disk  
└─mmcblk1p1   179:1    0 29,1G  0 part  
  └─cryptroot 254:0    0 29,1G  0 crypt 
    ├─vg-root 254:1    0   19G  0 lvm   /
    └─vg-home 254:2    0 10,1G  0 lvm   /home
mmcblk1boot0  179:8    0    4M  1 disk  
mmcblk1boot1  179:16   0    4M  1 disk  
zram0         253:0    0  1,9G  0 disk  [SWAP]

is it?

And also please comment on my steps on this post (to see if they are right or some unecessary) for me to learn. Thank you so much :slight_smile:

Now this, I really don't know (I don't use lvm, encryption). But if I have to guess, I think it is correct.
If others here can input to help, that will be good.

Good luck.

What does this do exactly @gohlip? And in which case it is needed?

It is resetting the environment block file, in case it may be messed with wrong values etc.
Grub-success is a variable for the incredible hidden grub function.

From gnu.org - Grub simple configuration

‘GRUB_TIMEOUT’
Boot the default entry this many seconds after the menu is displayed, unless a key is pressed. The default is ‘5’. Set to ‘0’ to boot immediately without displaying the menu, or to ‘-1’ to wait indefinitely.
If ‘GRUB_TIMEOUT_STYLE’ is set to ‘countdown’ or ‘hidden’, the timeout is instead counted before the menu is displayed.

In this thread:

Why did you said this @gohlip?

As petsam says, our grub by default has some values in grubenv (menu_hide) and it checks for it.
And in a convoluted way, if it finds there is a GRUB_TIMEOUT_STYLE= of any value, it stops checking. So that is to remove all values in grubenv.

Reminder that below has to be done too as GRUB_SAVEDEFAULT also puts in a value in grubenv.

In my testing of this new grub (quiet-grub) when it was introduced, and there were 3 iterations of it, in my f2fs and btrfs systems, I get the same error as you (btrfs and f2fs will have same problem as lvm and encryption) and the error disappears when grubenv was cleared.

And not mentioned is when you have 2 or more kernels, how are you going to boot different kernels to check if your current kernel has a problem?

A couple more few seconds for an important feature?

And even if we want to have a hidden grub, it is better to have GRUB_TIMEOUT_STYLE=hidden and remove the menu_hide grubenv value. Not only is the method better, it works faster too without checking grubenv, saving the couple seconds.

1 Like

Ok @gohlip. I understand it is a Manjaro special case. Thank you so much for the info

1 Like