Cryptsetup error during boot: /scripts/local-top/cryptroot: line 1: can't open /dev/mapper/ubuntu--vg-root: no such file

Bug #1273261 reported by Łukasz Fidosz on 2014-01-27
146
This bug affects 28 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
High
Unassigned
initramfs-tools (Ubuntu)
High
Unassigned

Bug Description

While booting cryptsetup outputs following error: /scripts/local-top/cryptroot: line 1: can't open /dev/mapper/ubuntu--vg-root: no such file, seems to be not related to this particular installation as saw the same output on other machines, also seems to be nothing major as everything boots fine, so just reporting to let you know it's there.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: cryptsetup 2:1.4.3-4ubuntu4
ProcVersionSignature: Ubuntu 3.11.0-15.23-generic 3.11.10
Uname: Linux 3.11.0-15-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
Date: Mon Jan 27 15:58:16 2014
InstallationDate: Installed on 2014-01-18 (8 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MarkForUpload: True
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
crypttab: sda3_crypt UUID=68851a49-83a4-41eb-84c0-27d15280bbc1 none luks

Łukasz Fidosz (virhilo) wrote :
Łukasz Fidosz (virhilo) wrote :
Kanariezwart (kanariezwart) wrote :

I have the same issue

see my boot.log

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cryptsetup (Ubuntu):
status: New → Confirmed

Same here on my Lenovo W530. Seems like a related issue: I have press [Esc] to get to the disc unlock menu, instead of being directed to a nice dark violet color inteface automatically (which I know should be the case, as I've seen it happening once or twice). See boot.log attched.

Sam Seed (samseed) wrote :

Same issue for me on 14.10

Sam Seed (samseed) wrote :

On 14.04 rather

Enkouyami (furyhamster) wrote :

This issue is preventing me from booting into my system. I have a volume group called CryptVolume and I have a root partition at CryptVolume-Root and it can't find that after I enter my password to unlock CryptVolume.

I have the same issue which appeared suddenly and I can not login to ubuntu 14.04

Martin R (martin-reiche-ka) wrote :

I can confirm this bug affecting my 14.04. System freezes after entering password. System is not usable that way.

It affected me on previously working system. The workaround is to add 'recoverty' to the boot options and then resume boot.

tadl (tadl-ubuntu) wrote :

I am affected by this issue as well on an almost fresh installation (14.04.1) after about a dozen boot procedures without issues. Now I am only able to boot in recovery mode.

I figured out for myself that it is a gnome issue. If you install eg KDE
over the existing installation the error disappears.. Seems to be an issue
with the gnome wm
On Sep 16, 2014 3:41 PM, "tadl" <email address hidden> wrote:

> I am affected by this issue as well on an almost fresh installation
> (14.04.1) after about a dozen boot procedures without issues. Now I am
> only able to boot in recovery mode.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1273261
>
> Title:
> Cryptsetup error during boot: /scripts/local-top/cryptroot: line 1:
> can't open /dev/mapper/ubuntu--vg-root: no such file
>
> Status in “cryptsetup” package in Ubuntu:
> Confirmed
>
> Bug description:
> While booting cryptsetup outputs following error: /scripts/local-
> top/cryptroot: line 1: can't open /dev/mapper/ubuntu--vg-root: no such
> file, seems to be not related to this particular installation as saw
> the same output on other machines, also seems to be nothing major as
> everything boots fine, so just reporting to let you know it's there.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.10
> Package: cryptsetup 2:1.4.3-4ubuntu4
> ProcVersionSignature: Ubuntu 3.11.0-15.23-generic 3.11.10
> Uname: Linux 3.11.0-15-generic x86_64
> ApportVersion: 2.12.5-0ubuntu2.2
> Architecture: amd64
> Date: Mon Jan 27 15:58:16 2014
> InstallationDate: Installed on 2014-01-18 (8 days ago)
> InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64
> (20131016.1)
> MarkForUpload: True
> SourcePackage: cryptsetup
> UpgradeStatus: No upgrade log present (probably fresh install)
> crypttab: sda3_crypt UUID=68851a49-83a4-41eb-84c0-27d15280bbc1 none luks
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1273261/+subscriptions
>

Kanariezwart (kanariezwart) wrote :

It's not a gnome issue

tadl (tadl-ubuntu) wrote :

@Martin R: Installing KDE over the existing installation does not solve this issue.

Martin R (martin-reiche-ka) wrote :

Worked pragmatically for me, so I didn't do more research on it.. Don't
know anything more either
On Sep 19, 2014 9:41 AM, "tadl" <email address hidden> wrote:

> @Martin R: Installing KDE over the existing installation does not solve
> this issue.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1273261
>
> Title:
> Cryptsetup error during boot: /scripts/local-top/cryptroot: line 1:
> can't open /dev/mapper/ubuntu--vg-root: no such file
>
> Status in “cryptsetup” package in Ubuntu:
> Confirmed
>
> Bug description:
> While booting cryptsetup outputs following error: /scripts/local-
> top/cryptroot: line 1: can't open /dev/mapper/ubuntu--vg-root: no such
> file, seems to be not related to this particular installation as saw
> the same output on other machines, also seems to be nothing major as
> everything boots fine, so just reporting to let you know it's there.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.10
> Package: cryptsetup 2:1.4.3-4ubuntu4
> ProcVersionSignature: Ubuntu 3.11.0-15.23-generic 3.11.10
> Uname: Linux 3.11.0-15-generic x86_64
> ApportVersion: 2.12.5-0ubuntu2.2
> Architecture: amd64
> Date: Mon Jan 27 15:58:16 2014
> InstallationDate: Installed on 2014-01-18 (8 days ago)
> InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64
> (20131016.1)
> MarkForUpload: True
> SourcePackage: cryptsetup
> UpgradeStatus: No upgrade log present (probably fresh install)
> crypttab: sda3_crypt UUID=68851a49-83a4-41eb-84c0-27d15280bbc1 none luks
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1273261/+subscriptions
>

cljokla (cljbville-gen) wrote :

I just had this happen to me today. I'm on 14.04LTS and it was current on it's patches as of 10/2/2014. I've been running 14.04LTS on this PC since it was release and had no problems until today.

I do have another observation to add. I have a laptop and I encrypted the whole disk. I started it up this morning and was working fine for about an hour. I opened a LibreOffice database and did some work in it just fine, then opened LibreOffice Calc. The Calc came up slow and was responding slow. It wasn't intolerable, but slower than normail. I jumped back to the File database and found it was slow too. I checked and my Firefox and Remmina RDP session were still running fine. So I figure it was a LibreOffice glitch. I finished what I was working on then closed the Libre apps and checked to make sure all their processes had closed, then I reopened the Libre apps and found them still slow. So I decided to reboot. I closed all my apps, and rebooted. It came up normally, asked for my password, show the encrypted drive was good and then just sat there on the Ubuntu logo. So after a few minutes I tried a cold boot, same thing. So I rebooted into recovery and it froze too.

Has the encrypted disk got corrupted in such a way that it's no longer useable? Or is this really a bug?

Has anyone had any success repairing this?

cljokla (cljbville-gen) wrote :

I pulled my problem HD and hooked up with a USB adapter to another Ubuntu 14.04LTS machine. It recognized the drive and asks for the password. I put it in then it said the encrypted disk was mounted but had no file system. :-( Any suggestions? Is the encrypted drive just corrupted beyond repair? Is there any options to try and repair an encrypted drive?

Fortunately I back it up daily, so I've got a back up from yesterday I can restore.

Dave Gilbert (ubuntu-treblig) wrote :

High: People can't boot their system.

Changed in cryptsetup (Ubuntu):
importance: Undecided → High

ApportVersion: 2.14.7-0ubuntu3
Architecture: amd64
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.10
InstallationDate: Installed on 2014-03-31 (190 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Beta amd64+mac (20140326)
Package: cryptsetup 2:1.6.1-1ubuntu3
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 3.16.0-21.28-generic 3.16.4
Tags: utopic
Uname: Linux 3.16.0-21-generic x86_64
UpgradeStatus: Upgraded to utopic on 2014-10-07 (0 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
crypttab: sda5_crypt UUID=af4b659e-9561-4597-9d91-3c7d521b5e45 none luks,discard

tags: added: apport-collected utopic

apport information

apport information

apport information

Gareth Woolridge (moon127) wrote :

I'm seeing this error and a failure to boot on a previously working Trusty environment upgraded to Utopic.

As a workaround if I drop to text mode with ESC or boot in recovery I can see the error "/scripts/local-top/cryptroot: line 1: can't open /dev/mapper/ubuntu--vg-root: no such file" but can then enter my passphrase and get to a working system.

lebedov (lebedov) wrote :

Also observed on a Thinkpad T440p running 14.04.1 64-bit Xubuntu. The system previously booted without any issue, but after bringing all packages up to date today booting results in the missing xubuntu--vg-root error. Booting into recovery mode and resuming circumvents the problem. Tried reinstalling linux-image-3.13.0-36-generic to force a rebuild of the boot ram disk image, but that didn't seem to have any effect.

tags: added: trusty
Floyd42 (axelheider) wrote :

I've seen this message in the boot logs also, after installing a new system from scratch with encryption enables. But everything is working for me, system boots and I can log in.

Shuhao (shuhao) wrote :

Also having this issue with an upgrade to utopic

Shuhao (shuhao) wrote :

Can anyone boot after encountering this issue? I can drop into root shell in recovery, mount my partition as rw, but I can't be the normal boot process to go.

Anyone around to help?

Shuhao (shuhao) wrote :

So looking at this, I'm not sure if the message is related to the fact that I can't boot. I have a 14.04 laptop that has the same message but boots just fine.

What I did notice is that the hard drive indicator light for the laptop that can't boot stays on after that message (and hangs).

I've tried booting with verbose and debug as parameter but nothing is showing up...

I have two almost identical installations of Xubuntu, one on my Laptop with Intel-graphics, one on my Desktop with a Nvidia 9something. I am not sure, which graphics drivers are installed, but on the Deskop it is the proprietary one. I don't know of any other differences. When I upgraded to utopic, I got this error message only on the Desktop, not on the Laptop. I don't remember if it stopped booting right from the beginnin, might be it came up once as utopic, before it quit.

Kanariezwart (kanariezwart) wrote :

I can confirm @shuhoa findings, my 14.04 /13.10 laptop displays the error, but I can boot and continue after the error. It just displays the error message, but harmless.

- Either a second cause for displaying the same error message is present (in all 14.04 and later distro's.)
- Or a different cause (probably with no output at all) which halts after the same error message is shown.

tags: added: boot

is this issue necessarily a cryptsetup issue, or could lvm2 or even update-initramfs be responsible for the bug? At least for me, I get the message, that the volume-group is now active, before the error message.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in initramfs-tools (Ubuntu):
status: New → Confirmed
Changed in initramfs-tools (Ubuntu):
importance: Undecided → High
RedScourge (redscourge) wrote :

I can confirm that this happened to me on a fresh install of Ubuntu 14.04.1 LTS via an expert mode install where I didn't really customize any of the options that allows, on an older Core 2 Duo E6800 based system with linux-server kernel choice, with triple drive raid 1 on 1TB msdos partition tabled devices. Server was configured with a partition setup where md0 is an unencrypted boot partition and md1 holds an encrypted volume holding LVM volumes eith ext4 fs with just / and /var and /srv partitions.

The setup program took at least 20 minutes to progress past the detecting the CD image stage, though partitioning went fine (once I used a Windows disk to wipe the existing partitions which were totally screwing up the partitioner the first several runs through, that is). Other than that, install went through without issue as far as I could tell, and I didn't install anything extra other than SSH and local-only postfix, or choose any weird options in the installer with the possible exception of my partitioning scheme (which has worked fine for me on other systems I installed before 14.04.1 LTS came out).

I was able after waiting a crapload of time to drop into a maintenance shell, whereupon I ran mount -a, init 2, apt-get update, apt-get upgrade, and am going to hope that this fixes it, however I'm not holding my breath as I do not seem to see an initramfs or cryptsetup update nor any seemingly related updates among the list of what it's going to install. Nevertheless I'm going to try installing all updates and rebooting.

RedScourge (redscourge) wrote :
Download full text (4.5 KiB)

Same errors came up after reboot, but it seemed to progress past it anyway. Here's a boot.log after the updates, still quite clearly showing the failure to map the partition but seemingly eventually succeeding and getting past it (rather quickly too, actually):

Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Reading all physical volumes. This may take a while...
  Found volume group "vmhost2lvmg1" using metadata type lvm2
  3 logical volume(s) in volume group "vmhost2lvmg1" now active
/scripts/local-top/cryptroot: line 1: can't open /dev/mapper/vmhost2lvmg1-2--root: no such file
done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
 * Starting Read required files in advance^[[154G[^[[31mfail^[[39;49m]
 * Starting Mount filesystems on boot^[[154G[ OK ]
 * Starting Fix-up sensitive /proc filesystem entries^[[154G[ OK ]
 * Stopping Fix-up sensitive /proc filesystem entries^[[154G[ OK ]
 * Starting Populate /dev filesystem^[[154G[ OK ]
 * Starting Populate and link to /run filesystem^[[154G[ OK ]
 * Stopping Populate /dev filesystem^[[154G[ OK ]
 * Stopping Populate and link to /run filesystem^[[154G[ OK ]
 * Stopping Track if upstart is running in a container^[[154G[ OK ]
 * Starting Signal sysvinit that the rootfs is mounted^[[154G[ OK ]
 * Stopping Read required files in advance (for other mountpoints)^[[154G[ OK ]
 * Starting Clean /tmp directory^[[154G[ OK ]
 * Stopping Clean /tmp directory^[[154G[ OK ]
 * Stopping Read required files in advance (for other mountpoints)^[[154G[ OK ]
 * Starting Initialize or finalize resolvconf^[[154G[ OK ]
 * Starting set console keymap^[[154G[ OK ]
 * Starting Signal sysvinit that virtual filesystems are mounted^[[154G[ OK ]
 * Starting Signal sysvinit that virtual filesystems are mounted^[[154G[ OK ]
 * Starting Bridge udev events into upstart^[[154G[ OK ]
 * Starting Signal sysvinit that local filesystems are mounted^[[154G[ OK ]
 * Starting Signal sysvinit that remote filesystems are mounted^[[154G[ OK ]
 * Starting Flush boot log to disk^[[154G[ OK ]
 * Starting flush early job output to logs^[[154G[ OK ]
 * Stopping Mount filesystems on boot^[[154G[ OK ]
 * Stopping Flush boot log to disk^[[154G[ OK ]
 * Stopping flush early job output to logs^[[154G[ OK ]
 * Starting Bridge file events into upstart^[[154G[ OK ]
 * Stopping set console keymap^[[154G[ OK ]
 * Starting device node and kernel event manager^[[154G[ OK ]
 * Starting load modules from /etc/modules^[[154G[ OK ]
 * Starting cold plug devices^[[154G[ OK ]
 * Starting log initial device creation^[[154G[ OK ]
 * Starting D-Bus system message bus^[[154G[ OK ]
 * Stopping load modules from /etc/modules^[[154G[ OK ]
 * Starting SystemD login management service^[[154G[ OK ]
 * Starting system logging daemon^[[154G[ OK ]
 * Starting Uncomplicated firewall^[[154G[ OK ]
 * Starting configure network device security^[[154G[ OK ]
 * Starting configure network device security^[[154G[ OK ]
 * Starting Mount network filesystems^[[154G[ OK ]
 * Starting Failsafe Boot Delay^[[154G[ OK ]
 * Stopping Mount network filesystems^[[154G[...

Read more...

Hayk Martirosyan (hayk-mart) wrote :

Same issue. I just upgraded to 3.13.0-44 and I can't fully boot. The screen gets stuck on the gnome footprint after entering the sda crypt password. Recovery mode also does not boot. Restarting gnome-session did not work.

However, I am able to switch to the CLI using Ctrl+Alt+F2. I installed lightdm, and now I can boot normally.

Jim Wright (jimwrightbe) wrote :

The original bug description was about a message that did NOT prevent booting

However if for some reason you cannot boot but can view boot messages on a text console then there is a good chance this message will already be visible and nothing much else. So if you have not looked before you might think this is the cause of your boot problem. Consequently many people who cannot boot (and I cannot boot) have ended up commenting on this ticket.

As boot problems and the message are not directly related there is not much reason to assume that different boot problems reported here have a common cause.

All in all it does not make sense to extend the scope of this ticket to fixing issues that prevent booting. One good reason for getting rid of the message is to avoid providing a false lead for people who have boot problems but that is the only useful connection to make between the two types of issue.

Nevertheless, as someone with boot problems some of the comments above are useful (I can boot using recovery mode) but I am now going to look elsewhere for resources specifically about boot problems. Good luck :-)

tadl (tadl-ubuntu) wrote :

@Jim: I do see your point.
However, for me the boot issue and this message seemed to be connected:
Just like you, I still could boot in recovery mode, WITHOUT seeing this error message. Since reinstalling everything I have never seen this message again in the bootlog. Unfortunately, I did not have bootlogs from the time before the boot failed for comparison.

Jim Wright (jimwrightbe) wrote :

OK. (It is a shame boot.log is not rotated to retain old versions.)

I fixed my boot issue and I still see the message - I did not need to reinstall.

BTW In case anyone is here for a boot problem ;-) In my particular case I installed lxc-android-config without checking what it was because it contained a file mentioned in a HOWTO I was trying to follow. Uninstalling it and redundant dependencies did not fix the problem because many files remained on my system. Files in these directories could have caused the problem AFAIK:

/etc/apparmor.d/
/etc/dnsmasq.d-available/
/etc/init/
/etc/rsyslog.d/
/etc/system-image/
/etc/udev/rules.d

I fixed manually by searching for files on my system only provided by the packages I wanted removed (according to apt-file list and apt-file search and using some bash glue). Then I removed them to a backup tgz.

Michael Bhola (mike-nw2wga2s5) wrote :

It would appear this message comes from:

eval $(fstype < "$NEWROOT")

on line 295 of:

/usr/share/initramfs-tools/scripts/local-top/cryptroot

It seems to be a timing issue. An extra udev_settle seems to fix it:

udev_settle
eval $(fstype < "$NEWROOT")

Then rebuild the initramfs:

update-initramfs -u

To be honest I'm not exactly sure it's udev it's waiting for or whether this just introduced a delay. I don't expect it to fix much apart from the message. I still had a bootable system even with the message.

seond (2ndbase) wrote :

I had this problem too and while it still exists for me I have identified a workaround that enables my system to boot. My issue was to do with cryptsetup not accepting my password. This prevents me for booting and fixing system issues.

Turns out that my password included a special character '@' as in P@ssword. At the prompt pressing RIGHT SHIFT and key 2 does not generate a '@' instead a '2' is generated. This can be confirmed by switching over to another TTY and typing in the password (CTRL + ALT + F1). I noted that using LEFT SHIFT and key 2 generated the '@' control character. Thus if LEFT SHIFT is used in complex password it will be typed correctly and cryptsetup will be able to decrypt the volume.

Note the Ubuntu install program rates user password with Poor, Fair, or Good thus encouraging the use of special characters leading to this scenario in the ubuntu recovery mode.

rob loranger (robjloranger) wrote :

just wanted to add that I am running 15.10 dev branch and have this issue too

Changed in cryptsetup (Ubuntu):
status: Confirmed → Fix Released
Changed in initramfs-tools (Ubuntu):
status: Confirmed → Fix Released
Darek (ddarek-ch) wrote :

It happened for me. My original report of the issue is here https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1581761. I'm updated and still my ubuntu won't boot.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers