This happened after a kernel update. Whenever I try to boot, my computer says Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1) Welcome to emergency mode!... followed by a bunch of things I can do.

It spits the same error out if I ctrl-d to boot into default mode, and the fstab file matches the drive UUIDs perfectly. But I think I found the culprit. When I run blkid, it takes a while, and then spits out blk_update_request: I/O error, dev fd0, sector 0 followed by the drives' data.

What is happening, why, and how do I fix it?

I tried the possible duplicate question, but it is a slightly different error and the solution doesn't work.


5 Answers 5



Your device doesn't have a floppy drive, but the floppy driver module is installed, so you have /dev/fd0, and many things will try to use it.

sudo rmmod floppy
echo "blacklist floppy" | sudo tee /etc/modprobe.d/blacklist-floppy.conf
sudo dpkg-reconfigure initramfs-tools
  • Thanks for that edit. That looks like exactly what was missing.
    – Auspex
    Jan 26, 2018 at 10:26
  • 25
    For anyone coming here after searching for this error running Ubuntu in a VM under Microsoft Hyper-V, this is because by default, a floppy drive is added to the VM configuration, but not correctly activated. The answer above still solves it, but do check to see if you have a floppy device in the VM config first, and try removing that before applying this fix. I have 15 of the darn things, and so far 5 of them fixed by removing the rouge floppy from the Hyper-V machine config using Hyper-V manager.
    – shawty
    Mar 25, 2018 at 15:27
  • 1
    @shawty Yes, I've seen that in VirtualBox, too.
    – Auspex
    Apr 6, 2018 at 9:27
  • 2
    I never had a rouge floppy, I think all of mine were beige or black. Maybe some blue ones too. Apr 5, 2021 at 3:43
  • 2
    Even though I removed floppy in VMware before setting up the VM it seems that some definition of it still exists. This is quite lazy in both VM and OS part. There is no reason to have the device on load modules by default. Oct 4, 2021 at 3:23

I had a different situation. Installed ubuntu server lts 18.04 and mod floppy was active.

There was a fstab entry and activated kernel module floppy.

## check for mod floppy
lsmod | grep -i floppy

I did this:

  • comment fstab entry (or just delete it)
  • disable mod floppy - add to blacklist

Blacklist module

echo "blacklist floppy" | sudo tee /etc/modprobe.d/blacklist-floppy.conf

Without reboot:

sudo rmmod floppy
sudo dpkg-reconfigure initramfs-tools

Or with reboot


Just disable the floppy drive in the Bios system, same thing happend to me did that working fine now.


I have been fiddling and fooling around with that for yet rather a long time. A short and a long solution.

This is the short one

  • First see that your fstab file is okay, especially your swap file.

  • Than run:

      sudo update-initramfs -u

    and your problems should be over.

The long version

The long version written by someone else which I did not take note of. (Sorry people!)


  • Use blkid to determine the UUID of your swap partition, and while at it, make sure all other partitions have correct UUID's in /etc/fstab. Also can use lsblk -f to find the UUID's.

  • Put the correct UUID's into /etc/fstab, especially swap, for this error.

  • Put the correct UUID for swap into /etc/initramfs-tools/conf.d/resume.

  • Run sudo update-initramfs -u

Reboot. Fixed my triple boot of Stretch all with this error, as the swap file had changed.

Explanation for the long version

The problem was due to my swap being encrypted. So the local-premount script in initramfs was waiting for a swap device that was not available, until it timed out. The relevant message was gave up waiting for suspend/resume device.

To disable this (as resuming from swap is not possible with an encrypted swap, and I don't use hibernation anyway), I modified this file: /etc/initramfs-tools/conf.d/resume.

  • In this file, a line with


(instead of the UUID that was here) will disable waiting for a resume device.

  • Run sudo update-initramfs -u to apply the changes.

  • System now boots normally.



First off: It is NOT your fault. It just shows that updates, without backups, are dangerous on ANY OS and no matter how often it worked before.

I had exactly the same problem today on Debian 9.

A whole ext3 RAID1 "vanished" after kernel was updated from:

linux-image-4.9.0-11-amd64                        4.9.189-3+deb9u2                            


linux-image-4.9.0-12-amd64                        4.9.210-1                                   

list all installed kernels

dpkg --list | grep linux-image
ii  linux-image-4.9.0-11-amd64                        4.9.189-3+deb9u2                            amd64        Linux 4.9 for 64-bit PCs
ii  linux-image-4.9.0-12-amd64                        4.9.210-1                                   amd64        Linux 4.9 for 64-bit PCs
rc  linux-image-4.9.0-6-amd64                         4.9.88-1+deb9u1                             amd64        Linux 4.9 for 64-bit PCs
rc  linux-image-4.9.0-8-amd64                         4.9.144-3.1                                 amd64        Linux 4.9 for 64-bit PCs
ii  linux-image-4.9.0-9-amd64                         4.9.168-1+deb9u3                            amd64        Linux 4.9 for 64-bit PCs
ii  linux-image-amd64                                 4.9+80+deb9u10                              amd64        Linux for 64-bit PCs (meta-package)

hostnamectl; # os used
   Static hostname: storagepc
         Icon name: computer-desktop
           Chassis: desktop
  Operating System: Debian GNU/Linux 9 (stretch)
            Kernel: Linux 4.9.0-12-amd64
      Architecture: x86-64

Those are the kind of "heart attack" moments X-D

Let's try to stay cool!

"solution": boot previous kernel ( in this case: linux-image-4.9.0-11-amd64 )

vim /etc/default/grub

GRUB_TIMEOUT=3 <- make sure a timeout larger than 0 is defined (or no time to select any options during boot)

# let grub2 do its stuff
# is the same as:

# reboot the system (if USB keyboard is not reacting during grub boot screen, try PS2 keyboard)

# when grub boot screen appears 

Grub2 Boot Screen Advanced Options for Debian 9 boot previous kernel 1

Grub2 Boot Screen Advanced Options for Debian 9 boot previous kernel 2

After booting linux-image-4.9.0-11-amd64 kernel, can access ext3 RAID1 AGAIN!

Problem: grub won't remember that choice.

To make this permanent:

vim /etc/default/grub

# during boot:
## select in the first menu the second (0,1) entry
#### then select in the second menu select the 3rd entry (0,1,2)

# make grub2 realize the changes

... yes it is confusing I know X-D

this is what it was supposed to look like

Have two RAID1 defined.

# show status of raid
cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md126 : active raid1 sdc1[1] sdb1[0]
      3906886464 blocks super 1.2 [2/2] [UU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

md127 : active raid1 sde1[0] sdd1[2]
      1953381376 blocks super 1.2 [2/2] [UU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

# show what is mounted
/dev/md126 on /media/user/ext4RAID1 type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/md127 on /media/user/ext3RAID1 type ext3 (rw,relatime,data=ordered)

# show block devices
fd0         2:0    1     4K  0 disk  
sda         8:0    0 238.5G  0 disk  
├─sda1      8:1    0 230.8G  0 part  /
├─sda2      8:2    0     1K  0 part  
└─sda5      8:5    0   7.7G  0 part  [SWAP]
sdb         8:16   0   3.7T  0 disk  
└─sdb1      8:17   0   3.7T  0 part  
  └─md126   9:126  0   3.7T  0 raid1 /media/user/ext4RAID1
sdc         8:32   0   3.7T  0 disk  
└─sdc1      8:33   0   3.7T  0 part  
  └─md126   9:126  0   3.7T  0 raid1 /media/user/ext4RAID1
sdd         8:48   0   1.8T  0 disk  
└─sdd1      8:49   0   1.8T  0 part  
  └─md127   9:127  0   1.8T  0 raid1 /media/user/ext3RAID1
sde         8:64   0   1.8T  0 disk  
└─sde1      8:65   0   1.8T  0 part  
  └─md127   9:127  0   1.8T  0 raid1 /media/user/ext3RAID1
sr0        11:0    1  1024M  0 rom 

# find defined raids
mdadm --examine --scan
ARRAY /dev/md/2  metadata=1.2 UUID=90642755:fa191325:0fe4ec59:2456c645 name=storagepc:2
ARRAY /dev/md/1  metadata=1.2 UUID=433fb7e1:9d7f3f17:bc5ee18b:0f4eeb52 name=storagepc:1

# show UUIDS
blkid /dev/sdb1
/dev/sdb1: UUID="90642755-fa19-1325-0fe4-ec592456c645" UUID_SUB="bee458e0-509a-c110-b577-8a1ddbe6bbb3" LABEL="storagepc:2" TYPE="linux_raid_member" PARTUUID="1fd02041-9dd2-4918-83a3-c8bafbab3bed"

blkid /dev/sdc1
/dev/sdc1: UUID="90642755-fa19-1325-0fe4-ec592456c645" UUID_SUB="7d5947f8-1ba0-0c7b-18a7-194ab4051a2c" LABEL="storagepc:2" TYPE="linux_raid_member" PARTUUID="5e4ea781-68e5-43f0-accf-26342aeb4daa"

userblkid /dev/sdd1
/dev/sdd1: UUID="433fb7e1-9d7f-3f17-bc5e-e18b0f4eeb52" UUID_SUB="bed17780-3817-27c9-6336-44d4aedfb857" LABEL="storagepc:1" TYPE="linux_raid_member" PARTUUID="f6aab6c2-01"

userblkid /dev/sde1
/dev/sde1: UUID="433fb7e1-9d7f-3f17-bc5e-e18b0f4eeb52" UUID_SUB="eb90b361-94d6-2f38-7727-d386097dce81" LABEL="storagepc:1" TYPE="linux_raid_member" PARTUUID="d2fd127f-01"

regular filesystem checks

Has nothing to do with the problem but defining this via tune2fs has the advantage, that it will automatically be performed during boot.

tune2fs -C 2 -c 1 /dev/sda1; # check filesystem on every boot (for ext3 takes rather long X-D)
tune2fs -c 10 -i 30 /dev/sda1; # check sda1 every 10 mounts or after 30 days
  • This caused the message in the question? I can't see any way that misconfigured RAID would cause an error on the floppy device! If you didn't get an error on the Floppy device, please fix your answer to make it clear that you had a similar error and not "exactly the same problem". In any case, the message in the original question is not an error, not "dangerous", and nothing to do with installing updates. It's just an annoying message that comes about because your BIOS configures a floppy, but there isn't one in the hardware.
    – Auspex
    Jan 6, 2021 at 13:03

You must log in to answer this question.