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

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

Debian 8 and Debian 9 Dual Boot

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

Contents

  Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 04:50 +0100
    Re: Debian 8 and Debian 9 Dual Boot David Christensen <dpchrist@holgerdanske.com> - 2017-11-13 07:20 +0100
      Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 16:30 +0100
        Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-13 20:10 +0100
          Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 21:10 +0100
          Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-14 00:10 +0100
            Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-14 01:50 +0100
              Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-14 03:40 +0100
                Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-14 04:00 +0100
                  Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-14 04:50 +0100
                  Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-16 19:40 +0100
                    Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-16 20:10 +0100
                      Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-16 23:40 +0100
                    Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-16 20:30 +0100
                      Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-16 21:20 +0100
                        Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 19:10 +0100
                          Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-29 19:20 +0100
                            Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-29 19:50 +0100
                          Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-29 19:40 +0100
                            Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 21:40 +0100
                              Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-29 22:00 +0100
                                Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 22:40 +0100
                                  Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-30 03:20 +0100
                              Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 22:10 +0100
                                Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-29 23:10 +0100
                      Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-17 00:00 +0100
                Re: Debian 8 and Debian 9 Dual Boot Jonathan Dowland <jmtd@debian.org> - 2017-11-29 10:10 +0100
        Re: Debian 8 and Debian 9 Dual Boot David Christensen <dpchrist@holgerdanske.com> - 2017-11-13 20:20 +0100
          Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-14 00:30 +0100
            Re: Debian 8 and Debian 9 Dual Boot David Christensen <dpchrist@holgerdanske.com> - 2017-11-14 00:40 +0100
    Re: Debian 8 and Debian 9 Dual Boot Jochen Spieker <ml@well-adjusted.de> - 2017-11-13 10:00 +0100
      Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 17:00 +0100
        Re: Debian 8 and Debian 9 Dual Boot Jochen Spieker <ml@well-adjusted.de> - 2017-11-13 21:30 +0100
    Re: Debian 8 and Debian 9 Dual Boot Roberto C. Sánchez <roberto@debian.org> - 2017-11-13 13:00 +0100
      Re: Debian 8 and Debian 9 Dual Boot Roberto C. Sánchez <roberto@debian.org> - 2017-11-13 17:10 +0100
        Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 18:10 +0100
      Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 17:10 +0100
        Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-13 20:00 +0100
          Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 04:20 +0100
            Re: Debian 8 and Debian 9 Dual Boot Michael Fothergill <michael.fothergill@gmail.com> - 2017-11-29 08:10 +0100
            Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-29 10:10 +0100
              Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 19:00 +0100
            Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-29 20:00 +0100
              Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-29 20:40 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#189414

On Wed, 29 Nov 2017 15:37:46 -0500
Dan Norton <dnorton@mindspring.com> wrote:

> On 11/29/2017 01:36 PM, Felix Miata wrote:
> > Dan Norton composed on 2017-11-29 13:07 (UTC-0500):  
> >> After POST, the following appears:
> >> [...]
> >> PXE-E53: No boot filename received
> >> PXE-MOF: Exiting PXE ROM.
> >> ERROR:No boot disk has been detected or the disk has failed.  
> > It tries to PXE boot because it finds no bootable storage device:
> > there is no active partition, or no boot code in the MBR sector of
> > the device that you expect to boot. Installing Grub to a partition
> > leaves the MBR untouched, so it might not yet contain anything
> > other than partition data. The partitioner I use installs MBR code
> > automatically. The one in the installer may have needed to have
> > this step explicitly asked for. It can be added post-install
> > manually. 'man install-mbr'. 
> >> Isn't that because the primary is not mounted to /boot?  
> > Mounting happens well after the point you have reached.
> >  
> 
> Nothing found for "man install-mbr" but web search yields "How to 
> Install Grub Onto Your MBR [1] which I will try.
> 
> [1] http://www.av8n.com/computer/htm/grub-reinstall.htm
> 

You've said that you can boot your system with the aid of a boot
utility disc: that bypasses a lot of trouble, and you should be able to
go directly to step 8 from within your working system. It's harder to
do if you have to work from a different environment.

As I said, I believe you should also do update-grub, which will
certainly do no harm. You don't yet know that grub is configured with
the necessary information for an unaided boot.

Note that grub2 is still a work in progress, and many of the boot
problem tutorials you find on the Net are no longer completely
accurate. This one should be OK, I think. It's usually worth adding
'debian' to your search keywords, if you turn up something on the
debian.org site there's a good chance it's up to date.

-- 
Joe

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

#189416

On 11/29/2017 03:57 PM, Joe wrote:
> On Wed, 29 Nov 2017 15:37:46 -0500
> Dan Norton <dnorton@mindspring.com> wrote:
>
>> On 11/29/2017 01:36 PM, Felix Miata wrote:
>>> Dan Norton composed on 2017-11-29 13:07 (UTC-0500):
>>>> After POST, the following appears:
>>>> [...]
>>>> PXE-E53: No boot filename received
>>>> PXE-MOF: Exiting PXE ROM.
>>>> ERROR:No boot disk has been detected or the disk has failed.
>>> It tries to PXE boot because it finds no bootable storage device:
>>> there is no active partition, or no boot code in the MBR sector of
>>> the device that you expect to boot. Installing Grub to a partition
>>> leaves the MBR untouched, so it might not yet contain anything
>>> other than partition data. The partitioner I use installs MBR code
>>> automatically. The one in the installer may have needed to have
>>> this step explicitly asked for. It can be added post-install
>>> manually. 'man install-mbr'.
>>>> Isn't that because the primary is not mounted to /boot?
>>> Mounting happens well after the point you have reached.
>>>   
>> Nothing found for "man install-mbr" but web search yields "How to
>> Install Grub Onto Your MBR [1] which I will try.
>>
>> [1] http://www.av8n.com/computer/htm/grub-reinstall.htm
>>
> You've said that you can boot your system with the aid of a boot
> utility disc: that bypasses a lot of trouble, and you should be able to
> go directly to step 8 from within your working system. It's harder to
> do if you have to work from a different environment.

Good. Actually, I started the procedure on my booted jessie system but 
stopped and booted the live cd when I re-read [1].
> As I said, I believe you should also do update-grub, which will
> certainly do no harm. You don't yet know that grub is configured with
> the necessary information for an unaided boot.

I ran update-grub recently but will be glad to do it again.

>
> Note that grub2 is still a work in progress, and many of the boot
> problem tutorials you find on the Net are no longer completely
> accurate. This one should be OK, I think. It's usually worth adding
> 'debian' to your search keywords, if you turn up something on the
> debian.org site there's a good chance it's up to date.
>

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

#189422

On 11/29/2017 04:29 PM, Dan Norton wrote:
>
>
> On 11/29/2017 03:57 PM, Joe wrote:
>> On Wed, 29 Nov 2017 15:37:46 -0500
>> Dan Norton <dnorton@mindspring.com> wrote:
>>
>>> On 11/29/2017 01:36 PM, Felix Miata wrote:
>>>> Dan Norton composed on 2017-11-29 13:07 (UTC-0500):
>>>>> After POST, the following appears:
>>>>> [...]
>>>>> PXE-E53: No boot filename received
>>>>> PXE-MOF: Exiting PXE ROM.
>>>>> ERROR:No boot disk has been detected or the disk has failed.
>>>> It tries to PXE boot because it finds no bootable storage device:
>>>> there is no active partition, or no boot code in the MBR sector of
>>>> the device that you expect to boot. Installing Grub to a partition
>>>> leaves the MBR untouched, so it might not yet contain anything
>>>> other than partition data. The partitioner I use installs MBR code
>>>> automatically. The one in the installer may have needed to have
>>>> this step explicitly asked for. It can be added post-install
>>>> manually. 'man install-mbr'.
>>>>> Isn't that because the primary is not mounted to /boot?
>>>> Mounting happens well after the point you have reached.
>>> Nothing found for "man install-mbr" but web search yields "How to
>>> Install Grub Onto Your MBR [1] which I will try.
>>>
>>> [1] http://www.av8n.com/computer/htm/grub-reinstall.htm
>>>
>> You've said that you can boot your system with the aid of a boot
>> utility disc: that bypasses a lot of trouble, and you should be able to
>> go directly to step 8 from within your working system. It's harder to
>> do if you have to work from a different environment.
>
> Good. Actually, I started the procedure on my booted jessie system but 
> stopped and booted the live cd when I re-read [1].
>> As I said, I believe you should also do update-grub, which will
>> certainly do no harm. You don't yet know that grub is configured with
>> the necessary information for an unaided boot.
>
> I ran update-grub recently but will be glad to do it again.

dan@debian8:~$ sudo update-grub
[sudo] password for dan:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
done

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

#189415

On 11/29/2017 03:37 PM, Dan Norton wrote:
>
>
> On 11/29/2017 01:36 PM, Felix Miata wrote:
>> Dan Norton composed on 2017-11-29 13:07 (UTC-0500):
>>> After POST, the following appears:
>>> [...]
>>> PXE-E53: No boot filename received
>>> PXE-MOF: Exiting PXE ROM.
>>> ERROR:No boot disk has been detected or the disk has failed.
>> It tries to PXE boot because it finds no bootable storage device: 
>> there is no
>> active partition, or no boot code in the MBR sector of the device 
>> that you
>> expect to boot. Installing Grub to a partition leaves the MBR 
>> untouched, so it
>> might not yet contain anything other than partition data. The 
>> partitioner I use
>> installs MBR code automatically. The one in the installer may have 
>> needed to
>> have this step explicitly asked for. It can be added post-install 
>> manually. 'man
>> install-mbr'.
>>
>>> Isn't that because the primary is not mounted to /boot?
>> Mounting happens well after the point you have reached.
>>
>
> Nothing found for "man install-mbr" but web search yields "How to 
> Install Grub Onto Your MBR [1] which I will try.
>
> [1] http://www.av8n.com/computer/htm/grub-reinstall.htm

Well that won't fly. Booted Debian-Live 8.8.0 amd64 Standard and reached 
Step 8 in section 1.1 of [1] which called for "grub-install 
--root-directory=/x $drive" but grub-install is not found.

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

#189417

On Wed, 29 Nov 2017 16:06:53 -0500
Dan Norton <dnorton@mindspring.com> wrote:


> >
> > [1] http://www.av8n.com/computer/htm/grub-reinstall.htm  
> 
> Well that won't fly. Booted Debian-Live 8.8.0 amd64 Standard and
> reached Step 8 in section 1.1 of [1] which called for "grub-install 
> --root-directory=/x $drive" but grub-install is not found.
> 

/usr/sbin/grub-install is part of grub2-common, which is of optional
priority, but really ought to be part of a live CD distribution.

-- 
Joe 

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

#189049

On 11/16/2017 02:27 PM, Joe wrote:
> On Thu, 16 Nov 2017 13:34:52 -0500
> Dan Norton <dnorton@mindspring.com> wrote:
>
>> On 11/13/2017 09:52 PM, Felix Miata wrote:
>>> Dan Norton composed on 2017-11-13 21:38 (UTC-0500):
>>>   
>>>> How do you set up LVM so that install does not clobber one of the
>>>> siblings? During installation, for partitioning, do you pick
>>>> "Manual" or "Guided -*" ?
>>> I don't think I've ever used Debian's, or any Debian derivative's,
>>> "guided". I can't remember the last time I didn't pick manual,
>>> after *fully* preparing in advance to my specifications.
>>>
>>> Manual will list what partitions and volumes exist, so if you've
>>> fully prepared logical volumes in advance, all that should need to
>>> be done within manual is select mount points and mount options for
>>> those you wish used. If volumes exist but are not formatted, then
>>> formatting would be a third selection using manual.
>> A better description of what I want is "multiboot", instead of "dual
>> boot" in this thread. I can see having up to 4 systems installed, all
>> Debians, on one disk drive. There is an item in [1] which I see that
>> reads:
>>
>>     6. Disable LVM support
>>
>> which is puzzling. Can multiboot be set up within LVM on one disk
>> drive? Or, is it necessary to disable  LVM, define multiple logical
>> partitions with fdisk or parted for example, install in these
>> partitions, and then set up LVM separately on each system?
> I see the date of the page is 2015, but to be honest, a lot of this
> page is completely obsolete, even more so if you're not using DOS, OS/2
> or early Windows. I would not even swear that item 6, LVM, even refers
> to the Linux system. There's certainly no problem about mixing multiple
> booting with lvm.

Glad to hear it!

>
> A volume group would normally be declared within a single old-style IBM
> partition, but doesn't have to be. Think of multiple hard drives, each
> containing multiple old-style partitions, then think of multiple lvm
> volume groups, each with multiple volumes, roughly overlaid on the
> drives and partitions but not physically matching them. A volume group
> can consist of multiple complete partitions on different drives, and
> the volumes it contains need not bear any relationship to the
> underlying partitions.
>
> Multiple OSes will still use one overall bootloader, which may or may
> not redirect to other bootloaders. It is common, therefore, to use a
> single physical partition for /boot, common to all *nix OSes, but by no
> means necessary. /boot can be an LVM volume if you wish, but a booting
> problem is slightly easier to deal with if the kernel and grub stuff is
> in a standard partition, you don't need to worry about looking up the
> lvm commands in addition to the grub set.
>
> My workstation, for example, has a 1GB primary partition for /boot, and
> the rest of the drive is a second primary partition which maps exactly
> to a volume group. The volume group is then divided into volumes, which
> mostly act like old-style partitions, at least as far as mounting goes.
> You can have a lot of them.
Apparently there are many ways to do multiboot in LVM. Is it practical 
to, on one fairly large (1TB) disk, [I can hear the snickers when 
someone reads this when 1TB is puny in a year or two] do the following:

1. Enlarge the volume group to span the entire disk (it's currently 40G).
2. Define a number of additional logical volumes, say 3.
3. Install stable in one of the lv's and have install treat it like a 
standard *partition* (logical) and have within it separate root, swap, 
/var, /tmp, and /home?

  - Dan

>   
>
> I have two drives set up the same, as I migrated from one to a newer
> one. After adjustment, the grub installation of the new drive handles
> the boot, and the kernel used by the old system lives in the /boot
> partition of the old drive. All of this could have been integrated into
> one volume group, but it's two because that's how the system evolved. I
> could pull the old drive, which I hardly ever touch now, plonk it into
> another PC and boot it with minimal fiddling about.
>
> So you have a common grub, basically from the latest installation
> unless you tell the installer otherwise, and before the installation is
> finished it should have detected any other bootable OSes anywhere in
> the hardware. You've been advised not to share other partitions, even
> /home, but several /homes can live in differently-named lvm volumes in
> the same volume group. Or not, by your preference. You can, for the
> most part, treat volumes as partitions, and not worry about whether
> they are primary or logical.
>
> You should probably track down a few tutorials on multiboot and lvm,
> read through them to get a feel for what needs doing. It's always
> difficult reading a manual for something and working out from that what
> steps you need to take to do something. Things like UEFI boot and disc
> encryption complicate things, so probably best to avoid them on your
> first attempt(s) if the hardware allows. If you're starting with a bare
> drive and your BIOS allows old-style IBM partitioning, that's the way
> to go to get the hang of this.
>

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

#189398

On Mon, Nov 13, 2017 at 09:38:59PM -0500, Dan Norton wrote:
>How do you set up LVM so that install does not clobber one of the 
>siblings? During installation, for partitioning, do you pick "Manual" 
>or "Guided -*" ?

Manual. Guided -* is very likely to result in you clobbering the
existing partitions or volume group by accident. (No offense intended.
I've done it myself very recently.)

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

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

#188956

On 11/13/17 07:26, Dan Norton wrote:
> 
> On 11/13/2017 01:10 AM, David Christensen wrote:
>>
>> 1.  Image, backup, and/or archive everything.  You will especially 
>> want to get a copy of the /etc tree onto a USB flash drive so you can 
>> see LVM, fstab, etc., configuration settings for mounting the Debian 8 
>> disk under Debian 9.
> 
> Please say more about the configuration settings. I back up /home and 
> /var. The git stuff is in /opt and pushed to GitHub. Should the /etc 
> tree be backed up also? How would the settings be used from 9?

Every operating system and every software application installed on that 
operating system has configuration settings.  One of the advantages of 
the traditional Unix model is that most OS settings are in plain text 
files that you can change with a text editor.  Similarly so for server 
applications.  (Desktops and their applications are another story, see 
below.)  Good software has manual pages that explain where its 
configuration files reside and the format and meaning of the contents. 
Debian and Debian-ized applications seem to put most of their 
configuration files under /etc.


Whenever I decide to change such files, I make a copy with '-orig' 
appended, put the original file into a version control system (CVS), 
edit-test-repeat, and check-in to CVS when done.  On a typical 
workstation, I might have a dozen files under /etc checked in.  On a 
server, more.


I once tried putting the entire /etc directory into CVS.  Adding and 
removing software made a lot of changes, as expected.  But, so did 
normal operations.  Locating meaningful changes in became an exercise in 
"find the needle in the hay stack".  And, adding/removing lots of files 
and directories in CVS working directories is labor intensive.  I don't 
do that any more.


For migrations, unless you are an expert already or psychic, you will 
want the old drive in it's entirety.  (I keep my system drives under 16 
GB, to encourage me to take images at opportune moments like this.) 
It's useful to also copy /etc onto a flash drive when your old drive is 
more complex than a partition table and normal file systems (so that you 
will have clues about how to mount it, for starters).


As for how the settings are used, each OS instance and it applications 
determine that.  Migrating settings involves editing configuration files 
and/or overwriting configuration files.  You have to go through each 
subsystem one at a time and see what configuration files it wants, 
format, and content, and then do what it takes to make it happy.


As others have replied, desktop and desktop application configuration 
settings and data in home directories are not agreeable to migration.  I 
don't even try.  I backup Thunderbird mail and export address books on 
the old system, and restore/ import on the new system.  I use the sync 
service built into Firefox to keep it current on all my machines where 
it is installed.  I check in my CVS working directories on the old 
system and check them out on the new system.  My bulk data is on the 
file server.  I manually configure whatever is left -- desktop, Open 
Office preferences, etc..


>> 2.  Put your bulk data onto a separate drive or a file server/ NAS.
>>
>> 3.  If your computer has a spare drive bay, buy a new drive, unplug 
>> your old drive, install the new drive, install Debian 9 onto the new 
>> drive, reconnect the old drive and mount read-only under Debian 9, and 
>> migrate your settings and remaining data from the old drive to the new 
>> drive. Your BIOS/UEFI should allow you to boot from either drive 
>> during this process.  So long as you don't damage the Debian 8 disk, 
>> you can always fall back to Debian 8 if the migration goes badly.
>>
>> 4.  If you computer does not have a spare drive bay, buy a new drive 
>> and a USB external drive enclosure, put your old drive in the 
>> enclosure, install the new drive, install Debian 9 onto the new drive, 
>> plug in the old drive and mount read-only under Debian 9, and migrate 
>> your settings and remaining data from the old drive to the new drive. 
>> Again, your BIOS/UEFI should allow you to boot from either drive and 
>> you can fall back to Debian 8 if necessary.
>>
> Sobering advice - good! Makes me re-think some things. A bit inefficient 
> WRT disk space.

Disk space is far cheaper than data loss.  Don't make the mistake of 
trying to save money through partition, LVM, file system, etc., 
gymnastics rather than simply buying another drive and doing it the KISS 
way.


> You did say "migrate" and not "upgrade" as I first read. Thanks David.

YW.  :-)


David

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

#188964

On 11/13/2017 02:14 PM, David Christensen wrote:
> [...]
> Disk space is far cheaper than data loss.  Don't make the mistake of 
> trying to save money through partition, LVM, file system, etc., 
> gymnastics rather than simply buying another drive and doing it the 
> KISS way.
>

Well I'm much in favor of the KISS principle, it's just that there is 
too much PC equipment lying around here doing nothing. I haul away, 
donate from time to time but it simply accumulates. I hate the thought 
of buying more when there is 900g unused on sda. :-)

  - Dan

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

#188965

On 11/13/17 15:27, Dan Norton wrote:
> 
> 
> On 11/13/2017 02:14 PM, David Christensen wrote:
>> [...]
>> Disk space is far cheaper than data loss.  Don't make the mistake of 
>> trying to save money through partition, LVM, file system, etc., 
>> gymnastics rather than simply buying another drive and doing it the 
>> KISS way.
>>
> 
> Well I'm much in favor of the KISS principle, it's just that there is 
> too much PC equipment lying around here doing nothing. I haul away, 
> donate from time to time but it simply accumulates. I hate the thought 
> of buying more when there is 900g unused on sda. :-)

So, a 1 TB drive?  Make and model?

Laptop, desktop, server, other?  Make and model?

Any spare drive bays?

Do you have any 16 ~ 128 GB HDD's or SSD's lying around?

David

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

#188939

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

Dan Norton:
henny|i
> My first Linux install was about one year ago. After some missteps, I have
> used Debian 8 in reasonable satisfaction on the desktop during that year.
> Now I want to leave 8 in place and do a network install for Debian 9 on the
> same disk and switch back and forth at boot time.

Your disk setup allows to do this comparably easy, but I would think
twice whether that is actually what I want to do. You end up with two
systems which you have to maintain and, most importantly, you cannot
properly share your /home. Most programs that save their settings to
$HOME will automatically upgrade their configuration files on first
start with a new version and after that you have to assume that the
older version cannot read it anymore. I realize that this is part of
your disk space calculation but I want to stress that the result is
probably not something that you will want to use for an extended period
of time.

> LVM reports as follows:
> 
> dan@debian:/$ sudo vgdisplay -C
>   VG           #PV #LV #SN Attr    VSize      VFree
>   debian-vg   1     5     0    wz--n- 976.56g 938.20g

You can vgreduce debian-vg easily to make room for your planned
debian9-vg.

> So there is plenty of disk space for the two Debians and more besides. The
> question is how to prepare to install 9? My guess is to define another
> volume group called debian9-vg perhaps but how will this be recognized
> during network install?

Yes, it will. It should also be possible to vgreduce debian.vg and
vgcreate debian9-vg inside the installer, but I would be more
comfortable doing that from the running system, using the regular tools.

During installation, you just have to make sure that all LVs in
debian-vg are marked as "Do not use".

> I've clobbered stuff before during installs and I'm
> gun shy. Maybe there is a better way. Any thoughts on this will be
> appreciated.

It happens to everybody. The only things that help are a good plan and
concentration on the task at hand. :)

J.
-- 
I like my Toyota RAV4 because of the commanding view of the traffic
jams.
[Agree]   [Disagree]
                 <http://archive.slowlydownward.com/NODATA/data_enter2.html>

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

#188950

On 11/13/2017 03:53 AM, Jochen Spieker wrote:
> Dan Norton:
> henny|i
>> My first Linux install was about one year ago. After some missteps, I have
>> used Debian 8 in reasonable satisfaction on the desktop during that year.
>> Now I want to leave 8 in place and do a network install for Debian 9 on the
>> same disk and switch back and forth at boot time.
> Your disk setup allows to do this comparably easy, but I would think
> twice whether that is actually what I want to do. You end up with two
> systems which you have to maintain and, most importantly, you cannot
> properly share your /home. Most programs that save their settings to
> $HOME will automatically upgrade their configuration files on first
> start with a new version and after that you have to assume that the
> older version cannot read it anymore. I realize that this is part of
> your disk space calculation but I want to stress that the result is
> probably not something that you will want to use for an extended period
> of time.

Indeed, I had thought to have 9 with a complete set of partitions as if 
8 didn't exist, but I did not say so.

>
>> LVM reports as follows:
>>
>> dan@debian:/$ sudo vgdisplay -C
>>    VG           #PV #LV #SN Attr    VSize      VFree
>>    debian-vg   1     5     0    wz--n- 976.56g 938.20g
> You can vgreduce debian-vg easily to make room for your planned
> debian9-vg.

So this must mean that VFree above is bound to debian-vg currently. I 
had not recognized the need to vgreduce. Thanks.

>
>> So there is plenty of disk space for the two Debians and more besides. The
>> question is how to prepare to install 9? My guess is to define another
>> volume group called debian9-vg perhaps but how will this be recognized
>> during network install?
> Yes, it will. It should also be possible to vgreduce debian.vg and
> vgcreate debian9-vg inside the installer, but I would be more
> comfortable doing that from the running system, using the regular tools.

For sure. Trying to do things within the installer has been the source 
of a lot of my problems.

>
> During installation, you just have to make sure that all LVs in
> debian-vg are marked as "Do not use".

Good. This is the kind of information I need.

>
>> I've clobbered stuff before during installs and I'm
>> gun shy. Maybe there is a better way. Any thoughts on this will be
>> appreciated.
> It happens to everybody. The only things that help are a good plan and
> concentration on the task at hand. :)

+1 and thank you, Jochen.

  - Dan

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

#188958

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

Dan Norton:
> On 11/13/2017 03:53 AM, Jochen Spieker wrote:
>> Dan Norton:
>> 
>>> LVM reports as follows:
>>> 
>>> dan@debian:/$ sudo vgdisplay -C
>>>    VG           #PV #LV #SN Attr    VSize      VFree
>>>    debian-vg   1     5     0    wz--n- 976.56g 938.20g
>>
>> You can vgreduce debian-vg easily to make room for your planned
>> debian9-vg.
> 
> So this must mean that VFree above is bound to debian-vg currently. I had
> not recognized the need to vgreduce. Thanks.

Good that you didn't, because I just noticed I was wrong. :) vgreduce is
only for removing physical volumes from a volume group.

It never occured to me before, but I think each physical volume can only
belong to exactly one volume group. That means if you want to use
separate volume groups you would need to pvresize (shrink) the physical
volume. I have never actually done this (only enlarged PVs).

I would probably accept that this is not easily possible with the
current layout and just use one VG. You do not gain much by separate
volume groups anyway.

J.
-- 
If I could travel in time I would show my minidisc to the Romans and
become Caesar until the batteries ran out.
[Agree]   [Disagree]
                 <http://archive.slowlydownward.com/NODATA/data_enter2.html>

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

#188943

On Sun, Nov 12, 2017 at 10:27:36PM -0500, Dan Norton wrote:
> My first Linux install was about one year ago. After some missteps, I have
> used Debian 8 in reasonable satisfaction on the desktop during that year.
> Now I want to leave 8 in place and do a network install for Debian 9 on the
> same disk and switch back and forth at boot time.
> 
If you use a desktop environment (e.g., GNOME or KDE) and want to share
the /home directory between both installations, you might encounter some
problems.  In particular, the desktop environments are known for not
behaving well when a newer version updates all the user-specific files
and then an older version tries to access them.

For example, the first time you boot to Debian 9 and log in (assume
GNOME for moment), files under ~/.config, ~/.gnome*, and possibly other
places will be modified by the new version of GNOME in Debian 9.  There
is no guarantee that when you go back to Debian 8 that the version of
GNOME there will cope will at all with the changed files under ~/.config
and ~/.gnome*.  In fact, it is quite likely that it will encounter some
sort of significant problem.

Your safest bet if you really intend to dual-boot in this way is to have
separate /home directories for each install and then use something like
/data to mount into both installations in order to share documents and
data between sessions.

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

#188951

On Mon, Nov 13, 2017 at 11:01:27AM -0500, Dan Norton wrote:
> 
> Although I didn't say so, each install would have its own set of
> directories. Please say more about how to mount the other installation and
> share data. How to mount things in another volume group?
> 
That would be as simple as creating a logical volume, call it "data,"
and then configuring it to mount in each installation with a line in
/etc/fstab:

/dev/vg00/data /data .....

Since you are talking about installing more than one version of Debian
and switching back and forth between them I assume that you are the only
user of the machine.  You would need to make sure that the assigned user
ID for your username matches in both installations and then just make
sure that /data has the appropriate permissions for your user account to
be able to write to it.

This is generally preferrable to directly mounting directories of the
other installation just to share data, as the dedicated data sharing
directory approach reduces the likelihood that a mistake will cause
problems in the other installation.

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

#188953

On 11/13/2017 11:07 AM, Roberto C. Sánchez wrote:
> On Mon, Nov 13, 2017 at 11:01:27AM -0500, Dan Norton wrote:
>> Although I didn't say so, each install would have its own set of
>> directories. Please say more about how to mount the other installation and
>> share data. How to mount things in another volume group?
>>
> That would be as simple as creating a logical volume, call it "data,"
> and then configuring it to mount in each installation with a line in
> /etc/fstab:
>
> /dev/vg00/data /data .....
Ah. OK. If each installation is in its own volume group, then vg00 above 
would be replaced with the actual vg.
>
> Since you are talking about installing more than one version of Debian
> and switching back and forth between them I assume that you are the only
> user of the machine.
Yes.
> You would need to make sure that the assigned user
> ID for your username matches in both installations and then just make
> sure that /data has the appropriate permissions for your user account to
> be able to write to it.
OK.
>
> This is generally preferrable to directly mounting directories of the
> other installation just to share data, as the dedicated data sharing
> directory approach reduces the likelihood that a mistake will cause
> problems in the other installation.
Great. If there's a mistake to be made ...

Thanks, Roberto.

  - Dan

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

#188952

On 11/13/2017 06:56 AM, Roberto C. Sánchez wrote:
> On Sun, Nov 12, 2017 at 10:27:36PM -0500, Dan Norton wrote:
>> My first Linux install was about one year ago. After some missteps, I have
>> used Debian 8 in reasonable satisfaction on the desktop during that year.
>> Now I want to leave 8 in place and do a network install for Debian 9 on the
>> same disk and switch back and forth at boot time.
>>
> If you use a desktop environment (e.g., GNOME or KDE) and want to share
> the /home directory between both installations, you might encounter some
> problems.  In particular, the desktop environments are known for not
> behaving well when a newer version updates all the user-specific files
> and then an older version tries to access them.

Xfce is what I use and it would surely encounter the same kinds of problems.

>
> For example, the first time you boot to Debian 9 and log in (assume
> GNOME for moment), files under ~/.config, ~/.gnome*, and possibly other
> places will be modified by the new version of GNOME in Debian 9.  There
> is no guarantee that when you go back to Debian 8 that the version of
> GNOME there will cope will at all with the changed files under ~/.config
> and ~/.gnome*.  In fact, it is quite likely that it will encounter some
> sort of significant problem.
>
> Your safest bet if you really intend to dual-boot in this way is to have
> separate /home directories for each install and then use something like
> /data to mount into both installations in order to share documents and
> data between sessions.

Although I didn't say so, each install would have its own set of 
directories. Please say more about how to mount the other installation 
and share data. How to mount things in another volume group?

Thanks, Roberto.

  - Dan

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

#188954

On Mon, 13 Nov 2017 11:01:27 -0500
Dan Norton <dnorton@mindspring.com> wrote:


> Although I didn't say so, each install would have its own set of 
> directories. Please say more about how to mount the other
> installation and share data. How to mount things in another volume
> group?
> 

Good advice so far, but to add a bit: all LVM groups will be seen at
boot, and /dev will know about them. See man lvm2 and also here:

https://wiki.debian.org/LVM  for complete information about the
commands you have available. There are also numerous tutorials on the
Net which show basic usage of the simpler commands. It's worth having a
look when you have some spare time, as one day you'll need to know some
of this and won't have any spare time.

Look in /etc/fstab for lines beginning /dev/mapper/[volume] which will
be the volumes mounted in the running installation. The 'mapper' is
turning LVM volumes into things which look like partitions for many
purposes.

To mount the volumes in the non-running installation, you need to add
similar-looking lines to fstab, and don't forget to create directories
somewhere quiet, like /mnt, to mount them on. You will need to add an
option to the entries that the running mounts do not have: if you
don't, systemd will try to mount them on boot, and if it fails, will
abort the boot. No problem if the extra mounts are on a drive that is
always there, but if stored on a second drive which is later removed,
it will kill the machine.

So you want either the option noauto, which tells systemd to ignore the
volume and you will always mount it manually (just mount <mountpoint>
in a terminal will do that, the fstab entry will have all the options
needed), or x-systemd.automount which will also be ignored during boot
but will be automounted when you try to access it. I mount my network
shares with that option, for the same reason (losing one will only put
a huge timeout into boot, but won't actually abort it) and also so that
mounting them will not slow down booting.

Here are a couple of spare LVM volumes on my workstation, one of which I
use only occasionally and always mount manually. You might notice that
the automount point is called oldroot, guess what that is...

/dev/mapper/newerlvm-spare  /mnt/spare  ext4  rw,user,noauto  0  0
/dev/mapper/newlvm-root  /mnt/oldroot  ext4  rw,user,x-systemd.automount
0 0

If you do mount the non-running system root, which is convenient for
many purposes, do be especially careful where you are in the directory
tree. The directories will look very similar, and it is easy to
misconfigure the wrong system. Years ago, I copied a system to a second
drive, then went into it to adjust the /etc/fstab to the new values it
needed. I managed to edit the wrong fstab, and neither system would
boot... fortunately, that was an easy one to fix.

So yes, it is safer only to mount the data of the other installation,
at least once you have the new one working properly and have duplicated
what you want from the old one.

-- 
Joe

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

#189388

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

On 11/13/2017 01:55 PM, Joe wrote:
> On Mon, 13 Nov 2017 11:01:27 -0500
> Dan Norton <dnorton@mindspring.com> wrote:
>
>
>> Although I didn't say so, each install would have its own set of
>> directories. Please say more about how to mount the other
>> installation and share data. How to mount things in another volume
>> group?
>>
> Good advice so far, but to add a bit: all LVM groups will be seen at
> boot, and /dev will know about them. See man lvm2 and also here:
>
> https://wiki.debian.org/LVM  for complete information about the
> commands you have available. There are also numerous tutorials on the
> Net which show basic usage of the simpler commands. It's worth having a
> look when you have some spare time, as one day you'll need to know some
> of this and won't have any spare time.

Reading the wiki reveals "Grub and ? <https://wiki.debian.org/LiLo>LiLo 
are not compatible with LVM, so /bootshould be outside the storage disk 
managed by LVM." Here's what I have:

Attempts to boot normally do not work. But using Super Grub2 on a 
bootable cd and selecting "Boot manually" and picking the hd1 entry 
brings up the jessie system that the installer reports as successfully 
installed on sda3. Using fdisk to take a look:

dan@debian8:~$ sudo fdisk /dev/sda
Command (m for help): p
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24

Device         Start        End    Sectors   Size Type
/dev/sda1       2048     411647     409600   200M BIOS boot
/dev/sda2     411648   16783359   16371712   7.8G Linux swap
/dev/sda3   16783360  151001087  134217728    64G Linux LVM
/dev/sda4  151001088  285218815  134217728    64G Linux LVM
/dev/sda5  285218816  419436543  134217728    64G Linux LVM
/dev/sda6  419436544  553654271  134217728    64G Linux LVM
/dev/sda7  553654272 1953525134 1399870863 667.5G Linux filesystem

Is there a problem here?

dan@debian8:~$ df -h
Filesystem                    Size  Used Avail Use% Mounted on
/dev/dm-0                     9.1G  3.0G  5.7G  35% /
udev                           10M     0   10M   0% /dev
tmpfs                         775M  9.0M  766M   2% /run
tmpfs                         1.9G   68K  1.9G   1% /dev/shm
tmpfs                         5.0M  4.0K  5.0M   1% /run/lock
tmpfs                         1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sda1                     992K  142K  851K  15% /boot/efi
/dev/mapper/debian8--vg-var   8.2G  1.3G  6.4G  17% /var
/dev/mapper/debian8--vg-home  9.1G  356M  8.3G   5% /home
/dev/mapper/debian8--vg-tmp   268M  2.1M  247M   1% /tmp
tmpfs                         388M  4.0K  388M   1% /run/user/115
tmpfs                         388M   12K  388M   1% /run/user/1000


Doesn't this satisfy the statement that "/boot should be outside the 
storage disk managed by LVM" since it is on sda1?

> Look in /etc/fstab for lines beginning /dev/mapper/[volume] which will
> be the volumes mounted in the running installation. The 'mapper' is
> turning LVM volumes into things which look like partitions for many
> purposes.

Here is fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type> <options>       <dump>  <pass>
/dev/mapper/debian8--vg-root /              ext4 errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=B07E-1F0B  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/debian8--vg-home /home          ext4 defaults        0       2
/dev/mapper/debian8--vg-tmp /tmp            ext4 defaults        0       2
/dev/mapper/debian8--vg-var /var            ext4 defaults        0       2
# swap was on /dev/sda2 during installation
UUID=6aa1846f-34dd-424d-b02c-dbd0af037a23 none            swap 
sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto 0       0


Why won't it boot normally, that is without using the bootable Grub2 cd?

  - Dan

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

#189393

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

On 29 November 2017 at 03:15, Dan Norton <dnorton@mindspring.com> wrote:

>
> On 11/13/2017 01:55 PM, Joe wrote:
>
> On Mon, 13 Nov 2017 11:01:27 -0500
> Dan Norton <dnorton@mindspring.com> <dnorton@mindspring.com> wrote:
>
>
>
> Although I didn't say so, each install would have its own set of
> directories. Please say more about how to mount the other
> installation and share data. How to mount things in another volume
> group?
>
>
> Good advice so far, but to add a bit: all LVM groups will be seen at
> boot, and /dev will know about them. See man lvm2 and also here:
> https://wiki.debian.org/LVM  for complete information about the
> commands you have available. There are also numerous tutorials on the
> Net which show basic usage of the simpler commands. It's worth having a
> look when you have some spare time, as one day you'll need to know some
> of this and won't have any spare time.
>
>
> Reading the wiki reveals "Grub and ? <https://wiki.debian.org/LiLo>LiLo
> are not compatible with LVM, so /boot should be outside the storage disk
> managed by LVM." Here's what I have:
>
> Attempts to boot normally do not work. But using Super Grub2 on a bootable
> cd and selecting "Boot manually" and picking the hd1 entry brings up the
> jessie system that the installer reports as successfully installed on sda3.
> Using fdisk to take a look:
>
> dan@debian8:~$ sudo fdisk /dev/sda
> Command (m for help): p
> Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24
>
> Device         Start        End    Sectors   Size Type
> /dev/sda1       2048     411647     409600   200M BIOS boot
> /dev/sda2     411648   16783359   16371712   7.8G Linux swap
> /dev/sda3   16783360  151001087  134217728    64G Linux LVM
> /dev/sda4  151001088  285218815  134217728    64G Linux LVM
> /dev/sda5  285218816  419436543  134217728    64G Linux LVM
> /dev/sda6  419436544  553654271  134217728    64G Linux LVM
> /dev/sda7  553654272 1953525134 1399870863 667.5G Linux filesystem
>
> Is there a problem here?
>

​I have been using Supergrub for ages now.   If you use Gentoo as I do you
appreciate the irritation of continuous babysitting of grub2 every time
you reconfigure the kernel (e.g. after setting up the long winded nonsense
required to make a firewall work properly) then grub tends to go awol
and requires TLC, massage therapy and soft music to start working
properly.

Meanwhile you will feel so frustrated that you want to chew on barbed wire
etc.

But supergrub is cool.  It is like a bloodhound.  You just can't fool it.  ​

The more you use it the dumber you feel using grub2 until you have finally
sorted the gripes and things have calmed down and stabilised - usually a
month later.

Remember the scene from 2001 space odyssey where the monkey throws the
bones up in the air.....

​Do the same with grub2, then use supergrub until things work and then
de-evolve again and vegetate in this area as I do.

Cheers​

​MF​

>
> dan@debian8:~$ df -h
> Filesystem                    Size  Used Avail Use% Mounted on
> /dev/dm-0                     9.1G  3.0G  5.7G  35% /
> udev                           10M     0   10M   0% /dev
> tmpfs                         775M  9.0M  766M   2% /run
> tmpfs                         1.9G   68K  1.9G   1% /dev/shm
> tmpfs                         5.0M  4.0K  5.0M   1% /run/lock
> tmpfs                         1.9G     0  1.9G   0% /sys/fs/cgroup
> /dev/sda1                     992K  142K  851K  15% /boot/efi
> /dev/mapper/debian8--vg-var   8.2G  1.3G  6.4G  17% /var
> /dev/mapper/debian8--vg-home  9.1G  356M  8.3G   5% /home
> /dev/mapper/debian8--vg-tmp   268M  2.1M  247M   1% /tmp
> tmpfs                         388M  4.0K  388M   1% /run/user/115
> tmpfs                         388M   12K  388M   1% /run/user/1000
>
>
> Doesn't this satisfy the statement that "/boot should be outside the
> storage disk managed by LVM" since it is on sda1?
>
> Look in /etc/fstab for lines beginning /dev/mapper/[volume] which will
> be the volumes mounted in the running installation. The 'mapper' is
> turning LVM volumes into things which look like partitions for many
> purposes.
>
>
> Here is fstab:
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name devices
> # that works even if disks are added and removed. See fstab(5).
> #
> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
> /dev/mapper/debian8--vg-root /              ext4    errors=remount-ro
> 0       1
> # /boot/efi was on /dev/sda1 during installation
> UUID=B07E-1F0B  /boot/efi       vfat    umask=0077      0       1
> /dev/mapper/debian8--vg-home /home          ext4    defaults
> 0       2
> /dev/mapper/debian8--vg-tmp /tmp            ext4    defaults
> 0       2
> /dev/mapper/debian8--vg-var /var            ext4    defaults
> 0       2
> # swap was on /dev/sda2 during installation
> UUID=6aa1846f-34dd-424d-b02c-dbd0af037a23 none            swap
> sw              0       0
> /dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
>
>
> Why won't it boot normally, that is without using the bootable Grub2 cd?
>
>  - Dan
>
>

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web