Re: Slow boot, looks like due to filesystem mounts
On Fri, Dec 15, 2023 at 10:14 PM Max Nikulin wrote: > > On 16/12/2023 05:08, Jeffrey Walton wrote: > > The resize operation included deleting swap > > at /dev/sda2, increasing disk size of /dev/sda, extending /dev/sda1, > > and recreating swap at the end of /dev/sda as /dev/sda2. > [...] > > $ sudo blkid > > /dev/sda2: UUID="b05d2596-5301-47d1-b208-95fca81be94e" TYPE="swap" > > PARTUUID="872398d9-02" > > /dev/sda1: UUID="6da839d7-eace-442d-b267-838637721471" > > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="872398d9-01" > > > > And I updated fstab: > > Have you updated initrd (or some packages caused generation of new > initramfs)? Perhaps kernel waits if a partition with old swap UUID > requires some time to make device ready. > > update-initramfs -u -k all Thanks, that was it. The missing step was to edit /etc/initramfs-tools/conf.d/resume, and then update initramfs. Jeff
Re: Slow boot, looks like due to filesystem mounts
On 16/12/2023 05:08, Jeffrey Walton wrote: The resize operation included deleting swap at /dev/sda2, increasing disk size of /dev/sda, extending /dev/sda1, and recreating swap at the end of /dev/sda as /dev/sda2. [...] $ sudo blkid /dev/sda2: UUID="b05d2596-5301-47d1-b208-95fca81be94e" TYPE="swap" PARTUUID="872398d9-02" /dev/sda1: UUID="6da839d7-eace-442d-b267-838637721471" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="872398d9-01" And I updated fstab: Have you updated initrd (or some packages caused generation of new initramfs)? Perhaps kernel waits if a partition with old swap UUID requires some time to make device ready. update-initramfs -u -k all
Re: Slow boot
On 12/01/19 4:47 PM, Richard Hector wrote: > On 12/01/19 1:28 AM, David wrote: >> Hi, I have no expertise in this, except to suggest that if I was >> seeing your symptoms then I would investigate if the discussion >> here might be relevant: >> https://lists.debian.org/debian-devel/2018/12/msg00184.html > > Interesting, thanks - I'm going to try 4.19 from backports, so that I > can try the random.trust_cpu option mentioned in that thread. Well - not as informative as I'd hoped - the new kernel doesn't have that delay (well, there seems to be a 20s delay in a similar place), so trying the random.trust_cpu option wasn't so useful. I did anyway, and the 20s delay remained - but it's not really apparent during the boot, so maybe I was wrong and user-mode processes have started by then. I guess I'll just keep using the 4.19 kernel anyway ... Richard signature.asc Description: OpenPGP digital signature
Re: Slow boot
On 12/01/19 1:28 AM, David wrote: > Hi, I have no expertise in this, except to suggest that if I was > seeing your symptoms then I would investigate if the discussion > here might be relevant: > https://lists.debian.org/debian-devel/2018/12/msg00184.html Interesting, thanks - I'm going to try 4.19 from backports, so that I can try the random.trust_cpu option mentioned in that thread. Richard signature.asc Description: OpenPGP digital signature
Re: Slow boot
On 12/01/19 3:41 AM, Michael Stone wrote: > On Fri, Jan 11, 2019 at 02:03:44PM +1300, Richard Hector wrote: >> According to dmesg, this is where it appears to hang: >> >> [ 2.717311] device-mapper: uevent: version 1.0.3 >> [ 2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) >> initialised: dm-d >> e...@redhat.com >> [ 2.978281] clocksource: Switched to clocksource tsc >> [ 121.459392] md: linear personality registered for level -1 >> [ 121.460391] md: multipath personality registered for level -4 >> [ 121.461444] md: raid0 personality registered for level 0 > > dmesg is the wrong tool for this, as it only shows kernel messages and > the delay is probably not in the kernel. try "journalctl -b", which will > show both kernel messages and other logs for the current boot. > I think it is in the kernel, actually. Compare: dmesg: [2.655799] random: crng init done [2.655828] random: 7 urandom warning(s) missed due to ratelimiting [2.666315] md8: detected capacity change from 0 to 499965231104 [2.839576] device-mapper: uevent: version 1.0.3 [2.839664] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) initialised: dm-de...@redhat.com [2.979835] clocksource: Switched to clocksource tsc [ 131.281666] PM: Starting manual resume from disk [ 131.281699] PM: Hibernation image partition 253:8 present [ 131.281699] PM: Looking for hibernation image. [ 131.281783] PM: Image not found (code -22) [ 131.281784] PM: Hibernation image not present or could not be loaded. [ 141.617008] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [ 172.514409] ip_tables: (C) 2000-2006 Netfilter Core Team [ 172.556027] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) [ 172.556181] systemd[1]: Detected architecture x86-64. journalctl -b: Jan 12 16:12:37 rh-khost1 kernel: random: crng init done Jan 12 16:12:37 rh-khost1 kernel: random: 7 urandom warning(s) missed due to ratelimiting Jan 12 16:12:37 rh-khost1 kernel: md8: detected capacity change from 0 to 499965231104 Jan 12 16:12:37 rh-khost1 kernel: device-mapper: uevent: version 1.0.3 Jan 12 16:12:37 rh-khost1 kernel: device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) initialised: dm-de...@redhat.com Jan 12 16:12:37 rh-khost1 kernel: clocksource: Switched to clocksource tsc Jan 12 16:12:37 rh-khost1 kernel: PM: Starting manual resume from disk Jan 12 16:12:37 rh-khost1 kernel: PM: Hibernation image partition 253:8 present Jan 12 16:12:37 rh-khost1 kernel: PM: Looking for hibernation image. Jan 12 16:12:37 rh-khost1 kernel: PM: Image not found (code -22) Jan 12 16:12:37 rh-khost1 kernel: PM: Hibernation image not present or could not be loaded. Jan 12 16:12:37 rh-khost1 kernel: EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) Jan 12 16:12:37 rh-khost1 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Jan 12 16:12:37 rh-khost1 systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS Jan 12 16:12:37 rh-khost1 systemd[1]: Detected architecture x86-64. So dmesg _does_ show systemd messages, systemd starts a couple of lines later, and it then reads all the kernel messages and writes them out with the same timestamp. I did try systemd-analyze (blame and critical-path) earlier, but they also showed that the delay wasn't on systemd's watch. Thanks, Richard signature.asc Description: OpenPGP digital signature
Re: Slow boot
On 1/11/19, Dan Ritter wrote: > Cindy-Sue Causey wrote: >> On 1/11/19, Dan Ritter wrote: >> > >> > As an experiment -- try this: >> > >> > echo udev_log=\"err\" >> /etc/udev/udev.conf >> > >> > (Or, alternatively, edit /etc/udef/udev.conf and insert/change >> > that as necessary.) >> >> >> Manually editing sounds like a good route because mine says this when >> you get there: >> >> # udevd is started in the initramfs, so when this file is modified the >> # initramfs should be rebuilt. >> >> "[S]hould"... Sounds like some of that should/shall/will and must >> (??) coming into play. > > Yes, it needs to be followed by running: > > # update-initramfs -k all -u > > or similar. Thanks for the catch! You're welcome. It was a nice side bonus from lurking along from the sidelines. Having read that, it occurred to me that it would be interesting to: 1) Enter that change but don't update then monitor appropriate files for short period of time. 2) Next update initramfs then monitor those files again. 3) DELETE that change but do NOT update initramfs then monitor same files again. 4) Lastly update initramfs over that deletion then monitor one last time to see what, if anything, changes. I'm a-suming it would possibly/likely turn out similar to how we *must* run update-grub after making changes to /etc/grub.d... if we would like to see our manual changes do anything useful, that is. :) PS This is one of those cases that falls under a different thread... that one (or more) about personalized tweaks under locations other than /home/user. I'm imagining this kind of tweak possibly getting zapped on the next upgrade that includes /etc/udef/udev.conf. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: Slow boot
David wrote: > Hi, I have no expertise in this, except to suggest that if I was > seeing your symptoms then I would investigate if the discussion > here might be relevant: > https://lists.debian.org/debian-devel/2018/12/msg00184.html Good story - thanks and no comments!
Re: Slow boot
On Fri, Jan 11, 2019 at 02:03:44PM +1300, Richard Hector wrote: According to dmesg, this is where it appears to hang: [2.717311] device-mapper: uevent: version 1.0.3 [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) initialised: dm-d e...@redhat.com [2.978281] clocksource: Switched to clocksource tsc [ 121.459392] md: linear personality registered for level -1 [ 121.460391] md: multipath personality registered for level -4 [ 121.461444] md: raid0 personality registered for level 0 dmesg is the wrong tool for this, as it only shows kernel messages and the delay is probably not in the kernel. try "journalctl -b", which will show both kernel messages and other logs for the current boot.
Re: Slow boot
Cindy-Sue Causey wrote: > On 1/11/19, Dan Ritter wrote: > > Richard Hector wrote: > >> Hi all, > >> > >> This machine is taking ages to boot. > >> > >> It's a fresh install. > >> > >> According to dmesg, this is where it appears to hang: > >> > >> [2.717311] device-mapper: uevent: version 1.0.3 > >> [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) > >> initialised: dm-d > >> e...@redhat.com > >> [2.978281] clocksource: Switched to clocksource tsc > >> [ 121.459392] md: linear personality registered for level -1 > >> [ 121.460391] md: multipath personality registered for level -4 > >> [ 121.461444] md: raid0 personality registered for level 0 > >> > >> I have started wondering recently about the hardware - could I have a > >> clock problem? > >> > >> None of the other 'clocksource' entries have a similar lag, and there's > >> no similar lag at that point on my desktop. > >> > >> Do I need to provide more context, or do more diagnostics? > >> > > > > As an experiment -- try this: > > > > echo udev_log=\"err\" >> /etc/udev/udev.conf > > > > (Or, alternatively, edit /etc/udef/udev.conf and insert/change > > that as necessary.) > > > Manually editing sounds like a good route because mine says this when > you get there: > > # udevd is started in the initramfs, so when this file is modified the > # initramfs should be rebuilt. > > "[S]hould"... Sounds like some of that should/shall/will and must > (??) coming into play. Yes, it needs to be followed by running: # update-initramfs -k all -u or similar. Thanks for the catch! -dsr-
Re: Slow boot
On Fri, 11 Jan 2019 at 12:04, Richard Hector wrote: > > This machine is taking ages to boot. You could also try the 'systemd-analyze blame' tool.
Re: Slow boot
On Fri, 11 Jan 2019 at 12:04, Richard Hector wrote: > > Hi all, > > This machine is taking ages to boot. > > It's a fresh install. > > According to dmesg, this is where it appears to hang: > > [2.717311] device-mapper: uevent: version 1.0.3 > [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) > initialised: dm-d > e...@redhat.com > [2.978281] clocksource: Switched to clocksource tsc > [ 121.459392] md: linear personality registered for level -1 > [ 121.460391] md: multipath personality registered for level -4 > [ 121.461444] md: raid0 personality registered for level 0 Hi, I have no expertise in this, except to suggest that if I was seeing your symptoms then I would investigate if the discussion here might be relevant: https://lists.debian.org/debian-devel/2018/12/msg00184.html
Re: Slow boot
On 1/11/19, Dan Ritter wrote: > Richard Hector wrote: >> Hi all, >> >> This machine is taking ages to boot. >> >> It's a fresh install. >> >> According to dmesg, this is where it appears to hang: >> >> [2.717311] device-mapper: uevent: version 1.0.3 >> [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) >> initialised: dm-d >> e...@redhat.com >> [2.978281] clocksource: Switched to clocksource tsc >> [ 121.459392] md: linear personality registered for level -1 >> [ 121.460391] md: multipath personality registered for level -4 >> [ 121.461444] md: raid0 personality registered for level 0 >> >> I have started wondering recently about the hardware - could I have a >> clock problem? >> >> None of the other 'clocksource' entries have a similar lag, and there's >> no similar lag at that point on my desktop. >> >> Do I need to provide more context, or do more diagnostics? >> > > As an experiment -- try this: > > echo udev_log=\"err\" >> /etc/udev/udev.conf > > (Or, alternatively, edit /etc/udef/udev.conf and insert/change > that as necessary.) Manually editing sounds like a good route because mine says this when you get there: # udevd is started in the initramfs, so when this file is modified the # initramfs should be rebuilt. "[S]hould"... Sounds like some of that should/shall/will and must (??) coming into play. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: Slow boot
Richard Hector wrote: > Hi all, > > This machine is taking ages to boot. > > It's a fresh install. > > According to dmesg, this is where it appears to hang: > > [2.717311] device-mapper: uevent: version 1.0.3 > [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) > initialised: dm-d > e...@redhat.com > [2.978281] clocksource: Switched to clocksource tsc > [ 121.459392] md: linear personality registered for level -1 > [ 121.460391] md: multipath personality registered for level -4 > [ 121.461444] md: raid0 personality registered for level 0 > > I have started wondering recently about the hardware - could I have a > clock problem? > > None of the other 'clocksource' entries have a similar lag, and there's > no similar lag at that point on my desktop. > > Do I need to provide more context, or do more diagnostics? > As an experiment -- try this: echo udev_log=\"err\" >> /etc/udev/udev.conf (Or, alternatively, edit /etc/udef/udev.conf and insert/change that as necessary.) -dsr-
Re: Slow boot
On 2019-01-11, Richard Hector wrote: > > Hints on where to look for the boot sequence in the kernel source, perhap= > s? > If you're using systemd the output of systemd-analyze blame systemd-analyze critical-chain might be informative.
Re: Slow boot
Richard Hector composed on 2019-01-11 16:54 (UTC+1300): ... > So either there's something else unlogged happening between, or there's > parallelism happening. Either way, I'm not sure where to look next :-( > Hints on where to look for the boot sequence in the kernel source, perhaps? Maybe pastebinit a bigger hunk of dmesg, or journal. Journal commonly has clues not found in dmesg. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Slow boot
On 11/01/19 3:27 PM, Felix Miata wrote: > Richard Hector composed on 2019-01-11 14:03 (UTC+1300): > >> This machine is taking ages to boot. > >> It's a fresh install. > >> According to dmesg, this is where it appears to hang: > >> [2.717311] device-mapper: uevent: version 1.0.3 >> [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) >> initialised: dm-d >> e...@redhat.com >> [2.978281] clocksource: Switched to clocksource tsc >> [ 121.459392] md: linear personality registered for level -1 >> [ 121.460391] md: multipath personality registered for level -4 >> [ 121.461444] md: raid0 personality registered for level 0 > >> I have started wondering recently about the hardware - could I have a >> clock problem? > >> None of the other 'clocksource' entries have a similar lag, and there's >> no similar lag at that point on my desktop. > >> Do I need to provide more context, or do more diagnostics? > > Possibly kernel-parameters.txt has a clock suggestion, maybe > > clocksource=hpet > > or forcing tsc from cmdline would switch to it at a more opportune time? > Thanks Felix. Well that's interesting - if I put clocksource=hpet on the kernel command line, it still pauses at the same place, but the clocksource message isn't there - which seems to me to eliminate it as the source of the problem. (when I use clocksource=tsc, that line does appear as before) But then I also got rid of those md messages by blacklisting the modules, so now I have different messages both sides of the hang. So either there's something else unlogged happening between, or there's parallelism happening. Either way, I'm not sure where to look next :-( Hints on where to look for the boot sequence in the kernel source, perhaps? Cheers, Richard signature.asc Description: OpenPGP digital signature
Re: Slow boot
Richard Hector composed on 2019-01-11 14:03 (UTC+1300): > This machine is taking ages to boot. > It's a fresh install. > According to dmesg, this is where it appears to hang: > [2.717311] device-mapper: uevent: version 1.0.3 > [2.717398] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) > initialised: dm-d > e...@redhat.com > [2.978281] clocksource: Switched to clocksource tsc > [ 121.459392] md: linear personality registered for level -1 > [ 121.460391] md: multipath personality registered for level -4 > [ 121.461444] md: raid0 personality registered for level 0 > I have started wondering recently about the hardware - could I have a > clock problem? > None of the other 'clocksource' entries have a similar lag, and there's > no similar lag at that point on my desktop. > Do I need to provide more context, or do more diagnostics? Possibly kernel-parameters.txt has a clock suggestion, maybe clocksource=hpet or forcing tsc from cmdline would switch to it at a more opportune time? -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Slow boot
On Tue, 14 Aug 2018 22:43:03 +0200 Johann Spies wrote: > On Tue, 14 Aug 2018 at 17:18, Patrick Bartek > wrote: > > > I'm curious. Did you just do a distribution upgrade on this laptop? > > From what to what? Or was it a clean install? Or is it an old > > install with everything working fine until now? > > I do regular dist-upgrades (testing) and have installed it as a new > computer about two or three years ago. Using Testing can be problematical as you've discovered. I'm assuming that everything was working fine, then you did a dist-upgrade and the long boot times began. I'm also assuming that your notebook is set to connect to a network at boot up. So, turn off the wireless transceiver (or disconnect your ethernet cable), reboot and see what happens. Also, here's a link how best to install and use Testing like a "rolling" release. Something I do not recommend. https://wiki.debian.org/DebianTesting B
Re: Slow boot
On 8/14/18, Johann Spies wrote: > On Tue, 14 Aug 2018 at 17:18, Patrick Bartek wrote: > >> I'm curious. Did you just do a distribution upgrade on this laptop? >> From what to what? Or was it a clean install? Or is it an old install >> with everything working fine until now? > > I do regular dist-upgrades (testing) and have installed it as a new > computer about two or three years ago. I started having some SLOW response times going back maybe 2 weeks ago. I've not tied it to anything specific until today. Mine's not at bootup, that goes quickly. This is immediately after I'm already in. It's both Thunar file manager and Mousepad text editor in Xfce4 environment. I'll click... pick a feature, ANY feature, and wait... and wait.. and wait.. And that's on a brand new, fresh reboot with approximate 6GB memory. Today something happened, and I ended up kicking an operating system's liveCD out of /dev/sr0 where it had been sitting quietly doing nothing. At least I think it was not engaged in any activity... :D Everything's been working fabulously ever since... That drive started automounting a few days ago after years of not doing so. No intervention from me *that I know of*. I've played with virtual machines, but I don't think that came into it because it has happened multiple times on reboots where I haven't touched VMs at all. Just tossing it out there because it's an exasperatingly slow something and may lead to an answer for someone eventually :) Cindy :) -- Cindy-Sue Causey Backyard Pishing (Very active private birding adventure) * runs with duct tape *
Re: Slow boot
On Tue, 14 Aug 2018 at 17:18, Patrick Bartek wrote: > I'm curious. Did you just do a distribution upgrade on this laptop? > From what to what? Or was it a clean install? Or is it an old install > with everything working fine until now? I do regular dist-upgrades (testing) and have installed it as a new computer about two or three years ago. Regards Johann -- Because experiencing your loyal love is better than life itself, my lips will praise you. (Psalm 63:3)
Re: Slow boot
On Tue, 14 Aug 2018 08:45:09 +0200 Johann Spies wrote: > I can push the power on button on my laptop, go and make coffee and > come back and wait a few minutes before I can work. > > The following services each takes longer than 10 seconds to activate: > > systemd-analyze blame > 1min 21.617s apt-daily.service > 1min 2.473s systemd-tmpfiles-setup.service > 1min 926ms console-setup.service > 47.192s postgresql@10-main.service > 38.873s exim4.service > 29.176s shorewall.service > 23.365s wicd.service > 22.402s mariadb.service > 18.925s nmbd.service > 13.917s udisks2.service > 13.177s ModemManager.service > 11.865s libvirtd.service > > I can disable apt-daily.service but I do not think the system will > work properly if I disable the second. The third one (console-setup) > seems to have a bug: > > systemd[1]: Failed to start Set console font and keymap. > It is looking for a file (symbols/us-intl) that does not exist > Aug 14 08:02:55 sitasie console-setup.sh[769]: setupcon: The keyboard > model is unknown, assuming 'pc105'. Keyboard may be configured > incorrectly. > Aug 14 08:03:55 sitasie console-setup.sh[769]: /usr/bin/ckbcomp: Can > not find file "symbols/us-intl" in any known directory > > This is the joy that I get since systemd became the standard. I'm curious. Did you just do a distribution upgrade on this laptop? From what to what? Or was it a clean install? Or is it an old install with everything working fine until now? B
Re: Slow boot
On Tue, 14 Aug 2018 at 12:32, Martin wrote: > Just a guess: If you have no working network, DNS in specific, it may take > ages until you local resolver terminates with a time out error. This could be > one reason, why this apt-daily.service (and may be exim) takes that long. > Correct guess. I did not realize before today that the apt-daily.service was part of the problem. As part of the university's network I have to unlock access to the internet. And that can only happen through a web browser. Regards Johann -- Because experiencing your loyal love is better than life itself, my lips will praise you. (Psalm 63:3)
Re: Slow boot
On Tue, 14 Aug 2018 at 12:22, Anders Andersson wrote: > > On Tue, Aug 14, 2018 at 8:45 AM, Johann Spies wrote: > I don't remember now if it's possible to log I/O activity, but maybe > you can inform us about the physical drive at least? I have a rotating disk - no ssd. I have since removed mariadb - which was installed as a dependency somewhere in the past. I will also remove libvirt as I do not really use it. Regards Johann -- Because experiencing your loyal love is better than life itself, my lips will praise you. (Psalm 63:3)
Re: Slow boot
Am 14.08.2018 um 08:45 schrieb Johann Spies: > I can push the power on button on my laptop, go and make coffee and > come back and wait a few minutes before I can work. > > The following services each takes longer than 10 seconds to activate: > > systemd-analyze blame > 1min 21.617s apt-daily.service > 1min 2.473s systemd-tmpfiles-setup.service > 1min 926ms console-setup.service > 47.192s postgresql@10-main.service > 38.873s exim4.service > 29.176s shorewall.service > 23.365s wicd.service > 22.402s mariadb.service > 18.925s nmbd.service > 13.917s udisks2.service > 13.177s ModemManager.service > 11.865s libvirtd.service > > I can disable apt-daily.service but I do not think the system will > work properly if I disable the second. The third one (console-setup) > seems to have a bug: > > systemd[1]: Failed to start Set console font and keymap. > It is looking for a file (symbols/us-intl) that does not exist > Aug 14 08:02:55 sitasie console-setup.sh[769]: setupcon: The keyboard > model is unknown, assuming 'pc105'. Keyboard may be configured > incorrectly. > Aug 14 08:03:55 sitasie console-setup.sh[769]: /usr/bin/ckbcomp: Can > not find file "symbols/us-intl" in any known directory > > This is the joy that I get since systemd became the standard. > > Regards > Johann > Just a guess: If you have no working network, DNS in specific, it may take ages until you local resolver terminates with a time out error. This could be one reason, why this apt-daily.service (and may be exim) takes that long.
Re: Slow boot
On Tue, Aug 14, 2018 at 8:45 AM, Johann Spies wrote: > I can push the power on button on my laptop, go and make coffee and > come back and wait a few minutes before I can work. > > The following services each takes longer than 10 seconds to activate: > > systemd-analyze blame > 1min 21.617s apt-daily.service > 1min 2.473s systemd-tmpfiles-setup.service > 1min 926ms console-setup.service > 47.192s postgresql@10-main.service > 38.873s exim4.service > 29.176s shorewall.service > 23.365s wicd.service > 22.402s mariadb.service > 18.925s nmbd.service > 13.917s udisks2.service > 13.177s ModemManager.service > 11.865s libvirtd.service > > I can disable apt-daily.service but I do not think the system will > work properly if I disable the second. The third one (console-setup) > seems to have a bug: > > systemd[1]: Failed to start Set console font and keymap. > It is looking for a file (symbols/us-intl) that does not exist > Aug 14 08:02:55 sitasie console-setup.sh[769]: setupcon: The keyboard > model is unknown, assuming 'pc105'. Keyboard may be configured > incorrectly. > Aug 14 08:03:55 sitasie console-setup.sh[769]: /usr/bin/ckbcomp: Can > not find file "symbols/us-intl" in any known directory > > This is the joy that I get since systemd became the standard. Not sure you can blame systemd here, except that without systemd you would have no clue what took so much time. Most of these services shouldn't take that long to start, and systemd is just the messenger here. What more, the system should still boot up without most of these, especially the databases. Part from console-setup being broken, I'm a bit curious about your hard drive activity and if you have a rotating platter drive or an SSD. If you start up apt-daily, two databases and libvirt in parallel on a rotating platter laptop drive, I'd expect a huge amount of disk thrashing. I don't remember now if it's possible to log I/O activity, but maybe you can inform us about the physical drive at least?
Re: Slow boot when network up
Marek Pawinski wrote: Hi, I have noticed recently when my DSL router is on and connected and i power on my machine, it's gets to the part (after i hit enter on my kernel of choice) where a message appears loading please wait and this goes on for a few minutes. However if my router is powered down Debian Squeeze 6.05 amd64 boots in a few seconds. What happens if you take out quiet from the kernel commandline? Hugo -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/k3tf06$e1a$1...@ger.gmane.org
Re: Slow boot when network up
On 26/09/2012 01:33, hvw59601 wrote: Marek Pawinski wrote: Hi, I have noticed recently when my DSL router is on and connected and i power on my machine, it's gets to the part (after i hit enter on my kernel of choice) where a message appears loading please wait and this goes on for a few minutes. However if my router is powered down Debian Squeeze 6.05 amd64 boots in a few seconds. What happens if you take out quiet from the kernel commandline? Hugo Cool i will try it on the next grid power failure. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50624a71.9020...@pawinski.co.za
Re: Slow boot when network up
On 9/25/2012 1:33 PM, Marek Pawinski wrote: Hi, I have noticed recently when my DSL router is on and connected and i power on my machine, it's gets to the part (after i hit enter on my kernel of choice) where a message appears loading please wait and this goes on for a few minutes. However if my router is powered down Debian Squeeze 6.05 amd64 boots in a few seconds. Is your DSL router connected to the PC via ethernet, via USB, or is this a wireless router. Does the PC get its IP address from the router via DHCP? If so, it may simply be that the router is slow in responding to the DHCP request. If it's wireless, it could be that logon to the router is slow for some reason. You specifically mentioned 6.05. Did this slow boot exist with previous Debian versions? Do you have any other computers using this router? Do they boot slowly as well? Are they Linux, MS Windows, Mac, or other? -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5062590e.20...@hardwarefreak.com
Re: Slow boot when network up
On 26/09/2012 03:23, Stan Hoeppner wrote: On 9/25/2012 1:33 PM, Marek Pawinski wrote: Hi, I have noticed recently when my DSL router is on and connected and i power on my machine, it's gets to the part (after i hit enter on my kernel of choice) where a message appears loading please wait and this goes on for a few minutes. However if my router is powered down Debian Squeeze 6.05 amd64 boots in a few seconds. Is your DSL router connected to the PC via ethernet, via USB, or is this I am connected to the DSL via a modem/router which is connected to a router only (no dial up function for DSL except USB 3G and has wifi capabilities) , basically I use Ethernet mostly. a wireless router. Does the PC get its IP address from the router via DHCP? If so, it may simply be that the router is slow in responding to the DHCP request. I don't use DHCP as it messes with my NFS If it's wireless, it could be that logon to the router is slow for some reason. You specifically mentioned 6.05. Did this slow boot exist with previous Debian versions? Can't remember, I will try and boot up with 3g connected one day and see what happens. Do you have any other computers using this router? Do they boot slowly as well? No they boot fast Are they Linux, MS Windows, Mac, or other? I am not familiar with the terms MS Windows, Mac, I will look them up on Google :-) Actually come to think of it i have Ubuntu 12.04.1 on another hard drive and in the same machine it boots up super quick. I will attempt what Hugo said in the near future. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50626919.9090...@pawinski.co.za
Re: SLOW boot disk?
In a message dated 2/24/99 11:14:07 AM Central Standard Time, [EMAIL PROTECTED] writes: Curiosity question here: I dual-boot Debian and Win95 by using a boot disk for Debian (it's partition is the last 1.2GB on a 6.4GB disk, so LILO doesn't like booting it). The book disk takes a LONG time to boot - 2 or 3 minutes just to do the initial load, then it starts loading off the HD and everything flies... I just created a boot disk during the install, same as on another PC I use, but the home one is slow, while the work one is nice and fast... Any ideas? Yah - use loadlin. It will do almost the same thing as LILO but without chaning the boot record. -Jay
RE: SLOW boot disk?
Curiosity question here: I dual-boot Debian and Win95 by using a boot disk for Debian (it's partition is the last 1.2GB on a 6.4GB disk, so LILO doesn't like booting it). The book disk takes a LONG time to boot - 2 or 3 minutes just to do the initial load, then it starts loading off the HD and everything flies... I just created a boot disk during the install, same as on another PC I use, but the home one is slow, while the work one is nice and fast... Any ideas? Yah - use loadlin. It will do almost the same thing as LILO but without chaning the boot record. Also have the LinLod95 package installed - when I want to swap from 95 to Linux I just fire it up and go. I was just wondering why a floppy could boot so slowly...
RE: SLOW boot disk - missing 'compact' option?
I had the same thing happen: 5+minute load for some boot floppies, others ran 'normally' (60 seconds). Is this what the LILO COMPACT option addresses? -- From: Hogland, Thomas E. To: debian-user@lists.debian.org; '[EMAIL PROTECTED]' Subject: RE: SLOW boot disk? Date: Wednesday, February 24, 1999 9:29AM Curiosity question here: I dual-boot Debian and Win95 by using a boot disk for Debian (it's partition is the last 1.2GB on a 6.4GB disk, so LILO doesn't like booting it). The book disk takes a LONG time to boot - 2 or 3 minutes just to do the initial load, then it starts loading off the HD and everything flies... I just created a boot disk during the install, same as on another PC I use, but the home one is slow, while the work one is nice and fast... Any ideas? Yah - use loadlin. It will do almost the same thing as LILO but without chaning the boot record. Also have the LinLod95 package installed - when I want to swap from 95 to Linux I just fire it up and go. I was just wondering why a floppy could boot so slowly... -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
RE: SLOW boot disk?
At 08:29 AM 2/24/1999 -0900, Hogland, Thomas E. wrote: Curiosity question here: I dual-boot Debian and Win95 by using a boot disk for Debian (it's partition is the last 1.2GB on a 6.4GB disk, so LILO doesn't like booting it). The book disk takes a LONG time to boot - 2 or 3 minutes just to do the initial load, then it starts loading off the HD and everything flies... I just created a boot disk during the install, same as on another PC I use, but the home one is slow, while the work one is nice and fast... Any ideas? Yah - use loadlin. It will do almost the same thing as LILO but without chaning the boot record. Also have the LinLod95 package installed - when I want to swap from 95 to Linux I just fire it up and go. I was just wondering why a floppy could boot so slowly... Just a couple of things to check. Maybe the floppy itself has a bad sector. Maybe the CMOS is set to the wrong type (720 instead of 1.4, etc) and that may be causing read problems. Both of these might cause slowness without causing error messages.
Re: SLOW boot disk?
Hogland, Thomas E. [EMAIL PROTECTED] writes: Curiosity question here: I dual-boot Debian and Win95 by using a boot disk for Debian (it's partition is the last 1.2GB on a 6.4GB disk, so LILO doesn't like booting it). The book disk takes a LONG time to boot - 2 or 3 minutes just to do the initial load, then it starts loading off the HD and everything flies... I just created a boot disk during the install, same as on another PC I use, but the home one is slow, while the work one is nice and fast... Any ideas? This is because we use the -s (== slow, stupid, _safe_) option on them, because we wanted the discs to boot on every PC. There is a resc1440-fast.bin disk image in the disks-i386 directory. Try it. Jens --- [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 2048/E451C639 Jens Ritter Key fingerprint: 5F 3D 43 1E 24 1E CC 48 1E 05 93 3A A7 10 73 37
RE: SLOW boot disk?
Curiosity question here: I dual-boot Debian and Win95 by using a boot disk for Debian (it's partition is the last 1.2GB on a 6.4GB disk, so LILO doesn't like booting it). The book disk takes a LONG time to boot - 2 or 3 minutes just to do the initial load, then it starts loading off the HD and everything flies... I just created a boot disk during the install, same as on another PC I use, but the home one is slow, while the work one is nice and fast... Any ideas? This is because we use the -s (== slow, stupid, _safe_) option on them, because we wanted the discs to boot on every PC. There is a resc1440-fast.bin disk image in the disks-i386 directory. Try it. Will have to try it, but will the resc1440 disks boot to the HD-installed stuff? (I thought they were set up to boot for an install...) Hmmm, boot option of linux root=/dev/hda2 maybe?
