Subject: Jessie (8.0) slow to boot

From: Richard Owlett <[email-masked]>
Date: Wed, 31 Aug 2016 09:16:00 -0500

I have Jessie installed on a desktop and a laptop. They both take 
about 105-110 seconds to boot. Squeeze on the desktop takes ~15 
seconds to boot.

Most of the delay seems to be in something that states approximately
"A start job is running for dev-disk-by\x2duuid?????.device (ttttt}"
Where ????? is a long alphanumeric string
       ttttt is a timer display
That is followed by two message identified as "Warning" in bright 
yellow.[they pass by to fast to read].

What's going on?
Are the messages that scroll past preserved anywhere?
TIA

---

From: Alan McConnell <[email-masked]>
Date: Wed, 31 Aug 2016 14:49:05 -0400

On Wed, Aug 31, 2016 at 09:16:00AM -0500, Richard Owlett wrote:
> I have Jessie installed on a desktop and a laptop. They both take about
> 105-110 seconds to boot. Squeeze on the desktop takes ~15 seconds to boot.
  	  My jessie install also takes a long time to boot.  A lot of it
	  is because of attempts to start/stop/do something with
	  COMRESET.  Eventually, after a minute, the boot process 'gives
	  up'.

	  What is COMRESET?  What does it do? can I get rid of these
	  attempts?

TIA for anticipated information/help.

Alan McConnell

-- 
Alan McConnell :  http://globaltap.com/~alan/
      Memory says, "I did that."  Pride replies, "I could not have
      done that."  Eventually, Memory yields.(Friederich Nietzsche)

---

From: Darac Marjal <[email-masked]>
Date: Thu, 1 Sep 2016 10:09:56 +0100

>	  What is COMRESET?  What does it do? can I get rid of these

A quick search of the internet leads me to 
https://askubuntu.com/questions/174137/should-i-be-concerned-about-comreset-errors-with-my-ssd 
which suggests that COMRESET is the kernel RESETing COMmunications with 
an ata device (a hard disk). If you have one message, such as the linked 
poster had, then it's probably not a problem. If you see a lot of them, 
then you may have a bad cable (or a bad hard disk, or a bad disk 
controller).

-- 
For more information, please reread.

---

From: Darac Marjal <[email-masked]>
Date: Wed, 31 Aug 2016 16:00:18 +0100

>yellow.[they pass by to fast to read].

UUID is considered to be the most reliable way to locate a disk, given 
modern kernels' asynchronous device discovery. It is no longer 
considered "safe" to assume that /dev/sda is your main hard drive. On 
small systems, it probably won't change, but if you have several drives, 
they can start at different times, and the order in which they get 
enumerated may change. Therefore, Linux now tends to refer to disks by 
UUID (Universally Unique IDentifier). The boot process now involves 
various methods for finding that UUID and, as you see above, waiting 
some considerable time for the device to appear (the device might be 
dependant on another host, or it might be on a relatively slow bus such 
as USB or SCSI-1 etc)

Now, there are a number of reasons why you might get the messages above, 
but one common 'gotcha' is that systemd is more strict about what 
devices are needed to boot the system. Basically, systemd assumes that, 
if you've listed a device in /etc/fstab and you've not told it 
otherwise, then that device is necessary for the system to boot. The two 
main ways to disabuse it of this notion are to either add the option 
"noauto", in which case the device will not get mounted at boot but you 
can still invoke "mount /path/to/mountpoint" once the system is up, or 
else you can add the option "nofail" which tells systemd that a failure 
to mount the device should not lead to a failure of the service (and 
thus booting can continue).

Another reason, and this may well be something you're hitting, is that 
the UUID doesn't match any devices on the system. UUIDs are, typically, 
created by mkfs (or mkswap). If you reformat a partition, the UUID will 
probably change, and your /etc/fstab might be pointing to the old 
device. If, say, you create filesystems and restore a backup to them, 
then /etc/fstab can be pointing to UUIDs which no longer exist; if 
that's the case, then consider using LABEL=something in /etc/fstab 
instead. UUIDs are reliable, but they are computer generated. Sometimes 
a maintainer-generated identifier is better.

---

From: Greg Wooledge <[email-masked]>
Date: Wed, 31 Aug 2016 10:24:01 -0400

> Are the messages that scroll past preserved anywhere?

When booting with systemd, the boot messages are stored in RAM
automatically, and can be viewed by running "journalctl" as root.
I'd definitely start there.

---

From: Dominic Knight <[email-masked]>
Date: Wed, 31 Aug 2016 17:01:15 +0100

> I'd definitely start there.

If it is the swap partition, it has probably been given a new UUID when
you installed a new/additional version of Debian. I use gparted to look
up the current UUID and then paste that over the relevant UUID in
/etc/fstab
Take care when using both gparted and writing to fstab.

Regards.

---

From: Richard Owlett <[email-masked]>
Date: Wed, 31 Aug 2016 09:58:39 -0500

> I'd definitely start there.

The relevant section appears to be

Aug 31 09:12:11 deb8-2ndtry kernel: psmouse serio2: alps: Unknown 
ALPS touchpad: E7=10 00 64, EC=10 00 64
Aug 31 09:12:13 deb8-2ndtry kernel: psmouse serio2: trackpoint: 
IBM TrackPoint firmware: 0x0e, buttons: 3/3
Aug 31 09:12:13 deb8-2ndtry kernel: input: TPPS/2 IBM TrackPoint 
as /devices/platform/i8042/serio1/serio2/input/inp
Aug 31 09:13:32 deb8-2ndtry systemd[1]: Job 
dev-disk-by\x2duuid-0a344714\x2dae06\x2d43ed\x2daf89\x2d33ba51934630.de
Aug 31 09:13:32 deb8-2ndtry systemd[1]: Timed out waiting for 
device dev-disk-by\x2duuid-0a344714\x2dae06\x2d43ed\x
Aug 31 09:13:32 deb8-2ndtry systemd[1]: Dependency failed for 
/dev/disk/by-uuid/0a344714-ae06-43ed-af89-33ba5193463
Aug 31 09:13:32 deb8-2ndtry systemd[1]: Dependency failed for Swap.
Aug 31 09:13:33 deb8-2ndtry anacron[493]: Anacron 2.3 started on 
2016-08-31
Aug 31 09:13:33 deb8-2ndtry anacron[493]: Normal exit (0 jobs run)

What is this trying to tel me?
Where could I have gone to find answer to above?

---

From: Felix Miata <[email-masked]>
Date: Wed, 31 Aug 2016 11:44:06 -0400

Richard Owlett composed on 2016-08-31 09:58 (UTC-0500):
...
> Aug 31 09:13:32 deb8-2ndtry systemd[1]: Dependency failed for Swap.

Which was installed last, Squeeze, or Jessie? You can expect this message 
trying to boot the earlier installed installation after having done the later 
install. Unless you take affirmative action to deny it, an existing swap 
partition used by the earlier installation will be reformatted by the later 
installation. Reformatting creates a new UUID, thus making the UUID referring 
to it in the earlier installation's fstab invalid. The earlier needs to have 
its fstab edited to use the correct swap partition UUID, or volume label, or 
device name, if swap is actually desired or needed.
-- 
"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/

---

From: Richard Owlett <[email-masked]>
Date: Wed, 31 Aug 2016 11:25:17 -0500

On 8/31/2016 10:44 AM, Felix Miata wrote:
>> Swap.
> Which was installed last, Squeeze, or Jessie? You can expect this
> message trying to boot the earlier installed installation after
> having done the later install. Unless you take affirmative action
> to deny it, an existing swap partition used by the earlier
> installation will be reformatted by the later installation.
> Reformatting creates a new UUID, thus making the UUID referring
> to it in the earlier installation's fstab invalid. The earlier
> needs to have its fstab edited to use the correct swap partition
> UUID, or volume label, or device name, if swap is actually
> desired or needed.

There may be some subtle problems still lurking somewhere which 
show up only for people like me doing many installs of *nearly* 
identical systems.

Commenting out the line in /etc/fstab DID allow it to boot 
without warning messages.

However,taking into account Darac's comments, does this now mean 
that the machines are now operating without a swap partition?

IIRC the current instance of Jessie on the laptop was the 
chronologically the last OS installed so by the comments in this 
thread should not have had the problem. The laptop is my 
designated "Guinea pig" so I'll do a fresh install to see if 
problem persists.

---

From: Richard Owlett <[email-masked]>
Date: Thu, 1 Sep 2016 07:02:14 -0500

> designated "Guinea pig" so I'll do a fresh install to see if

My procedure was:
1. Using the Live edition of Gparted, remove all partitions on 
hard disk.
2. Using install DVD 1 of Debian 8.0.0
    a. install Debian to /dev/sda1
    b. create swap on /dev/sda2
3. Verify Debian boots without problems
4. Using the same DVD
    a. install Debian to /dev/sda5
    b. re-create swap on /dev/sda2
5. Attempt to boot both instances
    a. Booting the install on /dev/sda1 generates the warning 
message and use
       of free shows swap does not exist.
    b. Booting the install on /dev/sda5 generates no warning 
message and use
       of free shows swap does exist.

I believe this justifies a bug report against the installer.
My expected behavior would be to check to see if a swap area 
already exists before "creating" a swap partition. Especially 
since replacing a swap partition can break a previously 
functioning install in a multi-boot situation.

Comments?

---

From: claude juif <[email-masked]>
Date: Thu, 1 Sep 2016 15:56:02 +0200

2016-09-01 14:02 GMT+02:00 Richard Owlett <[email-masked]>:

> 1. Using the Live edition of Gparted, remove all partitions on hard disk.
>    a. Booting the install on /dev/sda1 generates the warning message and
> use
>    b. Booting the install on /dev/sda5 generates no warning message and use

It is not a bug. If you want to use the same swap partition with multiple
install, then you should not reformat the swap partition. How can the
installer guess that you want to use the same swap partition for multiple
OS. (reinstalling the same system is a common task -- but i always wonder
why ...)

Maybe you want to add warning message before formatting like "Care, a swap
partition already exist at /dev/sdaXX, would you like to reformat it ?"

IMO, you should know what you're doing. It's not the installer job to
"think" for you ! The installer just does what you ask him to do !

> My expected behavior would be to check to see if a swap area already
> exists before "creating" a swap partition. Especially since replacing a
> swap partition can break a previously functioning install in a multi-boot
> situation.
>

By the way you can have a look at debootstrap if you want multiple debian
install, (only one booted OS, but multiple Debian OS accessible with chroot)

If you want more powerfull way of doing this you can check lxc, and docker.
Today multiboot seem really deprecated (unless you have windows)

> Regards,

---

From: Richard Owlett <[email-masked]>
Date: Fri, 2 Sep 2016 08:06:40 -0500

On 9/1/2016 8:56 AM, claude juif wrote:
>
> By the way you can have a look at debootstrap if you want
> multiple debian install, (only one booted OS, but multiple Debian
> OS accessible with chroot)If you want more powerfull way of doing
> this you can check lxc, and docker. Today multiboot seem really
> deprecated (unless you have windows)

I looked at https://en.wikipedia.org/wiki/LXC and 
http://www.docker.com/. Neither of them, nor virtual machines 
&/or chroot, are suitable for me.

Multiboot is explicitly the tool of choice. Think of Windows(TM) 
as only tip of iceberg.

---

From: Darac Marjal <[email-masked]>
Date: Thu, 1 Sep 2016 13:11:22 +0100

On Thu, Sep 01, 2016 at 07:02:14AM -0500, Richard Owlett wrote:
>   a. Booting the install on /dev/sda1 generates the warning message 
>and use
>exists before "creating" a swap partition. Especially since replacing 
>a swap partition can break a previously functioning install in a 
>multi-boot situation.
>
>Comments?

I think that sounds sensible. A swap partition should be considered 
scratch space, and its contents only relevant to the currently-booted 
OS.

The only fly in the ointment is hibernation. It's been a while since I 
played with hibernation, but I believe it stores the RAM image into 
Swap, so installing Debian while another OS is hibernated could even 
cause data loss. The solution there is A) to use a swap FILE for the 
hibernation image and B) for Debian to point-blank refuse to re-create a 
swap partition when it detects a hibernation image there.

---

From: David Wright <[email-masked]>
Date: Thu, 1 Sep 2016 09:44:47 -0500

On Thu 01 Sep 2016 at 13:11:22 (+0100), Darac Marjal wrote:
> scratch space, and its contents only relevant to the
> currently-booted OS.

I disagree. If you want to share swap space, then you've got to
take appropriate action yourself. The easy way is to LABEL it in
/etc/fstab rather than UUID it, unless you like reading and typing
long strings of hex.

> The only fly in the ointment is hibernation. It's been a while since
> I played with hibernation, but I believe it stores the RAM image
> into Swap, so installing Debian while another OS is hibernated could
> even cause data loss. The solution there is A) to use a swap FILE
> for the hibernation image and B) for Debian to point-blank refuse to
> re-create a swap partition when it detects a hibernation image
> there.

I disagree. Is d-i expected to have a list of partition types, and
contents, that shouldn't be overwritten? Are all the flavours of fdisk
to test all the partitions on a disk before they allow you to
repartition it? If yes, then what about C> FDISK ? This just lulls
people into a false sense of security. Then Windows comes along...

Just as you can install 145 OSes on one PC, you can share swap space
among them, but it's then up to you to work out how to do this safely,
not just file a bug against an innocent installer doing what's asked
of it. The OP has enjoyed help from a sizeable thread entitled
"Problem with NON-STANDARD install" (his emphasis) which focussed
mainly on Grub. Perhaps we have to look forward to more problems
arising from the non-standard circumstances, but these will all
help with the OP's desired learning process.

Cheers,
David.

---

From: Michael Biebl <[email-masked]>
Date: Fri, 2 Sep 2016 09:40:55 +0200

> /etc/fstab rather than UUID it, unless you like reading and typing

Well, you can assign labels, but this won't help you. As soon as you
install a new system on the same hardware, the (debian)-installer will
reformat your existing swap partition and the label will be gone along
with it. I've run into this myself a couple of times.

This has been the case forever basically. The only difference was, that
sysvinit didn't care, and you simply ended up with your system having no
swap partition set up. Systemd is much more picky in that regard (and
rightfully so, imho).

I think treating an *existing* swap partition like a non-empty partition
and not reformatting it by default would be right thing to do.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

---

From: David Wright <[email-masked]>
Date: Fri, 2 Sep 2016 10:32:15 -0500

> with it. I've run into this myself a couple of times.

I already wrote that in this thread:
https://lists.debian.org/debian-user/2016/08/msg01052.html
and hadn't realised I had to repeat myself just because the thread's
subject line was modified. Or maybe because the month clicked forward.

> swap partition set up. Systemd is much more picky in that regard (and

In which regard. I'm running systemd with no swap and it doesn't care.
Basically, if "KiB Swap: ... 0 used," is anything but zero, I might as
well reboot; any idea of getting work done while swapping is risible,
disk access is so slow. But I guess you may just mean that systemd
cares about /etc/fstab in a way that sysvinit didn't, rather than the
swap line in particular. Ironic, as systemd plays fast and loose with
fstab as far as the fstab documentation is concerned.

> and not reformatting it by default would be right thing to do.

OTOH the people who benefit are likely to be the people who understand
the issues. I would prefer a Non-defaulting option to save the
tediousness of working round the current default. That way, the naïve
tyro gets exactly what they expect from the installer, a clean slate.

Doing it my way (see ref) contravenes the recommendations of the
Installation Manual. But, while we're on the topic, perhaps you can
explain the reasoning behind this paragraph from §6.3.8.2:

"Note: Although you can do basically anything in a shell that the
available commands allow you to do, the option to use a shell is
really only there in case something goes wrong and for debugging.

"Doing things manually from the shell may interfere with the
installation process and result in errors or an incomplete
installation. In particular, you should always use let the installer
activate your swap partition and not do this yourself from a shell."

Cheers,
David.

---

From: Curt <[email-masked]>
Date: Fri, 2 Sep 2016 16:24:56 +0000 (UTC)

> installation. In particular, you should always use let the installer
                                                 ******* 
> activate your swap partition and not do this yourself from a shell."

Shouldn't the "use" be stricken out (struck out? I'm stricken with doubt)
entirely, or the "let" be removed so that it reads: "use the installer to
activate..."?

-- 
"I always say to people, ‘No one earns $100 million. You steal $100 million.’
People earn $10 an hour. People earn $40,000 a year. ‘Earn’ means work. Okay?
It doesn’t mean steal, which with these vast amounts of money, of course you
steal them." — Fran Lebowitz

---

From: Nicolas George <[email-masked]>
Date: Fri, 2 Sep 2016 17:44:39 +0200

> well reboot; any idea of getting work done while swapping is risible,

If you have to look at the output of a command do notice the swap is in use,
that means you were able to getting work done very well.

>			  But I guess you may just mean that systemd
> cares about /etc/fstab in a way that sysvinit didn't

sysvinit is just a bunch of shell script. Error codes were lost all the time
and nobody cared.

---

From: David Wright <[email-masked]>
Date: Fri, 2 Sep 2016 14:34:29 -0500

> that means you were able to getting work done very well.

Clever, but clearly not correct.

If the computer is nearby, as is typical, then the first two things
you notice are the noise from the disk and the slowdown.

So then the question is whether the computer is just generally
overloaded or, more usually, the browser is out of control.
The latter can be no more than the browser consuming more than
100% CPU in which case simply killing it is enough to restore order.

On the laptop, it might be possible to tell high CPU consumption
(obviously accompanied by disk activity) from swapping by the pitch of
the fan and the increasing discomfort in the right thigh, but $ top
is easier just so long as fvwm is able to switch to a suitable screen,
which is not a given.

There have been kernels when the right thigh has cried "wolf" for
too long, and then the best indication of increasing CPU temperature
is the colour of the root window, which switches to red at 80° and
brown at 85°, though that's not much help if a video is playing
full-screen. (My current record temperature peak is 96.5°.)

Forget all this if I'm doing the work on the computer in the basement¹
or the one in the attic². How am I going to hear disk swapping when I'm
sitting under a ceiling fan with the radio on? More than 80% of the
former's and 100% of the latter's use is remotely from the laptop.

> sysvinit is just a bunch of shell script. Error codes were lost all the time

Looks like my guess was correct, then.

¹ anti-tornado.  ² anti-flash flooding.

Cheers,
David.

---

From: David Wright <[email-masked]>
Date: Wed, 31 Aug 2016 13:38:02 -0500

On Wed 31 Aug 2016 at 11:25:17 (-0500), Richard Owlett wrote:
> There may be some subtle problems still lurking somewhere which show
> up only for people like me doing many installs of *nearly* identical
> systems.

There way well be. One possible scenario is installing Debian, then
installing again but overwriting the filesystems. To all intents
and purposes, the same responses will get you to the same place,
*but* the swap partition will have been recreated with a new UUID.

To avoid having the swap partition recreated is slightly tedious.
I do it as a matter of course because my swap is referenced by
LABEL rather than UUID. You have to force d-i to install without
one, and then enable it afterwards in VC2 (if you actually need it
for the d-i's use, which I don't) which is disapproved of.

> Commenting out the line in /etc/fstab DID allow it to boot without
> warning messages.
> 

Quite possibly. Do you need it, particularly on the desktop (which
I assume you don't hibernate). Maybe on the laptop.

> thread should not have had the problem. The laptop is my designated
> "Guinea pig" so I'll do a fresh install to see if problem persists.

Are you copying in a pre-existing /etc/fstab by any chance? Fine if
you use LABELs, but it needs checking/editing if you rely on UUIDs.

Cheers,
David.

---

From: Felix Miata <[email-masked]>
Date: Wed, 31 Aug 2016 12:48:48 -0400

> that the machines are now operating without a swap partition?

If fstab has no uncommented lines for swap, then there will no swap enabled. 
Among ways to see if swap is currently active are top and free.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

---

From: Richard Owlett <[email-masked]>
Date: Thu, 1 Sep 2016 05:50:13 -0500

On 8/31/2016 11:48 AM, Felix Miata wrote:
> If fstab has no uncommented lines for swap, then there will no
> swap enabled. Among ways to see if swap is currently active are
> top and free.

Thank you.
For we of tri-focal generation I recommend using free.
The relavant info is more easily found ;/

---

From: Gene Heskett <[email-masked]>
Date: Thu, 1 Sep 2016 09:50:59 -0400

> The relavant info is more easily found ;/

As a glasses wearer for 75 years, and one of the tri-focal crowd for 
about 65 years, I cheat, making use of the multiple workspaces windowing 
system, I have a multitab terminal-4.8 session open on workspace 1. The 
first tab has a 'sudo htop' run on it, first thing after a reboot, so I 
can always kill a runaway session of firefox or iceweasel that refuses 
to die on request. Accessable in 2 clicks no matter how stuffed the 
system is.

Next tab has a "sudo tail -fn400 /var/log/messages" on it so I can look 
at the whole boot log if I want, and the next 3 or 4 tabs are tailing 
other stuff that automate much of what I do here.

workspace 2 has a duplicate of a multitab terminal-4.8 on it, each tab 
logged into a different machine on my local network with an 
"ssh -Y machine-alias".

I could go on for 8 more "workspaces", but you get the idea.;-)
And after 19+ days of uptime, I have 39 megs of stuff in swap. And I'm 
still on wheezy LTS.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

---

From: Greg Wooledge <[email-masked]>
Date: Wed, 31 Aug 2016 11:06:29 -0400

> Aug 31 09:13:32 deb8-2ndtry systemd[1]: Dependency failed for Swap.

Look for swap partitions defined in /etc/fstab and see if one of them
is on a device that no longer exists (or exists only intermittently,
such as a removable USB drive).  Chances are you'll find one with
UUID=0a344714-something on it.  Try commenting it out.

---

From: Richard Owlett <[email-masked]>
Date: Wed, 31 Aug 2016 11:00:27 -0500

> UUID=0a344714-something on it.  Try commenting it out.

Commented out relevant line on both machines.
They both boot promptly now ;/
Thanks

---

From: Greg Wooledge <[email-masked]>
Date: Wed, 31 Aug 2016 12:04:15 -0400

> They both boot promptly now ;/

OK, good.  Now the final step is to review your fstab vs. your actual
disk partitions and add whatever you may be missing (e.g. a swap
partition whose UUID got changed, as someone else speculated).