Installation stuck on grub install

[Gorštak]

you might try to mount a partition before running os-prober, e.g. mount with Thunar file manager by selecting any partition on that drive.

There is some strange behavior with sdb on MX. I can't mount any of its partitions in Thunar. I don't think its idle, i was using those partitions less than 3 min ago while booted in Debian, surely it takes more to put it in sleep.

[j2mcgreg]

What does your set-up utility (bios) say about the smart status for sdb?

[fehlix]

There is some strange behavior with sdb on MX. I can't mount any of its partitions in Thunar.

Does this behavior also happen when booting LiveUSB?

[Gorštak]

What does your set-up utility (bios) say about the smart status for sdb?

There are no smart status related items in my bios.
GSmartControl shows it as a unknown model.

Code: Select all

 dmesg | tail
[ 1157.996285] ata1: lost interrupt (Status 0x0)
[ 1158.774418] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1158.774433] ata1.01: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 1158.819049] ata1.00: configured for UDMA/133
[ 1158.821924] ata1.01: configured for UDMA/33
[ 1189.228271] ata1: lost interrupt (Status 0x0)
[ 1190.006425] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1190.006440] ata1.01: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 1190.051012] ata1.00: configured for UDMA/133
[ 1190.054028] ata1.01: configured for UDMA/33

Does this behavior also happen when booting LiveUSB?

Yes, same thing on Live boot

Code: Select all

Error mounting /dev/sdb3 at /media/demo/manjaro: Command-line `mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/sdb3" "/media/demo/manjaro"' exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/sdb3,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Code: Select all

dmesg | tail
[  297.078365] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  297.078381] ata1.01: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  297.122931] ata1.00: configured for UDMA/133
[  297.125708] ata1.01: configured for UDMA/133
[  297.125846] sd 0:0:1:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  297.125851] sd 0:0:1:0: [sdb] tag#0 Sense Key : Illegal Request [current] 
[  297.125856] sd 0:0:1:0: [sdb] tag#0 Add. Sense: Unaligned write command
[  297.125861] sd 0:0:1:0: [sdb] tag#0 CDB: Read(10) 28 00 09 60 08 02 00 00 02 00
[  297.125864] print_req_error: I/O error, dev sdb, sector 157288450
[  297.125947] EXT4-fs (sdb3): unable to read superblock

[fehlix]

Code: Select all

[  297.125947] EXT4-fs (sdb3): unable to read superblock

Try to repair if possile: Reboot with MX LiveUSB
1 Check physical health of the drive with Gsmartcontrol
run selft-test : short self test or extended (last long!).

2 Check filesystem example partion /dev/sdb3 dry run with:

Code: Select all

  fsck.ext4 -nv /dev/sdb3  

If any message about bad superblock issues try to repair.
First we need to find the backup superblocks:

Code: Select all

dumpe2fs /dev/sdb3 | grep superblock

Output will look like this:

Code: Select all

dumpe2fs /dev/sdb3 | grep superblock
mpe2fs 1.43.4 (31-Jan-2017)
Primary superblock at 0, Group descriptors at 1-4
Backup superblock at 32768, Group descriptors at 32769-32772
Backup superblock at 98304, Group descriptors at 98305-98308
Backup superblock at 163840, Group descriptors at 163841-163844
Backup superblock at 229376, Group descriptors at 229377-229380
Backup superblock at 294912, Group descriptors at 294913-294916
Backup superblock at 819200, Group descriptors at 819201-819204
Backup superblock at 884736, Group descriptors at 884737-884740
Backup superblock at 1605632, Group descriptors at 1605633-1605636
Backup superblock at 2654208, Group descriptors at 2654209-2654212
Backup superblock at 4096000, Group descriptors at 4096001-4096004
Backup superblock at 7962624, Group descriptors at 7962625-7962628
Backup superblock at 11239424, Group descriptors at 11239425-11239428

Verfiy superblock position and size with testdisk :

Code: Select all

testdisk /dev/sdb

Navigate:
-> [ Proceed ] -> Intel/PC (for MSDOS partions table )
or-> EFI GPT (for GPT partion table)
-> [ Advanced ]

Code: Select all

TestDisk 7.1-WIP, Data Recovery Utility, June 2018
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/sdb - 4000 GB / 3726 GiB - CHS 486401 255 63

     Partition                  Start        End    Size in sectors
  1 P Linux filesys. data         2048  125831167  125829120
  2 P Linux filesys. data    125839360  251668479  125829120
> 3 P Linux filesys. data    251676672  377505791  125829120
  4 P Linux filesys. data    377513984  503343103  125829120
  5 P Linux filesys. data    503351296  629180415  125829120
  6 P Linux filesys. data    629188608 5600055295 4970866688
  9 P Linux filesys. data   5600063488 7747530751 2147467264
  7 P Linux Swap            7747538944 7814029311   66490368 [swap]
  8 P Unknown               7814033408 7814035455       2048 [bios_grub]

 [  Type  ] >[Superblock]  [  List  ]  [Image Creation]  [  Quit  ]
                    Locate ext2/ext3/ext4 backup superblock

-> [ Superblock ]

Code: Select all

TestDisk 7.1-WIP, Data Recovery Utility, June 2018
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/sdb - 4000 GB / 3726 GiB - CHS 486401 255 63

     Partition                  Start        End    Size in sectors

   Linux filesys. data    251676672  377505791  125829120 [sdb3_ext4]      
 superblock 0, blocksize=4096 [sdb3_ext4]
>superblock 32768, blocksize=4096 [sdb3_ext4]
 superblock 98304, blocksize=4096 [sdb3_ext4]
 superblock 163840, blocksize=4096 [sdb3_ext4]
 superblock 229376, blocksize=4096 [sdb3_ext4]
 superblock 294912, blocksize=4096 [sdb3_ext4]
 superblock 819200, blocksize=4096 [sdb3_ext4]
 superblock 884736, blocksize=4096 [sdb3_ext4][code]

 superblock 1605632, blocksize=4096 [sdb3_ext4]
 superblock 2654208, blocksize=4096 [sdb3_ext4]

 To repair the filesystem using alternate superblock, run
    Next

>[  Quit  ]

Replace damaged primary superblock with a backup superblock
Choose the 2nd one out of the list:

Code: Select all

fsck.ext4 -p -b 32768  -B 4096 /dev/sdb3

Try to mount /dev/sdb3
mkdir /mnt/sdb3
mount -t ext4 /dev/sdb3 /mnt/sdb3
If mount does not work try another superblock.

If mount works do unmount again:

Code: Select all

sudo umount /dev/sdb3

Do some further filesystem check & repairs.

Code: Select all

sudo fsck.ext4 -cDfty -C 0 /dev/sdb3

Good Luck

[Gorštak]

Try to repair if possile: Reboot with MX LiveUSB

Im not so sure if im willing to try any disk repairing from MX Live, since its the only distro that dont recognize my WD hdd and wont mount its partition. Every other distro works with those partitions and drive itself without any errors. If you want, I can check them in other distros and give the output. Im not expert, but seems to me like MX have problem with my WD drive, like if it cant recognize it, perhaps some driver issue.

Following output is from Ubuntu

Code: Select all

fsck.ext4 -nv /dev/sdb3  
e2fsck 1.44.4 (18-Aug-2018)
manjaro: clean, 231411/1638400 files, 1676649/6553600 blocks

[fehlix]

Following output is from Ubuntu

Code: Select all

fsck.ext4 -nv /dev/sdb3  
e2fsck 1.44.4 (18-Aug-2018)
manjaro: clean, 231411/1638400 files, 1676649/6553600 blocks

Fine. Do check also the other partitions to see if their is any show stopper.

[BitJam]

I have several debian based distros, including debian itself. All of them installed fine, and grub update pass without errors. I can use MX like this, it boots fine with other distro grub. But bootloader cross compatibility is one of my regular tests for new distros and Id love to do it with MX too. Any way i can find out what causes the problem?
Most partitions are ext4, few are ntfs, one on each drive is swap, and one partition (not on drive where MX is) is btrfs.

There is some strange behavior with sdb on MX. I can't mount any of its partitions in Thunar. I don't think its idle, i was using those partitions less than 3 min ago while booted in Debian, surely it takes more to put it in sleep.

We've had at least one other report of this strange problem where MX has IO errors reading a certain device that other distros did not have trouble with. It was not related to os-prober. My guess is it is related to the kernel we are using and only shows up on certain devices or hardware.

I suggest trying a different kernel in MX and see if the problem persists. It's probably easiest to just download a earlier version of MX and use that. But you can change the kernel on the live-usb if you made it with live-usb-maker. If you didn't make it with live-usb-maker then it is trivial to create a new live-usb from the running live system. Just plug in a new usb-stick, run live-usb-maker and tell it to clone the live system. Takes about a minute on modern hardware.

To change kernels, boot the new stick, install a new kernel, then run live-remaster followed by live-kernel-updater. The remaster will take a few minutes since it rebuilds the squashfs file but the entire procedure is pretty easy. If you are command line literate, it can all be done in the command line which I think is actually easier. If the problem goes away when you change the kernel and nothing else then we know the problem is in the kernel.

Again, it may be easiest to try an earlier version of MX. If that works then you may want to help us track down the problem in the latest MX by seeing if it is in the kernel or a user-land program.

[Gorštak]

Fine. Do check also the other partitions to see if their is any show stopper.

All ex4 partitions came clean

Again, it may be easiest to try an earlier version of MX. If that works then you may want to help us track down the problem in the latest MX by seeing if it is in the kernel or a user-land program.

Id be glad to help you out, just need you to tell me exactly what to do :)
I dont mind taking the harder way if that will be more productive in finding the bug

If you are command line literate, it can all be done in the command line which I think is actually easier.

I would say I am :) I surely can follow the instructions, with proper guidance ill manage any task given

[BitJam]

Id be glad to help you out, just need you to tell me exactly what to do :)
I dont mind taking the harder way if that will be more productive in finding the bug

I would say I am [command line literate] :) I surely can follow the instructions, with proper guidance ill manage any task given

Great! I think it would be best to start with an older iso and see if that can read the partition that gave you problems with IO errors. If it too fails then there is no need to bother changing the kernel on MX-18.1. Just to be clear, I am assuming you are getting IO errors when trying to read a partition in MX-18.1 but that same partition can be read fine by another distro.

So download an MX-17 iso from SourceForge, create another live-usb and see if it can read the partition.

In case that works or if you just want to do it the harder way first, here are instructions for changing the kernel on a live system.

0) Start with a live-usb-maker live-usb
It is best to start with a live-usb made by live-usb-maker (LUM). If yours is not and you have another usb-stick then boot your live-usb, plug in your new stick, and run:

Code: Select all

sudo live-usb-maker

Accept the "clone" option, then press <Enter> to accept defaults and/or to start. On modern hardware you should have a new LUM live-usb in about a minute. Reboot with the new live-usb.

1) Install the new kernel
If the older iso worked then install the kernel that was used there or one close to it. MX-17 uses 4.13.0-1 and MX-16 uses 4.7.0-0.bpo.1. You need to have an internet connection in order to download the kernel. Then use Synaptic, or the MX-Package-Installer, or the command line tool cli-aptiX to install the kernel and headers. IMO the command line tool is easiest:

Code: Select all

sudo cli-aptiX

The first time cli-aptiX runs it will force you to do a update so it gets the latest information about what software is available to install. This is usually quite fast. In the main menu there is an option to search for kernels. Choose this, select the kernel you want and then select the "install" option. When it installs the kernel, it will automatically install the headers. You could easily install more than one kernel if you want.

2) Remaster the live system
Doing a remaster will add the new kernel to the compressed squashfs file (located at /antiX/linusfs on the live-usb):

Code: Select all

sudo live-remaster --cli

There are a few questions. The answers don't make much difference for your case. It is fine if the optional label is blank. This takes a few minutes because it has to recompress the entire file system. The lz4 compression is very fast. I suggest using it unless you are short on space on the live-usb.

3) Change the live kernel
Run:

Code: Select all

sudo live-kernel-updater

and just follow the instructions. Updating to the new kernel should be the default (or close to it). If you didn't do the live-remaster then it will force you to before it changes the live kernel. This is to ensure the new kernel is actually in the linuxfs file for the next boot.

Then reboot. If something goes horribly wrong, you can rollback to the previous kernel by booting the other MX-17 live-usb. After you boot, plug in the broken MX-18.1 and run live-kernel-updater. Choose to work on the plugged in MX-18.1 stick rather then the running live system. It will offer you an option to roll back. You can also rollback manually by renaming a few vmlinuz.* and initrd.gz.* files in the /antiX/ directory of the live-usb. Of course, if it boots, the rollback option will be available on the running live system. Or you could change to a different kernel if you installed more than one.