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

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

Migrate Stretch to New UEFI Build?

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

Contents

  Migrate Stretch to New UEFI Build? Patrick Bartek <nemommxiv@gmail.com> - 2019-01-11 01:00 +0100
    Re: Migrate Stretch to New UEFI Build? deloptes <deloptes@gmail.com> - 2019-01-11 08:40 +0100
      Re: Migrate Stretch to New UEFI Build? Patrick Bartek <nemommxiv@gmail.com> - 2019-01-12 02:10 +0100
        Re: Migrate Stretch to New UEFI Build? deloptes <deloptes@gmail.com> - 2019-01-12 08:30 +0100
    Re: Migrate Stretch to New UEFI Build? Michael Stone <mstone@debian.org> - 2019-01-11 13:20 +0100
      Re: Migrate Stretch to New UEFI Build? Patrick Bartek <nemommxiv@gmail.com> - 2019-01-12 02:00 +0100
        Re: Migrate Stretch to New UEFI Build? Michael Stone <mstone@debian.org> - 2019-01-12 03:20 +0100
          Re: Migrate Stretch to New UEFI Build? Glenn Holmer <glenn.holmer@gmail.com> - 2019-01-12 17:30 +0100
          Re: Migrate Stretch to New UEFI Build? Patrick Bartek <nemommxiv@gmail.com> - 2019-01-13 03:10 +0100
            Re: Migrate Stretch to New UEFI Build? Stefan Monnier <monnier@iro.umontreal.ca> - 2019-01-13 15:40 +0100
              Re: Migrate Stretch to New UEFI Build? Patrick Bartek <nemommxiv@gmail.com> - 2019-01-13 21:20 +0100
                Re: Migrate Stretch to New UEFI Build? deloptes <deloptes@gmail.com> - 2019-01-13 23:20 +0100
                  Re: Migrate Stretch to New UEFI Build? Patrick Bartek <nemommxiv@gmail.com> - 2019-01-14 23:30 +0100
                    Re: Migrate Stretch to New UEFI Build? deloptes <deloptes@gmail.com> - 2019-01-14 23:50 +0100
                      Re: Migrate Stretch to New UEFI Build? Patrick Bartek <nemommxiv@gmail.com> - 2019-01-16 00:00 +0100
                Re: Migrate Stretch to New UEFI Build? Stefan Monnier <monnier@iro.umontreal.ca> - 2019-01-14 04:40 +0100
                  Re: Migrate Stretch to New UEFI Build? Patrick Bartek <nemommxiv@gmail.com> - 2019-01-14 23:40 +0100

#204300 — Migrate Stretch to New UEFI Build?

Building a new UEFI system to supplant my "showing its age" 12 year old
non-UEFI, MBR-only system, and don't want to do a clean install of
Stretch.  Cloning drive and converting to GPT is out. I want only to
migrate the Stretch install out of the others there. Any links
or suggestions as to the best way to do this will be greatly
appreciated.


I have done this before, but only with a MBR system & drives. Plus, I
want to have a common-shared  /boot partition for possible future
upgrades or expansions. 

Here's a general procedure gleaned from numerous sources, none which
individually covered exactly my circumstances. All the steps will take
place on the new UEFI system as root.


1. Boot New System with 64-bit hybrid LiveCD since I already have I
one  . . . somewhere ;-) Check it booted into UEFI mode.

2. Partition new drive appropriately in GPT and format

3. Mount appropriate partitions of both drives

4. Use rsync to copy contents of corresponsing partitions -- Old to New

6. Edit fstab on migrated system: new UUIDs; add mount line for /boot
partition, etc. Copy contents of /boot directory to /boot partition.
Add efi directory to new /boot partition. 

7. chroot to system on new drive

8. Install all necessary efi files, efi-grub especially, etc. (They are
not installed on old system.  MBR only, remember . . .)

9. Create new system map, initrd image, etc., for each kernel. Install
grub

10.  Shutdown, remove old drive.

11. Boot. Hope it works. ;-)


Any caveats?  Glaring errors?  Suggestions?

Thanks

B

[toc] | [next] | [standalone]

#204307

Patrick Bartek wrote:

> 
> Building a new UEFI system to supplant my "showing its age" 12 year old
> non-UEFI, MBR-only system, and don't want to do a clean install of
> Stretch.  Cloning drive and converting to GPT is out. I want only to
> migrate the Stretch install out of the others there. Any links
> or suggestions as to the best way to do this will be greatly
> appreciated.
> 
> 
> I have done this before, but only with a MBR system & drives. Plus, I
> want to have a common-shared  /boot partition for possible future
> upgrades or expansions.
> 
> Here's a general procedure gleaned from numerous sources, none which
> individually covered exactly my circumstances. All the steps will take
> place on the new UEFI system as root.
> 
> 
> 1. Boot New System with 64-bit hybrid LiveCD since I already have I
> one  . . . somewhere ;-) Check it booted into UEFI mode.
> 
> 2. Partition new drive appropriately in GPT and format
> 
> 3. Mount appropriate partitions of both drives
> 
> 4. Use rsync to copy contents of corresponsing partitions -- Old to New
> 
> 6. Edit fstab on migrated system: new UUIDs; add mount line for /boot
> partition, etc. Copy contents of /boot directory to /boot partition.
> Add efi directory to new /boot partition.
> 
> 7. chroot to system on new drive
> 
> 8. Install all necessary efi files, efi-grub especially, etc. (They are
> not installed on old system.  MBR only, remember . . .)
> 
> 9. Create new system map, initrd image, etc., for each kernel. Install
> grub
> 
> 10.  Shutdown, remove old drive.
> 
> 11. Boot. Hope it works. ;-)
> 
> 
> Any caveats?  Glaring errors?  Suggestions?
> 
> Thanks
> 
> B

there was a post yesterday that /boot/efi is dedicated partition formated in
FAT32 while /boot may be ext4.

I also plan to migrate to UEFI boot in Feb. :)

regards

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

#204333

On Fri, 11 Jan 2019 08:38:52 +0100
deloptes <deloptes@gmail.com> wrote:

> Patrick Bartek wrote:
> 
> > 
> > Building a new UEFI system to supplant my "showing its age" 12 year old
> > non-UEFI, MBR-only system, and don't want to do a clean install of
> > Stretch.  Cloning drive and converting to GPT is out. I want only to
> > migrate the Stretch install out of the others there. Any links
> > or suggestions as to the best way to do this will be greatly
> > appreciated.
> > 
> > 
> > I have done this before, but only with a MBR system & drives. Plus, I
> > want to have a common-shared  /boot partition for possible future
> > upgrades or expansions.
> > 
> > Here's a general procedure gleaned from numerous sources, none which
> > individually covered exactly my circumstances. All the steps will take
> > place on the new UEFI system as root.
> > 
> > 
> > 1. Boot New System with 64-bit hybrid LiveCD since I already have I
> > one  . . . somewhere ;-) Check it booted into UEFI mode.
> > 
> > 2. Partition new drive appropriately in GPT and format
> > 
> > 3. Mount appropriate partitions of both drives
> > 
> > 4. Use rsync to copy contents of corresponsing partitions -- Old to New
> > 
> > 6. Edit fstab on migrated system: new UUIDs; add mount line for /boot
> > partition, etc. Copy contents of /boot directory to /boot partition.
> > Add efi directory to new /boot partition.
> > 
> > 7. chroot to system on new drive
> > 
> > 8. Install all necessary efi files, efi-grub especially, etc. (They are
> > not installed on old system.  MBR only, remember . . .)
> > 
> > 9. Create new system map, initrd image, etc., for each kernel. Install
> > grub
> > 
> > 10.  Shutdown, remove old drive.
> > 
> > 11. Boot. Hope it works. ;-)
> > 
> > 
> > Any caveats?  Glaring errors?  Suggestions?
> > 
> > Thanks
> > 
> > B  
> 
> there was a post yesterday that /boot/efi is dedicated partition formated in
> FAT32 while /boot may be ext4.

Actually, if I've understood what I've read over the past two weeks,
that's not correct.  You need a dedicated partition formatted in FAT32,
marked ef00 partition-type with the "boot" flag enabled on it. Mounting
that partition on /boot/efi (or somewhere else, depends on the distro)
is a LInux thing.

> I also plan to migrate to UEFI boot in Feb. :)

Best of luck.  I got the last two components of my new system today.
It's my Christmas present to me! No one gives me toys anymore.  So, I
buy them myself. ;-)

B

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

#204338

Patrick Bartek wrote:

> Actually, if I've understood what I've read over the past two weeks,
> that's not correct.  You need a dedicated partition formatted in FAT32,
> marked ef00 partition-type with the "boot" flag enabled on it. Mounting
> that partition on /boot/efi (or somewhere else, depends on the distro)
> is a LInux thing.

I did not say you have to mount ext4 on /boot and on top of it the EFI, did
I?
Obviously if you configure your BIOS to use UEFI, it will not use legacy
boot, so ...

regards

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

#204312

On Thu, Jan 10, 2019 at 03:53:11PM -0800, Patrick Bartek wrote:
>Plus, I
>want to have a common-shared  /boot partition for possible future
>upgrades or expansions.

This is a really bad idea, and will cause far more trouble than it can 
possibly save in the future. You do need one EFI partition per system, 
and you can have different directories there for different OSs.

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

#204332

On Fri, 11 Jan 2019 07:13:30 -0500
Michael Stone <mstone@debian.org> wrote:

> On Thu, Jan 10, 2019 at 03:53:11PM -0800, Patrick Bartek wrote:
> >Plus, I
> >want to have a common-shared  /boot partition for possible future
> >upgrades or expansions.  
> 
> This is a really bad idea, and will cause far more trouble than it can 
> possibly save in the future. You do need one EFI partition per system, 
> and you can have different directories there for different OSs.
> 

You misunderstood as I was too general in my post about partitioning.

I WILL have a dedicated EFI System Partition (ESP) formatted FAT32
marked with the "boot" flag AS WELL AS a dedicated partition with a
mount point of /boot  /boot/efi will be the mount point for the ESP. As
far as I've read UEFI booting firmware, etc. does not require this.
It's a Linux recommendation.  But I could be wrong: UEFI/GPT is new to
me.

Thanks for the response.

B

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

#204334

On Fri, Jan 11, 2019 at 04:56:07PM -0800, Patrick Bartek wrote:
>On Fri, 11 Jan 2019 07:13:30 -0500 Michael Stone <mstone@debian.org> wrote:
>> On Thu, Jan 10, 2019 at 03:53:11PM -0800, Patrick Bartek wrote:
>> >Plus, I
>> >want to have a common-shared  /boot partition for possible future
>> >upgrades or expansions.
>>
>> This is a really bad idea, and will cause far more trouble than it can
>> possibly save in the future. You do need one EFI partition per system,
>> and you can have different directories there for different OSs.
>>
>
>You misunderstood as I was too general in my post about partitioning.
>
>I WILL have a dedicated EFI System Partition (ESP) formatted FAT32
>marked with the "boot" flag AS WELL AS a dedicated partition with a
>mount point of /boot  /boot/efi will be the mount point for the ESP. As
>far as I've read UEFI booting firmware, etc. does not require this.
>It's a Linux recommendation.  But I could be wrong: UEFI/GPT is new to
>me.

I'm not really sure what you're trying to say here. Yes, the UEFI spec 
doesn't talk about where to put the efi partition in a linux system, 
because it isn't a linux spec. In theory you can put it anywhere or 
nowhere (it's not used in day-to-day operation at all). But, if you 
intend to put grub on it using the normal install process, it needs to 
be in /boot/efi or the install won't work. (By default it will be in 
/boot/efi/EFI/debian.) It is possible to manually put it somewhere else, 
or to use a directory other than debian. I'm not sure why you would 
decide to mount it elsewhere, as I can't see any benefit to doing so. 
Putting grub in a directory other than "EFI/debian" does allow for 
multiple OSs to have their own boot loaders which can be started from 
the UEFI boot menu. (E.g., you could have EFI/stretch, EFI/centos7, 
EFI/sid, etc.) In this case I would still keep the efi partition mounted 
on /boot/efi to reduce long-term confusion. I'd also add new directories 
instead of trying to keep multiple versions of debian from overwriting 
the debian directory.

In addition to the efi partition, where the boot loader goes, you also 
need a /boot partition where the kernel and the grub menu configuration 
go. (Actually, in most cases this does not need to be a separate 
partition, but you do need a /boot directory.) You talk about sharing 
the /boot partition and this is what I said was a really bad idea: have 
a separate /boot per install or you'll have multiple installs stomping 
on each other's boot configs.

Just about everything above can in theory be worked around or done 
differently, but you'll be way outside of what you can expect support 
for at that point.

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

#204354

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

On Fri, Jan 11, 2019 at 8:12 PM Michael Stone <mstone@debian.org> wrote:
> Putting grub in a directory other than "EFI/debian" does allow for
> multiple OSs to have their own boot loaders which can be started from
> the UEFI boot menu. (E.g., you could have EFI/stretch, EFI/centos7,
> EFI/sid, etc.) In this case I would still keep the efi partition mounted
> on /boot/efi to reduce long-term confusion. I'd also add new directories
> instead of trying to keep multiple versions of debian from overwriting
> the debian directory.

Do you know how to do this? I've had quite a bit of difficulty just adding
new boot entries to EFI, including bizarre results like my newly-added boot
entry not appearing after reboot but both PXE entries (IPV4/6) being
duplicated. I've been using efibootmgr from within Linux as well as bcfg
from the EFI shell.

I've been trying in a VM with both stretch and buster installed (both use
the vendor directory "\EFI\debian)" as well as on my new laptop with Ubuntu
and Ubuntu Studio installed (both use the vendor directory "\EFI\ubuntu").
I was able to install GRUB to a new EFI directory (e.g. "ubustu" for Ubuntu
Studio), but I was left with the impression that there was something
hard-coded that was overriding the specification of vendor directory
(--bootloader-id in grub-install) when creating the EFI boot entry (e.g.
the "ubustu" entry booted Ubuntu, not Ubuntu Studio).

In practice, I suppose it doesn't matter because the most recently
installed GRUB will contain menu items to boot both operating systems, but
I am relatively new to EFI and want to learn it thoroughly.

--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

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

#204364

On Fri, 11 Jan 2019 21:11:53 -0500
Michael Stone <mstone@debian.org> wrote:

> On Fri, Jan 11, 2019 at 04:56:07PM -0800, Patrick Bartek wrote:
> >On Fri, 11 Jan 2019 07:13:30 -0500 Michael Stone <mstone@debian.org> wrote:  
> >> On Thu, Jan 10, 2019 at 03:53:11PM -0800, Patrick Bartek wrote:  
> >> >Plus, I
> >> >want to have a common-shared  /boot partition for possible future
> >> >upgrades or expansions.  
> >>
> >> This is a really bad idea, and will cause far more trouble than it can
> >> possibly save in the future. You do need one EFI partition per system,
> >> and you can have different directories there for different OSs.
> >>  
> >
> >You misunderstood as I was too general in my post about partitioning.
> >
> >I WILL have a dedicated EFI System Partition (ESP) formatted FAT32
> >marked with the "boot" flag AS WELL AS a dedicated partition with a
> >mount point of /boot  /boot/efi will be the mount point for the ESP. As
> >far as I've read UEFI booting firmware, etc. does not require this.
> >It's a Linux recommendation.  But I could be wrong: UEFI/GPT is new to
> >me.  
> 
> I'm not really sure what you're trying to say here. Yes, the UEFI spec

The reason I wanted a dedicated boot partition was related to possible
future implementations, if needed, of encryption and LVM.  Now, after
more research, I've concluded I have no need for LVM, but encryption
is a possibility in the future.  Need more research.  Only played
with it years ago on an old notebook, but the installer set it all up.  


> doesn't talk about where to put the efi partition in a linux system, 
> because it isn't a linux spec. In theory you can put it anywhere or 
> nowhere (it's not used in day-to-day operation at all). But, if you 
> intend to put grub on it using the normal install process, it needs to 
> be in /boot/efi or the install won't work. (By default it will be in 
> /boot/efi/EFI/debian.) It is possible to manually put it somewhere else, 
> or to use a directory other than debian. I'm not sure why you would 
> decide to mount it elsewhere, as I can't see any benefit to doing so.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^

I didn't.  Wanted dedicated ESP mounted on /boot/efi as recommended.
And wanted /boot to be a separated partition for the reason noted
above, and not a directory in /.

> Putting grub in a directory other than "EFI/debian" does allow for 
> multiple OSs to have their own boot loaders which can be started from 
> the UEFI boot menu. (E.g., you could have EFI/stretch, EFI/centos7, 
> EFI/sid, etc.) In this case I would still keep the efi partition mounted 
> on /boot/efi to reduce long-term confusion. I'd also add new directories 
> instead of trying to keep multiple versions of debian from overwriting 
> the debian directory.

I have been unable to find so far any detailed documentation on how to
manually set up a Linux EFI booting system -- single or mulit-boot.
What goes where. Even what to use. Etc. 

> In addition to the efi partition, where the boot loader goes, you also 
> need a /boot partition where the kernel and the grub menu configuration 
> go. (Actually, in most cases this does not need to be a separate 
> partition, but you do need a /boot directory.) You talk about sharing 
> the /boot partition and this is what I said was a really bad idea: have 
> a separate /boot per install or you'll have multiple installs stomping 
> on each other's boot configs.
> 
> Just about everything above can in theory be worked around or done 
> differently, but you'll be way outside of what you can expect support 
> for at that point.
> 

Thanks for your input, suggestions and recommendations.

B

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

#204383

> more research, I've concluded I have no need for LVM, but encryption

Side note: whether I need LVM or not, I just always use it.
It's just a much nicer option than partitions and UUIDs.


        Stefan

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

#204388

On Sun, 13 Jan 2019 09:34:06 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > more research, I've concluded I have no need for LVM, but encryption  
> 
> Side note: whether I need LVM or not, I just always use it.

I never could understand that type of "reasoning." With me, if there's
no NEED, it's not done. I'm very much the pragmatist. Always have
been even as a child, and never likely to change.

> It's just a much nicer option than partitions and UUIDs.

At least with Linux (unlike Windows), you can choose how YOU want to do
things.  And even though I may not agree, I support your right to do so.

B

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

#204390

Patrick Bartek wrote:

> I never could understand that type of "reasoning." With me, if there's
> no NEED, it's not done. I'm very much the pragmatist. Always have
> been even as a child, and never likely to change.

you need it but you don't know yet
For example I leave some percentage of the disc unused and can increase the
any partition when needed - because I do not know which one will get filled
first. Now this can be challengeing without lvm and lvm does not come with
significant overhead. So why not?!

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

#204423

On Sun, 13 Jan 2019 23:19:35 +0100
deloptes <deloptes@gmail.com> wrote:

> Patrick Bartek wrote:
> 
> > I never could understand that type of "reasoning." With me, if there's
> > no NEED, it's not done. I'm very much the pragmatist. Always have
> > been even as a child, and never likely to change.  
> 
> you need it but you don't know yet

Unlikely.  Haven't needed LVM (or RAID for that matter) in the almost 20
years Linux has been my personal OS.

> For example I leave some percentage of the disc unused and can increase the
> any partition when needed - because I do not know which one will get filled
> first. Now this can be challengeing without lvm and lvm does not come with
> significant overhead. So why not?!

I'm VERY diligent about pruning and deleting old or unneed files, data,
apps, etc.  For example, my Wheezy install which I used for 5 years
(until support was dropped): / 16GB 45% full; /home 207GB 43% full. I'm
not a gamer.  So, no humongous installs there.  I have no music, video
or movies taking up space. I don't even use a desktop environment.
Window manager and a single panel only. And I'm the only user of the
system.  My Stretch install (about 6 months old) has even lower
percentages, but that's to be expected.

Obviously, how and what you use for system for are very different from
mine.

B 

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

#204425

Patrick Bartek wrote:

>> Patrick Bartek wrote:
>> 
>> > I never could understand that type of "reasoning." With me, if there's
>> > no NEED, it's not done. I'm very much the pragmatist. Always have
>> > been even as a child, and never likely to change.
>> 
>> you need it but you don't know yet
> 
> Unlikely.  Haven't needed LVM (or RAID for that matter) in the almost 20
> years Linux has been my personal OS.
> 

For your private use, it might be OK, but when you need flexibility, you
understand what you were missing. And mostly you start thinking from there
and decide if it is worth implementing.

>> For example I leave some percentage of the disc unused and can increase
>> the any partition when needed - because I do not know which one will get
>> filled first. Now this can be challengeing without lvm and lvm does not
>> come with significant overhead. So why not?!
> 
> I'm VERY diligent about pruning and deleting old or unneed files, data,
> apps, etc.  For example, my Wheezy install which I used for 5 years
> (until support was dropped): / 16GB 45% full; /home 207GB 43% full. I'm
> not a gamer.  So, no humongous installs there.  I have no music, video
> or movies taking up space. I don't even use a desktop environment.
> Window manager and a single panel only. And I'm the only user of the
> system.  My Stretch install (about 6 months old) has even lower
> percentages, but that's to be expected.
> 
> Obviously, how and what you use for system for are very different from
> mine.

Obviously, but even for a smaller system it does not hurt to use LVM.
Encryption is worth using on notebook or when you have sensitive data. It
comes at a high price, but LVM is almost for free. 
I am also conservative in deleting history. I installed and tried couple of
distros between 1998 and 2002 on some older 686 then upgraded and moved to
amd64 with the time the system grew up - personal data, accounting, videos,
albums, software, development, open source, virtual machines ... this is
now 3x2TB and 2x1TB disks in RAID1, encrypted and with LVM on top.
Without good planning and flexibility to manage bigger amounts of data you
are doomed.

regards

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

#204435

On Mon, 14 Jan 2019 23:41:03 +0100
deloptes <deloptes@gmail.com> wrote:

> Patrick Bartek wrote:
> 
> >> Patrick Bartek wrote:
> >>   
> >> > I never could understand that type of "reasoning." With me, if there's
> >> > no NEED, it's not done. I'm very much the pragmatist. Always have
> >> > been even as a child, and never likely to change.  
> >> 
> >> you need it but you don't know yet  
> > 
> > Unlikely.  Haven't needed LVM (or RAID for that matter) in the almost 20
> > years Linux has been my personal OS.
> >   
> 
> For your private use, it might be OK, but when you need flexibility, you
> understand what you were missing. And mostly you start thinking from there
> and decide if it is worth implementing.

In my responses, I was referring to a "private" system -- mine: a box
under the desk and only one user, me.  Now if it had mulitple users or
it was a server, even a family only one, it's configuration with future
expansions in mind would be different tailored to the vagaries of users.

It's not that I reject LVM out of hand.  I researched it some years
ago.  Even set up a VM LVM system with 2 virtual drives to learn the
basics.  For my new system, I revisited LVM as an option because I had
added a new criteria to the system -- more than basic video editing, but
after some thought discovered a simplier solution that didn't need RAID
or LVM. Although, I'll set up the new system to make adding LVM easier,
if the need every arises. 


> >> For example I leave some percentage of the disc unused and can increase
> >> the any partition when needed - because I do not know which one will get
> >> filled first. Now this can be challengeing without lvm and lvm does not
> >> come with significant overhead. So why not?!  
> > 
> > I'm VERY diligent about pruning and deleting old or unneed files, data,
> > apps, etc.  For example, my Wheezy install which I used for 5 years
> > (until support was dropped): / 16GB 45% full; /home 207GB 43% full. I'm
> > not a gamer.  So, no humongous installs there.  I have no music, video
> > or movies taking up space. I don't even use a desktop environment.
> > Window manager and a single panel only. And I'm the only user of the
> > system.  My Stretch install (about 6 months old) has even lower
> > percentages, but that's to be expected.
> > 
> > Obviously, how and what you use for system for are very different from
> > mine.  
> 
> Obviously, but even for a smaller system it does not hurt to use LVM.

Even if the overhead is low, why use it if there's no real need? Kinda
like snow tires on your car, and you live in Florida. ;-)

B

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

#204392

>> > more research, I've concluded I have no need for LVM, but encryption  
>> Side note: whether I need LVM or not, I just always use it.
> I never could understand that type of "reasoning." With me, if there's
> no NEED, it's not done.  I'm very much the pragmatist.

Not sure if pragmatism has much to do with it: I use LVM because it's
more convenient, even if in the end what I do with it could have been
done with partitions.


        Stefan

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

#204424

On Sun, 13 Jan 2019 22:37:47 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> >> > more research, I've concluded I have no need for LVM, but encryption    
> >> Side note: whether I need LVM or not, I just always use it.  
> > I never could understand that type of "reasoning." With me, if there's
> > no NEED, it's not done.  I'm very much the pragmatist.  
> 
> Not sure if pragmatism has much to do with it: I use LVM because it's

You'd be surprised how much it can affect decisions and choices.  And
make logic easier.  Set your criteria and requirements, and stick to
them. Now I'm not saying it is any better than other methods, but it
does work best for me.  And it came naturally.

> more convenient, even if in the end what I do with it could have been
> done with partitions.

I keep my personal systems simple: /, /home, swap.  With 20 years
experience using Linux, I pretty much know how big my partitions need
to be and so once created never need to be resized.  However, with the
new system I'm building, there will be two additional partitions and
since they will be GPT/UEFI, no extended or logical partitions to fool
with.

B

[toc] | [prev] | [standalone]

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

csiph-web