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 2 of 2 — ← Prev page 1 [2]

#204062

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, 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.

You did that for this Jessie to Stretch upgrade? That sounds like "messing around with partitioning"
to me.

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

+1

So, boot rescue media, mount sda1, and check the contents of <mntdir>/var/. Its apt cache might be
loaded, thus you might not any more have reason to reinstall - just delete everything in it and
reboot. If something goes wrong, you planned on reinstalling anyway. :-)

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

+1
-- 
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]

#204077

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 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.
> +1
>
> So, boot rescue media, mount sda1, and check the contents of <mntdir>/var/. Its apt cache might be
> loaded, thus you might not any more have reason to reinstall - just delete everything in it and
> reboot. If something goes wrong, you planned on reinstalling anyway. :-)

No need for a live CD: you can use bind mounts to access the original
contents of dirs that serve as mount points for other filesystems:
https://unix.stackexchange.com/questions/4426/access-to-original-contents-of-mount-point

(Unless mount fails because of no free space...)


-- 
Eduardo M KALINOWSKI
eduardo@kalinowski.com.br

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

#204093

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 keep your separate /home partition. Except for
> dot files/directories, they're independent of the OS. It makes
> reinstallation and upgrades a lot easier.

That gives me a chance to rant (gently, I hope) on one of my pet peeves and 
how I solve it.

I hink it is really inconvenient to have config information (basically the . 
files) and what I call "real user data" (that is, documents, photos, videos, 
...) combined in the same directory with the config information hidden.

(I won't go into detail on that -- if you find it convenient, more power to 
you.)

My solution: I create a separate top level directory (e.g. /<user> instead of 
/home/<user>) and store all my "real user data" in /<user>, and let the OS and 
application programs do what they want in /home/<user>.  When I upgrade or 
move to a new machine, I move (well, copy) the content of /<user> but let the 
new OS create and fool with a new /home/<user>.  

(I do preserve the content of /home/<user> from the old machine / installation 
for some period of time in case I find that I need some configuration or such 
from there.)

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

#204160

On 06/01/2019 00.26, rhkramer@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 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.
> 
> I hink it is really inconvenient to have config information (basically the .
> files) and what I call "real user data" (that is, documents, photos, videos,
> ...) combined in the same directory with the config information hidden.
> 
> My solution: I create a separate top level directory (e.g. /<user> instead of
> /home/<user>) and store all my "real user data" in /<user>, and let the OS and
> application programs do what they want in /home/<user>.  When I upgrade or
> move to a new machine, I move (well, copy) the content of /<user> but let the
> new OS create and fool with a new /home/<user>.

Chime in to agree on that, but I use /data/<username>
It really makes upgrades easier to have all that ...data in its own  
partition.
Multi-boots can share it too.
-- 
John

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

#204210

On 2019-01-07 02:56, John Crawley wrote:
> On 06/01/2019 00.26, rhkramer@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 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.
>> 
>> I hink it is really inconvenient to have config information (basically 
>> the .
>> files) and what I call "real user data" (that is, documents, photos, 
>> videos,
>> ...) combined in the same directory with the config information 
>> hidden.
>> 
>> My solution: I create a separate top level directory (e.g. /<user> 
>> instead of
>> /home/<user>) and store all my "real user data" in /<user>, and let 
>> the OS and
>> application programs do what they want in /home/<user>.  When I 
>> upgrade or
>> move to a new machine, I move (well, copy) the content of /<user> but 
>> let the
>> new OS create and fool with a new /home/<user>.
> 
> Chime in to agree on that, but I use /data/<username>
> It really makes upgrades easier to have all that ...data in its own 
> partition.
> Multi-boots can share it too.

I've tended to make a soft link in /home/me to another disk.

mick

-- 
Key ID    4BFEBB31

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

#203999

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 put this thread to bed and stop wasting backspace.

  you're welcome, but for the life of me i can't figure
out why finding a few large files on / and moving or
removing them as needed to free up space isn't a quicker
solution for now...

  anyways, good luck.  :)


  asides follow:

  when i set up my new system i purposely did not include
LVM because i felt i didn't need that added layer of
complexity.  i also didn't use separate home directories
or var directories like i had on previous installs.

  with the price of SSDs coming down i felt that it was
more important to just have everything together and if i
need to create more space it will likely be easier to 
just get another SSD and plug it in.  so my current 
configuration looks like:


Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/sda2      412282128 194153408 197116244  50% /
/dev/sda3       45876068   4362484  39153472  11% /ro1-root
/dev/sda1         973952      2100    971852   1% /boot/efi

  and i have a swap space just in case i ever need it
(it rarely gets used):

/dev/sda4  935546880 974608383  39061504  18.6G Linux swap

  my /dev/sda3 partition is for running a backup stable
installation just in case i muck up the other testing/
unstable version on /dev/sda2 and need a fast way to 
get back on-line.  as yet another backup in case i really
mess up the system i have a stable installation to a
bootable USB stick.

  if you are installing to a newer machine be sure that
the EFI option is detected and used before you install
as fixing it afterwards can be painful.


  songbird

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web