Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #208655 > unrolled thread

Problem: Slow boot -- Mounts fail.

Started byDennis Wicks <wix@mgssub.com>
First post2019-05-14 23:40 +0200
Last post2019-06-24 11:40 +0200
Articles 7 — 3 participants

Back to article view | Back to linux.debian.user


Contents

  Problem: Slow boot -- Mounts fail. Dennis Wicks <wix@mgssub.com> - 2019-05-14 23:40 +0200
    Re: Problem: Slow boot -- Mounts fail. andreimpopescu@gmail.com - 2019-06-24 09:10 +0200
      Re: Problem: Slow boot -- Mounts fail. Dennis Wicks <wix@mgssub.com> - 2019-06-28 18:30 +0200
        Re: Problem: Slow boot -- Mounts fail. andreimpopescu@gmail.com - 2019-06-29 08:20 +0200
          Re: Problem: Slow boot -- Mounts fail. Dennis Wicks <wix@mgssub.com> - 2019-07-01 03:50 +0200
            Re: Problem: Slow boot -- Mounts fail. andreimpopescu@gmail.com - 2019-07-01 09:00 +0200
    Re: Problem: Slow boot -- Mounts fail. Cindy Sue Causey <butterflybytes@gmail.com> - 2019-06-24 11:40 +0200

#208655 — Problem: Slow boot -- Mounts fail.

FromDennis Wicks <wix@mgssub.com>
Date2019-05-14 23:40 +0200
SubjectProblem: Slow boot -- Mounts fail.
Message-ID<xXNjr-5hs-3@gated-at.bofh.it>
Greetings;

During the boot process there are several mount "jobs" 
started, and they all finish/fail with two messages;

	Dependency failed for ...
	Timeout waiting for ...

that is except for root.

I removed all the mounts for user partitions from fstab and 
just left the mounts for root, boot, home and home2 but got 
the same results for the four that were left. Incidentally, 
when I run the user mounts after the system is "up" it takes 
just a few seconds to mount 14 partitions.

After the mounts "fail" the boot process stops in Emergency 
Mode, and I have the choice of logging on to root to fix the 
problem, or entering ctl-d to continue on. If I log on to 
root I find that all four of the volumes are mounted and 
nothing is wrong. If I choose ctl-d the boot process will 
continue with no problems.

How do I prevent the mounts from failing and make the system 
continue on with the boot process?

Many TIA!
Dennis

[toc] | [next] | [standalone]


#210325

Fromandreimpopescu@gmail.com
Date2019-06-24 09:10 +0200
Message-ID<ycrgZ-qL-1@gated-at.bofh.it>
In reply to#208655

[Multipart message — attachments visible in raw view] — view raw

On Ma, 14 mai 19, 16:38:37, Dennis Wicks wrote:
> 
> How do I prevent the mounts from failing and make the system continue on
> with the boot process?

You could start by attaching your /etc/fstab and copy-pasting the output 
of 'lsblk -f' with all partitions mounted.

It would also be useful to know what init system you are using
(ls -l /sbin/init) and if your mounts have any specials (LVM, encrypted, 
NFS, RAID, etc.) basically anything besides plain extX filesystems 
mounted from internal drives.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]


#210469

FromDennis Wicks <wix@mgssub.com>
Date2019-06-28 18:30 +0200
Message-ID<ye1V7-5Tu-9@gated-at.bofh.it>
In reply to#210325
andreimpopescu@gmail.com wrote on 6/24/19 2:09 AM:
> On Ma, 14 mai 19, 16:38:37, Dennis Wicks wrote:
>>
>> How do I prevent the mounts from failing and make the system continue on
>> with the boot process?
> 
> You could start by attaching your /etc/fstab and copy-pasting the output
> of 'lsblk -f' with all partitions mounted.
> 
> It would also be useful to know what init system you are using
> (ls -l /sbin/init) and if your mounts have any specials (LVM, encrypted,
> NFS, RAID, etc.) basically anything besides plain extX filesystems
> mounted from internal drives.
> 
> Kind regards,
> Andrei
> 
No need for all that!

All my mounts are local PATA and SATA drives. The SATA 
drives are on an adapter card. All the file systems are xfs, 
ext2, ext4 or swap and use either /dir/dir, LABEL= or UUID=.
All very vanilla. No LVM, encrypted, NFS, RAID, etc. Doesn't 
make any difference as *all* of the mounts are failing on 
the first pass!

I found a work around on a forum. Put "nofail" in the 
options field of fstab. So now my entries contain 
"defaults,nofail" or "sw,pri=100,nofail" in the options field.

Doesn't make any difference though. All the
    Dependency failed for ...
     Timeout waiting for ...
messages still occur, they just don't stop the boot process 
and the mounts get done successfully later on.(??)

I can't tell what might have caused this as I don't re-boot 
after every update, just when an update to the kernel 
occurs. I think it was about the time that systemd was 
implemented as the boot screen looked different when the 
mount failures started happening.

Just an update in case someone else runs into the problem. 
In fact I am surprised that no once else has. Must be 
something different about my system that I don't know about 
and that isn't obvious! (Something from SysV that is 
incompatible with systemd?)

Regards,
Dennis

[toc] | [prev] | [next] | [standalone]


#210480

Fromandreimpopescu@gmail.com
Date2019-06-29 08:20 +0200
Message-ID<yeeSl-5AZ-3@gated-at.bofh.it>
In reply to#210469

[Multipart message — attachments visible in raw view] — view raw

On Vi, 28 iun 19, 11:26:43, Dennis Wicks wrote:
> andreimpopescu@gmail.com wrote on 6/24/19 2:09 AM:
> > On Ma, 14 mai 19, 16:38:37, Dennis Wicks wrote:
> > > 
> > > How do I prevent the mounts from failing and make the system continue on
> > > with the boot process?
> > 
> > You could start by attaching your /etc/fstab and copy-pasting the output
> > of 'lsblk -f' with all partitions mounted.
> > 
> > It would also be useful to know what init system you are using
> > (ls -l /sbin/init) and if your mounts have any specials (LVM, encrypted,
> > NFS, RAID, etc.) basically anything besides plain extX filesystems
> > mounted from internal drives.
> > 
> > Kind regards,
> > Andrei
> > 
> No need for all that!

Hmm...
 
> All my mounts are local PATA and SATA drives. The SATA drives are on an
> adapter card. All the file systems are xfs, ext2, ext4 or swap and use
> either /dir/dir, LABEL= or UUID=.
> All very vanilla. No LVM, encrypted, NFS, RAID, etc. Doesn't make any
> difference as *all* of the mounts are failing on the first pass!
> 
> I found a work around on a forum. Put "nofail" in the options field of
> fstab. So now my entries contain "defaults,nofail" or "sw,pri=100,nofail" in
> the options field.
> 
> Doesn't make any difference though. All the
>    Dependency failed for ...
>     Timeout waiting for ...
> messages still occur, they just don't stop the boot process and the mounts
> get done successfully later on.(??)
> 
> I can't tell what might have caused this as I don't re-boot after every
> update, just when an update to the kernel occurs. I think it was about the
> time that systemd was implemented as the boot screen looked different when
> the mount failures started happening.

There are a lot of eyes on this list and someone might spot something 
that you don't even think might have an impact.

But then it's your system, your rules ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]


#210513

FromDennis Wicks <wix@mgssub.com>
Date2019-07-01 03:50 +0200
Message-ID<yeTC9-5Ut-1@gated-at.bofh.it>
In reply to#210480

[Multipart message — attachments visible in raw view] — view raw

andreimpopescu@gmail.com wrote on 6/29/19 1:15 AM:
> On Vi, 28 iun 19, 11:26:43, Dennis Wicks wrote:
>> andreimpopescu@gmail.com wrote on 6/24/19 2:09 AM:
>>> On Ma, 14 mai 19, 16:38:37, Dennis Wicks wrote:
>>>>
>>>> How do I prevent the mounts from failing and make the system continue on
>>>> with the boot process?
>>>
>>> You could start by attaching your /etc/fstab and copy-pasting the output
>>> of 'lsblk -f' with all partitions mounted.
>>>
>>> It would also be useful to know what init system you are using
>>> (ls -l /sbin/init) and if your mounts have any specials (LVM, encrypted,
>>> NFS, RAID, etc.) basically anything besides plain extX filesystems
>>> mounted from internal drives.
>>>
>>> Kind regards,
>>> Andrei
>>>
>> No need for all that!
> 
> Hmm...
>   
>> All my mounts are local PATA and SATA drives. The SATA drives are on an
>> adapter card. All the file systems are xfs, ext2, ext4 or swap and use
>> either /dir/dir, LABEL= or UUID=.
>> All very vanilla. No LVM, encrypted, NFS, RAID, etc. Doesn't make any
>> difference as *all* of the mounts are failing on the first pass!
>>
>> I found a work around on a forum. Put "nofail" in the options field of
>> fstab. So now my entries contain "defaults,nofail" or "sw,pri=100,nofail" in
>> the options field.
>>
>> Doesn't make any difference though. All the
>>     Dependency failed for ...
>>      Timeout waiting for ...
>> messages still occur, they just don't stop the boot process and the mounts
>> get done successfully later on.(??)
>>
>> I can't tell what might have caused this as I don't re-boot after every
>> update, just when an update to the kernel occurs. I think it was about the
>> time that systemd was implemented as the boot screen looked different when
>> the mount failures started happening.
> 
> There are a lot of eyes on this list and someone might spot something
> that you don't even think might have an impact.
> 
> But then it's your system, your rules ;)
> 
> Kind regards,
> Andrei
> 

OK! Be my guest!!

One thing I have noticed is that it seems to do everything 2 
or 3 times while it is booting, and it takes about 30 mins 
before my desktop (xfce) is up and functioning.

TNX!

[toc] | [prev] | [next] | [standalone]


#210516

Fromandreimpopescu@gmail.com
Date2019-07-01 09:00 +0200
Message-ID<yeYsa-pt-9@gated-at.bofh.it>
In reply to#210513

[Multipart message — attachments visible in raw view] — view raw

On Du, 30 iun 19, 20:48:21, Dennis Wicks wrote:
> 
> OK! Be my guest!!
> 
> One thing I have noticed is that it seems to do everything 2 or 3 times
> while it is booting, and it takes about 30 mins before my desktop (xfce) is
> up and functioning.

On a first/quick look nothing unusual stands out, but I'll have more 
time for this tomorrow.

Please post also the outputs of

    journalctl -alb
    systemd-analyze blame
    systemd-analyze critical-chain

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]


#210329

FromCindy Sue Causey <butterflybytes@gmail.com>
Date2019-06-24 11:40 +0200
Message-ID<yctCa-1HD-5@gated-at.bofh.it>
In reply to#208655
On 5/14/19, Dennis Wicks <wix@mgssub.com> wrote:
> Greetings;
>
> During the boot process there are several mount "jobs"
> started, and they all finish/fail with two messages;
>
> 	Dependency failed for ...
> 	Timeout waiting for ...
>
> that is except for root.
>
> I removed all the mounts for user partitions from fstab and
> just left the mounts for root, boot, home and home2 but got
> the same results for the four that were left. Incidentally,
> when I run the user mounts after the system is "up" it takes
> just a few seconds to mount 14 partitions.
>
> After the mounts "fail" the boot process stops in Emergency
> Mode, and I have the choice of logging on to root to fix the
> problem, or entering ctl-d to continue on. If I log on to
> root I find that all four of the volumes are mounted and
> nothing is wrong. If I choose ctl-d the boot process will
> continue with no problems.
>
> How do I prevent the mounts from failing and make the system
> continue on with the boot process?


Hi.. As usual, I probably won't be a whole lot of help, BUT.. that
never stops my keyboard. :)

#1 Is this something new, or has it been doing this all along? What
I'm thinking is.. What about the (logical step-by-step) mount order in
fstab? That might be one thing that would explain why it doesn't work
at bootup but then does work after one or two primary mount points are
successful...

#2 I experience something similar related to hardware failure of the
kind where it's after a power outage. The hard drive dock will need to
be turned back on via the hardware on/off button. That's obviously not
this case because you didn't mention that. I am mentioning it so that
maybe someone else can check it off their list. :)

For my instances, the message will just keep unsuccessfully cycling
through all the various mount points that reference partitions on that
dock. If I'm distracted and don't see those advisements occurring,
mine will eventually end up at that same point of it kicking to the
prompt along with offering that CTRL+D as an option. Click the
hardware on/off button and then CTRL+D, and mine then completes yet
another successful boot operation. *yay, TEAM!*

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web