Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #203981 > unrolled thread

Re: Upgrade Problem

Back to article view | Back to linux.debian.user

Contents

  Re: Upgrade Problem "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-01-04 17:20 +0100
    Re: Upgrade Problem steve <dlist@bluewin.ch> - 2019-01-04 17:50 +0100
      Re: Upgrade Problem Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2019-01-04 18:00 +0100
        Re: Upgrade Problem David Wright <deblis@lionunicorn.co.uk> - 2019-01-04 18:10 +0100
          Re: Upgrade Problem Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2019-01-04 18:20 +0100
            Re: Upgrade Problem David Wright <deblis@lionunicorn.co.uk> - 2019-01-04 21:50 +0100
              Re: Upgrade Problem Roberto C. Sánchez <roberto@debian.org> - 2019-01-04 22:20 +0100
                Re: Upgrade Problem songbird <songbird@anthive.com> - 2019-01-04 23:10 +0100
                  Re: Upgrade Problem Michael Stone <mstone@debian.org> - 2019-01-04 23:40 +0100
                    Re: Upgrade Problem songbird <songbird@anthive.com> - 2019-01-05 15:50 +0100
                  Re: Upgrade Problem <tomas@tuxteam.de> - 2019-01-05 10:20 +0100
                Re: Upgrade Problem David Wright <deblis@lionunicorn.co.uk> - 2019-01-05 02:10 +0100
              Re: Upgrade Problem songbird <songbird@anthive.com> - 2019-01-04 23:10 +0100
        Re: Upgrade Problem Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2019-01-04 18:10 +0100
      Re: Upgrade Problem Roberto C. Sánchez <roberto@debian.org> - 2019-01-04 18:20 +0100
        Re: Upgrade Problem "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-01-04 19:00 +0100
          Re: Upgrade Problem Felix Miata <mrmazda@earthlink.net> - 2019-01-04 19:20 +0100
            Re: Upgrade Problem "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-01-04 20:10 +0100
              Re: Upgrade Problem Brian <ad44@cityscape.co.uk> - 2019-01-04 22:10 +0100
              Re: Upgrade Problem David Wright <deblis@lionunicorn.co.uk> - 2019-01-05 02:30 +0100
                Re: Upgrade Problem Felix Miata <mrmazda@earthlink.net> - 2019-01-05 04:20 +0100
                  Re: Upgrade Problem Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2019-01-05 10:30 +0100
                Re: Upgrade Problem rhkramer@gmail.com - 2019-01-05 16:30 +0100
                  Re: Upgrade Problem John Crawley <john@bunsenlabs.org> - 2019-01-07 04:00 +0100
                    Re: Upgrade Problem mick crane <mick.crane@gmail.com> - 2019-01-08 15:40 +0100
    Re: Upgrade Problem songbird <songbird@anthive.com> - 2019-01-04 19:30 +0100

Page 1 of 2  [1] 2  Next page →

#203981 — Re: Upgrade Problem

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 wasting backspace.

-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

[toc] | [next] | [standalone]

#203986

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. For your info,
I have not reinstalled my Debian system for the last 15 years.
Reinstalling is a solution but what if in ten days the same issue arises
again? You'll ask the same questions and won't have learned much…

One of the power of GNU/Linux is that you can learn and fix problems.

Happy New Year!

S

[toc] | [prev] | [next] | [standalone]

#203987

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 reinstalled my Debian system for the last 15 years.
> Reinstalling is a solution but what if in ten days the same issue arises
> again? You'll ask the same questions and won't have learned much…
>
> One of the power of GNU/Linux is that you can learn and fix problems.

I agree.

And in this case, the problem is easy to solve:
   rm /path/to/some/large/files/*
-- 
Eduardo M KALINOWSKI
eduardo@kalinowski.com.br

[toc] | [prev] | [next] | [standalone]

#203989

On Fri 04 Jan 2019 at 16:52:45 (+0000), 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 normally,
> > issues like yours do not require windows-style operation. For your info,
> > I have not reinstalled my Debian system for the last 15 years.
> > Reinstalling is a solution but what if in ten days the same issue arises
> > again? You'll ask the same questions and won't have learned much…
> > 
> > One of the power of GNU/Linux is that you can learn and fix problems.
> 
> I agree.
> 
> 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 you presuppose that these large files
exist, for which the OP has currently shown no evidence.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#203992

On sex, 04 jan 2019, David Wright wrote:
> On Fri 04 Jan 2019 at 16:52:45 (+0000), 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 you presuppose that these large files
> exist, for which the OP has currently shown no evidence.

The used disk space must be somewhere. But you're right, there is  
another possibility: lots of small files that together occupy a lot of  
space.
-- 
Eduardo M KALINOWSKI
eduardo@kalinowski.com.br

[toc] | [prev] | [next] | [standalone]

#204031

On Fri 04 Jan 2019 at 17:13:44 (+0000), Eduardo M KALINOWSKI wrote:
> On sex, 04 jan 2019, David Wright wrote:
> > On Fri 04 Jan 2019 at 16:52:45 (+0000), 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 you presuppose that these large files
> > exist, for which the OP has currently shown no evidence.
> 
> The used disk space must be somewhere. But you're right, there is
> another possibility: lots of small files that together occupy a lot of
> space.

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.

This checks whether the mountpoints for /var and so on had files in
them before the partitions were mounted. These files would consume
filespace but not be detected by du.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#204039

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.
> 
> This checks whether the mountpoints for /var and so on had files in
> them before the partitions were mounted. These files would consume
> filespace but not be detected by du.
> 

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 descriptor is still active and
the file can be written/read with the descriptor reference, but the file
cannot be seen with 'ls' and, as I recall, it will not show up in the
calculation made by 'du'.  The calculation made by 'df' will still be
accurate, though.

So, you might ask yourself, why would a program create a file only to
immediately unlink it?  Well, it happen that if the program terminates
abnormally (i.e,. crashes), the disappearance of the reference to the
file descriptor when the kernel cleans up the process table also causes
it to free the associated blocks.  The same thing happens in a normal
program termination, but in the abnormal case you have no guarantee that
any clean up code will run.

As it happens, this is a great practical interview question for a system
administrator.  Give them a machine where 'df' reports no free space but
'du' says it is not all used up and see if they know why that might be
the case and how to resolve it.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#204046

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 descriptor is still active and
> the file can be written/read with the descriptor reference, but the file
> cannot be seen with 'ls' and, as I recall, it will not show up in the
> calculation made by 'du'.  The calculation made by 'df' will still be
> accurate, though.
>
> So, you might ask yourself, why would a program create a file only to
> immediately unlink it?  Well, it happen that if the program terminates
> abnormally (i.e,. crashes), the disappearance of the reference to the
> file descriptor when the kernel cleans up the process table also causes
> it to free the associated blocks.  The same thing happens in a normal
> program termination, but in the abnormal case you have no guarantee that
> any clean up code will run.
>
> As it happens, this is a great practical interview question for a system
> administrator.  Give them a machine where 'df' reports no free space but
> 'du' says it is not all used up and see if they know why that might be
> the case and how to resolve it.

  wouldn't fsck clean that up?

  if it might be potential useful information you were missing
and wanted to get back you could copy the entire partition and
then run a recovery/forensics program on it to see what it all
was.


  songbird

[toc] | [prev] | [next] | [standalone]

#204050

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, then
>> immediatley calls unlink on it.  The file descriptor is still active and
>> the file can be written/read with the descriptor reference, but the file
>> cannot be seen with 'ls' and, as I recall, it will not show up in the
>> calculation made by 'du'.  The calculation made by 'df' will still be
>> accurate, though.
>
>  wouldn't fsck clean that up?

not if the program is still running; it's not an error condition. the 
only case where fsck would help is if the whole machine crashed.

the traditional gotcha for "nonexistent file taking up space" is 
something generating a large log file, when someone tries to free the 
space by deleting the file. if the program writing it is still running, 
the file is gone but the space won't be freed until the program lets go 
of the file. lsof has a "deleted" indicator which can identify this.

[toc] | [prev] | [next] | [standalone]

#204092

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
>>> immediatley calls unlink on it.  The file descriptor is still active and
>>> the file can be written/read with the descriptor reference, but the file
>>> cannot be seen with 'ls' and, as I recall, it will not show up in the
>>> calculation made by 'du'.  The calculation made by 'df' will still be
>>> accurate, though.
>>
>>  wouldn't fsck clean that up?
>
> not if the program is still running; it's not an error condition. the 
> only case where fsck would help is if the whole machine crashed.

  i should have noted that i would likely have 
killed off processes and unmounted the file system
before fsck'ing it.


> the traditional gotcha for "nonexistent file taking up space" is 
> something generating a large log file, when someone tries to free the 
> space by deleting the file. if the program writing it is still running, 
> the file is gone but the space won't be freed until the program lets go 
> of the file. lsof has a "deleted" indicator which can identify this.

  *nods*


  songbird

[toc] | [prev] | [next] | [standalone]

#204075

[Multipart message — attachments visible in raw view] — view raw

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, then
> > immediatley calls unlink on it [...]

Even easier: you rm a file which is still held open by some program
(a log file may be a typical example). The file will continue existing
until the last program which has an open file descriptor to it closes
it. If you think of it, it just makes sense.

[...]

>   wouldn't fsck clean that up?

No, definitely not. Terminating the processes keeping the file open
will help (i.e. reboot will most definitely help).

>   if it might be potential useful information you were missing
> and wanted to get back you could copy the entire partition and
> then run a recovery/forensics program on it to see what it all
> was.

There are tricks to it: open files are to be found in /proc/<PID>/fd:
there are some amusing war stories of clever sysadmins recovering
things from there after some mess-up.

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#204054

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):
> > 
> >   # du -shx
> >         +
> >   $ df's Available
> >         ≃
> >  partition's size.
> > 
> > This checks whether the mountpoints for /var and so on had files in
> > them before the partitions were mounted. These files would consume
> > filespace but not be detected by du.
> > 
> 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 descriptor is still active and
> the file can be written/read with the descriptor reference, but the file
> cannot be seen with 'ls' and, as I recall, it will not show up in the
> calculation made by 'du'.  The calculation made by 'df' will still be
> accurate, though.
> 
> So, you might ask yourself, why would a program create a file only to
> immediately unlink it?  Well, it happen that if the program terminates
> abnormally (i.e,. crashes), the disappearance of the reference to the
> file descriptor when the kernel cleans up the process table also causes
> it to free the associated blocks.  The same thing happens in a normal
> program termination, but in the abnormal case you have no guarantee that
> any clean up code will run.
> 
> As it happens, this is a great practical interview question for a system
> administrator.  Give them a machine where 'df' reports no free space but
> 'du' says it is not all used up and see if they know why that might be
> the case and how to resolve it.

Yes, that's a standard trick used by browsers when they're playing
videos etc. In fact, I have a program called hoover-streams.py for
just this case. It finds out the browser programs' PIDs and searches
/proc/$PID/fd/ for any that are connected to deleted files. Then it
copies from the file descriptors repeatedly, into files named from
wallclock time, printing the size so far and the filename, prefixed
by a + if something was just copied into that file and - if it wasn't.
(This corresponds to the right marker in the progress bar under the
video; the left one shows how far you've viewed it).
When you haven't seen + for a while, the files should all be complete.

But it does seem unlikely that the OP is going to have GB of files
being hung onto like this, even a chemist. :)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#204047

David Wright wrote:
> On Fri 04 Jan 2019 at 17:13:44 (+0000), Eduardo M KALINOWSKI wrote:
>> On sex, 04 jan 2019, David Wright wrote:
>> > On Fri 04 Jan 2019 at 16:52:45 (+0000), 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 you presuppose that these large files
>> > exist, for which the OP has currently shown no evidence.
>> 
>> The used disk space must be somewhere. But you're right, there is
>> another possibility: lots of small files that together occupy a lot of
>> space.
>
> 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.
>
> This checks whether the mountpoints for /var and so on had files in
> them before the partitions were mounted. These files would consume
> filespace but not be detected by du.

  very good points i hadn't considered.

  i do know it happens.

  thanks for the reminder.  :)


  songbird

[toc] | [prev] | [next] | [standalone]

#203990

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 grow quite a bit if one has several kernels  
installed. Ideal way to free up space is to apt-get remove the older  
kernel packages, but since that will likely not work while there is no  
free space, one could simply delete the files (with care not to remove  
the modules of the running kernel), and then remove the packages.
-- 
Eduardo M KALINOWSKI
eduardo@kalinowski.com.br

[toc] | [prev] | [next] | [standalone]

#203991

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 normally,
> issues like yours do not require windows-style operation. For your info,
> I have not reinstalled my Debian system for the last 15 years.
> Reinstalling is a solution but what if in ten days the same issue arises
> again? You'll ask the same questions and won't have learned much…
> 
> One of the power of GNU/Linux is that you can learn and fix problems.
> 
I am not sure if Stephen went with an LVM solution, though I hope he
did.  Given that his former partition scheme was problematic for his use
case and that it was based on static partitions, the reinstallation
route may have been the best course.

It is important to remember that adjusting a static partition layout is
a high risk operation for even a highly skilled system administrator who
has performed the operation multiple times.  I suspect that if Stephen
even considered the possibility of attempting that sort of operation,
that he rightly judged the time investment required and likelihood of
causing irreparable damage to his configuration were justification
enough to reinstall.

Sometimes one just wants to get the job done and fiddling around with
system issues becomes more of an obstacle than an opportunity to learn.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#203996

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 this last sentence is pretty sad because normally,
>> issues like yours do not require windows-style operation. For your info,
>> I have not reinstalled my Debian system for the last 15 years.
>> Reinstalling is a solution but what if in ten days the same issue arises
>> again? You'll ask the same questions and won't have learned much…
>>
>> One of the power of GNU/Linux is that you can learn and fix problems.
>>
> I am not sure if Stephen went with an LVM solution, though I hope he
> did.  Given that his former partition scheme was problematic for his use
> case and that it was based on static partitions, the reinstallation
> route may have been the best course.
>
> It is important to remember that adjusting a static partition layout is
> a high risk operation for even a highly skilled system administrator who
> has performed the operation multiple times.  I suspect that if Stephen
> even considered the possibility of attempting that sort of operation,
> that he rightly judged the time investment required and likelihood of
> causing irreparable damage to his configuration were justification
> enough to reinstall.
>
> Sometimes one just wants to get the job done and fiddling around with
> system issues becomes more of an obstacle than an opportunity to learn.
>
> Regards,
>
> -Roberto
>
I haven't messed around with partitioning since the early days of 
Slackware, and that was with a great deal of trepidation?  As far as 
computer OS's are concerned I hope that the days of fools rush in are a 
thing of the past.

-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

[toc] | [prev] | [next] | [standalone]

#203998

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, not to mention what will be used for your planned reinstallation.
-- 
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/

[toc] | [prev] | [next] | [standalone]

#204010

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 responsible for your current partitioning
> scheme, not to mention what will be used for your planned reinstallation.
The installer for Debian Stretch has an new option thzt  thought I'd 
try.:  separate /home, /var and/temp partitions.

Over the last 50+ years as  Research Scientist I have tried to follow 
the policy that it's all right to make mistakes..  As long as you try 
not to make the same mistake in the same contiguous four hours - that is 
if you make a mistake in the morning, wait until that afternoon to 
repeat it.  But even more important from the mistake and try not to 
repeat it. I think that making mistakes is an integral part of the 
scientific method.

Of course, there is a corollary - you can't teach an old scientist new 
science.

Having babbled for the last two paragraphs, I'll close buy saying that I 
will revert to the entire installation on the same partition.

-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

[toc] | [prev] | [next] | [standalone]

#204035

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 of trepidation?
> > You just multiplied my curiosity about what exactly was responsible for your current partitioning
> > scheme, not to mention what will be used for your planned reinstallation.
> The installer for Debian Stretch has an new option thzt  thought I'd try.:
> separate /home, /var and/temp partitions.

I don't regard that option as new. Not in 2018/2019 and not from the
present d-i.

> Over the last 50+ years as  Research Scientist I have tried to follow the
> policy that it's all right to make mistakes..  As long as you try not to
> make the same mistake in the same contiguous four hours - that is if you
> make a mistake in the morning, wait until that afternoon to repeat it.  But
> even more important from the mistake and try not to repeat it. I think that
> making mistakes is an integral part of the scientific method.
> 
> Of course, there is a corollary - you can't teach an old scientist new
> science.

You have not read Robert Boyle or Isacc Newton in recent weeks? That's
all apart from the idea that there is nothing new to be learned. Did
you say you are a scientist? Apparently not a physicist, anyway.

> 
> Having babbled for the last two paragraphs, I'll close buy saying that I
> will revert to the entire installation on the same partition.

That's the best. Ignore LVM advocates.

-- 

[toc] | [prev] | [next] | [standalone]

#204055

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 of trepidation?
> > You just multiplied my curiosity about what exactly was responsible for your current partitioning
> > scheme, not to mention what will be used for your planned reinstallation.
> The installer for Debian Stretch has an new option thzt  thought I'd
> try.:  separate /home, /var and/temp partitions.

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 down to leaving the
existing /var contents (in the root filesystem) in place when you
mount the new var partition onto /var, thereby making those files
inaccessible.

> Over the last 50+ years as  Research Scientist I have tried to follow
> the policy that it's all right to make mistakes..  As long as you try
> not to make the same mistake in the same contiguous four hours - that
> is if you make a mistake in the morning, wait until that afternoon to
> repeat it.  But even more important from the mistake and try not to
> repeat it. I think that making mistakes is an integral part of the
> scientific method.
> 
> Of course, there is a corollary - you can't teach an old scientist new
> science.
> 
> 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 keep your separate /home partition. Except for
dot files/directories, they're independent of the OS. It makes
reinstallation and upgrades a lot easier.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web