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

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

BTRFS and debian

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

Contents

  BTRFS and debian Ge <gpdsbe@mailbox.org> - 2018-07-09 20:20 +0200
    Re: BTRFS and debian Matthew Crews <mailinglists@mattcrews.com> - 2018-07-09 21:40 +0200
      Re: BTRFS and debian Ulf Volmer <u.volmer@u-v.de> - 2018-07-09 22:00 +0200
        Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-09 23:00 +0200
          Re: BTRFS and debian Ulf Volmer <u.volmer@u-v.de> - 2018-07-09 23:10 +0200
        Re: BTRFS and debian Matthew Crews <mailinglists@mattcrews.com> - 2018-07-09 23:40 +0200
    Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-10 05:40 +0200
      Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-11 20:40 +0200
        Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-12 05:10 +0200
          Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-12 07:50 +0200
            Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-13 03:20 +0200
              Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-14 00:40 +0200
                Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-14 03:00 +0200
                  Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-14 11:10 +0200
                    Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-14 21:40 +0200
                      Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-14 23:10 +0200
              Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-14 01:40 +0200
      Re: BTRFS and debian David Wright <deblis@lionunicorn.co.uk> - 2018-07-12 20:00 +0200
        Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-13 05:00 +0200
          Re: BTRFS and debian Dan Ritter <dsr@randomstring.org> - 2018-07-13 12:00 +0200
            Re: BTRFS and debian <tomas@tuxteam.de> - 2018-07-13 12:30 +0200
            Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-14 03:10 +0200
          Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-14 01:40 +0200
            Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-14 03:10 +0200
              Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-14 12:00 +0200
                Re: BTRFS and debian Reco <recoverym4n@gmail.com> - 2018-07-14 12:30 +0200
                  Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-14 12:40 +0200
                Wrapping lines, was Re: BTRFS and debian David Wright <deblis@lionunicorn.co.uk> - 2018-07-15 05:20 +0200
                  Re: Wrapping lines, was Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-15 05:30 +0200
                    Re: Wrapping lines, was Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-15 12:30 +0200
          Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-14 11:40 +0200

Page 1 of 2  [1] 2  Next page →

#197407 — BTRFS and debian

Hi there!
I am new here.

I am trying to install debian on a VM to test it before i install it on
my laptop. Since its a laptop i would like to encrypt the hard drive. I
would also like to be able to return my whole system to a previous state
or just my home directory.

I would like to ask

1. Whats the appropriate layout?
My current layout is:

LVM VG Laptop-vg LV root 16.9GB Linux device mapper (linear)
#1	16.9GB	f	btrfs	/


LVM VG Laptop-vg LV swap 4.3GB Linux device mapper (linear)
#1	4.3GB	f	swap	swap

Encrypted volume (sda5_crypt)-21.2GB Linux device mapper (crypt)
#1	21.2GB	K	lvm

SCSI1 (0,0,0) (sda) 21.2GB ATA QEMU HARDDISK
#1	primary	254.8MB	K	ext2	/boot
#5	logical	21.2GB	K	crypto	(sda5_crypt)


Should i make a different partition for /home/ ?


2.I will obviously make the / partition btrfs. Do i have to use btrfs
also on my boot partition?


3.Is there any btrfs GUI program to manage my system on debian stretch
or on debian buster? or i can only do this from the command line?


Thanks in advance for your help

[toc] | [next] | [standalone]

#197410

On 7/9/18 11:17 AM, Ge wrote:
> Should i make a different partition for /home/ ?

I would, especially if you intend on using BTRFS snapshot feature. Last
thing you want to do is accidentally roll back a critical document.

> 
> 2.I will obviously make the / partition btrfs. Do i have to use btrfs
> also on my boot partition?

No, you do not, but you can. I personally use EXT2.

> 
> 3.Is there any btrfs GUI program to manage my system on debian stretch
> or on debian buster? or i can only do this from the command line?
> 

Look into using Snapper, available in the Debian Stretch repos. Also see:
https://en.opensuse.org/Portal:Snapper

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

#197411

On 09.07.2018 21:32, Matthew Crews wrote:
> On 7/9/18 11:17 AM, Ge wrote:
>> Should i make a different partition for /home/ ?
> 
> I would, especially if you intend on using BTRFS snapshot feature. Last
> thing you want to do is accidentally roll back a critical document.

why not using a subvolume for /home? i see that concept in OpenSuse for
example to exclude /var from snapper. And it will be easier to handle a
single LUKS volume.

best regards
Ulf

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

#197412

Le 09/07/2018 à 21:58, Ulf Volmer a écrit :
> On 09.07.2018 21:32, Matthew Crews wrote:
>> On 7/9/18 11:17 AM, Ge wrote:
>>> Should i make a different partition for /home/ ?
>>
>> I would, especially if you intend on using BTRFS snapshot feature. Last
>> thing you want to do is accidentally roll back a critical document.
> 
> why not using a subvolume for /home? i see that concept in OpenSuse for
> example to exclude /var from snapper.

openSUSE uses XFS for /home, not a btrfs subvolume.

> And it will be easier to handle a single LUKS volume.

So what ? The encrypted volume is used as an LVM physical volume and can 
contain any number of logical volumes. No need for btrfs subvolumes.

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

#197413

On 09.07.2018 22:52, Pascal Hambourg wrote:
> Le 09/07/2018 à 21:58, Ulf Volmer a écrit :

>> why not using a subvolume for /home? i see that concept in OpenSuse for
>> example to exclude /var from snapper.
> 
> openSUSE uses XFS for /home, not a btrfs subvolume.

Yes. i assume that's caused by the decision of the commercial version
(sles) to not support btrfs for data volumes.

i can't see any technical reason against using a subvolume for /home.

>> And it will be easier to handle a single LUKS volume.
> 
> So what ? The encrypted volume is used as an LVM physical volume and can
> contain any number of logical volumes.

ok, ack.

best regards
Ulf

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

#197414

On 7/9/18 12:58 PM, Ulf Volmer wrote:
> On 09.07.2018 21:32, Matthew Crews wrote:
>> On 7/9/18 11:17 AM, Ge wrote:
>>> Should i make a different partition for /home/ ?
>>
>> I would, especially if you intend on using BTRFS snapshot feature. Last
>> thing you want to do is accidentally roll back a critical document.
> 
> why not using a subvolume for /home? i see that concept in OpenSuse for
> example to exclude /var from snapper. And it will be easier to handle a
> single LUKS volume.

Good point, I forgot you can do subvolumes that way.

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

#197423

On 07/09/18 11:17, Ge wrote:
> Hi there!
> I am new here.

Welcome! :-)


> I am trying to install debian on a VM to test it before i install it on
> my laptop. 

What hardware?  What host OS?  What hypervisor?


> Since its a laptop i would like to encrypt the hard drive. 

Disk encryption is a discussion unto itself.  One choice is a laptop 
with firmware that supports self-encrypting drives (SED) and a matching 
HDD/SSD.  One software choice for Stretch is dm-crypt/LUKS.

> I
> would also like to be able to return my whole system to a previous state
> or just my home directory.

Backup/recover, imaging, snapshots, version control, etc., are yet more 
discussions.  Since the subject line includes btrfs, subvolumes and 
snapshots may be an option:

https://en.wikipedia.org/wiki/Btrfs#Subvolumes_and_snapshots


I would need to work through the various use-cases to figure out what 
can be done with the subvolume mounted and in use, with the subvolume 
mounted but not in use, and with the subvolume not mounted.  (I use 
dd(1) to image partitions, with the LUKS container closed and/or the 
file system not mounted.)


> I would like to ask
> 
> 1. Whats the appropriate layout?
> My current layout is:
> 
> LVM VG Laptop-vg LV root 16.9GB Linux device mapper (linear)
> #1	16.9GB	f	btrfs	/
> 
> 
> LVM VG Laptop-vg LV swap 4.3GB Linux device mapper (linear)
> #1	4.3GB	f	swap	swap
> 
> Encrypted volume (sda5_crypt)-21.2GB Linux device mapper (crypt)
> #1	21.2GB	K	lvm
> 
> SCSI1 (0,0,0) (sda) 21.2GB ATA QEMU HARDDISK
> #1	primary	254.8MB	K	ext2	/boot
> #5	logical	21.2GB	K	crypto	(sda5_crypt)

I use 16 GiB SSD's and/or 16 GiB USB flash drives for system drives.  I 
wipe and test them using the manufacturer's diagnostic tool before 
installing Debian, or just wipe them with dd(1) if I do not have a tool. 
  In the Debian Installer, I choose 'manual' for 'partitioning method', 
create a new partition table (MBR), and create three primary partitions:

1   ~1 GiB btrfs mounted at /boot
2   ~2 GiB LUKS (random key) with swap
3  ~10 GiB LUKS (passphrase) with btrfs mounted at /

10 GiB root is enough for single-user Xfce workstation (my bulk data is 
on a file server).

The last ~3 GiB are unallocated -- for over-provisioning, because the 
drives have different numbers of sectors, and because of the GB/ GiB 
stupidity.


> Should i make a different partition for /home/ ?

I don't -- I put my bulk data on a file server, including all e-mail 
attachments.  My home directory is ~1 GB.


(If/when I want to travel with my laptop, I will need to figure out how 
to set up a VPN to my file server.)


> 2.I will obviously make the / partition btrfs. Do i have to use btrfs
> also on my boot partition?

No, but I do.


> 3.Is there any btrfs GUI program to manage my system on debian stretch
> or on debian buster? or i can only do this from the command line?

STFW I see:

http://carfax.org.uk/btrfs-gui
http://snapper.io/


Stretch has a package for Snapper:

https://packages.debian.org/search?keywords=snapper&searchon=names&suite=stable&section=all


(I use the included command-line tools.)


David

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

#197514

Le 10/07/2018 à 05:33, David Christensen a écrit :
> 
>   In the Debian Installer, I choose 'manual' for 'partitioning method', 
> create a new partition table (MBR), and create three primary partitions:
> 
> 1   ~1 GiB btrfs mounted at /boot
> 2   ~2 GiB LUKS (random key) with swap

How do you do that ?
AFAIK, you cannot set a random key with LUKS, only with plain dm-crypt.

> 3  ~10 GiB LUKS (passphrase) with btrfs mounted at /

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

#197526

On 07/11/18 11:29, Pascal Hambourg wrote:
> Le 10/07/2018 à 05:33, David Christensen a écrit :
>>
>>   In the Debian Installer, I choose 'manual' for 'partitioning 
>> method', create a new partition table (MBR), and create three primary 
>> partitions:
>>
>> 1   ~1 GiB btrfs mounted at /boot
>> 2   ~2 GiB LUKS (random key) with swap
> 
> How do you do that ?
> AFAIK, you cannot set a random key with LUKS, only with plain dm-crypt.

Perhaps it is plain dm-crypt, not LUKS.  (I am not familiar with the 
internals of either, so my understanding is that of a parrot or blind man.)


In the Debian Installer for Stretch:

1.  For "Partitioning method", choose "Manual".

2.  Create partitions, including a partition for swap.

3.  Move the highlight to the swap partition and press Enter to invoke 
the "Partition settings" pop-up dialog, and configure as follows (note 
"Encryption key" => "Random key" setting):

         Partition settings:
             Use as                      physical volume for encryption
             Encryption method           Device-mapper (dm-crypt)
             Encryption                  aes
             Key size                    256
             IV algorithm                xts-plain64
             Encryption key              Random key
             Erase data                  yes


David

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

#197531

Le 12/07/2018 à 05:01, David Christensen a écrit :
> On 07/11/18 11:29, Pascal Hambourg wrote:
>> Le 10/07/2018 à 05:33, David Christensen a écrit :
>>>
>>>   In the Debian Installer, I choose 'manual' for 'partitioning 
>>> method', create a new partition table (MBR), and create three primary 
>>> partitions:
>>>
>>> 1   ~1 GiB btrfs mounted at /boot
>>> 2   ~2 GiB LUKS (random key) with swap
>>
>> How do you do that ?
>> AFAIK, you cannot set a random key with LUKS, only with plain dm-crypt.
> 
> Perhaps it is plain dm-crypt, not LUKS.  (I am not familiar with the 
> internals of either, so my understanding is that of a parrot or blind man.)
> 
> 
> In the Debian Installer for Stretch:
> 
> 1.  For "Partitioning method", choose "Manual".
> 
> 2.  Create partitions, including a partition for swap.
> 
> 3.  Move the highlight to the swap partition and press Enter to invoke 
> the "Partition settings" pop-up dialog, and configure as follows (note 
> "Encryption key" => "Random key" setting):
> 
>          Partition settings:
>              Use as                      physical volume for encryption
>              Encryption method           Device-mapper (dm-crypt)
>              Encryption                  aes
>              Key size                    256
>              IV algorithm                xts-plain64
>              Encryption key              Random key
>              Erase data                  yes

Yes, this uses plain dm-crypt, not LUKS. You can see it in the resulting 
/etc/crypttab (no "luks" option), and blkid/file/wipefs do not show any 
LUKS header on the partition.

Note that this setup is flawed when using a partition on an SCSI-like 
disk : the installer writes the device name /dev/sdX which is known to 
be not persistent (that's why UUIDs are used instead when possible). But 
a plain dm-crypt device has no header and UUID. It would be more 
reliable to use the PARTUUID= (synthetic on a DOS-partitioned disk) instead.

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

#197568

On 07/11/18 22:40, Pascal Hambourg wrote:
> Le 12/07/2018 à 05:01, David Christensen a écrit :
>> On 07/11/18 11:29, Pascal Hambourg wrote:
>>> Le 10/07/2018 à 05:33, David Christensen a écrit :
>>>>
>>>>   In the Debian Installer, I choose 'manual' for 'partitioning 
>>>> method', create a new partition table (MBR), and create three 
>>>> primary partitions:
>>>>
>>>> 1   ~1 GiB btrfs mounted at /boot
>>>> 2   ~2 GiB LUKS (random key) with swap
>>>
>>> How do you do that ?
>>> AFAIK, you cannot set a random key with LUKS, only with plain dm-crypt.
>>
>> Perhaps it is plain dm-crypt, not LUKS.  (I am not familiar with the 
>> internals of either, so my understanding is that of a parrot or blind 
>> man.)
>>
>>
>> In the Debian Installer for Stretch:
>>
>> 1.  For "Partitioning method", choose "Manual".
>>
>> 2.  Create partitions, including a partition for swap.
>>
>> 3.  Move the highlight to the swap partition and press Enter to invoke 
>> the "Partition settings" pop-up dialog, and configure as follows (note 
>> "Encryption key" => "Random key" setting):
>>
>>          Partition settings:
>>              Use as                      physical volume for encryption
>>              Encryption method           Device-mapper (dm-crypt)
>>              Encryption                  aes
>>              Key size                    256
>>              IV algorithm                xts-plain64
>>              Encryption key              Random key
>>              Erase data                  yes
> 
> Yes, this uses plain dm-crypt, not LUKS. You can see it in the resulting 
> /etc/crypttab (no "luks" option), 

crypttab(5) -- yes:

2018-07-12 18:04:20 root@po ~
# grep sda2 /etc/crypttab
sda2_crypt 
/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_******************-part2 
/dev/urandom    cipher=aes-xts-plain64,size=256,swap

2018-07-12 18:07:43 root@po ~
# grep sda3 /etc/crypttab
sda3_crypt	UUID=0152d2e2-4cfb-42c4-a121-6fb832962e47				none		luks


> and blkid/file/wipefs do not show any 
> LUKS header on the partition.

blkid(8) -- yes:

2018-07-12 17:54:05 root@po ~
# blkid /dev/sda1
/dev/sda1: LABEL="po_boot" UUID="6ff0dd1d-8d46-454b-bb35-a09afc47145a" 
UUID_SUB="47a80883-0378-43da-b5e2-0ae9f87e2c95" TYPE="btrfs" 
PARTUUID="8d34b557-01"

2018-07-12 17:54:22 root@po ~
# blkid /dev/sda2
/dev/sda2: PARTUUID="8d34b557-02"

2018-07-12 17:54:23 root@po ~
# blkid /dev/sda3
/dev/sda3: UUID="0152d2e2-4cfb-42c4-a121-6fb832962e47" 
TYPE="crypto_LUKS" PARTUUID="8d34b557-03"


file(1) -- no:

2018-07-12 17:55:01 root@po ~
# file /dev/sda1
/dev/sda1: block special (8/1)

2018-07-12 17:55:26 root@po ~
# file /dev/sda2
/dev/sda2: block special (8/2)

2018-07-12 17:55:28 root@po ~
# file /dev/sda3
/dev/sda3: block special (8/3)


wipefs(8) -- not today (!).


Therefore, I should say I set up the second partition on my system 
drives as follows:

2   ~2 GiB dm-crypt (random key) with swap


> Note that this setup is flawed when using a partition on an SCSI-like 
> disk : the installer writes the device name /dev/sdX which is known to 
> be not persistent (that's why UUIDs are used instead when possible). But 
> a plain dm-crypt device has no header and UUID. It would be more 
> reliable to use the PARTUUID= (synthetic on a DOS-partitioned disk) 
> instead.

I have been using /dev/disk/by-id/* successfully for a while, but 
/dev/disk/by-partuuid sounds even better -- this will prevent confusion 
if and when I move partitions or images to other devices.


Thank you for the pointers.  :-)


David

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

#197614

Le 13/07/2018 à 03:13, David Christensen a écrit :
> file(1) -- no:
> 
> 2018-07-12 17:55:01 root@po ~
> # file /dev/sda1
> /dev/sda1: block special (8/1)

You must add the option -s so that file looks into the special device 
file contents.

> wipefs(8) -- not today (!).

Don't worry, despite its dreadful name, wipefs does not wipe anything 
without the -a or -o option, it just displays found metadata.

>> Note that this setup is flawed when using a partition on an SCSI-like 
>> disk : the installer writes the device name /dev/sdX which is known to 
>> be not persistent (that's why UUIDs are used instead when possible). 
>> But a plain dm-crypt device has no header and UUID. It would be more 
>> reliable to use the PARTUUID= (synthetic on a DOS-partitioned disk) 
>> instead.
> 
> I have been using /dev/disk/by-id/* successfully for a while, but 

Did the installer automatically wrote this in /etc/crypttab or did you 
replace the original device name ?

> /dev/disk/by-partuuid sounds even better -- this will prevent confusion 
> if and when I move partitions or images to other devices.

Beware that unlike a UUID or LABEL, a PARTUUID or PARTLABEL is stored in 
the partition table, not in the partition data.
Also note that a DOS partition table entry does not contain a UUID nor 
LABEL, and the PARTUUID is artificially built by combining the 32-bit 
"disk identifier" field in the MBR and the partition number. So if the 
partition number or the disk identifier changes, the PARTUUID changes.

In short :
- if you move the disk contents (including the partition table) to 
another disk, the PARTUUID is preserved ;
- if you move the partition contents to another partition, the PARTUUID 
is not preserved.

There is a hackish way to add a UUID to a plain dm-crypt partition : 
write metadata of any kind at the beginning of the partition (ext2, 
swap, LUKS...) and specify an offset for dm-crypt data beyond the metadata.

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

#197617

On 07/13/18 15:36, Pascal Hambourg wrote:
> Le 13/07/2018 à 03:13, David Christensen a écrit :
>> file(1) -- no:
>>
>> 2018-07-12 17:55:01 root@po ~
>> # file /dev/sda1
>> /dev/sda1: block special (8/1)
> 
> You must add the option -s so that file looks into the special device 
> file contents.

2018-07-13 17:39:48 root@po ~
# file -s /dev/sda1
/dev/sda1: BTRFS Filesystem label "po_boot", sectorsize 4096, nodesize 
16384, leafsize 16384, UUID=6ff0dd1d-8d46-454b-bb35-a09afc47145a, 
65490944/999292928 bytes used, 1 devices

2018-07-13 17:39:51 root@po ~
# file -s /dev/sda2
/dev/sda2: data

2018-07-13 17:39:59 root@po ~
# file -s /dev/sda3
/dev/sda3: LUKS encrypted file, ver 1 [aes, xts-plain64, sha256] UUID: 
0152d2e2-4cfb-42c4-a121-6fb832962e47


The output for /dev/sda2 is not very informative (e.g. clues that it has 
dm-crypt, random key, and swap).


>> I have been using /dev/disk/by-id/* successfully [in /etc/crypttab] for a while, but 
> 
> Did the installer automatically wrote this in /etc/crypttab or did you 
> replace the original device name ?

I edited /etc/crypttab.


>> /dev/disk/by-partuuid sounds even better -- this will prevent 
>> confusion if and when I move partitions or images to other devices.
> 
> Beware that unlike a UUID or LABEL, a PARTUUID or PARTLABEL is stored in 
> the partition table, not in the partition data.
> Also note that a DOS partition table entry does not contain a UUID nor 
> LABEL, and the PARTUUID is artificially built by combining the 32-bit 
> "disk identifier" field in the MBR and the partition number. So if the 
> partition number or the disk identifier changes, the PARTUUID changes.
> 
> In short :
> - if you move the disk contents (including the partition table) to 
> another disk, the PARTUUID is preserved ;
> - if you move the partition contents to another partition, the PARTUUID 
> is not preserved.

Thanks for the warning.  My typical use-case is to move the entire 
system drive image between various 16+ GB devices, so PARTUUID should work.


> There is a hackish way to add a UUID to a plain dm-crypt partition : 
> write metadata of any kind at the beginning of the partition (ext2, 
> swap, LUKS...) and specify an offset for dm-crypt data beyond the metadata.

Okay.


David

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

#197620

Le 14/07/2018 à 02:49, David Christensen a écrit :
> # file -s /dev/sda1
> /dev/sda1: BTRFS Filesystem label "po_boot", sectorsize 4096, nodesize 
> 16384, leafsize 16384, UUID=6ff0dd1d-8d46-454b-bb35-a09afc47145a, 
> 65490944/999292928 bytes used, 1 devices
> 
> 2018-07-13 17:39:51 root@po ~
> # file -s /dev/sda2
> /dev/sda2: data
> 
> 2018-07-13 17:39:59 root@po ~
> # file -s /dev/sda3
> /dev/sda3: LUKS encrypted file, ver 1 [aes, xts-plain64, sha256] UUID: 
> 0152d2e2-4cfb-42c4-a121-6fb832962e47
> 
> The output for /dev/sda2 is not very informative (e.g. clues that it has 
> dm-crypt, random key, and swap).

As expected. /dev/sda2 contains raw encrypted data which appear as 
random data. It is the purpose of encryption that one cannot see the 
real contents.

>> Beware that unlike a UUID or LABEL, a PARTUUID or PARTLABEL is stored 
>> in the partition table, not in the partition data.
>> Also note that a DOS partition table entry does not contain a UUID nor 
>> LABEL, and the PARTUUID is artificially built by combining the 32-bit 
>> "disk identifier" field in the MBR and the partition number. So if the 
>> partition number or the disk identifier changes, the PARTUUID changes.
>>
>> In short :
>> - if you move the disk contents (including the partition table) to 
>> another disk, the PARTUUID is preserved ;
>> - if you move the partition contents to another partition, the 
>> PARTUUID is not preserved.
> 
> Thanks for the warning.  My typical use-case is to move the entire 
> system drive image between various 16+ GB devices, so PARTUUID should work.

I forgot to mention another case, although you are not concerned :

- logical partitions numbers and synthetic PARTUUIDs may change when 
creating or deleting another logical partition on the same disk. Yet 
another reason to not use logical partitions and prefer GPT if you need 
more than 4 partitions.

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

#197635

On 07/14/18 02:04, Pascal Hambourg wrote:
> Le 14/07/2018 à 02:49, David Christensen a écrit :
>> # file -s /dev/sda1
>> /dev/sda1: BTRFS Filesystem label "po_boot", sectorsize 4096, nodesize 
>> 16384, leafsize 16384, UUID=6ff0dd1d-8d46-454b-bb35-a09afc47145a, 
>> 65490944/999292928 bytes used, 1 devices
>>
>> 2018-07-13 17:39:51 root@po ~
>> # file -s /dev/sda2
>> /dev/sda2: data
>>
>> 2018-07-13 17:39:59 root@po ~
>> # file -s /dev/sda3
>> /dev/sda3: LUKS encrypted file, ver 1 [aes, xts-plain64, sha256] UUID: 
>> 0152d2e2-4cfb-42c4-a121-6fb832962e47
>>
>> The output for /dev/sda2 is not very informative (e.g. clues that it 
>> has dm-crypt, random key, and swap).
> 
> As expected. /dev/sda2 contains raw encrypted data which appear as 
> random data. It is the purpose of encryption that one cannot see the 
> real contents.

Okay.


>>> Beware that unlike a UUID or LABEL, a PARTUUID or PARTLABEL is stored 
>>> in the partition table, not in the partition data.
>>> Also note that a DOS partition table entry does not contain a UUID 
>>> nor LABEL, and the PARTUUID is artificially built by combining the 
>>> 32-bit "disk identifier" field in the MBR and the partition number. 
>>> So if the partition number or the disk identifier changes, the 
>>> PARTUUID changes.
>>>
>>> In short :
>>> - if you move the disk contents (including the partition table) to 
>>> another disk, the PARTUUID is preserved ;
>>> - if you move the partition contents to another partition, the 
>>> PARTUUID is not preserved.
>>
>> Thanks for the warning.  My typical use-case is to move the entire 
>> system drive image between various 16+ GB devices, so PARTUUID should 
>> work.
> 
> I forgot to mention another case, although you are not concerned :
> 
> - logical partitions numbers and synthetic PARTUUIDs may change when 
> creating or deleting another logical partition on the same disk. 

Fortunately, I only need 3 partitions on my system drives.  I have 
always used primary partitions.


> Yet 
> another reason to not use logical partitions and prefer GPT if you need 
> more than 4 partitions.

GPT is nice; I use it when I want a 2+ TB partition (such as my backup/ 
archive/ image drives).  But I have several older computers, so I prefer 
solutions that work with BIOS/MBR.

David

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

#197639

Le 14/07/2018 à 21:29, David Christensen a écrit :
> On 07/14/18 02:04, Pascal Hambourg wrote:
> 
>> Yet another reason to not use logical partitions and prefer GPT if you 
>> need more than 4 partitions.
> 
> GPT is nice; I use it when I want a 2+ TB partition (such as my backup/ 
> archive/ image drives).  But I have several older computers, so I prefer 
> solutions that work with BIOS/MBR.

GPT works on all my old BIOS computers, such as the one from 2005 I am 
using to write this. I use GPT by default on any disk unless I have a 
strong reason no to. The only trick I need to use sometimes is to set 
the boot flag in the protective MBR, when a broken BIOS requires this 
flag to be set.

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

#197615

On Thu, Jul 12, 2018 at 06:13:36PM -0700, David Christensen wrote:
> 2018-07-12 17:55:28 root@po ~
> # file /dev/sda3
> /dev/sda3: block special (8/3)
> 

> wipefs(8) -- not today (!).

Oh come on! We're s'posed to take one for the team yo!

;)

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

#197561

On Mon 09 Jul 2018 at 20:33:00 (-0700), David Christensen wrote:
> On 07/09/18 11:17, Ge wrote:
> >1. Whats the appropriate layout?
> >My current layout is:
> >
> >LVM VG Laptop-vg LV root 16.9GB Linux device mapper (linear)
> >#1	16.9GB	f	btrfs	/
> 
> I use 16 GiB SSD's and/or 16 GiB USB flash drives for system drives.
> I wipe and test them using the manufacturer's diagnostic tool before
> installing Debian, or just wipe them with dd(1) if I do not have a
> tool.  In the Debian Installer, I choose 'manual' for 'partitioning
> method', create a new partition table (MBR), and create three
> primary partitions:
> 
> 1   ~1 GiB btrfs mounted at /boot
> 2   ~2 GiB LUKS (random key) with swap
> 3  ~10 GiB LUKS (passphrase) with btrfs mounted at /
> 
> 10 GiB root is enough for single-user Xfce workstation (my bulk data
> is on a file server).

I'm not an LVM user so I live with my partitioning for years.
I would opine that 10GiB is rather risky for a root partition
(with /home separate). My smallest root partition, on an old
laptop that I've been using since 2009, is 15GiB (74.5 GiB drive).

I'm not a DE user, which might reduce usage a little, but /usr
alone ranges from 8.4GiB (jessie on that laptop) to 10.2GiB
(wheezy, as it happens, on a desktop). That's without giving
any consideration to /var and /tmp.

> >Should i make a different partition for /home/ ?
> 
> I don't -- I put my bulk data on a file server, including all e-mail
> attachments.  My home directory is ~1 GB.
> 
> 
> (If/when I want to travel with my laptop, I will need to figure out
> how to set up a VPN to my file server.)

I would find that rather risky, so I have a "proper" separate,
encrypted /home that ranges from 50GiB (laptop) to ~400GiB
(desktops)—basically, the rest of the drive, though one laptop
gives a fair amount of space over to a W10 installation.

Bear in mind that were you to make your root far too large, it's easy
enough to borrow some space by symlinking to, say, /var/local/myname
(for unencrypted, less sensitive material).

Cheers,
David.

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

#197570

On 07/12/18 10:52, David Wright wrote:
> On Mon 09 Jul 2018 at 20:33:00 (-0700), David Christensen wrote:
>> On 07/09/18 11:17, Ge wrote:
>>> 1. Whats the appropriate layout?
>>> My current layout is:
>>>
>>> LVM VG Laptop-vg LV root 16.9GB Linux device mapper (linear)
>>> #1	16.9GB	f	btrfs	/
>>
>> I use 16 GiB SSD's and/or 16 GiB USB flash drives for system drives.
>> I wipe and test them using the manufacturer's diagnostic tool before
>> installing Debian, or just wipe them with dd(1) if I do not have a
>> tool.  In the Debian Installer, I choose 'manual' for 'partitioning
>> method', create a new partition table (MBR), and create three
>> primary partitions:
>>
>> 1   ~1 GiB btrfs mounted at /boot
>> 2   ~2 GiB LUKS (random key) with swap
>> 3  ~10 GiB LUKS (passphrase) with btrfs mounted at /
>>
>> 10 GiB root is enough for single-user Xfce workstation (my bulk data
>> is on a file server).
> 
> I'm not an LVM user so I live with my partitioning for years.
> I would opine that 10GiB is rather risky for a root partition
> (with /home separate). My smallest root partition, on an old
> laptop that I've been using since 2009, is 15GiB (74.5 GiB drive).
> 
> I'm not a DE user, which might reduce usage a little, but /usr
> alone ranges from 8.4GiB (jessie on that laptop) to 10.2GiB
> (wheezy, as it happens, on a desktop). That's without giving
> any consideration to /var and /tmp.

I have been reading Evi Nemeth, et al, 2018, "Unix and Linux System 
Administration Handbook", 5 e..  The authors make the point that cloud 
servers should be treated like cattle, not like pets -- e.g. when pets 
are sick, you expend resources trying to heal them; when cattle are 
sick, you shoot them [p. 272, fifth paragraph].


While a brutal analogy, it makes a point that can be applied to all 
computers -- devise strategies, invest in resources, and implement 
procedures that facilitate system roll-out, migration, and disaster 
recovery.  This is a goal I have pursued over the years.


When "apt-get update" broke networking on my primary desktop instance 
about two months ago, it took me perhaps two hours to confirm that 
networking was broken, to search for and to not find an easy fix, to 
migrate my Thunderbird profile to another computer (all other data and 
configuration settings were on the file/CVS server or in the cloud), and 
to reconfigure the backup/ archive server.


>>> Should i make a different partition for /home/ ?
>>
>> I don't -- I put my bulk data on a file server, including all e-mail
>> attachments.  My home directory is ~1 GB.
>>
>>
>> (If/when I want to travel with my laptop, I will need to figure out
>> how to set up a VPN to my file server.)
> 
> I would find that rather risky, so I have a "proper" separate,
> encrypted /home that ranges from 50GiB (laptop) to ~400GiB
> (desktops)—basically, the rest of the drive, though one laptop
> gives a fair amount of space over to a W10 installation.

First, I will need to test how the applications I use react to VPN 
connections going up and down.


My file server is also a CVS server.  This makes it easy to keep the 
same files on multiple computers, and to synchronize changes.  (CVS can 
solve the three-way merge problem for text files.  I need to be mindful 
when editing binary files.)


David

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

#197572

On Thu, Jul 12, 2018 at 07:53:01PM -0700, David Christensen wrote:
> 
> I have been reading Evi Nemeth, et al, 2018, "Unix and Linux System
> Administration Handbook", 5 e..  The authors make the point that cloud
> servers should be treated like cattle, not like pets -- e.g. when pets are
> sick, you expend resources trying to heal them; when cattle are sick, you
> shoot them [p. 272, fifth paragraph].

This is because you have many cattle doing the same things for
you, whereas you have a unique relationship with each pet.

So if you have three or thirty web servers handling the same
application, you can shoot and replace one with minimal impact;
if you have one database server, you had better treat it well.

Both cattle and pets continue to exist, because they serve
different needs. The tools that enable cattle can allow you to 
heal or resurrect a pet, but at a higher upfront cost.

-dsr-

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web