On 26/10/2014, Curt wrote:
> On 2014-10-25, Bret Busby wrote:
>>
>> which, from my understanding of a previous post or web page, relating
>> to Debian 6 LTS, is what is supposed to be in that file, to have
>> Debian 6 LTS updating as it should.
>>
>
> What I see here
>
> https://wiki.debian.org/L
Bret Busby wrote:
> Why a web page published to provide information to the public, needs
> to be "https", I have no idea.
To create more https traffic. If you only encrypt important things
then if it is encrypted them it must be important. An attacker now
knows that every piece of encrypted traf
On Sat, Oct 25, 2014 at 11:37:32PM +0800, Bret Busby wrote:
> On 25/10/2014, Andrei POPESCU wrote:
> > On Sb, 25 oct 14, 19:04:18, Bret Busby wrote:
> >>
> >> :~# df -h
> >> FilesystemSize Used Avail Use% Mounted on
> > ...
> >> /dev/sda8 77G 73G 194M 100% /home
> >
>
On 26/10/2014, Curt wrote:
> On 2014-10-25, Bret Busby wrote:
>>
>> which, from my understanding of a previous post or web page, relating
>> to Debian 6 LTS, is what is supposed to be in that file, to have
>> Debian 6 LTS updating as it should.
>>
>
> What I see here
>
> https://wiki.debian.org/L
On 2014-10-25, Bret Busby wrote:
>
> which, from my understanding of a previous post or web page, relating
> to Debian 6 LTS, is what is supposed to be in that file, to have
> Debian 6 LTS updating as it should.
>
What I see here
https://wiki.debian.org/LTS/Using
doesn't seem to correspond with
On 25/10/2014, Andrei POPESCU wrote:
> On Sb, 25 oct 14, 19:04:18, Bret Busby wrote:
>>
>> :~# df -h
>> FilesystemSize Used Avail Use% Mounted on
> ...
>> /dev/sda8 77G 73G 194M 100% /home
>
> Can't tell if this is the source of you problems, but I've seen all
> sorts
Hello, Cindy.
On 25/10/2014, Cindy-Sue Causey wrote:
> On 10/25/14, Andrei POPESCU wrote:
>> On Sb, 25 oct 14, 19:04:18, Bret Busby wrote:
>>>
>>> :~# df -h
>>> FilesystemSize Used Avail Use% Mounted on
>> ...
>>> /dev/sda8 77G 73G 194M 100% /home
>>
>> Can't tell if
On 10/25/14, Andrei POPESCU wrote:
> On Sb, 25 oct 14, 19:04:18, Bret Busby wrote:
>>
>> :~# df -h
>> FilesystemSize Used Avail Use% Mounted on
> ...
>> /dev/sda8 77G 73G 194M 100% /home
>
> Can't tell if this is the source of you problems, but I've seen all
> sorts of
On Sb, 25 oct 14, 19:04:18, Bret Busby wrote:
>
> :~# df -h
> FilesystemSize Used Avail Use% Mounted on
...
> /dev/sda8 77G 73G 194M 100% /home
Can't tell if this is the source of you problems, but I've seen all
sorts of strange failures with a full /home, including X
On 25/10/14 22:06, Bret Busby wrote:
> On 25/10/2014, Scott Ferguson wrote:
>> On 25/10/14 21:47, Bret Busby wrote:
>>> On 25/10/2014, Bret Busby wrote:
On 25/10/2014, Andrei POPESCU wrote:
> On Sb, 25 oct 14, 18:17:02, Bret Busby wrote:
>> On 25/10/2014, Brian wrote:
>>>
>>
>
On 25/10/2014, Scott Ferguson wrote:
> On 25/10/14 21:47, Bret Busby wrote:
>> On 25/10/2014, Bret Busby wrote:
>>> On 25/10/2014, Andrei POPESCU wrote:
On Sb, 25 oct 14, 18:17:02, Bret Busby wrote:
> On 25/10/2014, Brian wrote:
>>
>
>>
>> So, now I am confused, as to whether I ma
On 25/10/2014, Scott Ferguson wrote:
> On 25/10/14 21:17, Bret Busby wrote:
>> On 25/10/2014, Brian wrote:
>>> On Sat 25 Oct 2014 at 11:44:32 +0800, Bret Busby wrote:
>>>
On 23/10/2014, Bob Proulx wrote:
> Igor Sverkos wrote:
>> As you can see, it is always the "Unpacking" step whic
On 25/10/14 21:47, Bret Busby wrote:
> On 25/10/2014, Bret Busby wrote:
>> On 25/10/2014, Andrei POPESCU wrote:
>>> On Sb, 25 oct 14, 18:17:02, Bret Busby wrote:
On 25/10/2014, Brian wrote:
>
>
> So, now I am confused, as to whether I managed to achieve a successful
> system update.
>
On 25/10/14 21:17, Bret Busby wrote:
> On 25/10/2014, Brian wrote:
>> On Sat 25 Oct 2014 at 11:44:32 +0800, Bret Busby wrote:
>>
>>> On 23/10/2014, Bob Proulx wrote:
Igor Sverkos wrote:
> As you can see, it is always the "Unpacking" step which is taking all
> the
> time.
>>>
On 25/10/2014, Bret Busby wrote:
> On 25/10/2014, Andrei POPESCU wrote:
>> On Sb, 25 oct 14, 18:17:02, Bret Busby wrote:
>>> On 25/10/2014, Brian wrote:
>>> >
>>> > Please post the output of
>>> >
>>> >apt-get update
>>>
>>> "
>>> :~# apt-get update
>>
>> That looks fine. Please try 'apt-get
On 25/10/2014, Andrei POPESCU wrote:
> On Sb, 25 oct 14, 18:17:02, Bret Busby wrote:
>> On 25/10/2014, Brian wrote:
>> >
>> > Please post the output of
>> >
>> >apt-get update
>>
>> "
>> :~# apt-get update
>
> That looks fine. Please try 'apt-get upgrade'.
>
"
:~# apt-get upgrade
E: Could n
On Sb, 25 oct 14, 18:17:02, Bret Busby wrote:
> On 25/10/2014, Brian wrote:
> >
> > Please post the output of
> >
> >apt-get update
>
> "
> :~# apt-get update
That looks fine. Please try 'apt-get upgrade'.
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussio
On 25/10/2014, Bret Busby wrote:
> On 25/10/2014, Bret Busby wrote:
>> On 25/10/2014, Brian wrote:
>>> On Sat 25 Oct 2014 at 11:44:32 +0800, Bret Busby wrote:
>>>
On 23/10/2014, Bob Proulx wrote:
> Igor Sverkos wrote:
>> As you can see, it is always the "Unpacking" step which is
On 25/10/2014, Bret Busby wrote:
> On 25/10/2014, Brian wrote:
>> On Sat 25 Oct 2014 at 11:44:32 +0800, Bret Busby wrote:
>>
>>> On 23/10/2014, Bob Proulx wrote:
>>> > Igor Sverkos wrote:
>>> >> As you can see, it is always the "Unpacking" step which is taking all
>>> >> the
>>> >> time.
>>> >
>
On 25/10/2014, Brian wrote:
> On Sat 25 Oct 2014 at 11:44:32 +0800, Bret Busby wrote:
>
>> On 23/10/2014, Bob Proulx wrote:
>> > Igor Sverkos wrote:
>> >> As you can see, it is always the "Unpacking" step which is taking all
>> >> the
>> >> time.
>> >
>> > dpkg has added fsync() calls after all f
On Sat 25 Oct 2014 at 11:44:32 +0800, Bret Busby wrote:
> On 23/10/2014, Bob Proulx wrote:
> > Igor Sverkos wrote:
> >> As you can see, it is always the "Unpacking" step which is taking all the
> >> time.
> >
> > dpkg has added fsync() calls after all file actions. This
> > significantly slows d
On 23/10/2014, Bob Proulx wrote:
> Igor Sverkos wrote:
>> As you can see, it is always the "Unpacking" step which is taking all the
>> time.
>
> dpkg has added fsync() calls after all file actions. This
> significantly slows down file operations. Basically it disables the
> file system buffer ca
On Thursday, October 23, 2014 11:10:05 AM UTC+5:30, Bob Proulx wrote:
> Igor Sverkos wrote:
> > As you can see, it is always the "Unpacking" step which is taking all the
> > time.
>
> dpkg has added fsync() calls after all file actions. This
> significantly slows down file operations. Basically
Hi,
I already read the FAQ, that's why I am already using the "nodelalloc"
mount option.
I also tried "eatmydata":
> # eatmydata annotate-output apt-get install --reinstall tzdata
> 14:02:27 I: Started apt-get install --reinstall tzdata
> 14:02:27 O: Reading package lists...
> 14:02:27 O: Buildi
On Jo, 23 oct 14, 08:33:00, Curt wrote:
>
> What about some of the other workarounds/solutions outlined here
> (there)?
>
> https://wiki.debian.org/Teams/Dpkg/FAQ#User_Questions
>
> (Q: Why is dpkg so slow when using new filesystems such as btrfs or ext4?)
I'd be interested about the 'nodelallo
On 2014-10-23, Bob Proulx wrote:
>
>
> I expect this suggestion to be followed by many people griping that my
> suggestion is unsafe and that the years and years we spent living
> without fsync() were unsafe. But we did. We had at least a decade of
> fast systems in the "before time". And the s
Igor Sverkos wrote:
> As you can see, it is always the "Unpacking" step which is taking all the
> time.
dpkg has added fsync() calls after all file actions. This
significantly slows down file operations. Basically it disables the
file system buffer cache causing it to operate at disk drive spee
Hi,
I've got a physical machine with jessie/sid where installing/updating
a packages takes very long:
> # annotate-output strace -s 4096 -e trace=file -f -ttt -o /tmp/dpkg-debug.log
> apt-get install --reinstall tzdata
> 20:13:28 I: Started strace -s 4096 -e trace=file -f -ttt -o
> /tmp/dpkg-de
28 matches
Mail list logo
