0

I try to setup a Linux Mint 19 and Windows 10 dual-boot. (both in BIOS mode)

Windows is installed on /dev/sdc, Linux is installed to /dev/sdb Besides Linux there is a NTFS partition on /dev/sdb too. See the fdisk -l output:

Disk /dev/sdb: 1.8 TiB, 2000397852160 bytes, 3907027055 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe70e336d

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdb2          2002942 3907024064 3905021123   1.8T  5 Extended
/dev/sdb5       1034216568 3907024064 2872807497   1.3T  7 HPFS/NTFS/exFAT
/dev/sdb6  *     517107712 1034215423  517107712 246.6G 83 Linux
/dev/sdb7        515155968  517105663    1949696   952M 82 Linux swap / Solaris
/dev/sdb8          2002944  515153919  513150976 244.7G 83 Linux

Partition table entries are not in disk order.

Now, while setting up Linux Mint after install, everything runs fine. I can reboot without an issue. But as soon as I boot into Windows, it blocks /dev/sdb completely and I am no longer able to boot into Linux. The boot ends with a kernel panic, dropping me to BusyBox.

When checking the drive after booting a USB thumb drive, fsck /dev/sdb says:

root@mint:~# fsck /dev/sdb
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
/dev/sdb is in use.
e2fsck: Cannot continue, aborting.

Please note: /dev/sdb is NOT mounted at this point.

Oh and "fastboot" is turned off in Windows. It happens after a reboot as well as after a shutdown. Somehow Windows keeps the drive busy, even after a reboot. :-/

Any ideas on how to prevent this?

UPDATE

So I used the wrong fsck command. I did it again with the correct command and get the following:

root@mint:~# fsck /dev/sdb1

fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) 
ext2fs_open2: Superblock checksum does not match superblock 
fsck.ext4: Superblock invalid, trying backup blocks... 
/dev/sdb1 was not cleanly unmounted, check forced. 
Pass 1: Checking inodes, blocks, and sizes

After that I get like a thousand invalid blocks, which can all be corrected by fsck. After this, I can boot again into Linux. But only as long as I don't boot into Windows. As soon as I do that, everything is broken again.

I rearranged the partitions on that HDD as well, without success.

Disk /dev/sdb: 1.8 TiB, 2000397852160 bytes, 3907027055 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe70e336d

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdb1  *          2048  515104767  515102720 245.6G 83 Linux
/dev/sdb2        515106814 3907024064 3391917251   1.6T  5 Extended
/dev/sdb5       1034216568 3907024064 2872807497   1.3T  7 HPFS/NTFS/exFAT
/dev/sdb6        515106816 1032214527  517107712 246.6G 83 Linux
/dev/sdb7       1032216576 1034215423    1998848   976M 82 Linux swap / Solaris

Partition table entries are not in disk order

Oh and Smarty says that the HDD is healthy and just fine. There must be a reason why Windows in messing with the partition table in that way...

pixelbash
  • 31

2 Answers2

1

Ok, so apparently this has something to do with ex2fsd, which is a Windows tool to access ext2,3,4 formatted HDDs. It cannot cope with 64bit and the metadata_csum feature.

This helped me: windows-10-corrupting-the-ext4-superblock

If you ran into the same issue:

  1. boot into a live linux (eg Ubuntu 16.04 or later)
  2. correct the ext4 superblock with sudo fsck /dev/sdXX (XX is the number of the partition).
  3. Remove 64bit and metadata_csum with sudo tune2fs -O ^metadata_csum,^64bit /dev/sdXX

That should do the trick for you.

pixelbash
  • 31
0

You could comment out the mounting of /dev/sdb5 from /etc/fstab. Once you've done that it shouldn't throw a kernel panic because the partition that is the issue won't try to boot. I've found this link which should be helpful to unmount the particular drive before rebooting or shutdown in Windows 10. You could just write a new shutdown script or depending on which version of Windows 10 you could set the script to run at shutdown using GPO or the registry.

Grifulkin
  • 21