Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #208655 > unrolled thread
| Started by | Dennis Wicks <wix@mgssub.com> |
|---|---|
| First post | 2019-05-14 23:40 +0200 |
| Last post | 2019-06-24 11:40 +0200 |
| Articles | 7 — 3 participants |
Back to article view | Back to linux.debian.user
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
| From | Dennis Wicks <wix@mgssub.com> |
|---|---|
| Date | 2019-05-14 23:40 +0200 |
| Subject | Problem: 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]
| From | andreimpopescu@gmail.com |
|---|---|
| Date | 2019-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]
| From | Dennis Wicks <wix@mgssub.com> |
|---|---|
| Date | 2019-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]
| From | andreimpopescu@gmail.com |
|---|---|
| Date | 2019-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]
| From | Dennis Wicks <wix@mgssub.com> |
|---|---|
| Date | 2019-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]
| From | andreimpopescu@gmail.com |
|---|---|
| Date | 2019-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]
| From | Cindy Sue Causey <butterflybytes@gmail.com> |
|---|---|
| Date | 2019-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