Skip to main content
added 178 characters in body
Source Link
sourcejedi
  • 53.5k
  • 23
  • 178
  • 336
  • How can I determine what device this is?

You can double-check this device is not present using aby comparing it to the list of block devices and their UUIDs. The commands you already used to list them are fine. The device logic is driven by udev, which uses blkid internally.

  • Can it be safely removed from startup and if so, how?

You can create a backup copy of crypttab and then remove the line, or add a # at the start of the line to comment it out.

(I like to use etckeeper, it's like having "system restore points" for individual configuration files in /etc :-). You have to know how to use a version control system though).

While researching this I came across several posts that describe similar symptoms but apparently with different causes. Examples of these are this blog entry and this question on Superuser SE, both tracking this issue to a faulty swap partition / entry in fstab. The excerpt from the bootlog however leads me to believe that these are not related to my particular problem.

Fair. It's a very closely related problem though. You have a device which is listed as being required for the boot process. Therefore your boot waits to find it. After a timeout, the device is considered failed.

(According to my documentation, the boot process should also require this device, meaning that a failure or timeout will boot into the emergency.target shell, instead of default.target). crypttab even supports the same named options as in fstab to modify this behaviour: noauto, nofail, and x-systemd.device-timeout=....

For fstab entries, systemd generates .mount and .swap units. For crypttab entries, it just generates an instance of a template .service unit, [email protected].

The .device unit appears in systemd because it needs something to represent that it is waiting for a matching device. This is expected behaviour.

the boot log, which showed the start job for a device timing out and directly afterwards failing the cryptography setup of a device referenced as cr_usb-General_USB_Flash_Disk. I am unsure whether the two are connected.

They are. The UUID of the timed-out device is the same as the UUID the crypttab lists as belonging to this USB flash disk. EDIT: ah, you meant the slow bootup. Yes, absolutely.


[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-00a69115\x2d956d\x2d41b3\x2d830c\x2d9a3878087d41.device.
[DEPEND] Dependency failed for Cryptography Setup for cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2.

/etc/crypttab

cr_sda2 UUID=7f99168c-4972-468b-900f-fb5bbfb90e66
cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2 UUID=00a69115-956d-41b3-83

  • How can I determine what device this is?

You can double-check this device is not present using a list of UUIDs. The commands you already used to list them are fine. The device logic is driven by udev, which uses blkid internally.

  • Can it be safely removed from startup and if so, how?

You can create a backup copy of crypttab and then remove the line, or add a # at the start of the line to comment it out.

(I like to use etckeeper, it's like having "system restore points" for individual configuration files in /etc :-). You have to know how to use a version control system though).

While researching this I came across several posts that describe similar symptoms but apparently with different causes. Examples of these are this blog entry and this question on Superuser SE, both tracking this issue to a faulty swap partition / entry in fstab. The excerpt from the bootlog however leads me to believe that these are not related to my particular problem.

Fair. It's a very closely related problem though. You have a device which is listed as being required for the boot process. Therefore your boot waits to find it. After a timeout, the device is considered failed.

(According to my documentation, the boot process should also require this device, meaning that a failure or timeout will boot into the emergency.target shell, instead of default.target). crypttab even supports the same named options as in fstab to modify this behaviour: noauto, nofail, and x-systemd.device-timeout=....

For fstab entries, systemd generates .mount and .swap units. For crypttab entries, it just generates an instance of a template .service unit, [email protected].

The .device unit appears in systemd because it needs something to represent that it is waiting for a matching device. This is expected behaviour.

the boot log, which showed the start job for a device timing out and directly afterwards failing the cryptography setup of a device referenced as cr_usb-General_USB_Flash_Disk. I am unsure whether the two are connected.

They are. The UUID of the timed-out device is the same as the UUID the crypttab lists as belonging to this USB flash disk. EDIT: ah, you meant the slow bootup. Yes, absolutely.


[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-00a69115\x2d956d\x2d41b3\x2d830c\x2d9a3878087d41.device.
[DEPEND] Dependency failed for Cryptography Setup for cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2.

/etc/crypttab

cr_sda2 UUID=7f99168c-4972-468b-900f-fb5bbfb90e66
cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2 UUID=00a69115-956d-41b3-83

  • How can I determine what device this is?

You can double-check this device is not present by comparing it to the list of block devices and their UUIDs. The commands you already used to list them are fine. The device logic is driven by udev, which uses blkid internally.

  • Can it be safely removed from startup and if so, how?

You can create a backup copy of crypttab and then remove the line, or add a # at the start of the line to comment it out.

(I like to use etckeeper, it's like having "system restore points" for individual configuration files in /etc :-). You have to know how to use a version control system though).

While researching this I came across several posts that describe similar symptoms but apparently with different causes. Examples of these are this blog entry and this question on Superuser SE, both tracking this issue to a faulty swap partition / entry in fstab. The excerpt from the bootlog however leads me to believe that these are not related to my particular problem.

Fair. It's a very closely related problem though. You have a device which is listed as being required for the boot process. Therefore your boot waits to find it. After a timeout, the device is considered failed.

(According to my documentation, the boot process should also require this device, meaning that a failure or timeout will boot into the emergency.target shell, instead of default.target). crypttab even supports the same named options as in fstab to modify this behaviour: noauto, nofail, and x-systemd.device-timeout=....

For fstab entries, systemd generates .mount and .swap units. For crypttab entries, it just generates an instance of a template .service unit, [email protected].

The .device unit appears in systemd because it needs something to represent that it is waiting for a matching device. This is expected behaviour.

the boot log, which showed the start job for a device timing out and directly afterwards failing the cryptography setup of a device referenced as cr_usb-General_USB_Flash_Disk. I am unsure whether the two are connected.

They are. The UUID of the timed-out device is the same as the UUID the crypttab lists as belonging to this USB flash disk. EDIT: ah, you meant the slow bootup. Yes, absolutely.


[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-00a69115\x2d956d\x2d41b3\x2d830c\x2d9a3878087d41.device.
[DEPEND] Dependency failed for Cryptography Setup for cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2.

/etc/crypttab

cr_sda2 UUID=7f99168c-4972-468b-900f-fb5bbfb90e66
cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2 UUID=00a69115-956d-41b3-83

added 178 characters in body
Source Link
sourcejedi
  • 53.5k
  • 23
  • 178
  • 336
  • How can I determine what device this is?

You can double-check this device is not present using a list of UUIDs... the The commands you'veyou already used to list them are fine. The device logic is driven by udev, which uses blkid internally.

  • Can it be safely removed from startup and if so, how?

You can create a backup copy of crypttab and then remove the line, or add a # at the start of the line to comment it out.

(I like to use etckeeper, it's like having "system restore points" for individual configuration files in /etc :-). It relies on you knowing Git You have to know how to use a version control system though).

While researching this I came across several posts that describe similar symptoms but apparently with different causes. Examples of these are this blog entry and this question on Superuser SE, both tracking this issue to a faulty swap partition / entry in fstab. The excerpt from the bootlog however leads me to believe that these are not related to my particular problem.

Fair. It's a very closely related problem though. You have a device which is listed as being required for the boot process. Therefore your boot waits to find it. After a timeout, the device is considerconsidered failed.

(According to my documentation, the boot process should also require this device, meaning that a failure or timeout will boot into the emergency.target shell, instead of default.target). crypttab even supports the same named options as in fstab to modify this behaviour: noauto, nofail, and x-systemd.device-timeout=....

For fstab entries, systemd generates .mount and .swap units. For crypttab entries, it just generates an instance of a template .service unit, [email protected].

The .device unit appears in systemd because it needs something to represent that it is waiting for a matching device. This is expected behaviour.

the boot log, which showed the start job for a device timing out and directly afterwards failing the cryptography setup of a device referenced as cr_usb-General_USB_Flash_Disk. I am unsure whether the two are connected.

They are. The UUID of the timed-out device is the same as the UUID the crypttab lists as belonging to this USB flash disk. EDIT: ah, you meant the slow bootup. Yes, absolutely.


[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-00a69115\x2d956d\x2d41b3\x2d830c\x2d9a3878087d41.device.
[DEPEND] Dependency failed for Cryptography Setup for cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2.

/etc/crypttab

cr_sda2 UUID=7f99168c-4972-468b-900f-fb5bbfb90e66
cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2 UUID=00a69115-956d-41b3-83

  • How can I determine what device this is?

You can double-check this device is not present using a list of UUIDs... the commands you've already used to list them are fine.

  • Can it be safely removed from startup and if so, how?

You can create a backup copy of crypttab and then remove the line, or add a # at the start of the line to comment it out.

(I like to use etckeeper, it's like having "system restore points" for individual configuration files in /etc :-). It relies on you knowing Git though).

While researching this I came across several posts that describe similar symptoms but apparently with different causes. Examples of these are this blog entry and this question on Superuser SE, both tracking this issue to a faulty swap partition / entry in fstab. The excerpt from the bootlog however leads me to believe that these are not related to my particular problem.

Fair. It's a very closely related problem though. You have a device which is listed as being required for the boot process. Therefore your boot waits to find it. After a timeout, the device is consider failed.

(According to my documentation, the boot process should also require this device, meaning that a failure or timeout will boot into the emergency.target shell, instead of default.target). crypttab even supports the same named options as in fstab to modify this behaviour: noauto, nofail, and x-systemd.device-timeout=....

For fstab entries, systemd generates .mount and .swap units. For crypttab entries, it just generates an instance of a template .service unit, [email protected].

the boot log, which showed the start job for a device timing out and directly afterwards failing the cryptography setup of a device referenced as cr_usb-General_USB_Flash_Disk. I am unsure whether the two are connected.

They are. The UUID of the timed-out device is the same as the UUID the crypttab lists as belonging to this USB flash disk. EDIT: ah, you meant the slow bootup. Yes, absolutely.


[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-00a69115\x2d956d\x2d41b3\x2d830c\x2d9a3878087d41.device.
[DEPEND] Dependency failed for Cryptography Setup for cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2.

/etc/crypttab

cr_sda2 UUID=7f99168c-4972-468b-900f-fb5bbfb90e66
cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2 UUID=00a69115-956d-41b3-83

  • How can I determine what device this is?

You can double-check this device is not present using a list of UUIDs. The commands you already used to list them are fine. The device logic is driven by udev, which uses blkid internally.

  • Can it be safely removed from startup and if so, how?

You can create a backup copy of crypttab and then remove the line, or add a # at the start of the line to comment it out.

(I like to use etckeeper, it's like having "system restore points" for individual configuration files in /etc :-). You have to know how to use a version control system though).

While researching this I came across several posts that describe similar symptoms but apparently with different causes. Examples of these are this blog entry and this question on Superuser SE, both tracking this issue to a faulty swap partition / entry in fstab. The excerpt from the bootlog however leads me to believe that these are not related to my particular problem.

Fair. It's a very closely related problem though. You have a device which is listed as being required for the boot process. Therefore your boot waits to find it. After a timeout, the device is considered failed.

(According to my documentation, the boot process should also require this device, meaning that a failure or timeout will boot into the emergency.target shell, instead of default.target). crypttab even supports the same named options as in fstab to modify this behaviour: noauto, nofail, and x-systemd.device-timeout=....

For fstab entries, systemd generates .mount and .swap units. For crypttab entries, it just generates an instance of a template .service unit, [email protected].

The .device unit appears in systemd because it needs something to represent that it is waiting for a matching device. This is expected behaviour.

the boot log, which showed the start job for a device timing out and directly afterwards failing the cryptography setup of a device referenced as cr_usb-General_USB_Flash_Disk. I am unsure whether the two are connected.

They are. The UUID of the timed-out device is the same as the UUID the crypttab lists as belonging to this USB flash disk. EDIT: ah, you meant the slow bootup. Yes, absolutely.


[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-00a69115\x2d956d\x2d41b3\x2d830c\x2d9a3878087d41.device.
[DEPEND] Dependency failed for Cryptography Setup for cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2.

/etc/crypttab

cr_sda2 UUID=7f99168c-4972-468b-900f-fb5bbfb90e66
cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2 UUID=00a69115-956d-41b3-83

added 178 characters in body
Source Link
sourcejedi
  • 53.5k
  • 23
  • 178
  • 336
  • How can I determine what device this is?

You can double-check this device is not present using a list of UUIDs... the commands you've already used to list them are fine.

  • Can it be safely removed from startup and if so, how?

You can create a backup copy of crypttab and then remove the line, or add a # at the start of the line to comment it out.

(I like to use etckeeper, it's like having "system restore points" for individual configuration files in /etc :-). It relies on you knowing Git though).

While researching this I came across several posts that describe similar symptoms but apparently with different causes. Examples of these are this blog entry and this question on Superuser SE, both tracking this issue to a faulty swap partition / entry in fstab. The excerpt from the bootlog however leads me to believe that these are not related to my particular problem.

Fair. It's a very closely related problem though. You have a device which is listed as being required for the boot process. Therefore your boot waits forto find it.   After a timeout, the device is consider failed.

(According to my documentation, the boot process should also require this device, meaning that a failure or timeout will boot into the emergency.target shell, instead of default.target). crypttab even supports the same named options as in fstab to modify this behaviour: noauto, nofail, and x-systemd.device-timeout=....

For fstab entries, systemd generates .mount and .swap units. For crypttab entries, it just generates an instance of a template .service unit, [email protected].

the boot log, which showed the start job for a device timing out and directly afterwards failing the cryptography setup of a device referenced as cr_usb-General_USB_Flash_Disk. I am unsure whether the two are connected.

They are. (The The UUID of the timed-out device is the same as the UUID the crypttab lists as belonging to this USB flash disk). EDIT: ah, you meant the slow bootup. Yes, absolutely.


[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-00a69115\x2d956d\x2d41b3\x2d830c\x2d9a3878087d41.device.
[DEPEND] Dependency failed for Cryptography Setup for cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2.

/etc/crypttab

cr_sda2 UUID=7f99168c-4972-468b-900f-fb5bbfb90e66
cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2 UUID=00a69115-956d-41b3-83

  • How can I determine what device this is?

You can double-check this device is not present using a list of UUIDs... the commands you've already used to list them are fine.

  • Can it be safely removed from startup and if so, how?

You can create a backup copy of crypttab and then remove the line, or add a # at the start of the line to comment it out.

(I like to use etckeeper, it's like having "system restore points" for individual configuration files in /etc :-). It relies on you knowing Git though).

While researching this I came across several posts that describe similar symptoms but apparently with different causes. Examples of these are this blog entry and this question on Superuser SE, both tracking this issue to a faulty swap partition / entry in fstab. The excerpt from the bootlog however leads me to believe that these are not related to my particular problem.

Fair. It's a very closely related problem though. You have a device which is listed as being required for the boot process. Therefore your boot waits for it.  (According to my documentation, the boot process should also require this device, meaning that a failure or timeout will boot into the emergency.target shell, instead of default.target). crypttab even supports the same named options as in fstab to modify this behaviour: noauto, nofail, and x-systemd.device-timeout=....

For fstab entries, systemd generates .mount and .swap units. For crypttab entries, it just generates an instance of a template .service unit, [email protected].

the boot log, which showed the start job for a device timing out and directly afterwards failing the cryptography setup of a device referenced as cr_usb-General_USB_Flash_Disk. I am unsure whether the two are connected.

They are. (The UUID of the timed-out device is the same as the UUID the crypttab lists as belonging to this USB flash disk).


[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-00a69115\x2d956d\x2d41b3\x2d830c\x2d9a3878087d41.device.
[DEPEND] Dependency failed for Cryptography Setup for cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2.

/etc/crypttab

cr_sda2 UUID=7f99168c-4972-468b-900f-fb5bbfb90e66
cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2 UUID=00a69115-956d-41b3-83

  • How can I determine what device this is?

You can double-check this device is not present using a list of UUIDs... the commands you've already used to list them are fine.

  • Can it be safely removed from startup and if so, how?

You can create a backup copy of crypttab and then remove the line, or add a # at the start of the line to comment it out.

(I like to use etckeeper, it's like having "system restore points" for individual configuration files in /etc :-). It relies on you knowing Git though).

While researching this I came across several posts that describe similar symptoms but apparently with different causes. Examples of these are this blog entry and this question on Superuser SE, both tracking this issue to a faulty swap partition / entry in fstab. The excerpt from the bootlog however leads me to believe that these are not related to my particular problem.

Fair. It's a very closely related problem though. You have a device which is listed as being required for the boot process. Therefore your boot waits to find it. After a timeout, the device is consider failed.

(According to my documentation, the boot process should also require this device, meaning that a failure or timeout will boot into the emergency.target shell, instead of default.target). crypttab even supports the same named options as in fstab to modify this behaviour: noauto, nofail, and x-systemd.device-timeout=....

For fstab entries, systemd generates .mount and .swap units. For crypttab entries, it just generates an instance of a template .service unit, [email protected].

the boot log, which showed the start job for a device timing out and directly afterwards failing the cryptography setup of a device referenced as cr_usb-General_USB_Flash_Disk. I am unsure whether the two are connected.

They are. The UUID of the timed-out device is the same as the UUID the crypttab lists as belonging to this USB flash disk. EDIT: ah, you meant the slow bootup. Yes, absolutely.


[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-00a69115\x2d956d\x2d41b3\x2d830c\x2d9a3878087d41.device.
[DEPEND] Dependency failed for Cryptography Setup for cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2.

/etc/crypttab

cr_sda2 UUID=7f99168c-4972-468b-900f-fb5bbfb90e66
cr_usb-General_USB_Flash_Disk_0349315060001623-0:0-part2 UUID=00a69115-956d-41b3-83

added 178 characters in body
Source Link
sourcejedi
  • 53.5k
  • 23
  • 178
  • 336
Loading
added 254 characters in body
Source Link
sourcejedi
  • 53.5k
  • 23
  • 178
  • 336
Loading
added 37 characters in body
Source Link
sourcejedi
  • 53.5k
  • 23
  • 178
  • 336
Loading
added 37 characters in body
Source Link
sourcejedi
  • 53.5k
  • 23
  • 178
  • 336
Loading
Source Link
sourcejedi
  • 53.5k
  • 23
  • 178
  • 336
Loading