Hi,
Max Nikulin wrote:
> I was not aware that partition type might be an issue.
Thanks to the normative power of the facts a "may" in the specs becomes
a reason to return a mainboard with an EFI that chooses to join the
"may not" side.
Have a nice day :)
Thomas
On 25/04/2024 13:51, Thomas Schmitt wrote:
Max Nikulin wrote:
"12.3.3 Number and Location of System Partitions
... Further, UEFI implementations may allow the use of conforming FAT
partitions which do not use the ESP GUID."
Another problem with the statement is that it only talks of GUID and
Hi,
i wrote:
> > It is disputed, whether the specs say that the partitions must be marked
> > by 0xEF in legacy MBR tables and by C12A7328-F81F-11D2-BA4B-00A0C93EC93B
> > in GPT.
Max Nikulin wrote:
> It happened so that I had locally a file with UEFI spec Version 2.3.1,
> Errata C June 27, 2012.
On 23/04/2024 13:21, Thomas Schmitt wrote:
Max Nikulin wrote:
Out of curiosity, does the requirement of specific GUID exist for removable
drives?
It is disputed, whether the specs say that the partitions must be marked
by 0xEF in legacy MBR tables and by C12A7328-F81F-11D2-BA4B-00A0C93EC93B
El 23/4/24 a las 8:21, Thomas Schmitt escribió:
(I still wonder which software in the Debian ISO needs the symbolic link
"/debian -> ." and which parts of the file tree are accessed via this
link. Probably one can avoid to duplicate the whole tree under /debian.)
Hello:
I have copied the
Hi,
Max Nikulin wrote:
> Out of curiosity, does the requirement of specific GUID exist for removable
> drives?
It is disputed, whether the specs say that the partitions must be marked
by 0xEF in legacy MBR tables and by C12A7328-F81F-11D2-BA4B-00A0C93EC93B
in GPT.
In practice there seems to be
On 23/04/2024 00:49, Thomas Schmitt wrote:
This aims at an undocumented habit of EFI implementations to look in
any FAT filesystem for a \EFI\BOOT directory with a suitable BOOT*.EFI
file and to start it, if found.
(Officially documented is to look in FAT filesystems of partitions with
MBR type
Hi,
Luis Muñoz Fuente wrote:
> I assume the problem is the debian link, which points to the same directory:
> $ ls -l tmp/debian
> lrwxrwxrwx 1 user user 1 Apr 22 20:47 tmp/debian -> .
> and creates a loop,
That's not a link loop, because "." is not a symbolic link.
But if a tree traversal is
I assume the problem is the debian link, which points to the same directory:
$ ls -l tmp/debian
lrwxrwxrwx 1 user user 1 Apr 22 20:47 tmp/debian -> .
and creates a loop, I guess that's also why if I compress with:
zip -r debian.zip tmp
It never ends but from the graphical environment it does
El 22/4/24 a las 20:25, Thomas Schmitt escribió:
Hard to say if you do not show what you do in particular.
Yes, sorry.
$ du debian-12.5.0-amd64-netinst.iso
644100 debian-12.5.0-amd64-netinst.iso
# mount debian-12.5.0-amd64-netinst.iso /mnt
mount: /mnt: ATENCIÓN: el dispositivo está
Hi,
Luis Muñoz Fuente wrote:
> why does extracting the files from the debian iso increase the
> size so much?
Hard to say if you do not show what you do in particular.
In general an increase of about 120 MB is to be expected because of
expansion of hardlinks:
$ du
El 22/4/24 a las 19:49, Thomas Schmitt escribió:
Hi,
Thanks for the reply. My question is rather why the size increases so
much. When I take a folder that occupies 5 GiB and with mkisofs I create
an iso file, it still occupies 5 GiB. And if I later extract the files
it takes up 5 GiB
Hi,
Luis Muñoz Fuente wrote:
> I recently used clonezilla and followed these instructions:
> https://clonezilla.org/liveusb.php#linux-setup
The variation for "uEFI", i assume.
This aims at an undocumented habit of EFI implementations to look in
any FAT filesystem for a \EFI\BOOT directory with
Hello:
I recently used clonezilla and followed these instructions:
https://clonezilla.org/liveusb.php#linux-setup
to create a bootable pendrive from a zip file. What I liked about this
method is that I can continue saving data on the pendrive and if I want
to delete clonezilla I just have
14 matches
Mail list logo
