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.
> [...]
> > $ sud
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="sw
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.
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
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)
>> initial
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.)
>>
>>
>> Manual
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!
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: S
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
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.
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 (
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
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: d
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.
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 pasteb
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.71
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)
>
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 un
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
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
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.6
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.
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 mar
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-dail
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 a
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..
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 mi
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
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
> > 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
"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 th
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
>
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
> > 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 load
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
35 matches
Mail list logo
