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.

2

5 Answers

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

5

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

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

reboot

2

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!)

Try:

• 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

   RESUME=none

(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.

Bert

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 

to

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
update-grub
# is the same as:
uupdate-grub2
# reboot the system (if USB keyboard is not reacting during grub boot screen, try PS2 keyboard)
reboot
# when grub boot screen appears 

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)
GRUB_DEFAULT="1>2"
# make grub2 realize the changes
update-grub

... 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
mount
/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
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
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

1

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy