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

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

virtualisation

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  virtualisation "mick.crane" <mick.crane@gmail.com> - 2023-05-22 20:50 +0200
    Re: virtualisation Dan Ritter <dsr@randomstring.org> - 2023-05-22 21:30 +0200
      Re: virtualisation Mark Allums <maa@allums.com> - 2023-05-22 21:40 +0200
        Re: virtualisation "Andrew M.A. Cater" <amacater@einval.com> - 2023-05-22 21:50 +0200
      Re: virtualisation Dan Ritter <dsr@randomstring.org> - 2023-05-22 22:40 +0200
    Re: virtualisation David Christensen <dpchrist@holgerdanske.com> - 2023-05-23 00:20 +0200
      Re: virtualisation Charles Curley <charlescurley@charlescurley.com> - 2023-05-23 15:10 +0200
      Re: virtualisation David Christensen <dpchrist@holgerdanske.com> - 2023-05-24 00:10 +0200
        Re: virtualisation David Christensen <dpchrist@holgerdanske.com> - 2023-05-24 10:40 +0200
          Re: virtualisation David Christensen <dpchrist@holgerdanske.com> - 2023-05-24 20:50 +0200
        Re: virtualisation Michael <ml@hemathor.de> - 2023-05-26 10:20 +0200
          GPT backup table, was Re: virtualisation "Thomas Schmitt" <scdbackup@gmx.net> - 2023-05-26 11:50 +0200
            Re: GPT backup table, was Re: virtualisation David Christensen <dpchrist@holgerdanske.com> - 2023-05-26 12:50 +0200
            Re: GPT backup table, was Re: virtualisation Michael <ml@hemathor.de> - 2023-05-27 11:40 +0200
              Re: GPT backup table, was Re: virtualisation Dan Ritter <dsr@randomstring.org> - 2023-05-27 17:50 +0200
              Re: GPT backup table, was Re: virtualisation David Christensen <dpchrist@holgerdanske.com> - 2023-05-28 05:20 +0200
            Re: GPT backup table, was Re: virtualisation zithro <slack@rabbit.lu> - 2023-05-27 19:20 +0200
              Re: GPT backup table, was Re: virtualisation Stefan Monnier <monnier@iro.umontreal.ca> - 2023-05-27 20:00 +0200
          Re: virtualisation David Christensen <dpchrist@holgerdanske.com> - 2023-05-26 12:40 +0200
      Re: virtualisation Max Nikulin <manikulin@gmail.com> - 2023-05-25 18:30 +0200

#258610 — virtualisation

This is a request for best practice, perceived knowledge.
For one reason and another this PC/Workstation (what is the difference?)
boots in legacy mode. It was something to do with the SS usb port not 
booting the installer in EFI mode.
I forget exactly.
Anyway, it's a niggle that it is legacy mode and changing a working 
system seems a palaver.
As I have the /home stuff all being/copied onto another disk I thought 
I'd reinstall and try to get it tidy.
I thought to try this virtualisation.
Q1. Would openbox be the one to go for?
Things I use work happily on Bookworm but seems openbox is only 
available in Sid for now.
Should I try to build openbox or try to get it from Sid if OpenBox is 
what I want?
I have purchased 64Gb of this DIMM memory for the experimentation.

mick

[toc] | [next] | [standalone]

#258612

mick.crane wrote: 
> This is a request for best practice, perceived knowledge.
> For one reason and another this PC/Workstation (what is the difference?)
> boots in legacy mode. It was something to do with the SS usb port not
> booting the installer in EFI mode.
> I forget exactly.
> Anyway, it's a niggle that it is legacy mode and changing a working system
> seems a palaver.
> As I have the /home stuff all being/copied onto another disk I thought I'd
> reinstall and try to get it tidy.
> I thought to try this virtualisation.
> Q1. Would openbox be the one to go for?
> Things I use work happily on Bookworm but seems openbox is only available in
> Sid for now.
> Should I try to build openbox or try to get it from Sid if OpenBox is what I
> want?
> I have purchased 64Gb of this DIMM memory for the experimentation.

Openbox is a window manager.

You probably mean VirtualBox, and the answer is no.

Try KVM/QEMU, which is available via the libvirt tools; the
primary graphical interface is virt-manager, and the primary CLI
is virsh.

-dsr-

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

#258613

On 5/22/2023 2:10 PM, Dan Ritter wrote:
> mick.crane wrote:
>> This is a request for best practice, perceived knowledge.
>> For one reason and another this PC/Workstation (what is the difference?)
>> boots in legacy mode. It was something to do with the SS usb port not
>> booting the installer in EFI mode.
>> I forget exactly.
>> Anyway, it's a niggle that it is legacy mode and changing a working system
>> seems a palaver.
>> As I have the /home stuff all being/copied onto another disk I thought I'd
>> reinstall and try to get it tidy.
>> I thought to try this virtualisation.
>> Q1. Would openbox be the one to go for?
>> Things I use work happily on Bookworm but seems openbox is only available in
>> Sid for now.
>> Should I try to build openbox or try to get it from Sid if OpenBox is what I
>> want?
>> I have purchased 64Gb of this DIMM memory for the experimentation.
> Openbox is a window manager.
>
> You probably mean VirtualBox, and the answer is no.

Why is VirtualBox a no?  I use it; it works  fine.


> Try KVM/QEMU, which is available via the libvirt tools; the
> primary graphical interface is virt-manager, and the primary CLI
> is virsh.
>
> -dsr-
>
Marl Allums

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

#258614

On Mon, May 22, 2023 at 02:35:52PM -0500, Mark Allums wrote:
> On 5/22/2023 2:10 PM, Dan Ritter wrote:
> > mick.crane wrote:
> > > This is a request for best practice, perceived knowledge.
> > > For one reason and another this PC/Workstation (what is the difference?)
> > > boots in legacy mode. It was something to do with the SS usb port not
> > > booting the installer in EFI mode.
> > > I forget exactly.
> > > Anyway, it's a niggle that it is legacy mode and changing a working system
> > > seems a palaver.
> > > As I have the /home stuff all being/copied onto another disk I thought I'd
> > > reinstall and try to get it tidy.
> > > I thought to try this virtualisation.
> > > Q1. Would openbox be the one to go for?
> > > Things I use work happily on Bookworm but seems openbox is only available in
> > > Sid for now.
> > > Should I try to build openbox or try to get it from Sid if OpenBox is what I
> > > want?
> > > I have purchased 64Gb of this DIMM memory for the experimentation.
> > Openbox is a window manager.
> > 
> > You probably mean VirtualBox, and the answer is no.
> 
> Why is VirtualBox a no?  I use it; it works  fine.
> 

Virtualbox is a no because of the security policy for bugfixes from Oracle.
This is the reason that it was removed from Debian stable and testing.

The virtualbox guest additions (if used) are also distributable but can
only be used subject to a personal licence acceptance.

KVM and virt-manager are assuredly a good and easy way to go.

All the very best, as ever,

Andy Cater
> 
> > Try KVM/QEMU, which is available via the libvirt tools; the
> > primary graphical interface is virt-manager, and the primary CLI
> > is virsh.
> > 
> > -dsr-
> > 
> Marl Allums
> 
> 

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

#258616

mick.crane wrote: 
> On 2023-05-22 20:10, Dan Ritter wrote:
> > mick.crane wrote:
> > > This is a request for best practice, perceived knowledge.
> > Try KVM/QEMU, which is available via the libvirt tools; the
> > primary graphical interface is virt-manager, and the primary CLI
> > is virsh.
> > 
> > -dsr-
> 
> This is like a "container" using the kernel from debian installation ?


Let's look at the landscape of partitioning, from least
separated to most.

a program running as root
a program running as a shared user
a program that starts as root and then drops capabilities to run
  as a dedicated user
a program running as a dedicated user
a program running as a dedicated user in a chroot jail
a program running in a container [uses the kernel namespaces
  feature to keep separation for filesystem, network access,
  CPUs]
a program running in a paravirtualized machine [OS calls are
  wrapped and passed through]
a program running in an emulated machine [everything is
  emulated]

libvirt can manage containers, paravirtualized machines, and
emulated machines. KVM/QEMU can handle the latter two.

-dsr-

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

#258617

On 5/22/23 11:43, mick.crane wrote:
> This is a request for best practice, perceived knowledge.
> For one reason and another this PC/Workstation (what is the difference?)
> boots in legacy mode. It was something to do with the SS usb port not 
> booting the installer in EFI mode.
> I forget exactly.
> Anyway, it's a niggle that it is legacy mode and changing a working 
> system seems a palaver.
> As I have the /home stuff all being/copied onto another disk I thought 
> I'd reinstall and try to get it tidy.


Why do you think legacy mode is untidy?


I do not use multi-boot; I install mobile racks in my computers and put 
each OS instance on its own drive.  This allows me to use BIOS/ MBR/ 
legacy mode, which is simpler to install and simpler to image/ clone:

1.  No UEFI boot variables/entries to create; BIOS/MBR detects devices 
connected to interfaces and I use Setup to set the boot order.  (I also 
set "Boot USB Devices First", so I can boot a live USB stick without 
having to touch Setup.)  In UEFI mode, I must use Setup to create a boot 
table entry that includes the correct bootloader file in the correct 
ESP.  Once I have a correct UEFI boot entry, then I can set the boot 
order.  These UEFI steps are inobvious if you have never heard of them, 
and there is more than one way to screw it up (pick the wrong ESP or 
wrong bootloader file).

2.  No ESP confusion.  I attempted to create a Debian bootable USB stick 
using d-i in "Install" mode on a computer with an NVMe drive and Windows 
10.  d-i did not ask me where to put GRUB; d-i automatically added 
entries into the ESP on the NVMe drive (!).  This made the USB flash 
drive unbootable in any other computer and made the boot table entry 
useless whenever the USB stick was not connected.

3.  No GPT secondary partition table.  I install BIOS/ MBR with a 1 GB 
boot partition, 1 GB encrypted swap partition, and 13 GB encrypted root 
partition.  Once I have Debian installed on a 16+ GB HDD, SSD, or USB 
flash drive, I can boot alternate media and copy the system drive from 
LBA 0 through the end of the root partition to a file on a USB HDD.  I 
can later reverse the process onto the same system device or onto any 
other 16+ GB device, and the restored Debian instance "just works". 
With GPT, there is a secondary/ backup partition table located at the 
end of the device.  This forces you into to less flexible imaging 
choices: copy the entire device and restore onto a device of exactly the 
same size, copy the entire device and fix the GPT secondary table after 
restoring onto a device of different size, copy from LBA 0 to the end of 
the root partition then add a GPT table after restore, copy LBA 0 
through the end of root in one piece, copy the GPT secondary table in 
another piece, restore the first piece, do the math, and restore the 
second piece, etc..


> I thought to try this virtualisation.


Why?


> Q1. Would openbox be the one to go for?
> Things I use work happily on Bookworm but seems openbox is only 
> available in Sid for now.
> Should I try to build openbox or try to get it from Sid if OpenBox is 
> what I want?
> I have purchased 64Gb of this DIMM memory for the experimentation.
> 
> mick


https://en.wikipedia.org/wiki/XY_problem


David

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

#258641

On Tue, 23 May 2023 11:33:56 +0100
"mick.crane" <mick.crane@gmail.com> wrote:

> On 2023-05-22 23:18, David Christensen wrote:
>  [...]  
>  [...]  
>  [...]  
> I had previously installed Ubuntu on this disk,
> after installing Bookworm the Ubuntu EFI option in the BIOS was still 
> there.
> I removed it in the BIOS menu. There was some message in the boot
> screen in legacy mode
> "Alternate (partition?) corrupted using primary" or something.
> It doesn't seem to have stopped anything working.
> 
> root@pumpkin:~# fdisk -l /dev/sda
> Disk /dev/sda: 223.57 GiB, 240057409536 bytes, 468862128 sectors
> Disk model: KINGSTON SA400S3
> 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: dos
> Disk identifier: 0x7899140a
> 
> Device     Boot     Start       End   Sectors   Size Id Type
> /dev/sda1  *         2048 466862079 466860032 222.6G 83 Linux
> /dev/sda2       466864126 468860927   1996802   975M  5 Extended
> /dev/sda5       466864128 468860927   1996800   975M 82 Linux swap / 
> Solaris
> root@pumpkin:~#
> 
> boot is in /
> Is sda2 something to do with EFI?

No. Wikipedia is your friend.
https://en.wikipedia.org/wiki/Extended_boot_record


> 
> >   
> >> I thought to try this virtualisation.  
> > 
> > 
> > Why?  
> 
> I thought maybe I could run a Windows program in a window on Debian 
> desktop.

You might look into wine as well.

apt show wine

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#258649

On 5/23/23 03:33, mick.crane wrote:
> On 2023-05-22 23:18, David Christensen wrote:
>> On 5/22/23 11:43, mick.crane wrote:
>>> This is a request for best practice, perceived knowledge.
>>> For one reason and another this PC/Workstation (what is the difference?)
>>> boots in legacy mode. It was something to do with the SS usb port not 
>>> booting the installer in EFI mode.
>>> I forget exactly.
>>> Anyway, it's a niggle that it is legacy mode and changing a working 
>>> system seems a palaver.
>>> As I have the /home stuff all being/copied onto another disk I 
>>> thought I'd reinstall and try to get it tidy.
>>
>>
>> Why do you think legacy mode is untidy?
>>
> I had previously installed Ubuntu on this disk,
> after installing Bookworm the Ubuntu EFI option in the BIOS was still 
> there.
> I removed it in the BIOS menu. 


https://en.wikipedia.org/wiki/Nonvolatile_BIOS_memory

https://en.wikipedia.org/wiki/UEFI#Booting


Removing obsolete UEFI NVRAM boot table entries is good housekeeping.


> There was some message in the boot screen 
> in legacy mode
> "Alternate (partition?) corrupted using primary" or something.
> It doesn't seem to have stopped anything working.


https://en.wikipedia.org/wiki/GUID_Partition_Table


Did you zero your drive prior to installing Debian?  Perhaps there is a 
leftover GPT secondary partition table on disk.  See below.


> root@pumpkin:~# fdisk -l /dev/sda
> Disk /dev/sda: 223.57 GiB, 240057409536 bytes, 468862128 sectors
> Disk model: KINGSTON SA400S3
> 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: dos
> Disk identifier: 0x7899140a
> 
> Device     Boot     Start       End   Sectors   Size Id Type
> /dev/sda1  *         2048 466862079 466860032 222.6G 83 Linux
> /dev/sda2       466864126 468860927   1996802   975M  5 Extended
> /dev/sda5       466864128 468860927   1996800   975M 82 Linux swap / 
> Solaris
> root@pumpkin:~#
> 
> boot is in /
> Is sda2 something to do with EFI?


https://en.wikipedia.org/wiki/Master_boot_record

https://en.wikipedia.org/wiki/Extended_partition


sda1 is an MBR primary partition.

sda2 is an MBR extended partition.

sda5 is a partition within sda2.


Your disk has 468862128 sectors.  A GPT secondary partition table should 
start 33 sectors before the end of the disk:

468862128 - 33 = 468862095

Run the following command to see if there is a GPT secondary partition 
table on your disk:

# dd bs=512 count=33 if=/dev/sda skip=468862095 | hexdump -C


>>> I thought to try this virtualisation.
>>
>> Why?
> 
> I thought maybe I could run a Windows program in a window on Debian 
> desktop.


You have several choices:

https://wiki.debian.org/RunningWindowsPrograms


That said, running Windows directly on hardware is the KISS solution and 
should provide the best usage experience.  Prices on used computers are 
very good right now.


David

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

#258654

On 5/23/23 20:35, mick.crane wrote:

> root@pumpkin:/home/mick# dd bs=512 count=33 if=/dev/sda skip=468862095 | 
> hexdump -C >dump.txt
> 33+0 records in
> 33+0 records out
> 16896 bytes (17 kB, 16 KiB) copied, 0.0114308 s, 1.5 MB/s
> root@pumpkin:/home/mick# nano dump.txt
> 00000000  d0 80 47 bf 2b 38 99 33  54 ee ec 10 02 26 2a 11 
> |..G.+8.3T....&*.|
> 00000010  8b f6 af 00 1e a7 6f 28  22 63 84 18 3b 60 5b fb 
> |......o("c..;`[.|
> ..........
> 000041e0  19 d0 6a 27 a9 7e e9 e0  21 24 82 de 64 66 58 41 
> |..j'.~..!$..dfXA|
> 000041f0  7d 12 94 8f f4 f3 a0 3a  f1 4a b9 53 fb ac 8d 6e 
> |}......:.J.S...n|
> 00004200


The sectors are outside the range of partition sda5.  In an ideal 
BIOS-MBR configuration, they should be zeroed.  The fact that they are 
not means something set them, but it has hard to tell from that limited 
output if those bytes correspond to a secondary GPT partition table, 
encrypted file system leftovers, or something else.


The first 16 bytes of the secondary GPT header in the last block are the 
best clue -- they contain an signature, a revision, and a header size:

https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_table_header_(LBA_1)


My UEFI-GPT machine matches the WikiPedia specification exactly:

2023-05-24 01:09:37 root@taz ~
# dd bs=512 count=1 if=/dev/sda skip=117231407 status=none | hexdump -C 
| head -n 1
00000000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI 
PART....\...|


Try this command on your machine:

468862128 - 1 = 468862127

# dd bs=512 count=1 if=/dev/sda skip=468862127 status=none | hexdump -C 
| head -n 1


David

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

#258664

On 5/24/23 02:45, mick.crane wrote:
> On 2023-05-24 09:29, David Christensen wrote:
> 
>> Try this command on your machine:
>>
>> 468862128 - 1 = 468862127
>>
>> # dd bs=512 count=1 if=/dev/sda skip=468862127 status=none | hexdump
>> -C | head -n 1
> 
> root@pumpkin:/home/mick# dd bs=512 count=1 if=/dev/sda skip=468862127 
> status=none | hexdump -C | head -n 1
> 00000000  c1 1a 12 6b 70 45 54 83  2e f4 b0 a3 24 17 53 5c 
> |...kpET.....$.S\|
> root@pumpkin:/home/mick#


So, your disk does not contain a valid secondary GPT header.  That 
explains the complaints about a corrupt secondary GPT partition table.


At this point, options include:

1.  Ignore it.

2.  Zero-fill the last 33 sectors of the disk.

3.  Zero-fill all the sectors after sda5.


This topic was a tangent off your OP.  Are there any remaining issues 
that you wish to discuss?


David

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

#258680

On Tuesday, 23 May 2023 23:59:41 CEST, David Christensen wrote:
> On 5/23/23 03:33, mick.crane wrote:
> [...]
>> root@pumpkin:~# fdisk -l /dev/sda
>> Disk /dev/sda: 223.57 GiB, 240057409536 bytes, 468862128 sectors
>> Disk model: KINGSTON SA400S3
>> 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: dos
>> Disk identifier: 0x7899140a

as i interpret this, the disk in questions has a dos partition table...


> Your disk has 468862128 sectors.  A GPT secondary partition 
> table should start 33 sectors before the end of the disk:

on a disk with a gpt partition table, yes.


maybe i am missing something. if so, please enlighten me!

greetings...

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

#258683 — GPT backup table, was Re: virtualisation

Hi,

mick.crane wrote:
> > > root@pumpkin:~# fdisk -l /dev/sda
> > > Disk /dev/sda: 223.57 GiB, 240057409536 bytes, 468862128 sectors
> > > ...
> > > Disklabel type: dos
> > > ...
> > > Device     Boot     Start       End   Sectors   Size Id Type
> > > /dev/sda1  *         2048 466862079 466860032 222.6G 83 Linux
> > > /dev/sda2       466864126 468860927   1996802   975M  5 Extended
> > > /dev/sda5       466864128 468860927   1996800   975M 82 Linux swap / Solaris

Michael wrote:
> as i interpret this, the disk in questions has a dos partition table...

Indeed.

(And as mick.crane already noticed, it is a bit awkward to create an
extended partiton 2 only to fill it nearly up with logical partition 5.
I wonder what entity decided to do so.)


David Christensen wrote:
> > Did you zero your drive prior to installing Debian? Perhaps there
> > is a leftover GPT secondary partition table on disk. See below.

> on a disk with a gpt partition table, yes.
> maybe i am missing something. if so, please enlighten me!

A remnant backup GPT is a typical risk of repartitioning a USB stick
from GPT to MBR Partition Table. Such repartitioning happens e.g. if you
put a Debian installation or Live ISO onto a previously GPT partitioned
stick.
(xorriso-dd-target zeros the last block of the target stick in order to
prevent partition editors from re-creating the previous GPT partitioning.)


> > Your disk has 468862128 sectors. A GPT secondary partition table
> >  should start 33 sectors before the end of the disk:

Here i disagree. The size of the GPT partition array is adjustable.

32 blocks of 4 entries each is a usual size. But actually you have to
read from the GPT header block the 4 bytes beginning at offset 80 as
little-endian number to get the number of array blocks (by dividing by 4).
The start block of the partition array is adjustable, too: Offset 72,
8 bytes as 64-bit little-endian number.

The position of the GPT header is always 512-byte block 1 for the primary
partition table and the last valid block address of the device for the
backup table.

Specs for GPT are part of the UEFI specs. Current is:
  https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html
(I myself am still reading version 2.6 ...)


> > Run the following command to see if there is a GPT secondary partition
> > table on your disk:
> > # dd bs=512 count=33 if=/dev/sda skip=468862095 | hexdump -C

So i would rather propose to inspect the last block, whether it begins
by the bytes "EFI PART\000\000\001\000" (meaning GPT version 1.0):

  dd bs=512 count=1 if=/dev/sda skip=468862127 | hexdump -C


Have a nice day :)

Thomas

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

#258686 — Re: GPT backup table, was Re: virtualisation

On 5/26/23 02:47, Thomas Schmitt wrote:
 >>On 5/23/23 14:59, David Christensen wrote:
>>> Your disk has 468862128 sectors. A GPT secondary partition table
>>>   should start 33 sectors before the end of the disk:
> 
> Here i disagree. The size of the GPT partition array is adjustable.
> 
> 32 blocks of 4 entries each is a usual size. But actually you have to
> read from the GPT header block the 4 bytes beginning at offset 80 as
> little-endian number to get the number of array blocks (by dividing by 4).
> The start block of the partition array is adjustable, too: Offset 72,
> 8 bytes as 64-bit little-endian number.
> 
> The position of the GPT header is always 512-byte block 1 for the primary
> partition table and the last valid block address of the device for the
> backup table.
> 
> Specs for GPT are part of the UEFI specs. Current is:
>    https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html
> (I myself am still reading version 2.6 ...)


Thank you for the clarification and the citation.  :-)


David

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

#258711 — Re: GPT backup table, was Re: virtualisation

On Friday, 26 May 2023 11:47:04 CEST, Thomas Schmitt wrote:
> (And as mick.crane already noticed, it is a bit awkward to create an
> extended partiton 2 only to fill it nearly up with logical partition 5.
> I wonder what entity decided to do so.)

on my debian 11 test vm with default installation it is exactly the same:

root@debian11test:~# fdisk -l /dev/sda
Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Disk model: VBOX HARDDISK   
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: dos
Disk identifier: 0x2e739d33

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1  *        2048 39942143 39940096   19G 83 Linux
/dev/sda2       39944190 41940991  1996802  975M  5 Extended
/dev/sda5       39944192 41940991  1996800  975M 82 Linux swap / Solaris

greetings...

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

#258715 — Re: GPT backup table, was Re: virtualisation

mick.crane wrote: 
> 
> I just installed bookworm on another SSD disk.
> The installer said it was going to partition the disk one for the / and
> another for swap
> After the installation the extended partition was there.
> Is this some attribute of pre formatted SSDs


Nah, this is just the default. Run the partitioner yourself, get
it to happen the way you want it to be.

-dsr-

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

#258728 — Re: GPT backup table, was Re: virtualisation

On 5/27/23 07:42, mick.crane wrote:
> On 2023-05-27 10:33, Michael wrote:
>> On Friday, 26 May 2023 11:47:04 CEST, Thomas Schmitt wrote:
>>> (And as mick.crane already noticed, it is a bit awkward to create an
>>> extended partiton 2 only to fill it nearly up with logical partition 5.
>>> I wonder what entity decided to do so.)
>>
>> on my debian 11 test vm with default installation it is exactly the same:
>>
>> root@debian11test:~# fdisk -l /dev/sda
>> Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
>> Disk model: VBOX HARDDISK   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: dos
>> Disk identifier: 0x2e739d33
>>
>> Device     Boot    Start      End  Sectors  Size Id Type
>> /dev/sda1  *        2048 39942143 39940096   19G 83 Linux
>> /dev/sda2       39944190 41940991  1996802  975M  5 Extended
>> /dev/sda5       39944192 41940991  1996800  975M 82 Linux swap / Solaris
>>
>> greetings...
> 
> I just installed bookworm on another SSD disk.
> The installer said it was going to partition the disk one for the / and 
> another for swap
> After the installation the extended partition was there.


That sounds like d-i did what you told it to do:

https://www.debian.org/releases/stable/amd64/ch06s03.en.html#di-partition

6.3.4.2. Guided Partitioning

All files in one partition


> Is this some attribute of pre formatted SSDs


Unlikely.


> I didn't zero the disk as my old systemrescueCD CD failed to 
> successfully boot.
> I'll get a more recent copy.
> mick
> 


d-i includes a rescue shell.  You can use dd(1) to zero disks.


David

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

#258716 — Re: GPT backup table, was Re: virtualisation

On 26 May 2023 11:47, Thomas Schmitt wrote:
> Hi,
> 
> mick.crane wrote:
>>>> root@pumpkin:~# fdisk -l /dev/sda
>>>> Disk /dev/sda: 223.57 GiB, 240057409536 bytes, 468862128 sectors
>>>> ...
>>>> Disklabel type: dos
>>>> ...
>>>> Device     Boot     Start       End   Sectors   Size Id Type
>>>> /dev/sda1  *         2048 466862079 466860032 222.6G 83 Linux
>>>> /dev/sda2       466864126 468860927   1996802   975M  5 Extended
>>>> /dev/sda5       466864128 468860927   1996800   975M 82 Linux swap / Solaris
> 
> Michael wrote:
>> as i interpret this, the disk in questions has a dos partition table...
> 
> Indeed.
> 
> (And as mick.crane already noticed, it is a bit awkward to create an
> extended partiton 2 only to fill it nearly up with logical partition 5.
> I wonder what entity decided to do so.)

IIRC, DOS types are limited to 4 "primary" partitions (or 2 ?), but 
extended partitions have no such limit, and can contain any number of 
others.

Back in the (DOS/w95) days, you would usually create one primary and one 
extended, and populate the extended with as many partitions as you want.
This way was used to avoid making mistakes : how many primary partitions 
do I have in the "root" table ?

It's from memory, so 30 years old ^^

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

#258718 — Re: GPT backup table, was Re: virtualisation

> Back in the (DOS/w95) days, you would usually create one primary and one
> extended, and populate the extended with as many partitions as you want.

IIRC the reason why there was still that one primary was that you could
only boot to a primary partition.

BTW, I don't use extended partitions any more, but I reproduce the above
structure because I typically have one smallish [the 500MB HDDs of our
64bit DEC Alpha workstations felt quite spacious back then]
partition for /boot and a second for LVM  :-)


        Stefan

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

#258685

On 5/26/23 01:08, Michael wrote:
> On Tuesday, 23 May 2023 23:59:41 CEST, David Christensen wrote:
>> On 5/23/23 03:33, mick.crane wrote:
>> [...]
>>> root@pumpkin:~# fdisk -l /dev/sda
>>> Disk /dev/sda: 223.57 GiB, 240057409536 bytes, 468862128 sectors
>>> Disk model: KINGSTON SA400S3
>>> 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: dos
>>> Disk identifier: 0x7899140a
> 
> as i interpret this, the disk in questions has a dos partition table...


Agreed.


>> Your disk has 468862128 sectors.  A GPT secondary partition table 
>> should start 33 sectors before the end of the disk:
> 
> on a disk with a gpt partition table, yes.


Agreed.


> maybe i am missing something. if so, please enlighten me!
> 
> greetings...


The OP reported error messages regarding a corrupt secondary GPT table. 
So, we went looking for a secondary GPT table.  What we found appears to 
be leftovers from some previous layout.


Zeroing disks before setting them up prevents this kind of confusion 
(and reduces the size of compressed images).


David

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

#258672

On 23/05/2023 05:18, David Christensen wrote:
> 1.  No UEFI boot variables/entries to create; BIOS/MBR detects devices 
> connected to interfaces and I use Setup to set the boot order.  (I also 
> set "Boot USB Devices First", so I can boot a live USB stick without 
> having to touch Setup.)

There is no problem to boot usual live images that have single FAT 
partition. Removable disk layout is used in this case 
EFI/BOOT/BOOTX64.efi (on amd64). It should be possible to enable USB 
boot and increase its priority from firmware setup. It might be 
implemented as modifying NVRAM to add a boot entry and to modify UEFI 
boot order.

I have never tried to make a portable installation. Even if specific 
UEFI implementation ignores removable path on EFI System Partition, I 
would try to make a first FAT partition that is not ESP with signed shim 
as EFI/BOOT/BOOTX64.efi

> With 
> GPT, there is a secondary/ backup partition table located at the end of 
> the device.  This forces you into to less flexible imaging choices:

I expect that --backup, --restore-backup, and --move-second-header 
options of sgdisk may help.

[toc] | [prev] | [standalone]

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

csiph-web