On Sun, 16 Oct 2022 23:44:00 +0100
Mark Fletcher wrote:
> "apt list --upgradable" shows a new version of the Amazon Workspaces
> client, version 4.3.0.1766. It also shows that there is one more
> version available.
This may be a silly question, but have you checked with Amazon customer
support?
On Sun, 16 Oct 2022 23:44:00 +0100 Mark Fletcher wrote:
> After "sudo apt update", the system informs me there is 1 package that can
> be upgraded.
>
> "sudo apt upgrade" reports nothing to do, 0 packages upgraded, 0 newly
> installed, 0 to remove and 0 not upgraded...
One possible reason
On Sun 16 Oct 2022 at 23:44:00 (+0100), Mark Fletcher wrote:
>
> Tonight I am seeing a behaviour pattern in my Debian Bullseye system that I
> have not seen before.
>
> After "sudo apt update", the system informs me there is 1 package that can
> be upgraded.
>
> "sudo apt upgrade" reports
Hi
Tonight I am seeing a behaviour pattern in my Debian Bullseye system that I
have not seen before.
After "sudo apt update", the system informs me there is 1 package that can
be upgraded.
"sudo apt upgrade" reports nothing to do, 0 packages upgraded, 0 newly
installed, 0 to remove and 0 not
On Sun 22 Aug 2021, at 15:37, David Wright wrote:
> On Sun 22 Aug 2021 at 13:18:38 (+0100), Gareth Evans wrote:
> > On Sun 22 Aug 2021, at 05:36, David Wright wrote:
> > > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
>
> > > > There is also no explanation in term.log, syslog or
On Sun 22 Aug 2021 at 13:18:38 (+0100), Gareth Evans wrote:
> On Sun 22 Aug 2021, at 05:36, David Wright wrote:
> > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > > There is also no explanation in term.log, syslog or dpkg.log for the
> > > second interruption:
> > >
> > > --
>
On Sun 22 Aug 2021, at 13:18, Gareth Evans wrote:
> On Sun 22 Aug 2021, at 05:36, David Wright wrote:
> > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > > On Fri 20 Aug 2021, at 04:45, David Wright
> > > wrote:
> > > > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans
On Sun 22 Aug 2021, at 05:36, David Wright wrote:
> On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > On Fri 20 Aug 2021, at 04:45, David Wright wrote:
> > > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
>
> > $ apt policy pitivi
> > pitivi:
> > Installed:
On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> On Fri 20 Aug 2021, at 04:45, David Wright wrote:
> > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> $ apt policy pitivi
> pitivi:
> Installed: 0.999-1+b1
> Candidate: 0.999-1+b1
> Version table:
> *** 0.999-1+b1
On Sat 21 Aug 2021, at 13:42, Sven Hartge wrote:
> Gareth Evans wrote:
>
> > So I would like to know if apt is not handling this properly, or if
> > the scenario of a file changing packages (see David's previous email)
> > is an expected exception to the (sort of) rule.
>
Hi Sven,
> >
Gareth Evans wrote:
> So I would like to know if apt is not handling this properly, or if
> the scenario of a file changing packages (see David's previous email)
> is an expected exception to the (sort of) rule.
> Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?
No, because
On Fri 20 Aug 2021, at 04:45, David Wright wrote:
> On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> > On Thu 19 Aug 2021, at 05:50, David Wright wrote:
> > > On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > > > On Wed 18 Aug 2021, at 23:33, piorunz wrote:
> > > > >
On Fri 20 Aug 2021, at 12:32, Greg Wooledge wrote:
> On Thu, Aug 19, 2021 at 10:45:57PM -0500, David Wright wrote:
> > One might assume so, but only you can check that. There are two logs
> > of the upgrade. /var/log/apt/history.log (and its predecessors) shows
> > the command issued, followed by
On Thu, Aug 19, 2021 at 10:45:57PM -0500, David Wright wrote:
> One might assume so, but only you can check that. There are two logs
> of the upgrade. /var/log/apt/history.log (and its predecessors) shows
> the command issued, followed by the packages affected, with the old
> and new version
On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> On Thu 19 Aug 2021, at 05:50, David Wright wrote:
> > On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > > On Wed 18 Aug 2021, at 23:33, piorunz wrote:
> > > > On 18/08/2021 16:14, Gareth Evans wrote:
> > > > > Unpacking
On Thu 19 Aug 2021, at 05:50, David Wright wrote:
> On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > On Wed 18 Aug 2021, at 23:33, piorunz wrote:
> > > On 18/08/2021 16:14, Gareth Evans wrote:
> > > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > > [1mdpkg:[0m
On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> On Wed 18 Aug 2021, at 23:33, piorunz wrote:
> > On 18/08/2021 16:14, Gareth Evans wrote:
> > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > [1mdpkg:[0m error processing archive
> > >
On Wed 18 Aug 2021, at 23:33, piorunz wrote:
> On 18/08/2021 16:14, Gareth Evans wrote:
> > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > [1mdpkg:[0m error processing archive
> > /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> > (--unpack):
> >
On 18/08/2021 16:14, Gareth Evans wrote:
Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
[1mdpkg:[0m error processing archive
/tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
(--unpack):
trying to overwrite
On Wed 18 Aug 2021, at 00:44, Gareth Evans wrote:
> Hello,
>
> I upgraded from Buster stable to Bullseye stable last night, with
> apparent success eventually, but it went less than smoothly and I would
> be grateful for any advice as to why that may have been.
>
> I followed the preparation
Hello,
I upgraded from Buster stable to Bullseye stable last night, with apparent
success eventually, but it went less than smoothly and I would be grateful for
any advice as to why that may have been.
I followed the preparation advice at
Hello,
since iOS upgrade to 14.5 last week I can not upload my photos to my samba
share (Debian/unstable) anymore.
I tried to increase logging and took a look to wireshark already but didn't
found the issue.
Anyone else has a problem with Samba since upgrade to iOS 14.5?
Thanks!
Bye
Am Freitag, 4. Januar 2019 schrieb Richard Hector:
> On 4/01/19 9:49 PM, Andy Smith wrote:
> > Stephen, I think you're going to have to analyse where the space is
> > being used. If you use a graphical desktop then there might be a
> > graphical application that can help with this. On GNOME it's
On Fri 04 Jan 2019 at 19:36:42 (-0500), Felix Miata wrote:
> David Wright composed on 2019-01-04 14:27 (UTC-0600):
> > On Fri 04 Jan 2019 at 13:41:33 (-0500), Felix Miata wrote:
> >> David Wright composed on 2019-01-04 10:19 (UTC-0600):
> >> > On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata
On 2019-01-07 02:56, John Crawley wrote:
On 06/01/2019 00.26, rhkra...@gmail.com wrote:
On Friday, January 04, 2019 08:21:30 PM David Wright wrote:
On Fri 04 Jan 2019 at 14:02:27 (-0500), Stephen P. Molnar wrote:
Having babbled for the last two paragraphs, I'll close buy saying
that
I will
On 06/01/2019 00.26, rhkra...@gmail.com wrote:
On Friday, January 04, 2019 08:21:30 PM David Wright wrote:
On Fri 04 Jan 2019 at 14:02:27 (-0500), Stephen P. Molnar wrote:
Having babbled for the last two paragraphs, I'll close buy saying that
I will revert to the entire installation on the
On Friday, January 04, 2019 08:21:30 PM David Wright wrote:
> On Fri 04 Jan 2019 at 14:02:27 (-0500), Stephen P. Molnar wrote:
> > Having babbled for the last two paragraphs, I'll close buy saying that
> > I will revert to the entire installation on the same partition.
>
> I would advise you to
Michael Stone wrote:
> songbird wrote:
>>Roberto C Sánchez wrote:
>>> It might also indicate files that exist (i.e., occupy blocks) without
>>> having directory entries. For example, this is the case when a program
>>> creates a temporary file, gets the descritor back from the syscall, then
>>>
On 05/01/2019 01:15, Felix Miata wrote:
> David Wright composed on 2019-01-04 19:21 (UTC-0600):
>
>> Ignoring /home as it dwarfs / in size, it would be very easy to make a
>> mistake if you take an existing installation and hive off the /tmp and
>> /var into separate partitions. The problem boils
On Fri, Jan 04, 2019 at 05:04:49PM -0500, songbird wrote:
> Roberto C Sánchez wrote:
> ...
> > It might also indicate files that exist (i.e., occupy blocks) without
> > having directory entries. For example, this is the case when a program
> > creates a temporary file, gets the descritor back
Hi.
On Fri, Jan 04, 2019 at 11:03:48PM -0500, rhkra...@gmail.com wrote:
> On Friday, January 04, 2019 08:23:59 AM Reco wrote:
> > # pvs
> > PV VG Fmt Attr PSize PFree
> > /dev/md10 naslvm2 a-- 14.55t 10.43t
> >
> > # hdparm -Tt /dev/md10
> > /dev/md10:
> >
On 2019-01-04 21:03, Gene Heskett wrote:
On Friday 04 January 2019 14:34:59 Brian wrote:
On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
> On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> > deloptes (12019-01-04):
> > >We just
On Friday 04 January 2019 19:32:18 deloptes wrote:
> Gene Heskett wrote:
> >> So I was thinking perhaps this is good for the economy, because if
> >> most of the users were like me, there wouldn't be any economic
> >> growth in the past years.
> >
> > I see that too, darn it.
>
> Suddenly I
On Friday, January 04, 2019 08:23:59 AM Reco wrote:
> # pvs
> PV VG Fmt Attr PSize PFree
> /dev/md10 naslvm2 a-- 14.55t 10.43t
>
> # hdparm -Tt /dev/md10
> /dev/md10:
> Timing cached reads: 1224 MB in 2.00 seconds = 612.05 MB/sec
> Timing buffered disk reads:
David Wright composed on 2019-01-04 19:21 (UTC-0600):
> On Fri 04 Jan 2019 at 14:02:27 (-0500), Stephen P. Molnar wrote:
>> Felix Miata wrote:
>>> Stephen P. Molnar composed on 2019-01-04 12:57 (UTC-0500):
I haven't messed around with partitioning since the early days of
Slackware,
On Fri 04 Jan 2019 at 14:02:27 (-0500), Stephen P. Molnar wrote:
> On 01/04/2019 01:11 PM, Felix Miata wrote:
> > Stephen P. Molnar composed on 2019-01-04 12:57 (UTC-0500):
> >
> > > I haven't messed around with partitioning since the early days of
> > > Slackware, and that was with a great deal
On Fri 04 Jan 2019 at 16:18:03 (-0500), Roberto C. Sánchez wrote:
> On Fri, Jan 04, 2019 at 02:39:40PM -0600, David Wright wrote:
> >
> > There's at least one other scenario that it would be worth eliminating
> > by checking that this equation is true (allowing for filesystem overheads):
> >
> >
David Wright composed on 2019-01-04 14:27 (UTC-0600):
> On Fri 04 Jan 2019 at 13:41:33 (-0500), Felix Miata wrote:
>> David Wright composed on 2019-01-04 10:19 (UTC-0600):
>> > On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote:
>> >>> This partitioning scheme seems really odd and
Gene Heskett wrote:
>> So I was thinking perhaps this is good for the economy, because if
>> most of the users were like me, there wouldn't be any economic growth
>> in the past years.
>
> I see that too, darn it.
Suddenly I spotted something that fits our discussion by the worst example -
On Fri, Jan 04, 2019 at 05:04:49PM -0500, songbird wrote:
Roberto C Sánchez wrote:
It might also indicate files that exist (i.e., occupy blocks) without
having directory entries. For example, this is the case when a program
creates a temporary file, gets the descritor back from the syscall,
Roberto C Sánchez wrote:
...
> It might also indicate files that exist (i.e., occupy blocks) without
> having directory entries. For example, this is the case when a program
> creates a temporary file, gets the descritor back from the syscall, then
> immediatley calls unlink on it. The file
David Wright wrote:
> On Fri 04 Jan 2019 at 17:13:44 (+), Eduardo M KALINOWSKI wrote:
>> On sex, 04 jan 2019, David Wright wrote:
>> > On Fri 04 Jan 2019 at 16:52:45 (+), Eduardo M KALINOWSKI wrote:
>> > > And in this case, the problem is easy to solve:
>> > > rm
Joe wrote:
> Reinstalling looks good until you've done it, the old installation is
> history, and over the next few weeks you realise how much time you had
> spent over the last few years tweaking your computer to get it the way
> you like it.
>
> And no, you cannot at the same time a) clear out
On Fri, Jan 04, 2019 at 02:39:40PM -0600, David Wright wrote:
>
> There's at least one other scenario that it would be worth eliminating
> by checking that this equation is true (allowing for filesystem overheads):
>
> # du -shx
> +
> $ df's Available
> ≃
> partition's size.
On Friday 04 January 2019 14:34:59 Brian wrote:
> On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
> > On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> > > deloptes (12019-01-04):
> > > > We just pointed out
> > > > that you do not
On Fri 04 Jan 2019 at 14:02:27 -0500, Stephen P. Molnar wrote:
> On 01/04/2019 01:11 PM, Felix Miata wrote:
> > Stephen P. Molnar composed on 2019-01-04 12:57 (UTC-0500):
> >
> > > I haven't messed around with partitioning since the early days of
> > > Slackware, and that was with a great deal
On Fri 04 Jan 2019 at 17:13:44 (+), Eduardo M KALINOWSKI wrote:
> On sex, 04 jan 2019, David Wright wrote:
> > On Fri 04 Jan 2019 at 16:52:45 (+), Eduardo M KALINOWSKI wrote:
> > > And in this case, the problem is easy to solve:
> > > rm /path/to/some/large/files/*
> >
> > Wrong again.
On Fri, 04 Jan 2019 20:46:53 +0100
deloptes wrote:
>
> I asked why he does not reinstall, but didn't get meaningful answer -
> only, I can not do it and it takes too much time.
>
> One can not argue with educated people, so I gave up.
> This is just an example how it works for most of the
On Fri 04 Jan 2019 at 13:41:33 (-0500), Felix Miata wrote:
> David Wright composed on 2019-01-04 10:19 (UTC-0600):
>
> > On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote:
>
> >>> This partitioning scheme seems really odd and unwieldy.
>
> >> Indeed. Considering the absence of a
On Fri, Jan 04, 2019 at 08:09:55PM +, Brian wrote:
> On Fri 04 Jan 2019 at 14:37:36 -0500, Roberto C. Sánchez wrote:
>
> > On Fri, Jan 04, 2019 at 07:34:59PM +, Brian wrote:
> > > On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
> > >
> > > > On Friday 04 January 2019 13:31:05
On Fri 04 Jan 2019 at 14:37:36 -0500, Roberto C. Sánchez wrote:
> On Fri, Jan 04, 2019 at 07:34:59PM +, Brian wrote:
> > On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
> >
> > > On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> > >
> > > > deloptes (12019-01-04):
> > > >
On 4/01/19 9:49 PM, Andy Smith wrote:
> Stephen, I think you're going to have to analyse where the space is
> being used. If you use a graphical desktop then there might be a
> graphical application that can help with this. On GNOME it's called
> Disk Usage Analyzer. On the command line you could
Nicolas George wrote:
> It really is not, because the resources invested in the old computer are
> wasted (unless somebody gets it and recycles it). It is the same scheme
> than in Chaplin's _The Kid_: breaking a window to let a glazier sell a
> new one.
>
> Alas, the idiotic way most people
Brian wrote:
> Using the facilities on a computer is what a user does, just like the
> simple task of switching on an electric light in a house.
>
> If by "operating", deloptes means "using", I think I could agree. If
> he means change the bulb or mend the fuse or go down to to the local
>
Gene Heskett wrote:
> On Friday 04 January 2019 13:31:05 Nicolas George wrote:
>
>> deloptes (12019-01-04):
>> >We just pointed out
>> > that you do not have to be a sysadmin to operate a computer.
>>
>> And you are wrong. Operating a computer requires a sysadmin, there is
>> no way around it.
On Fri, Jan 04, 2019 at 07:34:59PM +, Brian wrote:
> On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
>
> > On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> >
> > > deloptes (12019-01-04):
> > > > We just pointed out
> > > >
On Fri 04 Jan 2019 at 13:49:52 -0500, Gene Heskett wrote:
> On Friday 04 January 2019 13:31:05 Nicolas George wrote:
>
> > deloptes (12019-01-04):
> > > We just pointed out
> > > that you do not have to be a sysadmin to operate a computer.
> >
> >
On Fri 04 Jan 2019 at 19:31:05 +0100, Nicolas George wrote:
> deloptes (12019-01-04):
> > We just pointed out
> > that you do not have to be a sysadmin to operate a computer.
>
> And you are wrong. Operating a computer requires a sysadmin, there
On 01/04/2019 01:11 PM, Felix Miata wrote:
Stephen P. Molnar composed on 2019-01-04 12:57 (UTC-0500):
I haven't messed around with partitioning since the early days of
Slackware, and that was with a great deal of trepidation?
You just multiplied my curiosity about what exactly was
On Friday 04 January 2019 13:31:05 Nicolas George wrote:
> deloptes (12019-01-04):
> > We just pointed out
> > that you do not have to be a sysadmin to operate a computer.
>
> And you are wrong. Operating a computer requires a sysadmin, there is
>
On Friday 04 January 2019 13:24:39 deloptes wrote:
> Greg Wooledge wrote:
> > All he has to do is find whatever's taking up an unexpected amount
> > of space in his root file system, and get rid of it. This is an
> > essential system management skill that he HAS to learn, which he
> > will
David Wright composed on 2019-01-04 10:19 (UTC-0600):
> On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote:
>>> This partitioning scheme seems really odd and unwieldy.
>> Indeed. Considering the absence of a sysadmin,
> What's so unusual about that?
Standing alone, absolutely
deloptes (12019-01-04):
> So I was thinking perhaps this is good for the economy, because if most of
> the users were like me, there wouldn't be any economic growth in the past
> years.
It really is not, because the resources invested in the old computer are
wasted (unless somebody gets it and
deloptes (12019-01-04):
> We just pointed out
> that you do not have to be a sysadmin to operate a computer.
And you are wrong. Operating a computer requires a sysadmin, there is no
way around it. If there is no dedicated one, that makes the
Stephen P. Molnar wrote:
> I want to thank those of you who responded to my request for assistance.
>
> A number of the replies, particularly those that did not editorialize,
> where useful in that they convinced me that reinstalling the OS is the
> simplest remedy for the problems.
>
> Let us
Greg Wooledge wrote:
> All he has to do is find whatever's taking up an unexpected amount of
> space in his root file system, and get rid of it. This is an essential
> system management skill that he HAS to learn, which he will continue
> to use well beyond the current crisis.
>
> Reinstalling
Stephen P. Molnar composed on 2019-01-04 12:57 (UTC-0500):
> I haven't messed around with partitioning since the early days of
> Slackware, and that was with a great deal of trepidation?
You just multiplied my curiosity about what exactly was responsible for your
current partitioning
scheme,
On 01/04/2019 12:13 PM, Roberto C. Sánchez wrote:
On Fri, Jan 04, 2019 at 05:47:07PM +0100, steve wrote:
Le vendredi 04 janvier 2019, Stephen P. Molnar a écrit :
where useful in that they convinced me that reinstalling the OS is the
simplest remedy for the problems.
You're welcome. But
Nicolas George wrote:
> Exactly. And the kind of payment that is expected from you for help on
> this mailing-list is not pecuniary, of course. It is that you do not
> just consume the answers given to you but instead try to increase your
> knowledge and understanding so that maybe one day you
On Fri, Jan 04, 2019 at 05:47:07PM +0100, steve wrote:
> Le vendredi 04 janvier 2019, Stephen P. Molnar a écrit :
>
>
> > where useful in that they convinced me that reinstalling the OS is the
> > simplest remedy for the problems.
>
> You're welcome. But this last sentence is pretty sad because
On sex, 04 jan 2019, David Wright wrote:
On Fri 04 Jan 2019 at 16:52:45 (+), Eduardo M KALINOWSKI wrote:
And in this case, the problem is easy to solve:
rm /path/to/some/large/files/*
Wrong again. The free space on /home is sufficient to hold 10 copies
of the entire / filesystem. And
On Fri 04 Jan 2019 at 16:52:45 (+), Eduardo M KALINOWSKI wrote:
> On sex, 04 jan 2019, steve wrote:
> > > where useful in that they convinced me that reinstalling the
> > > OS is the simplest remedy for the problems.
> >
> > You're welcome. But this last sentence is pretty sad because
On sex, 04 jan 2019, Eduardo M KALINOWSKI wrote:
And in this case, the problem is easy to solve:
rm /path/to/some/large/files/*
The usual suspects (/var/logs, /var/cache, etc) have already been
mentioned, and are in a different partition. One place to investigate
is /lib/modules. It can
On Fri 04 Jan 2019 at 08:15:11 (-0500), Greg Wooledge wrote:
> On Thu, Jan 03, 2019 at 09:22:49PM -0500, Gene Heskett wrote:
> > In this case, I hate to sound like
> > an ass, but perhaps a re-install is in the future, doing the reinstall
> > to a new drive [...]
>
> Come on, people. Show some
On sex, 04 jan 2019, steve wrote:
where useful in that they convinced me that reinstalling the OS is
the simplest remedy for the problems.
You're welcome. But this last sentence is pretty sad because normally,
issues like yours do not require windows-style operation. For your info,
I have not
Le vendredi 04 janvier 2019, Stephen P. Molnar a écrit :
where useful in that they convinced me that reinstalling the OS is the
simplest remedy for the problems.
You're welcome. But this last sentence is pretty sad because normally,
issues like yours do not require windows-style operation.
On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote:
> Andy Smith composed on 2019-01-04 08:57 (UTC):
> > Several people have now suggested saving space in a bits of the
> > filesystem that Stephen has on dedicated partitions, so this is not
> > helpful.
>
> > This partitioning scheme
I want to thank those of you who responded to my request for assistance.
A number of the replies, particularly those that did not editorialize,
where useful in that they convinced me that reinstalling the OS is the
simplest remedy for the problems.
Let us put this thread to bed and stop
On Thu, Jan 03, 2019 at 02:38:09PM -0500, Stephen P. Molnar wrote:
On 01/03/2019 01:27 PM, songbird wrote:
apt-get install libc --reinstall
root@AbNormal:/home/comp# apt-get install libc --reinstall
Reading package lists... Done
Building dependency tree
Reading state information... Done
E:
On Fri, Jan 04, 2019 at 08:44:27AM -0500, Gene Heskett wrote:
> On Friday 04 January 2019 08:15:11 Greg Wooledge wrote:
>
> > On Thu, Jan 03, 2019 at 09:22:49PM -0500, Gene Heskett wrote:
> > > In this case, I hate to sound like
> > > an ass, but perhaps a re-install is in the future, doing the
>
On Fri, Jan 04, 2019 at 08:44:27AM -0500, Gene Heskett wrote:
> My own reinstall to a new, much larger disk, recommendation still stands,
> that the OP would be back to a working system where he could remount
> that old drive to his new install and recover the data he needs to
> continue his
On Friday 04 January 2019 08:15:11 Greg Wooledge wrote:
> On Thu, Jan 03, 2019 at 09:22:49PM -0500, Gene Heskett wrote:
> > In this case, I hate to sound like
> > an ass, but perhaps a re-install is in the future, doing the
> > reinstall to a new drive [...]
>
> Come on, people. Show some sense.
Hi.
On Fri, Jan 04, 2019 at 08:13:38AM -0500, rhkra...@gmail.com wrote:
> On Friday, January 04, 2019 03:49:37 AM Andy Smith wrote:
> > It's unfortunate that LVM was not used as it would make juggling
> > space between the multiple filesystems a lot easier. Oh well.
>
> I guess I should
On Fri, Jan 04, 2019 at 10:42:57AM +, Brian wrote:
> 2. Then go through
>
>dpkg -l | less
>
>line by line, asking "do I really need that?". I'd not bother with
>looking at the library packages. Tedious? Yes, like tidying the boot
>of a car.
There are some tools that will
On Thu, Jan 03, 2019 at 09:22:49PM -0500, Gene Heskett wrote:
> In this case, I hate to sound like
> an ass, but perhaps a re-install is in the future, doing the reinstall
> to a new drive [...]
Come on, people. Show some sense. (And yes, this includes the OP.)
He simply has a full root file
On Friday, January 04, 2019 03:49:37 AM Andy Smith wrote:
> It's unfortunate that LVM was not used as it would make juggling
> space between the multiple filesystems a lot easier. Oh well.
I guess I should consider using LVM on my next install. Does it incur any
overhead during normal disk
On 2019-01-03, Andy Smith wrote:
> On Thu, Jan 03, 2019 at 10:27:30PM +0100, Nicolas George wrote:
>> > > Then ask your sysadmin.
>>
>> > I have no sysadmin.
>>
>> Then you are not "only a user", you are a sysadmin, and you are trying
>> to be one without acquiring the required knowledge.
>
> I
Roberto C. Sánchez (12019-01-04):
> That said, like owning an automobile, with a computer sometimes things
> break or quit working as expected. The machine then either has to be
> repaired or replaced and if the owner cannot handle the job on his or
> her own, then somebody else will need to
On Fri, Jan 04, 2019 at 11:16:57AM +0100, Nicolas George wrote:
> deloptes (2019-01-04):
> > Come on, the argument of Roberto C. Sánchez holds. Operator != Mechanic.
>
> And I have not suggested that Roberto become a kernel hacker. I hope you
> noticed.
>
I tried about 15 years ago. It turns
Hi.
On Fri, Jan 04, 2019 at 10:42:57AM +, Brian wrote:
> On Fri 04 Jan 2019 at 08:57:18 +, Andy Smith wrote:
>
> > Hello,
> >
> > On Fri, Jan 04, 2019 at 02:47:52AM +, Matthew Crews wrote:
> > > My guess? /home is on the same partition as /, which is a common setup
> > > for
On Fri 04 Jan 2019 at 08:57:18 +, Andy Smith wrote:
> Hello,
>
> On Fri, Jan 04, 2019 at 02:47:52AM +, Matthew Crews wrote:
> > My guess? /home is on the same partition as /, which is a common setup
> > for most end users. Running lsblk is one way to tell if this is the case.
>
> >From
Felix Miata (2019-01-03):
> As others have noted, this is your root if not entire problem.
There is still the very worrying problem that ldconfig reported "ENOENT
2 No such file or directory" instead of "ENOSPC 28 No space left on
device". This is a bug, it should be reported.
Regards,
--
deloptes (2019-01-04):
> Come on, the argument of Roberto C. Sánchez holds. Operator != Mechanic.
And I have not suggested that Roberto become a kernel hacker. I hope you
noticed.
> To
> operate a PC means you know how to
Andy Smith composed on 2019-01-04 08:57 (UTC):
> Several people have now suggested saving space in a bits of the
> filesystem that Stephen has on dedicated partitions, so this is not
> helpful.
> This partitioning scheme seems really odd and unwieldy.
Indeed. Considering the absence of a
Hi Stephen,
Stephen P. Molnar:
On 01/03/2019 02:42 PM, Greg Wooledge wrote:
On Thu, Jan 03, 2019 at 02:30:49PM -0500, Stephen P. Molnar wrote:
root@AbNormal:/home/comp# ls -ld / /etc /etc/ld.*
drwxr-xr-x 26 root root 4096 Dec 19 13:17 /
drwxr-xr-x 134 root root 12288 Jan 3 09:43 /etc
Hello,
On Fri, Jan 04, 2019 at 02:47:52AM +, Matthew Crews wrote:
> My guess? /home is on the same partition as /, which is a common setup
> for most end users. Running lsblk is one way to tell if this is the case.
>From one of Stephen's earlier emails:
root@AbNormal:/home/comp# df -hl
Hello,
On Thu, Jan 03, 2019 at 10:47:26PM -0500, Felix Miata wrote:
> Stephen P. Molnar composed on 2019-01-03 15:39 (UTC-0500):
>
> > root@AbNormal:/home/comp# df -hl
> > Filesystem Size Used Avail Use% Mounted on
> ...
> > /dev/sda123G 23G 0 100% /
>
> As others have
songbird wrote:
> often you can get quite a bit of space from the
> package cache.
>
but his var is on dedicated partition
Stephen P. Molnar composed on 2019-01-03 15:39 (UTC-0500):
> root@AbNormal:/home/comp# df -hl
> Filesystem Size Used Avail Use% Mounted on
...
> /dev/sda123G 23G 0 100% /
As others have noted, this is your root if not entire problem.
du -h on Stretch host fi965 here:
On 1/3/19 7:09 PM, Patrick Bartek wrote:
> I see from a later response that your / partition is 100% full. That
> will defintely cause problems. Whether it's THE problem, we won't know
> until you clean out / to less than 100%, say at least 90%. Less would
> be better.
>
> I don't know why
1 - 100 of 632 matches
Mail list logo
