Re: An answer to "Gave up waiting for suspend/resume device"
It worked for me too. Thanks a lot!
Re: An answer to "Gave up waiting for suspend/resume device"
Le 29/09/2017 à 18:31, Larry Dighera a écrit : Note what occurs when there is no image in the swap FS and initramfs is expecting to find one. A swap is not a filesystem. The initramfs does not expect to find a hibernation image. If the swap contains a hibernation image then it is used to resume the system. Otherwise the normal boot proceeds.
Re: An answer to "Gave up waiting for suspend/resume device"
On Sat, 23 Sep 2017 04:42:07 + (UTC), Mark Luxton <truthseek...@yahoo.ca> wrote: >RE:Re: Gave up waiting for suspend/resume device > > >| >| | >Re: Gave up waiting for suspend/resume device > | | > > | > > > >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. >Truly, Mark Luxton Note what occurs when there is no image in the swap FS and initramfs is expecting to find one.
Re: An answer to "Gave up waiting for suspend/resume device"
On Thu 28 Sep 2017 at 10:29:27 (+0200), Pascal Hambourg wrote: > Le 28/09/2017 à 09:39, Jimmy Johnson a écrit : > >On 09/27/2017 02:38 AM, Pascal Hambourg wrote: > >>Le 27/09/2017 à 10:37, Jimmy Johnson a écrit : > > > >>> But if everything is correct and you are using lets say sda1 > >>>as root in your fstab your system will use sda1 as the LABEL, > >>>I've seen this over and over. > >> > >>Nonsense. sda1 is the block device name and does not have > >>anything to do with the LABEL which is a filesystem metadata > >>field. > >> > >>>But all this is advanced setup for people running more than > >>>one Linux system and having to edit UUID on all systems > >>>because you install a new system is undesirable. > >> > >>No it does not have anything to do with multiple Linux systems. > > > >In fstab a label is used as a device name, a uuid is used as a > >device name and /dev/sda1 is a device name, you are just trying to > >make nonsense out of nothing. > > A label or a UUID are not really used as device names, they are used > *instead* of a device name. > > Anyway, this is not the same as what you wrote earlier and is pure > nonsense : > > "your system will use sda1 as the LABEL" > > Unless you meant "define 'sda1' as the filesystem/swap label and use > LABEL='sda1' in /etc/fstab", which is a really bad use of labels > leading to confusion between labels and device names. Labels are > meant to be explicit about the contents, not the container. > > >And editing multiple fstab config files because I've installed a > >new system is, like I said undesirable and why I use device names > >in both my fstab and grub boot menu. As you know when a new > >system is installed swap is formatted and it's uuid gets changed > >every time it's formatted. > > The Debian installer does this, but I am not sure that all other > distro installers do the same. Moreover, the Debian installer will > format an existing swap only if that swap is marked for use (the > trick is that all existing swaps are automatically marked for use by > default, so you have to pay attention and unmark them if you do not > want them to be formatted). IMO this is a real bug in the installer. > > So my general policy when installing Debian is to mark any existing > swap as "not used", and if I want to share an existing swap, I add > the line manually in /etc/fstab in the new system after the > installation. In the past I have used the VC2 shell to swapon immediately the partitioner has formatted the partitions (but not swap), ie just before "Install the base system". This has never caused a problem for me, but the Installation Guide says: "In particular, you should always use [sic] let the installer activate your swap partition and not do this yourself from a shell." (§6.3.8.2) Any idea why? Cheers, David.
Re: An answer to "Gave up waiting for suspend/resume device"
Le 28/09/2017 à 09:39, Jimmy Johnson a écrit : On 09/27/2017 02:38 AM, Pascal Hambourg wrote: Le 27/09/2017 à 10:37, Jimmy Johnson a écrit : But if everything is correct and you are using lets say sda1 as root in your fstab your system will use sda1 as the LABEL, I've seen this over and over. Nonsense. sda1 is the block device name and does not have anything to do with the LABEL which is a filesystem metadata field. But all this is advanced setup for people running more than one Linux system and having to edit UUID on all systems because you install a new system is undesirable. No it does not have anything to do with multiple Linux systems. In fstab a label is used as a device name, a uuid is used as a device name and /dev/sda1 is a device name, you are just trying to make nonsense out of nothing. A label or a UUID are not really used as device names, they are used *instead* of a device name. Anyway, this is not the same as what you wrote earlier and is pure nonsense : "your system will use sda1 as the LABEL" Unless you meant "define 'sda1' as the filesystem/swap label and use LABEL='sda1' in /etc/fstab", which is a really bad use of labels leading to confusion between labels and device names. Labels are meant to be explicit about the contents, not the container. And editing multiple fstab config files because I've installed a new system is, like I said undesirable and why I use device names in both my fstab and grub boot menu. As you know when a new system is installed swap is formatted and it's uuid gets changed every time it's formatted. The Debian installer does this, but I am not sure that all other distro installers do the same. Moreover, the Debian installer will format an existing swap only if that swap is marked for use (the trick is that all existing swaps are automatically marked for use by default, so you have to pay attention and unmark them if you do not want them to be formatted). IMO this is a real bug in the installer. So my general policy when installing Debian is to mark any existing swap as "not used", and if I want to share an existing swap, I add the line manually in /etc/fstab in the new system after the installation. To address this swap sharing issue you may be interested in the GPT partition scheme : among other advantages, it supports partition labels and UUIDs (PARTLABEL and PARTUUID) which are independent of the contents of the partition, so they do not change when the partition is formatted. Debian supports them in /etc/fstab since Jessie. Recent kernel emulates partition UUIDs with legacy MBR/DOS partition scheme, but they are less reliable because these PARTUUID contain the partition number, and logical partitions may be renumbered after creating or removing another logical partition. That is another reason not to use logical partition device names in /etc/fstab.
Re: An answer to "Gave up waiting for suspend/resume device"
On 09/27/2017 02:38 AM, Pascal Hambourg wrote: Le 27/09/2017 à 10:37, Jimmy Johnson a écrit : On 09/26/2017 02:25 AM, Pascal Hambourg wrote: Le 26/09/2017 à 03:55, Jimmy Johnson a écrit : Hi Mark, while multi-booting I use the device name in fstab, /dev/sd?? none swap sw 0 0, it works for all my installed systems. It is not always reliable with multiple drives, because device names are not stable across reboots. So it is advised to use persistent identifiers such as UUID or LABEL instead. Yes, what you say is true, but not very often and from what I've seen is due to mainboard setup or defects in the mainboard causing the bad setup due to mainboard SATA connection being mislabeled. No, it is due to the asynchronous nature of device probing and module loading by the kernel and udev in modern Linux systems. Could be but I've only seen that problem on two computers out of easily more than 1000 and one of those was a mislabeled main board under warranty and the computer was replaced with another model and the other computer has taken out of service. But if everything is correct and you are using lets say sda1 as root in your fstab your system will use sda1 as the LABEL, I've seen this over and over. Nonsense. sda1 is the block device name and does not have anything to do with the LABEL which is a filesystem metadata field. But all this is advanced setup for people running more than one Linux system and having to edit UUID on all systems because you install a new system is undesirable. No it does not have anything to do with multiple Linux systems. In fstab a label is used as a device name, a uuid is used as a device name and /dev/sda1 is a device name, you are just trying to make nonsense out of nothing. And editing multiple fstab config files because I've installed a new system is, like I said undesirable and why I use device names in both my fstab and grub boot menu. As you know when a new system is installed swap is formatted and it's uuid gets changed every time it's formatted. I do use labels on external plug and play drives though. -- Jimmy Johnson Debian Stretch - KDE Plasma 5.8.6 - AMD A8-7600 - EXT4 at sda6 Registered Linux User #380263
Re: An answer to "Gave up waiting for suspend/resume device"
Le 27/09/2017 à 10:37, Jimmy Johnson a écrit : On 09/26/2017 02:25 AM, Pascal Hambourg wrote: Le 26/09/2017 à 03:55, Jimmy Johnson a écrit : Hi Mark, while multi-booting I use the device name in fstab, /dev/sd?? none swap sw 0 0, it works for all my installed systems. It is not always reliable with multiple drives, because device names are not stable across reboots. So it is advised to use persistent identifiers such as UUID or LABEL instead. Yes, what you say is true, but not very often and from what I've seen is due to mainboard setup or defects in the mainboard causing the bad setup due to mainboard SATA connection being mislabeled. No, it is due to the asynchronous nature of device probing and module loading by the kernel and udev in modern Linux systems. But if everything is correct and you are using lets say sda1 as root in your fstab your system will use sda1 as the LABEL, I've seen this over and over. Nonsense. sda1 is the block device name and does not have anything to do with the LABEL which is a filesystem metadata field. But all this is advanced setup for people running more than one Linux system and having to edit UUID on all systems because you install a new system is undesirable. No it does not have anything to do with multiple Linux systems.
Re: An answer to "Gave up waiting for suspend/resume device"
On 09/26/2017 02:25 AM, Pascal Hambourg wrote: Le 26/09/2017 à 03:55, Jimmy Johnson a écrit : Hi Mark, while multi-booting I use the device name in fstab, /dev/sd?? none swap sw 0 0, it works for all my installed systems. It is not always reliable with multiple drives, because device names are not stable across reboots. So it is advised to use persistent identifiers such as UUID or LABEL instead. Yes, what you say is true, but not very often and from what I've seen is due to mainboard setup or defects in the mainboard causing the bad setup due to mainboard SATA connection being mislabeled. But if everything is correct and you are using lets say sda1 as root in your fstab your system will use sda1 as the LABEL, I've seen this over and over. But all this is advanced setup for people running more than one Linux system and having to edit UUID on all systems because you install a new system is undesirable. -- Jimmy Johnson Debian Stretch - KDE Plasma 5.8.6 - AMD A8-7600 - EXT4 at sda6 Registered Linux User #380263
Re: An answer to "Gave up waiting for suspend/resume device"
Le 26/09/2017 à 03:55, Jimmy Johnson a écrit : Hi Mark, while multi-booting I use the device name in fstab, /dev/sd?? none swap sw 0 0, it works for all my installed systems. It is not always reliable with multiple drives, because device names are not stable across reboots. So it is advised to use persistent identifiers such as UUID or LABEL instead.
Re: An answer to "Gave up waiting for suspend/resume device"
On 09/22/2017 09:42 PM, Mark Luxton wrote: RE:Re: Gave up waiting for suspend/resume device | | | Re: Gave up waiting for suspend/resume device | | | 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. Truly, Mark Luxton Hi Mark, while multi-booting I use the device name in fstab, /dev/sd?? none swap sw 0 0, it works for all my installed systems. -- Jimmy Johnson Debian Stretch - KDE Plasma 5.8.6 - Intel i7-3540M - EXT4 at sda6 Registered Linux User #380263
An answer to "Gave up waiting for suspend/resume device"
RE:Re: Gave up waiting for suspend/resume device | | | Re: Gave up waiting for suspend/resume device | | | 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. Truly, Mark Luxton
Re: Gave up waiting for suspend/resume device
On 08/17/17 17:20, Ben Caradoc-Davies wrote: On 18/08/17 11:27, David Christensen wrote: On 08/17/17 00:44, Curt wrote: On 2017-08-17, David Christensen <dpchr...@holgerdanske.com> wrote: Is there a configuration file I can edit so that the kernel does not wait 30 seconds on boot for a suspend/resume device? "kernel parameter 'noresume' or 'resume='" Into which file do I put one of those options? I would put it in /etc/default/grub; for example, mine contains: GRUB_CMDLINE_LINUX="quiet" I would change this to: GRUB_CMDLINE_LINUX="quiet noresume" After changing /etc/default/grub, run "update-grub" to regenerate /boot/grub/grub.cfg. That worked -- thank you. :-) David
Re: Gave up waiting for suspend/resume device
On 18/08/17 11:27, David Christensen wrote: On 08/17/17 00:44, Curt wrote: On 2017-08-17, David Christensen <dpchr...@holgerdanske.com> wrote: Is there a configuration file I can edit so that the kernel does not wait 30 seconds on boot for a suspend/resume device? "kernel parameter 'noresume' or 'resume='" Into which file do I put one of those options? David I would put it in /etc/default/grub; for example, mine contains: GRUB_CMDLINE_LINUX="quiet" I would change this to: GRUB_CMDLINE_LINUX="quiet noresume" After changing /etc/default/grub, run "update-grub" to regenerate /boot/grub/grub.cfg. Kind regards, -- Ben Caradoc-Davies <b...@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand
Re: Gave up waiting for suspend/resume device
On 08/17/17 00:44, Curt wrote: On 2017-08-17, David Christensen <dpchr...@holgerdanske.com> wrote: Is there a configuration file I can edit so that the kernel does not wait 30 seconds on boot for a suspend/resume device? "kernel parameter 'noresume' or 'resume='" Into which file do I put one of those options? David
Re: Gave up waiting for suspend/resume device
On 2017-08-17, David Christensen <dpchr...@holgerdanske.com> wrote: > debian-user: > > I have recently installed: > > 2017-08-16 18:35:17 dpchrist@tinkywinky ~ > $ cat /etc/debian_version > 9.1 > > 2017-08-16 18:36:03 dpchrist@tinkywinky ~ > $ uname -a > Linux tinkywinky 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 > (2017-08-06) x86_64 GNU/Linux > > > on a few older machines (Pentium D 945, Core 2 Duo T7400) with > unencrypted /boot, encrypted swap, and encrypted root partitions. > > > When booting every machine, after I enter the LUKS passphrase, there is > a ~30 second pause and then the subject message appears: > > Gave up waiting for suspend/resume device > > > As I don't use suspend (or hibernate). > > > STFW, apparently this is a feature, not a bug: > > https://duckduckgo.com/?q=gave+up+waiting+for+suspend%2Fresume+device=ffsb=web Maybe it is a bug rather than a feature: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860543#22 > Is there a configuration file I can edit so that the kernel does not > wait 30 seconds on boot for a suspend/resume device? "kernel parameter 'noresume' or 'resume='" > David > > -- "One can remain alive long past the usual date of disintegration if one is unafraid of change, insatiable in intellectual curiosity, interested in big things, and happy in small things." — Edith Wharton
Gave up waiting for suspend/resume device
debian-user: I have recently installed: 2017-08-16 18:35:17 dpchrist@tinkywinky ~ $ cat /etc/debian_version 9.1 2017-08-16 18:36:03 dpchrist@tinkywinky ~ $ uname -a Linux tinkywinky 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux on a few older machines (Pentium D 945, Core 2 Duo T7400) with unencrypted /boot, encrypted swap, and encrypted root partitions. When booting every machine, after I enter the LUKS passphrase, there is a ~30 second pause and then the subject message appears: Gave up waiting for suspend/resume device As I don't use suspend (or hibernate). STFW, apparently this is a feature, not a bug: https://duckduckgo.com/?q=gave+up+waiting+for+suspend%2Fresume+device=ffsb=web Is there a configuration file I can edit so that the kernel does not wait 30 seconds on boot for a suspend/resume device? David
Re: Bug#860543: 'Gave up waiting for suspend/resume device'
Hello Ben, Thank you for your prompt response to my inquiry, and your kind assistance. My comments in-line below: On Sat, 13 May 2017 00:40:47 +0100, Ben Hutchings <b...@decadent.org.uk> wrote: >On Fri, 2017-05-12 at 21:26 +, Larry Dighera wrote: >> Dear Mr. Hutchings, >> Todays update appears to have caused my Debian Stretch Linux system >> to fail to boot with this error message: >> >> "Gave up waiting for suspend/resume device..." > >That (by itself) does not indicate a boot failure; it only means that >resume from disk (hibernation) won't work. > Previous to the update, hibernation worked. > >Do any messages appear afterward? > Yes. There is a bit after that. "Gave up waiting for root file system device" or "Gave up waiting for suspend/resume device" Then some suggestions presumably about how to address the issue: "Boot Args. Cat /proc/cmdline" something about "check root delay" perhaps not long enough... missing modules..." "UUID 2d182fb2... doesn't exist." > >> The Grub menu is still accessible, but I'm clueless how to return the >> system to operational status. >> Please provide complete step-by-step instructions to restore >> successful system booting through the Grub menu. > >One of the 'recovery mode' item under Advanced Options will enable >verbose logging to the screen and will perhaps get you to a shell. > Unfortunately, selecting the 'recovery mode' grub menu option is useless. There is something about 'busybox' and a '(initramfs)' prompt(?), but the system fails to respond to keyboard or mouse input at that point. So 'recovery mode' appears to be useless. However, by entering 'e' at the grub menu, I can edit the 'command line. At your suggestion above, I changed 'quite' to 'verbose', but nothing seems to have changed when rebooting. By entering 'c' at the grub menu, I can get a 'Grub>' prompt from which I am able to 'ls' and 'cat' and probably a hundred or more other commands that can be displayed with the 'help' command. It is necessary to enter 'set pager=1' to see them before they scroll off screen. Entering 'help ' provides some additional terse (cryptic) information about the command. I don't find any sort of editing command, and redirection '>>' attempts fail. Can you give me a clue to necessary commands to go about returning my system to operational status from this 'Grub>' prompt? > >In any case, you should open a *new* bug report rather than appending >to this one. > >Ben. It was not my intent to open a bug report at all. I apologize for any issue I may have caused. In the information at this link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860543 you stated: "Is there a resume device specified in /etc/initramfs-tools/conf.d/resume and does it exist?" I found /etc/initramfs-tools/conf.d/resume. It contains the single entry: "RESUME=UUID=f5aa19f3-7707-4bab-bd18-15d6124a0147" I have no idea where to find that file/device/?. I just want my system to boot again. Please assist me in reaching that goal. Best regards, Larry PS: On that page, you also stated: > ... > /etc/initramfs-tools/conf.d/resume exists and did not contain a valid > device. The problem still persists, if I enter a valid UUID, or remove > the file. This issue should only affect systems that have a nonexistent device specified in the configuration, or that have a swap device that isn't suitable as a resume device because it's not set up early enough. Previously we would only look for the resume device once, so this didn't hurt, but it also meant that resume was broken on some systems. Unfortunately, as you've seen, there isn't currently a way to completely disable use of a resume device when building the initramfs. It *is* possible to do so at boot time (kernel parameter 'noresume' or 'resume='). I think I need to add: - The option to disable use of a resume device in the configuration (e.g. RESUME=none) - A warning on upgrade if the configured resume device doesn't exist or is unlikely to be available Ben. Is that what I need to do? If so, please provide step-by-step keystrokes I need to enter at the "Grub>" prompt.
'Gave up waiting for suspend/resume device'
Dear Mr. Hutchings, Todays update appears to have caused my Debian Stretch Linux system to fail to boot with this error message: "Gave up waiting for suspend/resume device..." The Grub menu is still accessible, but I'm clueless how to return the system to operational status. Please provide complete step-by-step instructions to restore successful system booting through the Grub menu. As the eMMC flash memory on which the Linux system resides in soldered to the PC board, mounting it on another system for editing is not feasible. REF: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860543 Thank you for your assistance. Best regards,Larry Dighera
Re: suspend/resume device
> That "apt-listchanges" package comes in handy thanks for that tip, I have it installed now. -- CK pgp0IIh2byNkp.pgp Description: OpenPGP digital signature
Re: suspend/resume device [SOLVED]
thank you Cindy-Sue, I did have both of those files but the one with RESUME in it and it did list a mysterious UUID device number (I don't know where it got that as this is a desktop but it does get a lot of dist-upgrades I'll admit) so that's the one I removed and added 'none' in its place. the other file /etc/initramfs-tools/initramfs.conf didn't mention the resume device, so it had its own file. (maybe I should just remove that file?) anyway, well done you and all the best. -- CK pgpujxbhJDiQS.pgp Description: OpenPGP digital signature
Re: suspend/resume device
On 5/5/17, Charles Kroeger <ckro...@frankensteinface.com> wrote:
> on a normal boot I get a long wait (30 seconds +-) whilst the cursor winks
> then
> the message: waiting on suspend/resume device, before resuming the steps to
> boot to a login prompt.
Your words, "boot", "wait", and "30 seconds" there triggered this
response. Did you do any upgrades in last couple days? This may not
affect others but on Stretch, I received the following
"apt-listchanges" auto-generated message that I knew was one of those
"keeper" kind of things:
BEGIN apt-listchanges: News MESSAGE
initramfs-tools (0.129) unstable; urgency=medium
* Some systems that do not support suspend-to-disk (hibernation) will
require a configuration change to explicitly disable this.
From version 0.128, the boot code waits for a suspend/resume device
to appear, rather than checking just once. If the configured or
automatically selected resume device is not available at boot time,
this results in a roughly 30 second delay.
You should set the RESUME variable in
/etc/initramfs-tools/conf.d/resume or
/etc/initramfs-tools/initramfs.conf to one of:
- auto - select the resume device automatically
- none - disable use of a resume device
- UUID= - use a specific resume device (by UUID)
- /dev/ - use a specific resume device (by kernel name)
-- Ben Hutchings <b...@decadent.org.uk> Thu, 20 Apr 2017 23:21:32
+0100
END apt-listchanges: News MESSAGE
That "apt-listchanges" package comes in handy for putting that type of
information right in your face during upgrades.
Hope that helps someone somewhere some day... :)
Cindy :)
--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with plastic sporks *
suspend/resume device
on a normal boot I get a long wait (30 seconds +-) whilst the cursor winks then the message: waiting on suspend/resume device, before resuming the steps to boot to a login prompt. -- CK pgpPyMPjo4Wft.pgp Description: OpenPGP digital signature
Re: multiple drives, 'Gave up waiting for suspend/resume device'
craigswin composed on 2017-04-25 04:41 (UTC-0700): > For a desktop install from a thumbdrive of testing RC3, there were three > drives plugged in to the motherboard. One drive was the installation > target. The other two had old installs, RC3 and Wheezy. > > Bizarrely, the resulting fstab has two swap partitions. One from the > target drive, and a second from one of the accessory drives. I > commented the second swap line out of the fstab. The new installation > boots fine with or without the second swap as long as all three drives > are attached. > > All other references in fstab to the target drive. > > If remove one of the drives, the new install has problems booting with > or without the second swap. Booting takes a very long time, etc... One > message is 'Gave up waiting for suspend/resume device'. > > Here is a possibly related thread: > https://mail-archive.com/debian-bugs-dist@lists.debian.org/msg1513355.html > > When the boot menu appears, grub, there are options to boot the new > install, but also additional options to boot the old installs on the > accessory drives, even if those drives are not attached. > > What is going on? How can I fix it? Or should I just redo the > installation with only the target drive attached? Looks to me like this may be a manifestation of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860543 just fixed yesterday. Have you tried including noresume on your kernel cmdline? Have you updated and rebuilt initrd since that bug fix reached the mirrors? Do both of the other installations still boot normally (no swap waits) since completing the new installation? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
multiple drives, 'Gave up waiting for suspend/resume device'
For a desktop install from a thumbdrive of testing RC3, there were three drives plugged in to the motherboard. One drive was the installation target. The other two had old installs, RC3 and Wheezy. Bizarrely, the resulting fstab has two swap partitions. One from the target drive, and a second from one of the accessory drives. I commented the second swap line out of the fstab. The new installation boots fine with or without the second swap as long as all three drives are attached. All other references in fstab to the target drive. If remove one of the drives, the new install has problems booting with or without the second swap. Booting takes a very long time, etc... One message is 'Gave up waiting for suspend/resume device'. Here is a possibly related thread: https://mail-archive.com/debian-bugs-dist@lists.debian.org/msg1513355.html When the boot menu appears, grub, there are options to boot the new install, but also additional options to boot the old installs on the accessory drives, even if those drives are not attached. What is going on? How can I fix it? Or should I just redo the installation with only the target drive attached?
