Fedora boots into emergency mode (on Dual Boot with win10) after every win10 update

Ask Fedora
,
1

Hi everyone.

My machine is Fedora 36 with dual boot win10. I rarely use win10 but I need it for some specific software, otherwise I use Fedora 99% of the time. The Fedora partition is encrypted and both fedora and win10 are installed via UEFI.

However every single time I boot into win10 (because I seldom use it - only once per week) it performs an update and without fail, 100% of the time, 100% repeatable, after it performs an update, my fedora does not boot up anymore but goes into emergency boot mode. Thus far Iā€™ve had to re-install fedora again and again, even after trying various backup software which never seems to work in a real scenario (like timeshift), Iā€™m now fed up with this problem and I really want to understand why this is happening and how to stop it from happening again. I know Iā€™m not the only person with this problem and it should not be happening.

Iā€™ve tried using timeshift to keep a complete backup (except the /home directory) thinking it would restore it okay, but unfortunately both through live usb or booting into emergency mode and going to root, then issuing a ā€˜timeshift --restoreā€™ I get the following error on timeshift, after selecting all default options:

E. Failed to mount device ā€˜dev/dm-0ā€™ at mount point ā€˜run/timeshift/restoreā€™
E. mount: /run/timeshift/restore: mount(2) system call failed: No such file or directory.
dmesg(1) may have more information after failed mount system call.

My system has 3x SSDs and 1x SATA mechanical drive. The main drive (sda) is encrypted (luks) and paritioned into 3 partitions. Its nothing special, I didnā€™t create special parameters or a special paritioning scheme when I installed fedora, its just default auto created the paritioning scheme upon install. The only different thing I did was I used luks encryption which is just a click of a square during the installation process.

Here is the output of lsblk:

cad6ad52b29e7bb7d4c01071a4286af4bf985f4e.jpeg
cad6ad52b29e7bb7d4c01071a4286af4bf985f4e.jpeg1180Ɨ634 72.4 KB

So my questions are:

1/ How to restore the boot partition without the need to re-install everything again?

2/ What is win10 doing to the partition that creates the scenario that fedora is then unable to mount the partition on reboot back into fedora?

3/ How to stop this from happening again in the future? (apart from not updating win10 but sometimes it automatically does it, even if youā€™ve turned off autoupdates).

I hope someone can help, this issue is really driving me crazy and having to re-install time and time again (which is around once per week) is wasting precious time, but this problem should not be happening.

Looking forward to any help.
Thanks.

2

That screenshot does not even show where / and /boot are located, nor does it show /boot/efi/

I have to assume that it is possible you created a new efi partition for fedora during the install instead of allowing the system to use the efi partition that was part of the windows install. If you did then it is likely the efibootmgr that is causing the issue when windows does its update since it is now selecting the windows efi partition rather than the fedora one.

Please show us the output of sudo fdisk -l while either booted from the install media or while actually booted to fedora. Copy and paste that text into the post using the </> Preformatted text tags available on the toolbar above the post. Using images make it difficult to read and impossible to copy the info.

2 Likes
3

Hi Jeff V thanks for the reply.

1/ The reason why iā€™ve made a screenshot is because i didnā€™t setup ssh access to the pc to copy and past the actual output in text Iā€™ll use live USB from now on when I post.

2/ I havenā€™t set up the partitioning, it was automatically done by the fedora installer. Infact every single flavor of linux (Iā€™ve been using linux for the last 25 years now), sets up the drive in exactly the same way when you ENCRYPT the drive, thus meaning during the installation process, you select the ā€˜encrypt driveā€™ box and enter password. Iā€™ve never separately setup the partitioning, its all done by the installer.

3/ here is the fdisk output, from live usb fedora instance:

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WD Green 2.5 100
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: gpt
Disk identifier: 0A17EC9B-A9F0-#############

Device       Start        End    Sectors   Size Type
/dev/sda1     2048    1230847    1228800   600M EFI System
/dev/sda2  1230848    3327999    2097152     1G Linux filesystem
/dev/sda3  3328000 1953523711 1950195712 929.9G Linux filesystem


Disk /dev/sdb: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: CT1000MX500SSD1 
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: gpt
Disk identifier: FF31E41B-9B6B-#############

Device          Start        End    Sectors   Size Type
/dev/sdb1        2048     923647     921600   450M Windows recovery environment
/dev/sdb2      923648    1126399     202752    99M EFI System
/dev/sdb3     1126400    1159167      32768    16M Microsoft reserved
/dev/sdb4     1159168 1952458062 1951298895 930.5G Microsoft basic data
/dev/sdb5  1952458752 1953521663    1062912   519M Windows recovery environment


Disk /dev/sdc: 447.13 GiB, 480103981056 bytes, 937703088 sectors
Disk model: KINGSTON SHSS37A
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: gpt
Disk identifier: 7671251E-20C8-#############

Device     Start       End   Sectors   Size Type
/dev/sdc1   2048 937701375 937699328 447.1G unknown


Disk /dev/sdd: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EZRZ-00G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 2A958DD2-E5E3-#############

Device     Start        End    Sectors  Size Type
/dev/sdd1   2048 7814035455 7814033408  3.6T Microsoft basic data


Disk /dev/sde: 14.46 GiB, 15527313408 bytes, 30326784 sectors
Disk model: STORE N GO      
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: 0x71382bed

Device     Boot Start     End Sectors  Size Id Type
/dev/sde1  *        0 7881663 7881664  3.8G  0 Empty
/dev/sde2         172   20559   20388   10M ef EFI (FAT-12/16/32)
/dev/sde3       20560   63455   42896 20.9M  0 Empty


Disk /dev/loop0: 3.64 GiB, 3909128192 bytes, 7635016 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


Disk /dev/loop1: 25 GiB, 26845642752 bytes, 52432896 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


Disk /dev/loop2: 32 GiB, 34359738368 bytes, 67108864 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


Disk /dev/mapper/live-rw: 25 GiB, 26845642752 bytes, 52432896 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


Disk /dev/mapper/live-base: 25 GiB, 26845642752 bytes, 52432896 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


Disk /dev/zram0: 8 GiB, 8589934592 bytes, 2097152 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Notes:
1/ The Disk model: STORE N GO is the Fedora Live USB
2/ The Disk model: WD Green 2.5 100 (sda) is the ā€˜installed Fedoraā€™ on SSD
3/ The Disk model: CT1000MX500SSD1 (sdb) is the ā€˜installed win10ā€™ on SSD

and just to make sure you get additional information, here is the output of inxi -Fxz
(Note Iā€™m using Live USB)

[liveuser@localhost-live ~]$ sudo inxi -Fxz
System:
  Kernel: 5.18.10-201.fsync.fc36.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 2.37-27.fc36 Console: pty pts/1 Distro: Fedora release 36 (Thirty Six)
Machine:
  Type: Desktop Mobo: ASUSTeK model: P8Z68 DELUXE/GEN3 v: Rev 1.xx
    serial: <#####> UEFI: American Megatrends v: 3304 date: 04/17/2012
CPU:
  Info: quad core model: Intel Core i7-2600K bits: 64 type: MT MCP
    arch: Sandy Bridge rev: 7 cache: L1: 256 KiB L2: 1024 KiB L3: 8 MiB
  Speed (MHz): avg: 1605 min/max: 1600/3800 cores: 1: 1605 2: 1605 3: 1605
    4: 1605 5: 1605 6: 1605 7: 1605 8: 1605 bogomips: 54575
  Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: AMD Navi 23 [Radeon RX 6600/6600 XT/6600M] vendor: XFX
    driver: amdgpu v: kernel arch: RDNA 2 bus-ID: 04:00.0
  Device-2: Microsoft LifeCam VX-2000 type: USB
    driver: snd-usb-audio,uvcvideo bus-ID: 2-1.1:3
  Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 22.1.2 driver: X:
    loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa gpu: amdgpu
    resolution: 1: 1920x1080~60Hz 2: 1920x1080~60Hz 3: 1920x1080~60Hz
    4: 1920x1080~60Hz
  OpenGL:
    renderer: NAVI23 (navi23 LLVM 14.0.0 DRM 3.46 5.18.10-201.fsync.fc36.x86_64)
    v: 4.6 Mesa 22.2.0-devel direct render: Yes
Audio:
  Device-1: Intel 6 Series/C200 Series Family High Definition Audio
    vendor: ASUSTeK P8P67 Deluxe driver: snd_hda_intel bus-ID: 2-1.1:3
    v: kernel bus-ID: 00:1b.0
  Device-2: AMD Navi 21/23 HDMI/DP Audio driver: snd_hda_intel v: kernel
    bus-ID: 04:00.1
  Sound Server-1: ALSA v: k5.18.10-201.fsync.fc36.x86_64 running: yes
  Sound Server-2: PulseAudio v: 15.0 running: no
  Sound Server-3: PipeWire v: 0.3.54 running: yes
Network:
  Device-1: Intel 82579V Gigabit Network vendor: ASUSTeK P8P67 Deluxe
    driver: e1000e v: kernel port: f040 bus-ID: 00:19.0
  IF: eno1 state: down mac: <filter>
  Device-2: Qualcomm Atheros AR9462 Wireless Network Adapter
    vendor: Lite-On driver: ath9k v: kernel bus-ID: 0e:00.0
  IF: wlp14s0 state: down mac: <filter>
  Device-3: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    vendor: ASUSTeK P8P67 and other motherboards driver: r8169 v: kernel
    port: a000 bus-ID: 11:00.0
  IF: enp17s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Bluetooth:
  Device-1: ASUSTek Bluetooth Adapter type: USB driver: btusb v: 0.8
    bus-ID: 2-1.7:7
  Report: rfkill ID: hci0 rfk-id: 0 state: up address: see --recommends
Drives:
  Local Storage: total: 5.91 TiB used: 11.14 GiB (0.2%)
  ID-1: /dev/sda vendor: Western Digital model: WD Green 2.5 1000GB
    size: 931.51 GiB temp: 40 C
  ID-2: /dev/sdb vendor: Crucial model: CT1000MX500SSD1 size: 931.51 GiB
    temp: 27 C
  ID-3: /dev/sdc vendor: Kingston model: SHSS37A480G size: 447.13 GiB
    temp: 30 C
  ID-4: /dev/sdd vendor: Western Digital model: WD40EZRZ-00GXCB0
    size: 3.64 TiB temp: 30 C
  ID-5: /dev/sde type: USB vendor: Verbatim model: STORE N GO
    size: 14.46 GiB
Partition:
  ID-1: / size: 24.44 GiB used: 11.14 GiB (45.6%) fs: ext4 dev: /dev/dm-0
    mapped: live-rw
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 28.0 C mobo: N/A gpu: amdgpu temp: 36.0 C
  Fan Speeds (RPM): N/A gpu: amdgpu fan: 0
Info:
  Processes: 372 Uptime: 16m Memory: 31.19 GiB used: 5.4 GiB (17.3%)
  Init: systemd target: graphical (5) Compilers: gcc: 12.1.1 Packages: N/A
  note: see --pkg Shell: Bash v: 5.1.16 inxi: 3.3.19

Does this help?

4

Hi Jeff V,

Iā€™ve managed to get the partition back up and running by doing the following, Whilst in emergency mode

Note that this is something Iā€™ve used in the past to resolve the issue on a slightly different configuration (regarding SSDs) but basically the same problem.

First I checked sda1 with ā€˜fsck -fā€™ with the following result

[root@fedora ~]# fsck -f /dev/sdal
fsck from util-linux 2.38
fsck.fat 4.2 (2021-01-31)
/dev/sdal: 25 files, 3584/153290 clusters

but then when I checked sda2 here is what I got:

[root@fedora ]# fsck -f /dev/sda2
fsck from util-linux 2.38
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_open2: Super block checksum does not match super block
fsck.ext4: Superblock invalid, trying backup blocks...
Pass 1: Checking modes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: +(163840--163968)
Fix<y>? yes
Free blocks count wrong for group #0 (28521, counted=28515).
Fix<y>? yes
Free blocks count wrong for group #1 (32639, counted=16087).
Fix<y>? yes
Free blocks count wrong for group #2 (32768, counted=18267).
Fix<y>? yes
Free blocks count wrong for group #3 (32639, counted=887).
Fix<y>? yes
Free blocks count wrong for group 84 (24576, counted=24357).
Fix<y>? yes
Free blocks count wrong (249189, counted=186159).
Fix<y>? yes
Free modes count wrong for group #0 (8181, counted=8895).
Fix<0? yes
Directories count wrong for group #0 (2, counted=5).
Fix<y>? yes
Free modes count wrong for group #1 (8192, counted=8189).
Fix ('a' enables 'yes' to all) <y>? yes
Directories count wrong for group #1 (0, counted=3).
Fix ('a' enables 'yes' to all) <y>? yes to all
Free modes count wrong (65525, counted=65436).
Fix? yes 

Padding at end of anode bitmap is not set. Fix? yes 

/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 100/65536 files (5.0x non-contiguous), 75985/262144 blocks

After issuing the above command and allowing fsck to fix the partition, Fedora now boots up correctly without any glitches. Fedora IS the linux benchmark in my opinion, extremely solid and very polished.

However, it now proves beyond any shadow of a doubt, that win10 somehow modified the ext4 partition, either due to malicious intent or perhaps something to do with secure boot or another mb bios setting?

From what I know about windows, by itself it is unable to view the ext4 filesystem unless you add a 3rd party software to enable this. I donā€™t want to sound like a conspiracy theorist but I canā€™t see this as just some coincidence, I can repeat this 100 times with exactly the same outcome with any linux distro where the linux SSD is on sda and win10 on sdb.

How can this be stopped from occurring again?

5
  1. Does the same thing happen with windows and running fdisk every time?
  2. You definitely have 2 efi partitions, /dev/sda1 (fedora) and /dev/sdb2 (windows)
  3. Windows is always by default installed on the first hard drive. Did you relocate the window drive to sdb and install a new drive for use to install fedora as sda

It is quite possible that windows still thinks it is the first hard drive and its boot loader and the updates believe that /dev/sda2 is the correct boot partition for windows, which it obviously is not.

I do not believe you would have this issue if 2 things were true.
first, windows were still seen as the first drive (sda)
second, you had allowed fedora to use the efi partition on the windows disk so bios only had to deal with one efi partition.

When you tell bios to use one efi partiton it may switch to only booting from that partition since the system only allows one ESP partition

6

Hi Jeff V,

1/ Iā€™m not sure I understand this question so please forgive me if its misunderstood.
(a) If I only RUN windows and there are ZERO updates, everything is fine. No issues on Fedora.
(b) If I RUN windows and it UPDATES, then that is where I have an issue on Fedora as listed above.
(c) If I run fsck to solve the problem, it ALWAYS fixes it.
(d) I can repeat this 100 times with the same result.

2/ Yes I know I have 2x EFI partitions, but they are both separate on separate SSDs.
(a) When I installed windows initially, I did it WITHOUT any other drive connected to the motherboard and initially it was listed as sda.
(b) When I installed Fedora on a separate SSD, the win10 SSD was connected and after installation process was completed, grub2 listed win10 in bootup screen.
(c) somehow, the mb swapped the win10 sda to become sdb and the Fedora SSD became sda.

3/ Yes win10 was the first drive on the mb, and that is because in the past, when I had installed Fedora on the first drive and then installed windows, the boot up sequence would result in the win10 boot loader (which is horrible) being used rather than grub2, so thats why I always install win10 first by itself, then install Fedora on a Separate SSD.
Note: This never used to happen on win7, it only happens with win10

Additionally, I have checked using gparted on a separate live USB (Parted Magic) and the win10 SSD is listed as sdb and Fedora SSD listed as sda. Iā€™ve checked with kparted (after booting up with Fedora), the win10 SSD is listed as sdb and Fedora is listed as sda.

With regards to your comment ā€œyou had allowed fedora to use the efi partition on the windows disk so bios only had to deal with one efi partition.ā€ Iā€™ve never set anything anywhere to force the bios to make Fedora use the efi partition on the win10 drive and I can confirm that if I use the boot manager of the mb, loading both win10 and Fedora via the mb boot manager, the exact same result occurs. There is no available setting on my mb to make that possible either. My mb (P8Z68 DELUXE/GEN3) is a little dated but top of the line in itā€™s day.

However youā€™ve got me curious now to try and see what I can find out about the EFI settings on the mb. What I can recall is that in the past I was running 3x SSDs on the same motherboard and the same installation process was performed, namely win10 installed first on SSD#1 without any other drives connected. Then installed RedHat on SSD#2 and Fedora on SSD#3. During that time I recall the RedHat drive always having the same problem, I had to run fsck -f /dev/sda2 to fix it after a win10 update. win10 was listed as (sdb), RedHat was listed as (sda) and The Fedora SSD#3 was listed as (sdc), and Fedora never had this issue in that particular configuration which renders your suggestion regarding win10 thinking its on sda to be quite valid and probable.
The weird thing is that what youā€™ve mentioned seems to be the only logical and most probable cause, especially when the mb is changing SSD#1 to sdb when it was initially sda.

Perhaps there might be something in the mb configuration that is the cause of all this grief, something that may have been automatically implemented because I can certainly assure you Iā€™ve never fiddled with the bios settings, other than update the bios firmware and that happened a long time ago. Since then the mb has been reset several times to default.

In any case, I shall check it shortly and report back.

Thanks again for your time and attention to help me in this matter, I greatly appreciate it.
Hopefully my investigation in this matter will bear fruit that will be able to help others with the same problem because from what iā€™ve seen thus far in all the forums, so many people are having the exact same issue.

7

Fedora designates the first drive identified by the bios as sda, the second as sdb, etc.

If that is the only issue then it seems likely that a simple swap of the connections on the mobo would probably swap the identity of the drive within fedora so the windows drive would become sda and the fedora drive would be sdb.

My comment about

is based on the fact that fedora gladly shares an efi partition with windows and AFAIK has never had a problem with dual booting or with updates to either windows or fedora when doing so. What I have done since the day I first began using uefi and dual booting is (when installing fedora) allow fedora to use an empty, unallocated space on one drive (full drive or partial) but also make sure fedora is allowed to install to the drive containing windows. Fedora is capable of detecting an existing ESP and mounting it as /boot/efi even when doing automatic partitioning. It creates all the other partitions in the previously unallocated space. The only caveat is that you need to be sure you select to use unallocated space and not wipe any existing partitions.

I think what is happening with the data on /dev/sda2 is because windows is not seeing its drive as second (probably because it was installed on the first drive), but thinks it is first while the system, including bios, sees windows as residing on the second drive and the linux drive as first.

Usually the sata port the drive is connected to tells the bios the order to name the drives, but if only one drive is connected it will always be seen as first regardless of the port where it is connected. Connecting another drive can change the identity of the first, which is why fedora and most other linux distros now use UUID to identify what to mount.

8

Hi Jeff V,

Iā€™ve finally managed to get the time to swap over the sata cables so that sda and sdb were reversed, thus making win10 identified on sda and Fedora identified on sdb as shown below:

[root@fedora ~]$ fdisk -l
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: CT1000MX500SSD1 
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: gpt
Disk identifier: FF31E41B-################

Device          Start        End    Sectors   Size Type
/dev/sda1        2048     923647     921600   450M Windows recovery environment
/dev/sda2      923648    1126399     202752    99M EFI System
/dev/sda3     1126400    1159167      32768    16M Microsoft reserved
/dev/sda4     1159168 1952458062 1951298895 930.5G Microsoft basic data
/dev/sda5  1952458752 1953521663    1062912   519M Windows recovery environment


Disk /dev/sdb: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WD Green 2.5 100
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: gpt
Disk identifier: 0A17EC9B-################

Device       Start        End    Sectors   Size Type
/dev/sdb1     2048    1230847    1228800   600M EFI System
/dev/sdb2  1230848    3327999    2097152     1G Linux filesystem
/dev/sdb3  3328000 1953523711 1950195712 929.9G Linux filesystem

Thus, that has resolved the problem of changing the identification from sdb to sda.
Anyone reading this with the same problem I guess needs to be aware that win10 expects always to be at sda, no matter what.

What I do find interesting is that win10 does always expect to be at sda, and if its not, will overwrite sda2 (whatever that may be which can also be linux). It speaks volumes for the poor quality of microsoft coding and speaks volumes for the superb and extremely intuitive coding by the Linux team where Fedora does not have this issue at all, as it does NOT overwrite partitions of other drives when its not supposed to.

However I will now test this with an update and Iā€™ll add some more comments after this.

9

Hi Jeff,

Since that last update I gave yesterday, I loaded up win10 and found any update, installed it and rebooted the machine. Now please be aware now that sda is win10 and sdb is Fedora.

The result is once the update was performed in win10, it still changed sdb2 (was sda2 before), somehow corrupting the partition.

So now even when Iā€™ve swapped the cables I still get the same problem, win10 still keeps fiddling with the partition on the Fedora install. This is driving me bananas.

Any other ideas?

10

Bumpā€¦ Anyone have any ideas?