Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Some of the parameters used in my genisoimage command don’t produce a bootable ISO image
1,409 views
Skip to first unread message
Mario Marietto
Oct 9, 2022, 3:40:06 PM10/9/22
to
Hello.
I'm trying to extract all the files from a (bootable) Debian ISO and then re-generate a bootable ISO image. Below you can see the commands that I've issued. For some unknown reason,the generated ISO image does not boot. Can someone help me to understand why ? thanks.
apt update && apt -y install xorriso genisoimage
wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.5.0-amd64-netinst.iso
xorriso -osirrox on -indev debian-11.5.0-amd64-netinst.iso -extract / isofiles/
genisoimage -r -J -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot
-boot-load-size 4 -boot-info-table -o debian-11-unattended.iso isofiles
As you can see I haven't done any modification to the files inside the ISO image,so the error should be most likely on the latest command.
According with this post :
I have also tried with this command :
mkisofs -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot
-boot-load-size 4 -boot-info-table -J -R -v -T -V 'd-live 11.5.0 xf amd64'
"isofiles/" > file.iso
but also in this case the ISO produced is not bootable : https://ibb.co/GstvTvR
I've omitted the parameter "-reproducible-date=20221009" because it hasn't been accepted. The error produced is : "genisoimage: Uh oh, I can't find the boot image 'producible-date=20221009' and the ISO produced is only 32k.
This is how is the internal structure of the debian ISO file produced by the command above :
# isoinfo -d -i debian-11-unattended.iso
CD-ROM is in ISO 9660 format
System id: LINUX
Volume id: d-live 11.5.0 xf amd64
Volume set id:
Publisher id:
Data preparer id:
Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 224756
El Torito VD version 1 found, boot catalog is in sector 1020
Joliet with UCS level 3 found
Rock Ridge signatures version 1 found
Eltorito validation header:
Hid 1
Arch 0 (x86)
ID ''
Key 55 AA
Eltorito defaultboot header:
Bootid 88 (bootable)
Boot media 0 (No Emulation Boot)
Load segment 0
Sys type 0
Nsect 4
Bootoff 3FD 1021
You can also give a look at this full log,maybe you find the reason of the failure :
I guess the error could be :
xorriso : NOTE : Detected El-Torito boot information which currently is set to
be discarded"
but I don't know,really. Im dealing with this error from 1 week,I have asked help
in a lot of places,but no one really understood why. I hope you can.
Mario.
Thomas Schmitt
Oct 9, 2022, 4:20:05 PM10/9/22
to
Hi,
i already saw your questions in the web and wrote on
https://ubuntuforums.org/showthread.php?t=2479825&p=14115063#post14115063
-------------------------------------------------------------------------
Your genisoimage run does not produce boot lures for EFI which would lead
to GRUB, but only boot lures for legacy BIOS which would lead to ISOLINUX.
So the fact that you see in
https://ibb.co/GstvTvR
a GRUB prompt indicates that this GRUB stems from some other storage medium.
(Shown on https://askubuntu.com/questions/1434549 which is cumbersome for
me to participate.)
Is your QEMU/KVM running with EFI as firmware (OVMF) ? If so, try to get
it started with legacy BIOS (SeaBIOS) and with the ISO as virtual CD-ROM.
For a still valid proposal to repack a Debian amd64 bootable ISO for EFI
and BIOS from CD and USB stick see:
https://wiki.debian.org/RepackBootableISO#Determine_those_options_which_need_to_be_adapted_on_amd64_or_i386
-------------------------------------------------------------------------
> I guess the error could be :
> xorriso : NOTE : Detected El-Torito boot information which currently is set to
> be discarded"
That's from the osirrox extraction run. Since no ISO got written by
this program run, the message is of no importance.
> I have asked help
> in a lot of places,but no one really understood why.
Let's see how far we get together. :))
Try the proposals about booting via legacy BIOS and/or equipping the ISO
by the full BIOS+EFI+CD+USB-Stick stuff as in
https://wiki.debian.org/RepackBootableISO
Then there would be the modernish way of
xorriso -indev debian-11.5.0-amd64-netinst.iso \
-outdev debian-11-unattended.iso \
... xorriso image manipulation commands like -map, -rm, -mv ... \
-boot_image any replay
No unpacking of the original ISO is needed. (Your xorriso 1.5.4 is young
enough to cope even with the new layouts of Ubuntu, Arch, and Fedora.)
Have a nice day :)
Thomas
i already saw your questions in the web and wrote on
https://ubuntuforums.org/showthread.php?t=2479825&p=14115063#post14115063
-------------------------------------------------------------------------
Your genisoimage run does not produce boot lures for EFI which would lead
to GRUB, but only boot lures for legacy BIOS which would lead to ISOLINUX.
So the fact that you see in
https://ibb.co/GstvTvR
a GRUB prompt indicates that this GRUB stems from some other storage medium.
(Shown on https://askubuntu.com/questions/1434549 which is cumbersome for
me to participate.)
Is your QEMU/KVM running with EFI as firmware (OVMF) ? If so, try to get
it started with legacy BIOS (SeaBIOS) and with the ISO as virtual CD-ROM.
For a still valid proposal to repack a Debian amd64 bootable ISO for EFI
and BIOS from CD and USB stick see:
https://wiki.debian.org/RepackBootableISO#Determine_those_options_which_need_to_be_adapted_on_amd64_or_i386
-------------------------------------------------------------------------
> I guess the error could be :
> xorriso : NOTE : Detected El-Torito boot information which currently is set to
> be discarded"
this program run, the message is of no importance.
> I have asked help
> in a lot of places,but no one really understood why.
Try the proposals about booting via legacy BIOS and/or equipping the ISO
by the full BIOS+EFI+CD+USB-Stick stuff as in
https://wiki.debian.org/RepackBootableISO
Then there would be the modernish way of
xorriso -indev debian-11.5.0-amd64-netinst.iso \
-outdev debian-11-unattended.iso \
... xorriso image manipulation commands like -map, -rm, -mv ... \
-boot_image any replay
No unpacking of the original ISO is needed. (Your xorriso 1.5.4 is young
enough to cope even with the new layouts of Ubuntu, Arch, and Fedora.)
Have a nice day :)
Thomas
Mario Marietto
Oct 9, 2022, 4:50:05 PM10/9/22
to
Sorry,I didn't see that reply. Anyway,it didn't work. I need some other support,please. I've replied on the ubuntuforums.
Mario.
Mario Marietto
Oct 9, 2022, 5:40:05 PM10/9/22
to
I have also tried this version :
xorriso \
-outdev debian-live-11.5.0-amd64-xfce.iso \-volid d-live \
-padding 0 \
-map /home/ziomario/Scrivania/PassT-Cubic/ISO/iso_unpacked_and_modified / \
-chmod 0755 / -- \
-boot_image isolinux dir=/isolinux \
-boot_image isolinux system_area=/home/ziomario/Scrivania/PassT-Cubic/ISO/isohdpfx.bin \
-boot_image any next \
-boot_image any efi_path=boot/grub/efi.img \
-boot_image isolinux partition_entry=gpt_basdat
this didn't even work :
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.
Drive current: -outdev 'debian-live-11.5.0-amd64-xfce.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Media summary: 1 session, 1310720 data blocks, 2560m data, 44.0g free
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
Added to ISO image: directory '/'='/home/ziomario/Scrivania/PassT-Cubic/ISO/iso_unpacked_and_modified'
xorriso : FAILURE : Cannot find in ISO image: -boot_image ... bin_path='/isolinux/isolinux.bin'
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
Mario.
Thomas Schmitt
Oct 10, 2022, 3:50:07 AM10/10/22
to
Hi,
Mario Marietto wrote:
> I've replied on the ubuntuforums.
The deficiency of your run in
https://ubuntuforums.org/showthread.php?t=2479825&p=14115075#post14115075
is that you did not give the options for creating EFI boot lures.
Your VM states to have OVMF as firmware.
> I have also tried this version :
> xorriso \
> -outdev debian-live-11.5.0-amd64-xfce.iso \
> -volid d-live \
> -padding 0 \
> -map /home/ziomario/Scrivania/PassT-Cubic/ISO/iso_unpacked_and_modified /
> \
> -chmod 0755 / -- \
> -boot_image isolinux dir=/isolinux \
> -boot_image isolinux
> system_area=/home/ziomario/Scrivania/PassT-Cubic/ISO/isohdpfx.bin \
> -boot_image any next \
> -boot_image any efi_path=boot/grub/efi.img \
> -boot_image isolinux partition_entry=gpt_basdat
>
> this didn't even work :
> ...
complete. There should be a file
/home/ziomario/Scrivania/PassT-Cubic/ISO/iso_unpacked_and_modified/isolinux/isolinux.bin
which is supposed to get into the emerging ISO as file
/isolinux/isolinux.bin
Elsewise this run would be sufficient for creating an EFI bootable ISO.
It uses xorriso's native commands rather than the options of its mkisofs
emulation.
I just tested it with the extracted files of a Debian netinst ISO.
Like my proposal at ubuntuforums.org this yields an ISO with EFI boot lures:
$ xorriso -indev "$new_iso" -report_system_area plain -report_el_torito plain
...
System area summary: MBR isohybrid cyl-align-on GPT
...
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0x00 0 884736
MBR partition : 2 0x00 0xef 2260 5184
MBR partition path : 2 /boot/grub/efi.img
...
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 1861
El Torito boot img : 2 UEFI y none 0x0000 0x00 5184 565
El Torito img path : 1 /isolinux/isolinux.bin
El Torito img opts : 1 boot-info-table isohybrid-suitable
El Torito img path : 2 /boot/grub/efi.img
MBR partition 2 is the EFI System Partition for booting from USB stick.
El Torito boot image 2 is the same storage area advertised as boot
opportunity for EFI from CD-ROM.
> (on the experiment n.2 I have extracted the files with Ark,but the error is
> still there)
This looks like your report at ubuntuforums.
As stated above, it lacks the options for creating EFI boot lures.
But the tree "$new_files" contains the file /isolinux/isolinux.bin, so
that this run does not fail when trying to find that file in the emerging
ISO.
My proposal at ubuntuforums.org is
xorriso -as mkisofs \
-r -J --joliet-long \
-V 'Debian' \
-o "$new_iso" \
-isohybrid-mbr "$mbr_template" \
-partition_offset 16 \
-c isolinux/boot.cat \
-b isolinux/isolinux.bin \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-eltorito-alt-boot \
-e boot/grub/efi.img \
-no-emul-boot -isohybrid-gpt-basdat -isohybrid-apm-hfsplus \
$new_files
Mario Marietto wrote:
> I've replied on the ubuntuforums.
https://ubuntuforums.org/showthread.php?t=2479825&p=14115075#post14115075
is that you did not give the options for creating EFI boot lures.
Your VM states to have OVMF as firmware.
> I have also tried this version :
> xorriso \
> -outdev debian-live-11.5.0-amd64-xfce.iso \
> -volid d-live \
> -padding 0 \
> -map /home/ziomario/Scrivania/PassT-Cubic/ISO/iso_unpacked_and_modified /
> \
> -chmod 0755 / -- \
> -boot_image isolinux dir=/isolinux \
> -boot_image isolinux
> system_area=/home/ziomario/Scrivania/PassT-Cubic/ISO/isohdpfx.bin \
> -boot_image any next \
> -boot_image any efi_path=boot/grub/efi.img \
> -boot_image isolinux partition_entry=gpt_basdat
>
> this didn't even work :
> xorriso : FAILURE : Cannot find in ISO image: -boot_image ...
> bin_path='/isolinux/isolinux.bin'
It looks like the extracted file tree .../iso_unpacked_and_modified is not
> bin_path='/isolinux/isolinux.bin'
complete. There should be a file
/home/ziomario/Scrivania/PassT-Cubic/ISO/iso_unpacked_and_modified/isolinux/isolinux.bin
which is supposed to get into the emerging ISO as file
/isolinux/isolinux.bin
Elsewise this run would be sufficient for creating an EFI bootable ISO.
It uses xorriso's native commands rather than the options of its mkisofs
emulation.
I just tested it with the extracted files of a Debian netinst ISO.
Like my proposal at ubuntuforums.org this yields an ISO with EFI boot lures:
$ xorriso -indev "$new_iso" -report_system_area plain -report_el_torito plain
...
System area summary: MBR isohybrid cyl-align-on GPT
...
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0x00 0 884736
MBR partition : 2 0x00 0xef 2260 5184
MBR partition path : 2 /boot/grub/efi.img
...
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 1861
El Torito boot img : 2 UEFI y none 0x0000 0x00 5184 565
El Torito img path : 1 /isolinux/isolinux.bin
El Torito img opts : 1 boot-info-table isohybrid-suitable
El Torito img path : 2 /boot/grub/efi.img
MBR partition 2 is the EFI System Partition for booting from USB stick.
El Torito boot image 2 is the same storage area advertised as boot
opportunity for EFI from CD-ROM.
> (on the experiment n.2 I have extracted the files with Ark,but the error is
> still there)
This looks like your report at ubuntuforums.
As stated above, it lacks the options for creating EFI boot lures.
But the tree "$new_files" contains the file /isolinux/isolinux.bin, so
that this run does not fail when trying to find that file in the emerging
ISO.
My proposal at ubuntuforums.org is
xorriso -as mkisofs \
-r -J --joliet-long \
-V 'Debian' \
-o "$new_iso" \
-isohybrid-mbr "$mbr_template" \
-partition_offset 16 \
-c isolinux/boot.cat \
-b isolinux/isolinux.bin \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-eltorito-alt-boot \
-e boot/grub/efi.img \
-no-emul-boot -isohybrid-gpt-basdat -isohybrid-apm-hfsplus \
$new_files
Mario Marietto
Oct 10, 2022, 5:30:06 AM10/10/22
to
Thanks. I've replied to ubuntuforums. Concerning the first attempt,instead,I have created the folder iso_unpacked_and_modified and inside of it I have placed the folder isolinux with the file isolinux.bin. This is what happened :
script2.sh
orig_iso=debian-live-11.5.0-amd64-xfce.iso
new_files=debian-live-11.5.0-amd64-xfce
new_iso=debian-live-11.5.0-amd64-modified-xfce.iso
mbr_template=isohdpfx.bin
# Extract MBR template file to disk
new_files=debian-live-11.5.0-amd64-xfce
new_iso=debian-live-11.5.0-amd64-modified-xfce.iso
mbr_template=isohdpfx.bin
# Extract MBR template file to disk
dd if="$orig_iso" bs=1 count=432 of="$mbr_template"
xorriso \
-outdev debian-live-11.5.0-amd64-xfce.iso \
-volid d-live \
-padding 0 \
-map /home/ziomario/Scrivania/PassT-Cubic/ISO/iso_unpacked_and_modified / \
-chmod 0755 / -- \
-boot_image isolinux dir=/isolinux \
-boot_image isolinux system_area=/home/ziomario/Scrivania/PassT-Cubic/ISO/isohdpfx.bin \
-boot_image any next \
-boot_image any efi_path=boot/grub/efi.img \
-boot_image isolinux partition_entry=gpt_basdat
# ./script2.sh
432+0 record dentro
432+0 record fuori
432 bytes copied, 0.000496522 s, 870 kB/s
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.
Drive current: -outdev 'debian-live-11.5.0-amd64-xfce.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Drive current: -outdev 'debian-live-11.5.0-amd64-xfce.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Media summary: 1 session, 1310720 data blocks, 2560m data, 40.3g free
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
xorriso : UPDATE : 2 files added in 1 seconds
Added to ISO image: directory '/'='/home/ziomario/Scrivania/PassT-Cubic/ISO/iso_unpacked_and_modified'
xorriso : FAILURE : -indev differs from -outdev and -outdev media holds non-zero data
xorriso : NOTE : -return_with SORRY 32 triggered by problem severity FAILURE
xorriso : NOTE : -return_with SORRY 32 triggered by problem severity FAILURE
Mario.
Thomas Schmitt
Oct 10, 2022, 6:20:06 AM10/10/22
to
Hi,
Mario Marietto wrote:
> Drive current: -outdev 'debian-live-11.5.0-amd64-xfce.iso'
> Media current: stdio file, overwriteable
> Media status : is written , is appendable
> Media summary: 1 session, 1310720 data blocks, 2560m data, 40.3g free
> ...
xorriso use this name as target for writing.
Other than with the mkisofs emulation, the native command mode does not
automatically truncate the -outdev target to 0 bytes. That's mainly because
-outdev may also be an optical drive which cannot be truncated.
Instead some optical media can be blanked and some can be overwritten.
Data files as targets are considered to be pseudo-drives which behave like
DVD+RW or BD-RE media.
In any case, if the target looks like containing valid data, the xorriso
user has to invalidate those data explicitely. In case of a data file you
may remove or rename it. For all, real and pseudo drives, the data can be
invalidated by
xorriso -outdev "$target" -blank as_needed
This works with CD-RW, DVD-RW, DVD+RW, DVD-RAM, BD-RE, block devices, and
data files. Data files don't shrink in sizei by -blank, but can afterwards
be overwritten from their beginning and may grow.
The -outdev target may only exist with a recognizable ISO 9660 filesystem
if the xorriso run uses it also as -indev for multi-session. In that case,
the ISO 9660 filesystem in the image file or on the medium does not get
truncated but rather expanded by a new session.
(The combination of -indev X -outdev X is normally abbreviated as: -dev X)
See this section in man xorriso:
"Creating, Growing, Modifying, Blind Growing:"
Mario Marietto wrote:
> Drive current: -outdev 'debian-live-11.5.0-amd64-xfce.iso'
> Media current: stdio file, overwriteable
> Media status : is written , is appendable
> Media summary: 1 session, 1310720 data blocks, 2560m data, 40.3g free
> xorriso : FAILURE : -indev differs from -outdev and -outdev media holds non-zero data
Remove or rename debian-live-11.5.0-amd64-xfce.iso before you try to let
xorriso use this name as target for writing.
Other than with the mkisofs emulation, the native command mode does not
automatically truncate the -outdev target to 0 bytes. That's mainly because
-outdev may also be an optical drive which cannot be truncated.
Instead some optical media can be blanked and some can be overwritten.
Data files as targets are considered to be pseudo-drives which behave like
DVD+RW or BD-RE media.
In any case, if the target looks like containing valid data, the xorriso
user has to invalidate those data explicitely. In case of a data file you
may remove or rename it. For all, real and pseudo drives, the data can be
invalidated by
xorriso -outdev "$target" -blank as_needed
This works with CD-RW, DVD-RW, DVD+RW, DVD-RAM, BD-RE, block devices, and
data files. Data files don't shrink in sizei by -blank, but can afterwards
be overwritten from their beginning and may grow.
The -outdev target may only exist with a recognizable ISO 9660 filesystem
if the xorriso run uses it also as -indev for multi-session. In that case,
the ISO 9660 filesystem in the image file or on the medium does not get
truncated but rather expanded by a new session.
(The combination of -indev X -outdev X is normally abbreviated as: -dev X)
See this section in man xorriso:
"Creating, Growing, Modifying, Blind Growing:"
Mario Marietto
Oct 10, 2022, 6:40:05 AM10/10/22
to
Finally,this version works as expected :
script2.sh
orig_iso=debian-live-11.5.0-amd64-xfce.iso
new_iso=debian-live-11.5.0-amd64-modified-xfce.iso
mbr_template=isohdpfx.bin
# Extract MBR template file to disk
dd if="$orig_iso" bs=1 count=432 of="$mbr_template"
xorriso \
mbr_template=isohdpfx.bin
# Extract MBR template file to disk
dd if="$orig_iso" bs=1 count=432 of="$mbr_template"
xorriso \
-outdev "$new_iso" -blank as_needed \
-volid d-live \
-padding 0 \
-map /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce / \
-volid d-live \
-padding 0 \
-map /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce / \
-chmod 0755 / -- \
-boot_image isolinux dir=/isolinux \
-boot_image isolinux system_area=/home/ziomario/Scrivania/PassT-Cubic/ISO/isohdpfx.bin \
-boot_image any next \
-boot_image any efi_path=boot/grub/efi.img \
-boot_image isolinux partition_entry=gpt_basdat
Mario.
Mario Marietto
Oct 10, 2022, 9:00:06 AM10/10/22
to
Hello again.
Now it's the right time to explain the whole project that I'm working on to you,because now I have the missing piece,thanks to Thomas and I can exclude one of the reasons why it does not work. What I would like to do is to use a preseed file to preconfigure some options,so that the debian installer does not ask me the relative questions. I've found this tutorial and I've followed,integrating the Thomas suggestions :
these are the commands that I have issued :
apt update && apt -y install xorriso genisoimage
wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.5.0-amd64-netinst.iso
wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.5.0-amd64-netinst.iso
xorriso -osirrox on -indev /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-11.5.0-amd64-netinst.iso -extract / /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/
chmod +w -R /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/
gunzip /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd.gz
echo /home/ziomario/Scrivania/PassT-Cubic/ISO/preseed/preseed.cfg | cpio -H newc -o -A -F /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd
gzip /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd
chmod -w -R /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/
cd /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/
chmod a+w /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/isolinux/isolinux.bin
cd /home/ziomario/Scrivania/PassT-Cubic/ISO/
chmod +w -R /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/
gunzip /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd.gz
echo /home/ziomario/Scrivania/PassT-Cubic/ISO/preseed/preseed.cfg | cpio -H newc -o -A -F /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd
gzip /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd
chmod -w -R /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/
cd /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/
chmod a+w /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/isolinux/isolinux.bin
cd /home/ziomario/Scrivania/PassT-Cubic/ISO/
./script1.sh
orig_iso=debian-live-11.5.0-amd64-xfce.iso
new_files=debian-live-11.5.0-amd64-xfce
new_iso=debian-live-11.5.0-amd64-mod-xfce.iso
mbr_template=isohdpfx.bin
# Extract MBR template file to disk
dd if="$orig_iso" bs=1 count=432 of="$mbr_template"
xorriso -as mkisofs \
-r -J --joliet-long \
-r -J --joliet-long \
-V 'd-live 11.5.0 xf amd64' \
-o "$new_iso" \
-isohybrid-mbr "$mbr_template" \
-partition_offset 16 \
-c isolinux/boot.cat \
-b isolinux/isolinux.bin \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-eltorito-alt-boot \
-e boot/grub/efi.img \
-no-emul-boot -isohybrid-gpt-basdat -isohybrid-apm-hfsplus \
"$new_files"
cd debian-live-11.5.0-amd64-xfce/
LOG :
432+0 record in
432+0 record out
432 bytes copied, 0.000426907 s, 1.0 MB/s
LOG :
432+0 record in
432+0 record out
432 bytes copied, 0.000426907 s, 1.0 MB/s
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.
Drive current: -outdev 'stdio:debian-live-11.5.0-amd64-mod-xfce.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 40.3g free
xorriso : WARNING : -volid text problematic as automatic mount point name
xorriso : WARNING : -volid text is too long for Joliet (22 > 16)
Media summary: 0 sessions, 0 data blocks, 0 data, 40.3g free
xorriso : WARNING : -volid text problematic as automatic mount point name
xorriso : WARNING : -volid text is too long for Joliet (22 > 16)
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
Added to ISO image: directory '/'='/home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce'
xorriso : UPDATE : 1389 files added in 1 seconds
xorriso : UPDATE : 1389 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 432 bytes from file '/home/ziomario/Scrivania/PassT-Cubic/ISO/isohdpfx.bin'
libisofs: NOTE : Automatically adjusted MBR geometry to 1019/162/32
libisofs: NOTE : Aligned image size to cylinder size by 866 blocks
xorriso : UPDATE : 7.49% done
xorriso : UPDATE : 38.62% done
xorriso : UPDATE : Thank you for being patient. Working since 2 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 3 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 4 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 5 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 6 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 7 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 8 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 9 seconds.
ISO image produced: 1320624 sectors
Written to medium : 1320624 sectors at LBA 0
Writing to 'stdio:debian-live-11.5.0-amd64-mod-xfce.iso' completed successfully.
xorriso : UPDATE : 1389 files added in 1 seconds
xorriso : UPDATE : 1389 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 432 bytes from file '/home/ziomario/Scrivania/PassT-Cubic/ISO/isohdpfx.bin'
libisofs: NOTE : Automatically adjusted MBR geometry to 1019/162/32
libisofs: NOTE : Aligned image size to cylinder size by 866 blocks
xorriso : UPDATE : 7.49% done
xorriso : UPDATE : 38.62% done
xorriso : UPDATE : Thank you for being patient. Working since 2 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 3 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 4 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 5 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 6 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 7 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 8 seconds.
xorriso : UPDATE : Thank you for being patient. Working since 9 seconds.
ISO image produced: 1320624 sectors
Written to medium : 1320624 sectors at LBA 0
Writing to 'stdio:debian-live-11.5.0-amd64-mod-xfce.iso' completed successfully.
Yes,the resulting ISO image is bootable,but the preseed file does not stick. The installer stills asks me the questions that it shouldn't , according with the preeseed.cfg file that I've used :
d-i debian-installer/add-kernel-opts string intel_iommu=on
d-i mirror/http/hostname string http.us.debian.org
d-i mirror/http/directory string /debian
d-i passwd/root-password password marietto
d-i passwd/user-fullname string marietto User
d-i passwd/username string marietto
d-i passwd/user-password password a
d-i passwd/user-password-again password a
d-i user-setup/allow-password-weak boolean true
d-i mirror/http/hostname string http.us.debian.org
d-i mirror/http/directory string /debian
d-i passwd/root-password password marietto
d-i passwd/user-fullname string marietto User
d-i passwd/username string marietto
d-i passwd/user-password password a
d-i passwd/user-password-again password a
d-i user-setup/allow-password-weak boolean true
so,do you know why it is totally ignored by Debian,according to the commands that I have issued ? Thank you very much.
Mario.
Thomas Schmitt
Oct 10, 2022, 10:30:05 AM10/10/22
to
Hi,
Mario Marietto wrote:
> I've found this tutorial and I've followed,integrating the Thomas
> suggestions :
> https://github.com/Nidouille/Debian-Automated-Installation
The section "Creation de l'ISO" is outdated since Debian 7.
The excuse "UEFI : grub Modification non faite, car je suis en vm"
is not valid any more.
In general i would rather try to follow Debian docs, although they tend
to be a few releases behind. Google leads me to
https://wiki.debian.org/DebianInstaller/Preseed/EditIso
which looks like being on the same stage of development as the french site.
But it sends me to
https://www.debian.org/releases/stable/i386/apbs01.en.html
from where i hop to
https://www.debian.org/releases/stable/amd64/apbs01.en.html
Consider to check your preseeding commands for compliance with this
documentation.
> xorriso -osirrox on -indev /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-11.5.0-amd64-netinst.iso -extract / /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/
Despite the directory name "debian-live" you are experimenting with a
netinst ISO, which is on topic on debi...@lists.debian.org .
About Debian Live install images as of
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/
you should ask at debia...@lists.debian.org .
--------------------------------------------------------------------------
A guess out of competition, as i have no clue of presseding:
> echo /home/ziomario/Scrivania/PassT-Cubic/ISO/preseed/preseed.cfg | cpio -H newc -o -A -F /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd
You put the whole lengthy path into the cpio archive initrd.
But
https://www.debian.org/releases/stable/amd64/apbs02.en.html
says
"If you are using initrd preseeding, you only have to make sure a file
named preseed.cfg is included in the root directory of the initrd."
That would be
( cd /home/ziomario/Scrivania/PassT-Cubic/ISO/preseed/
echo preseed.cfg | cpio -H newc -o -A -F /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd )
Inspect the resulting cpio archive by:
cpio -t </home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd 2>&1 | less
Mario Marietto wrote:
> I've found this tutorial and I've followed,integrating the Thomas
> suggestions :
> https://github.com/Nidouille/Debian-Automated-Installation
The excuse "UEFI : grub Modification non faite, car je suis en vm"
is not valid any more.
In general i would rather try to follow Debian docs, although they tend
to be a few releases behind. Google leads me to
https://wiki.debian.org/DebianInstaller/Preseed/EditIso
which looks like being on the same stage of development as the french site.
But it sends me to
https://www.debian.org/releases/stable/i386/apbs01.en.html
from where i hop to
https://www.debian.org/releases/stable/amd64/apbs01.en.html
Consider to check your preseeding commands for compliance with this
documentation.
> xorriso -osirrox on -indev /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-11.5.0-amd64-netinst.iso -extract / /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/
netinst ISO, which is on topic on debi...@lists.debian.org .
About Debian Live install images as of
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/
you should ask at debia...@lists.debian.org .
--------------------------------------------------------------------------
A guess out of competition, as i have no clue of presseding:
> echo /home/ziomario/Scrivania/PassT-Cubic/ISO/preseed/preseed.cfg | cpio -H newc -o -A -F /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd
But
https://www.debian.org/releases/stable/amd64/apbs02.en.html
says
"If you are using initrd preseeding, you only have to make sure a file
named preseed.cfg is included in the root directory of the initrd."
That would be
( cd /home/ziomario/Scrivania/PassT-Cubic/ISO/preseed/
echo preseed.cfg | cpio -H newc -o -A -F /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd )
Inspect the resulting cpio archive by:
cpio -t </home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd 2>&1 | less
Thomas Schmitt
Oct 10, 2022, 2:00:05 PM10/10/22
to
Hi,
i wrote:
> > ( cd /home/ziomario/Scrivania/PassT-Cubic/ISO/preseed/
> > echo preseed.cfg | cpio -H newc -o -A -F /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd )
Mario Marietto wrote in a mail Cc'ed to debia...@lists.debian.org:
> ok. I did it. But it has been ignored. Please check the image below :
> Istantanea_2022-10-10_17-29-30.png
Your mail copies to debia...@lists.debian.org don't arrive in my mail
box and don't show up in the archives. I guess that's because of the
attached images.
If you see the need for images instead of copied+pasted text, then you
will have to upload the images somewhere and include the links in your
mails.
Whatever, consider to ask at debia...@lists.debian.org for contemporary
examples how to customize a live ISO by preseeding.
i wrote:
> > ( cd /home/ziomario/Scrivania/PassT-Cubic/ISO/preseed/
> > echo preseed.cfg | cpio -H newc -o -A -F /home/ziomario/Scrivania/PassT-Cubic/ISO/debian-live-11.5.0-amd64-xfce/d-i/initrd )
> ok. I did it. But it has been ignored. Please check the image below :
> Istantanea_2022-10-10_17-29-30.png
Your mail copies to debia...@lists.debian.org don't arrive in my mail
box and don't show up in the archives. I guess that's because of the
attached images.
If you see the need for images instead of copied+pasted text, then you
will have to upload the images somewhere and include the links in your
mails.
Whatever, consider to ask at debia...@lists.debian.org for contemporary
examples how to customize a live ISO by preseeding.
Tim Ye
Oct 10, 2022, 8:10:05 PM10/10/22
to
I would recommend to put the preseed file on a HTTP/FTP server. Then the file
is easier to edit, and it saves you the effort to customize an ISO.
- Tim
is easier to edit, and it saves you the effort to customize an ISO.
- Tim
Mario Marietto
Oct 11, 2022, 6:10:05 AM10/11/22
to
Nope. My project is not compatible with that. I want to re-distribute the ISO,so if I do that I should keep online a server only for the distribution of the preseed file. This costs money. And furthermore there is something that is not working. Your job should be to understand the reasons and help,not to find an alternative way,bypassing the real problem. I want more than you to understand why it does not work. My job is not the system administrator,I'm a psychologist,but anyway,I'm stubborn but also eager to know how things work under the hood and I like challenges. I would invite you to not surrender. Furthermore,I suppose that the ML debian-live is not active or it is a very very low level of activity. I don't expect to be helped there. So I want to come back here. I would like to be helped by Thomas,because I trust in his high level of skills.
Mario.
Thomas Schmitt
Oct 11, 2022, 7:10:06 AM10/11/22
to
Hi,
Mario Marietto wrote:
> I suppose that the ML debian-live is not
> active or it is a very very low level of activity.
It's what exists in respect to Debian Live ISOs.
https://www.debian.org/devel/debian-live/
mentions the bug tracking system, the debian-live mailing list, and an
IRC channel.
I'm not sure whether Debian Live has a dedicated maintainer currently.
But there is some hope that someone is subscribed to the mailing list
and knows what currently works and what does not.
> I would like to be helped by
> Thomas,because I trust in his high level of skills.
I was able to help you with the task of repacking the ISO bootable for
BIOS and EFI, because i am the developer of xorriso, which Debian uses
instead of genisoimage to pack up its ISOs.
But i cannot help with questions about preseeding Debian ISOs or most
other aspects of the content of a Debian ISO.
As stated, i am even unsure if the documentation at
https://www.debian.org/releases/stable/amd64/apbs01.en.html
applies to Debian Live (or only to debian-cd ISOs).
Therefore i recommended to ask at debian-live for currently working examples.
Maybe you will receive some help here or there, maybe not.
Actually frustration about lack of support is one of the classic
motivations to start own software projects.
Mario Marietto wrote:
> I suppose that the ML debian-live is not
> active or it is a very very low level of activity.
https://www.debian.org/devel/debian-live/
mentions the bug tracking system, the debian-live mailing list, and an
IRC channel.
I'm not sure whether Debian Live has a dedicated maintainer currently.
But there is some hope that someone is subscribed to the mailing list
and knows what currently works and what does not.
> I would like to be helped by
> Thomas,because I trust in his high level of skills.
BIOS and EFI, because i am the developer of xorriso, which Debian uses
instead of genisoimage to pack up its ISOs.
But i cannot help with questions about preseeding Debian ISOs or most
other aspects of the content of a Debian ISO.
As stated, i am even unsure if the documentation at
https://www.debian.org/releases/stable/amd64/apbs01.en.html
applies to Debian Live (or only to debian-cd ISOs).
Therefore i recommended to ask at debian-live for currently working examples.
Maybe you will receive some help here or there, maybe not.
Actually frustration about lack of support is one of the classic
motivations to start own software projects.
Mario Marietto
Oct 11, 2022, 9:20:05 AM10/11/22
to
Sometimes it happens that no one replied to a specific ML. Anyway I have some experience in linux and freebsd management. I have used Linux,as a hobbyist ,since the 1990's. But it happens rarely. More often happens that inside the IRC channels no one will help. I've always found a lot of bots and nothing more than that. I'm not in a good situation. I've posted the question in a LOT of places. I have trouble finding more places to ask. I can't even open a bug report,because I don't see any bugs. I've even asked more times on the cubic github. No one replied and after 15 days questions expired. Can you suggest some other nice places where I can post the question again ? Check all the questions that I have already asked and that still are without a reply :
I can't start my own project. I'm a hobbyist. I don't have the competences. Furthermore,it makes no sense to do that,because the projects I need are already there. It is called cubic and even the Debian preseeding is an old method. I don't need to reinvent the wheel. Here the question is structural. A lot of developers have no time to give support. But I'm sure that if they get money,they will find it.
Mario.
Thomas Schmitt
Oct 11, 2022, 11:30:06 AM10/11/22
to
Hi,
Mario Marietto wrote:
> Can you suggest some other nice places where I can post the
> question again ?
No. This list here and debian-live are the best places to ask.
At least i know of no better ones.
If i were in your situation i would try to find out how the software
in the initrd is supposed to deal with preseed.cfg.
We already know how to get the uncompressed cpio archive "initrd".
Curiously i put it into some playground directory and do:
mkdir unpacked_initrd
cd unpacked_initrd
cpio -id <../initrd
fgrep -r preseed.cfg . | less
which yields various file paths. (I tried with the /d-i/initrd.gz of
debian-live-11.1.0-amd64-xfce.iso)
lib/debian-installer-startup.d/S30initrd-preseed looks interesting.
It calls preseed_location() in lib/preseed/preseed.sh with the URL
file:///preseed.cfg .
So i'd begin to study what it does and insert messages which tell at
run time what's going on. Then i'd pack it up again by (i guess):
find | cpio -H newc -o | gzip > new_initrd.gz
and put it into the new ISO.
In preseed.sh i see at the start:
logfile=/var/lib/preseed/log
I'd try to find out how to assess that file after the modified ISO has
booted. (Is the initrd ramdisk filesystem the same as the Live filesystem ?
Does the log get copied from one to the other ?)
But of course this is an open ended adventure with lots of wrong ways
to follow and lots of things to learn.
Also consider the mind set of those who possibly could help you:
Would it be fun for them, or at least interesting and bringing progress ?
A first step in their direction would be to show patience and appreciation
for the work which they do while you are waiting for them to show up.
Mario Marietto wrote:
> Can you suggest some other nice places where I can post the
> question again ?
At least i know of no better ones.
If i were in your situation i would try to find out how the software
in the initrd is supposed to deal with preseed.cfg.
We already know how to get the uncompressed cpio archive "initrd".
Curiously i put it into some playground directory and do:
mkdir unpacked_initrd
cd unpacked_initrd
cpio -id <../initrd
fgrep -r preseed.cfg . | less
which yields various file paths. (I tried with the /d-i/initrd.gz of
debian-live-11.1.0-amd64-xfce.iso)
lib/debian-installer-startup.d/S30initrd-preseed looks interesting.
It calls preseed_location() in lib/preseed/preseed.sh with the URL
file:///preseed.cfg .
So i'd begin to study what it does and insert messages which tell at
run time what's going on. Then i'd pack it up again by (i guess):
find | cpio -H newc -o | gzip > new_initrd.gz
and put it into the new ISO.
In preseed.sh i see at the start:
logfile=/var/lib/preseed/log
I'd try to find out how to assess that file after the modified ISO has
booted. (Is the initrd ramdisk filesystem the same as the Live filesystem ?
Does the log get copied from one to the other ?)
But of course this is an open ended adventure with lots of wrong ways
to follow and lots of things to learn.
Also consider the mind set of those who possibly could help you:
Would it be fun for them, or at least interesting and bringing progress ?
A first step in their direction would be to show patience and appreciation
for the work which they do while you are waiting for them to show up.
Mario Marietto
Oct 11, 2022, 12:40:08 PM10/11/22
to
You entered in a kind of analysis that I'm not able to do without the help of someone else more skilled than me. I've tried to add the preseed file even on the initrd file located on the live folder,but it didn't work. I don't know what to do further,but you gave me more material to post another question,this time more oriented to programming,so I know which is the right place to ask and what to ask.
Mario.
Mario Marietto
Oct 11, 2022, 2:10:05 PM10/11/22
to
Does it make sense to insert the preseed file inside this file ? ----> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/initrd.img-5.10.0-18-amd64 ?
What's the difference between initrd and initrd.img-5.10.0-18-amd64 ?
Instructions says :
Regenerating md5sum.txt
cd isofiles chmod +w md5sum.txt
I don't have that file. Do you know how to generate it ?
Mario.
Andrew M.A. Cater
Oct 11, 2022, 2:40:05 PM10/11/22
to
On Tue, Oct 11, 2022 at 06:36:26PM +0200, Mario Marietto wrote:
> You entered in a kind of analysis that I'm not able to do without the help
> of someone else more skilled than me. I've tried to add the preseed file
> even on the initrd file located on the live folder,but it didn't work. I
> don't know what to do further,but you gave me more material to post another
> question,this time more oriented to programming,so I know which is the
> right place to ask and what to ask.
>
>
Hi Mario,
> You entered in a kind of analysis that I'm not able to do without the help
> of someone else more skilled than me. I've tried to add the preseed file
> even on the initrd file located on the live folder,but it didn't work. I
> don't know what to do further,but you gave me more material to post another
> question,this time more oriented to programming,so I know which is the
> right place to ask and what to ask.
>
>
I think you have hit on a problem which is a combination of problems: that's
quite common on this list :)
See also: https://en.wikipedia.org/wiki/XY_problem
Preseeding
==========
Although this list is fairly knowledgeable about many things, there are a few
things that need specialist experience. Preseeding is one of those things - it
is documented in, for example, the Debian handbook (the Debian package is
debian-handbook) or https://debian-handbook.info/browse/stable/sect.automated-installation.html#sect.d-i-preseeding which refers on to resources like
http://preseed.einval.com
Preseeding is a very easy concept to explain - provide the answers to
the questions in the installer - but it's not so straightforward to
get it right first time. That's the reason behind someone suggesting setting
up the file on a local webserver where you can change it, reload and see the
results immediately. Break the problem down and make one change at a time
until you're sure it's OK?
Debian-live and live images
===========================
Debian-live is its own animal - the installer is different and you have the
complexities of making the image bootable as you've seen.
There aren't many experts on this, unfortunately, on this list or anywhere else.
Remastering .iso images
=======================
Thomas has given you much of the help you need, I think - he's the expert
on the tools here.
The intersection of all of these gives you a smaller and smaller group
of potential experts. What do you want to do, _exactly_ ?
If you explain the end goal well to yourself and to us, we can help you
break it down into stages.
For example "I want to make a Debian Live CD
to show my family my collection of model trains and give instructions
to others on how I built it"
* Make a Live CD
* Customise it
* Set up a webserver inside the iso
* Write custom scripts to run the demonstrations and put them into the .iso
As you explain each stage, and point out what resources you have found / where
things are missing, we can probably find people to tackle one piece at a time.
"I wanted to do X, thought I could do it by doing Y - and I can't remember
exactly what I did or how I did it - and now I have to fix situation Z"
is really, really common - we can all be guilty of it - but breaking down
the problem into small pieces may really help here - and that may be by
explaining what you want.
There are alternatives, sometimes - several webservers are available - and
people may have a favourite application but if you specify simple requirements
we may be better able to help.
Happy to help in any way I can, as ever,
With every good wish,
Andy Cater.
Thomas Schmitt
Oct 11, 2022, 3:00:06 PM10/11/22
to
Hi,
Mario Marietto wrote:
> Does it make sense to insert the preseed file inside this file ? ---->
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/initrd.img-5.10.0-18-amd64
?
> What's the difference between initrd and initrd.img-5.10.0-18-amd64 ?
Interesting question. (You see ? New adventures.)
There are five files with names matching '*initrd*'. Two of them are udeb
packages. So there remain
d-i/gtk/initrd.gz
d-i/initrd.gz
live/initrd.img-5.10.0-18-amd64
Listing their content shows that the "d-i/gtk" initrd is mostly a superset
of the "d-i" initrd. Only "screen" is in "d-i" but not in "d-i/gtk".
gunzip </mnt/iso/d-i/gtk/initrd.gz | cpio -t | sort >d_i_gtk
gunzip </mnt/iso/d-i/initrd.gz | cpio -t | sort >d_i
diff -puN d_i d_i_gtk
A comparison between "d-i/gtk" and "live" shows that "live" seems to
provide much more files in /usr/bin. Further the kernel modules directory
names differ:
-lib/modules/5.10.0-18-amd64
+usr/lib/modules/5.10.0-18-amd64
I'd put the preseed.cfg file into each of the three cpio archives.
If it works, then you can replace two of them by the originals and try
whether one alone does the trick for you.
----------------------------------------------------------------------
> Instructions says :
> Regenerating md5sum.txt
> cd isofiles chmod +w md5sum.txt
I don't find it in the Live ISO. I know it from the adventure to merge
all debian-cd installation DVD ISOs into one big ISO for a USB stick.
You'll find an example in the root directory of the netinst ISO.
It contains lines with the MD5 checksums and paths of files inside the ISO.
Afaik it is used for an optional verification run. Zhang Boyang wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011343#170
"A bad md5sum.txt will cause cdrom-checker in d-i to fail. (Fortunately
it's not a standard step, but user can invoke it under `Advance options
- Expert install')"
Since it is missing in the Live ISO, you most probably won't need it.
(And i bet that there is no such advanced option in Live ISO.)
Mario Marietto wrote:
> Does it make sense to insert the preseed file inside this file ? ---->
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/initrd.img-5.10.0-18-amd64
?
> What's the difference between initrd and initrd.img-5.10.0-18-amd64 ?
There are five files with names matching '*initrd*'. Two of them are udeb
packages. So there remain
d-i/gtk/initrd.gz
d-i/initrd.gz
live/initrd.img-5.10.0-18-amd64
Listing their content shows that the "d-i/gtk" initrd is mostly a superset
of the "d-i" initrd. Only "screen" is in "d-i" but not in "d-i/gtk".
gunzip </mnt/iso/d-i/gtk/initrd.gz | cpio -t | sort >d_i_gtk
gunzip </mnt/iso/d-i/initrd.gz | cpio -t | sort >d_i
diff -puN d_i d_i_gtk
A comparison between "d-i/gtk" and "live" shows that "live" seems to
provide much more files in /usr/bin. Further the kernel modules directory
names differ:
-lib/modules/5.10.0-18-amd64
+usr/lib/modules/5.10.0-18-amd64
I'd put the preseed.cfg file into each of the three cpio archives.
If it works, then you can replace two of them by the originals and try
whether one alone does the trick for you.
----------------------------------------------------------------------
> Instructions says :
> Regenerating md5sum.txt
> cd isofiles chmod +w md5sum.txt
all debian-cd installation DVD ISOs into one big ISO for a USB stick.
You'll find an example in the root directory of the netinst ISO.
It contains lines with the MD5 checksums and paths of files inside the ISO.
Afaik it is used for an optional verification run. Zhang Boyang wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011343#170
"A bad md5sum.txt will cause cdrom-checker in d-i to fail. (Fortunately
it's not a standard step, but user can invoke it under `Advance options
- Expert install')"
Since it is missing in the Live ISO, you most probably won't need it.
(And i bet that there is no such advanced option in Live ISO.)
Thomas Schmitt
Oct 11, 2022, 3:20:05 PM10/11/22
to
Hi,
i should have looked into the boot/grub/grub.cfg file for initrd usage:
...
menuentry "Debian GNU/Linux Live (kernel 5.10.0-18-amd64)" {
linux /live/vmlinuz-5.10.0-18-amd64 boot=live components splash quiet "${loopback}"
initrd /live/initrd.img-5.10.0-18-amd64
}
... many language choices with the same initrd ...
menuentry "Graphical Debian Installer" {
linux /d-i/gtk/vmlinuz append video=vesa:ywrap,mtrr vga=788 "${loopback}"
initrd /d-i/gtk/initrd.gz
}
menuentry "Debian Installer" {
linux /d-i/vmlinuz "${loopback}"
initrd /d-i/initrd.gz
}
...
So which GRUB menu item did you choose in your test whether your preseed.cfg
in /d-i/initrd.gz works ?
Only "Debian Installer" uses it. "Live" and "Graphical Debian Installer" use
the other two.
i should have looked into the boot/grub/grub.cfg file for initrd usage:
...
menuentry "Debian GNU/Linux Live (kernel 5.10.0-18-amd64)" {
linux /live/vmlinuz-5.10.0-18-amd64 boot=live components splash quiet "${loopback}"
initrd /live/initrd.img-5.10.0-18-amd64
}
... many language choices with the same initrd ...
menuentry "Graphical Debian Installer" {
linux /d-i/gtk/vmlinuz append video=vesa:ywrap,mtrr vga=788 "${loopback}"
initrd /d-i/gtk/initrd.gz
}
menuentry "Debian Installer" {
linux /d-i/vmlinuz "${loopback}"
initrd /d-i/initrd.gz
}
...
So which GRUB menu item did you choose in your test whether your preseed.cfg
in /d-i/initrd.gz works ?
Only "Debian Installer" uses it. "Live" and "Graphical Debian Installer" use
the other two.
Mario Marietto
Oct 11, 2022, 3:40:06 PM10/11/22
to
I always choose "Graphical Debian Installer" ,but I have to curb your enthusiasm. Yesterday I added the preseed.cfg file inside the /d-i/gtk/initrd.gz file and it has been ignored as well.
Mario.
Mario Marietto
Oct 11, 2022, 3:50:05 PM10/11/22
to
Maybe we reach the goal faster if we understand what the "cubic" developer wants us to do by reading the message that appears on top of the preseed tab ? Some step is missed and I'm not able to understand which one : give a look here : https://ibb.co/9N0zL2P
Mario.
Mario Marietto
Oct 11, 2022, 4:10:05 PM10/11/22
to
Finally I found something that's very close to the solution :
Mario.
Thomas Schmitt
Oct 11, 2022, 4:40:07 PM10/11/22
to
Hi,
Mario Marietto wrote:
> Finally I found something that's very close to the solution :
> https://askubuntu.com/questions/1228909/preseed-config-using-cubic-is-ignored-during-installation
If this shall be the solution then the files to change would probably be
isolinux/menu.cfg
boot/grub/grub.cfg
The isolinux configuration serves when booting by legacy BIOS or EFI
legacy mode. For booting via EFI native mode you need to modify the grub
configuration.
Mario Marietto wrote:
> Finally I found something that's very close to the solution :
> https://askubuntu.com/questions/1228909/preseed-config-using-cubic-is-ignored-during-installation
isolinux/menu.cfg
boot/grub/grub.cfg
The isolinux configuration serves when booting by legacy BIOS or EFI
legacy mode. For booting via EFI native mode you need to modify the grub
configuration.
Mario Marietto
Oct 11, 2022, 5:20:05 PM10/11/22
to
I'm trying to modify them as follows :
isolinux/menu.cfg
LABEL English (en)
SAY "Booting English (en)..."
linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash intel_iommu=on
SAY "Booting English (en)..."
linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash intel_iommu=on
boot/grub/grub.cfg
menuentry "English (en)" {
linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash intel_iommu=on "${loopback}"initrd /live/initrd.gz
}
I'm not even sure that it's correct,mostly because the grub.cfg file uses two command lines. The second one is "initrd /live/initrd.gz". I'm not sure if it should be there or if I should delete it.
Mario.
Mario Marietto
Oct 11, 2022, 5:40:06 PM10/11/22
to
I've added the string in both config files (menu.cfg and grub.cfg) and then I have rebuilt the ISO with cubic but the preseed file has been ignored by the graphical debian installer.
Mario.
Mario Marietto
Oct 11, 2022, 6:00:06 PM10/11/22
to
What is "${loopback}" in the context below ?
if loadfont $prefix/font.pf2 ; then
set gfxmode=800x600set gfxpayload=keep
insmod efi_gop
insmod efi_uga
insmod video_bochs
insmod video_cirrus
insmod gfxterm
insmod png
terminal_output gfxterm
fi
if background_image /isolinux/splash intel_iommu=on.png; then
set color_normal=light-gray/black
set color_highlight=white/black
elif background_image /splash intel_iommu=on.png; then
set color_normal=light-gray/black
set color_highlight=white/black
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
insmod play
play 960 440 1 0 4 440 1
if [ ${iso_path} ] ; then
set loopback="findiso=${iso_path}"
export loopback
fi
menuentry "Debian GNU/Linux Live (kernel 5.10.0-18-amd64)" {
linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash "${loopback}"
initrd /live/initrd.gz
}
initrd /live/initrd.gz
}
Mario.
Greg Wooledge
Oct 11, 2022, 6:10:05 PM10/11/22
to
On Tue, Oct 11, 2022 at 11:55:56PM +0200, Mario Marietto wrote:
> What is "${loopback}" in the context below ?
[...]
> What is "${loopback}" in the context below ?
> insmod play
> play 960 440 1 0 4 440 1
> if [ ${iso_path} ] ; then
> set loopback="findiso=${iso_path}"
> export loopback
> fi
If this is supposed to be a shell script, that "set" is wrong. Remove it.
> play 960 440 1 0 4 440 1
> if [ ${iso_path} ] ; then
> set loopback="findiso=${iso_path}"
> export loopback
> fi
(There are also issues with missing quotes, if this is shell.)
If this is supposed to be internal GRUB language... then carry on.
Mario Marietto
Oct 11, 2022, 6:30:04 PM10/11/22
to
It is on the file /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/grub/grub.cfg,with this content :
The preseed file is still ignored.
Mario.
Mario Marietto
Oct 11, 2022, 6:50:05 PM10/11/22
to
In the end I found the solution. I've added these lines on top of the file : /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/grub/grub.cfg,with this content :
menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash "${loopback}"initrd /d-i/gtk/initrd.gz
}
and the preseed.cfg file has been taken into consideration. Imagination is more powerful than knowledge.
Mario.
Charles Curley
Oct 11, 2022, 7:00:07 PM10/11/22
to
On Tue, 11 Oct 2022 23:35:48 +0200
Mario Marietto <mariet...@gmail.com> wrote:
> > isolinux/menu.cfg
> >
> > LABEL English (en)
> > SAY "Booting English (en)..."
> > linux /live/vmlinuz boot=casper APPEND
> > file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz
> > boot=live components locales=en_US.UTF-8 quiet splash intel_iommu=on
I've never gotten automating finding the preseed file to work.
Mario Marietto <mariet...@gmail.com> wrote:
> > isolinux/menu.cfg
> >
> > LABEL English (en)
> > SAY "Booting English (en)..."
> > linux /live/vmlinuz boot=casper APPEND
> > file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz
> > boot=live components locales=en_US.UTF-8 quiet splash intel_iommu=on
Instead, I boot a USB stick with the netinst installer on it, and the
preseed file (and all my custom stuff) on another USB stick. When the
netinst stick boots, I arrow key down to Help, and select that, to get
the boot prompt. Select the installation I want, typically "expert". Add
"auto file=/media/preseed.cfg".
So it is possible that you should have the "auto" before the "file=".
You might also take the quiet out of there for a more verbose boot.
Once you boot up, you can then examine the boot process in the usual
place, /var/log.
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
Thomas Schmitt
Oct 12, 2022, 2:40:06 AM10/12/22
to
Hi,
Mario Marietto wrote:
> In the end I found the solution.
Congrats.
-------------------------------------------------------------------------
Some remarks on the way to success:
> isolinux/menu.cfg
> LABEL English (en)
> SAY "Booting English (en)..."
> linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
I think "APPEND" should be in an extra line. At least it is so in the
examples which i saw up to now.
> boot/grub/grub.cfg
> menuentry "English (en)" {
I assume that this "APPEND" is handed over to the Linux kernel as
argument, like the others.
> the grub.cfg file
> uses two command lines. The second one is "initrd /live/initrd.gz".
https://www.gnu.org/software/grub/manual/grub/grub.html#initrd
https://www.gnu.org/software/grub/manual/grub/grub.html#linux
> What is "${loopback}" in the context below ?
> linux /live/vmlinuz ... "${loopback}"
Interesting question, again.
> In the end I found the solution.
i still think is not appropriate.
I'd try in any case whether it can be omitted. If this remains as
successful end of this thread, then i fear that future readers might get
confused by it.
Mario Marietto wrote:
> In the end I found the solution.
-------------------------------------------------------------------------
Some remarks on the way to success:
> isolinux/menu.cfg
> LABEL English (en)
> SAY "Booting English (en)..."
> linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
examples which i saw up to now.
> boot/grub/grub.cfg
> menuentry "English (en)" {
> linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
"APPEND" is SYSLINUX/ISOLINUX speech, not GRUB.
I assume that this "APPEND" is handed over to the Linux kernel as
argument, like the others.
> the grub.cfg file
> uses two command lines. The second one is "initrd /live/initrd.gz".
https://www.gnu.org/software/grub/manual/grub/grub.html#linux
> What is "${loopback}" in the context below ?
> set loopback="findiso=${iso_path}"
> export loopback
> ...
> export loopback
> linux /live/vmlinuz ... "${loopback}"
Interesting question, again.
> In the end I found the solution.
> menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
> linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg
I really wonder what the kernel thinks when seeing this "APPEND", of which
> linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg
i still think is not appropriate.
I'd try in any case whether it can be omitted. If this remains as
successful end of this thread, then i fear that future readers might get
confused by it.
Mario Marietto
Oct 12, 2022, 6:10:06 AM10/12/22
to
Actually I'm using only UEFI and the file that I should modify is located on /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/grub/grub.cfg. What works is this :
menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash "${loopback}"
initrd /d-i/gtk/initrd.gz
}
initrd /d-i/gtk/initrd.gz
}
NOT this :
menuentry "English (en)" {
linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash intel_iommu=on "${loopback}"
initrd /live/initrd.gz
}
linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash intel_iommu=on "${loopback}"
initrd /live/initrd.gz
}
I think because the script that detects the presence of the preseed file is inside the /d-i/gtk/initrd.gz and NOT inside /live/initrd.gz. Maybe something like this will work ?
menuentry "English (en)" {
linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg initrd=/d-i/gtk/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash intel_iommu=on "${loopback}"
initrd /d-i/gtk/initrd.gz
}
linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg initrd=/d-i/gtk/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash intel_iommu=on "${loopback}"
initrd /d-i/gtk/initrd.gz
}
or :
menuentry "Graphical Debian Installer" {
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg video=vesa:ywrap,mtrr vga=788 "${loopback}"
initrd /d-i/gtk/initrd.gz
}
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg video=vesa:ywrap,mtrr vga=788 "${loopback}"
initrd /d-i/gtk/initrd.gz
}
I'm not interested in modifying the isolinux / menu.cfg file,so I will remove from there any reference to the preseed.cfg file.
Mario.
Mario Marietto
Oct 12, 2022, 9:20:06 AM10/12/22
to
Hello.
What I haven't understood well is if, in your opinion, this "code" is well written or not :
menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash "${loopback}" initrd /d-i/gtk/initrd.gz
It works,but maybe it can work even if it is not the best way to do it.
Mario.
Thomas Schmitt
Oct 13, 2022, 4:20:06 AM10/13/22
to
Hi,
Mario Marietto wrote:
> What I haven't understood well is if, in your opinion, this "code" is well
> written or not :
>
> menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
> linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash "${loopback}"
> initrd /d-i/gtk/initrd.gz
I doubt that "APPEND" and "initrd=/live/initrd.gz" are appropriate.
As already stated, "APPEND" is a SYSLINUX/ISOLINUX configuration directive
https://wiki.syslinux.org/wiki/index.php?title=Config#APPEND
But you use it as argument to GRUB2's "linux" command, from where i
expect it to become a Linux kernel argument which is not a defined
kernel option.
"initrd=/live/initrd.gz" is a Linux kernel option:
https://docs.kernel.org/admin-guide/initrd.html
This (quite old) document promises that Linux will try to unpack the
cpio image into the RAM disk. But there is no file /live/initrd.gz in the
ISO.
"initrd" in an own line and without "=" is the GRUB2 command to specify
one or more initial ramdisks:
https://www.gnu.org/software/grub/manual/grub/grub.html#initrd
Neither "APPEND" nor an "initrd=" kernel option are to see in the original
GRUB2 configuration of debian-live-11.5.0-amd64-xfce.iso .
So i assume they sneaked in while you were tinkering around with various
inspirations from the internet and came to a ISOLINUX configuration
example.
I advise to try whether your GRUB2 configuration works as well if you
omit them.
Mario Marietto wrote:
> What I haven't understood well is if, in your opinion, this "code" is well
> written or not :
>
> menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
> linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash "${loopback}"
> initrd /d-i/gtk/initrd.gz
As already stated, "APPEND" is a SYSLINUX/ISOLINUX configuration directive
https://wiki.syslinux.org/wiki/index.php?title=Config#APPEND
But you use it as argument to GRUB2's "linux" command, from where i
expect it to become a Linux kernel argument which is not a defined
kernel option.
"initrd=/live/initrd.gz" is a Linux kernel option:
https://docs.kernel.org/admin-guide/initrd.html
This (quite old) document promises that Linux will try to unpack the
cpio image into the RAM disk. But there is no file /live/initrd.gz in the
ISO.
"initrd" in an own line and without "=" is the GRUB2 command to specify
one or more initial ramdisks:
https://www.gnu.org/software/grub/manual/grub/grub.html#initrd
Neither "APPEND" nor an "initrd=" kernel option are to see in the original
GRUB2 configuration of debian-live-11.5.0-amd64-xfce.iso .
So i assume they sneaked in while you were tinkering around with various
inspirations from the internet and came to a ISOLINUX configuration
example.
I advise to try whether your GRUB2 configuration works as well if you
omit them.
Mario Marietto
Oct 13, 2022, 6:40:06 AM10/13/22
to
I've removed the "APPEND file=/cdrom/preseed/preseed.cfg auto=true" parameter(s) from the live menu entry,even because it makes no sense to keep it. The live system does not imply that the user can choose some parameters. It is not an installer at all,all parameters have been decided from the beginning. But I've kept it on the graphical debian installer. In Fact it is already used on the original ISO,as you can see below :
menuentry "Graphical Debian Installer" {
linux /d-i/gtk/vmlinuz append video=vesa:ywrap,mtrr vga=788 "${loopback}"initrd /d-i/gtk/initrd.gz
}
As you can see some parameters have been already appended by default by the debian developers. So I assume that different parameters than those can be appended. So,it becomes like this :
menuentry "Debian Custom Graphical Debian Installer" {
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true video=vesa:ywrap,mtrr vga=788 "${loopback}"
initrd /d-i/gtk/initrd.gz
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true video=vesa:ywrap,mtrr vga=788 "${loopback}"
initrd /d-i/gtk/initrd.gz
Does it make more sense ?
Mario.
Thomas Schmitt
Oct 13, 2022, 7:10:05 AM10/13/22
to
Hi,
> menuentry "Debian Custom Graphical Debian Installer" {
> linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true video=vesa:ywrap,mtrr vga=788 "${loopback}"
> initrd /d-i/gtk/initrd.gz
>
> Does it make more sense ?
In the interest of future readers who seek the same solution as you, i am
much in favor of making only the necessary changes.
But still i stumble over the argument "APPEND".
> menuentry "Debian Custom Graphical Debian Installer" {
> linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true video=vesa:ywrap,mtrr vga=788 "${loopback}"
> initrd /d-i/gtk/initrd.gz
>
> Does it make more sense ?
much in favor of making only the necessary changes.
But still i stumble over the argument "APPEND".
Mario Marietto
Oct 13, 2022, 7:30:06 AM10/13/22
to
ok. If you don't like to append,tell me what you would like to do because I didn't understand.
Mario.
Thomas Schmitt
Oct 13, 2022, 10:30:05 AM10/13/22
to
Hi,
Mario Marietto wrote:
> > > menuentry "Debian Custom Graphical Debian Installer" {
> > > linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true video=vesa:ywrap,mtrr vga=788 "${loopback}"
> > > initrd /d-i/gtk/initrd.gz
> > >
> > > Does it make more sense ?
still does what you expect from it.
(As said, i think you carried it from an ISOLINUX example to the GRUB2
configuration file, were it is not especially interpreted by GRUB2 but
forwarded as kernel option to vmlinuz. There i expect it to be ignored.
But i also expect it to be mistaken as essential by people who are in
the same situation as you were a week ago and searching the web for
solutions.)
Mario Marietto wrote:
> > > menuentry "Debian Custom Graphical Debian Installer" {
> > > linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true video=vesa:ywrap,mtrr vga=788 "${loopback}"
> > > initrd /d-i/gtk/initrd.gz
> > >
> > > Does it make more sense ?
I wrote:
> > still i stumble over the argument "APPEND".
> > still i stumble over the argument "APPEND".
> ok. If you don't like to append,tell me what you would like to do because I
> didn't understand.
Simply remove the argument "APPEND" and then try whether your modified ISO
> didn't understand.
still does what you expect from it.
(As said, i think you carried it from an ISOLINUX example to the GRUB2
configuration file, were it is not especially interpreted by GRUB2 but
forwarded as kernel option to vmlinuz. There i expect it to be ignored.
But i also expect it to be mistaken as essential by people who are in
the same situation as you were a week ago and searching the web for
solutions.)
Mario Marietto
Oct 13, 2022, 11:10:07 AM10/13/22
to
If I remove the argument APPEND,the only other chance that I have to pass the preseed file is to add it inside the initrd file. But this is not the official method suggested by the cubic developers. If you will read on the preseed tab on cubic you will see that they suggest to prefix the preseed file with the word "cdrom" in the boot configuration. This seems to be exactly what I'm doing. And I don't understand why you are talking about ISOLINUX,when I have added the preseed file in another folder,in the /boot/grub.cfg file...and I told you that the preseed file is not ignored anymore from since I have added it on the grub.cfg file.
Mario.
Tixy
Oct 13, 2022, 11:50:05 AM10/13/22
to
On Thu, 2022-10-13 at 17:02 +0200, Mario Marietto wrote:
> If I remove the argument APPEND,the only other chance that I have to pass
> the preseed file is to add it inside the initrd file.
What effect do we think the word 'APPEND' below is having in the grub
> If I remove the argument APPEND,the only other chance that I have to pass
> the preseed file is to add it inside the initrd file.
config file?
menuentry "Debian GNU/Linux Custom (kernel 5.10.0-18-amd64)" {
linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg auto=true initrd=/live/initrd.gz boot=live components locales=en_US.UTF-8 quiet splash "${loopback}"
initrd /d-i/gtk/initrd.gz
the command-line passed to the linux kernel when it boots, and that
there isn't anything that will parse and act on that.
The second argument is "file=/cdrom/preseed/preseed.cfg" and presumably
there is something running after the kernel boots that will act on
that.
Thomas was saying that the word "APPEND" looks superfluous and seems to
have been copied from an example config file for ISOLINUX, not Grub.
Looking at the wiki for ISOLINUX config [1], the "APPEND" command will
append the arguments to the kernel command-line.
[1] https://wiki.syslinux.org/wiki/index.php?title=Directives/append
--
Tixy
>
Thomas Schmitt
Oct 13, 2022, 12:10:06 PM10/13/22
to
Hi,
Mario Marietto wrote:
> ... > menuentry "Debian Custom Graphical Debian Installer" {
> ... > linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg
> If I remove the argument APPEND,the only other chance that I have to pass
> the preseed file is to add it inside the initrd file.
To my understanding this passing is achieved by argument
file=/cdrom/preseed/preseed.cfg
with no need for a preceeding argument "APPEND".
> If you will read on the preseed tab on cubic
For that i'd need to know where this tab is.
> they suggest to prefix the preseed
> file with the word "cdrom" in the boot configuration.
If it works for you then it's a good hint for others.
> And I don't understand why you are talking about ISOLINUX,
Because "APPEND" in a separate line is a SYSLINUX/ISOLINUX configuration
directive and because you wrote on Tue, 11 Oct 2022 23:17:39 +0200:
> ... > I'm trying to modify them as follows :
> ... > isolinux/menu.cfg
> ... > LABEL English (en)
> ... > SAY "Booting English (en)..."
> ... > linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
This is the configuration file for ISOLINUX which boots on legacy BIOS.
(I think it is wrong by not giving APPEND an own line, so that ISOLINUX
would recognize it as configuration directive. See
https://wiki.syslinux.org/wiki/index.php?title=Config
)
On Tue, 11 Oct 2022 12:02:47 +0200 you wrote:
> ... > I would like to be helped by Thomas,because I trust
> ... > in his high level of skills.
Now i want to improve my skills by learning what exactly did the
trick for you. So i ask for the favor that you test whether "APPEND" is
needed for success.
(And further i ask for the favor to give me a link to that Cubic preseed
documentation.)
Mario Marietto wrote:
> ... > menuentry "Debian Custom Graphical Debian Installer" {
> ... > linux /d-i/gtk/vmlinuz APPEND file=/cdrom/preseed/preseed.cfg
auto=true video=vesa:ywrap,mtrr vga=788 "${loopback}"
> ... > initrd /d-i/gtk/initrd.gz
> If I remove the argument APPEND,the only other chance that I have to pass
> the preseed file is to add it inside the initrd file.
file=/cdrom/preseed/preseed.cfg
with no need for a preceeding argument "APPEND".
> If you will read on the preseed tab on cubic
> they suggest to prefix the preseed
> file with the word "cdrom" in the boot configuration.
> And I don't understand why you are talking about ISOLINUX,
directive and because you wrote on Tue, 11 Oct 2022 23:17:39 +0200:
> ... > I'm trying to modify them as follows :
> ... > isolinux/menu.cfg
> ... > LABEL English (en)
> ... > SAY "Booting English (en)..."
> ... > linux /live/vmlinuz boot=casper APPEND file=/cdrom/preseed/preseed.cfg
This is the configuration file for ISOLINUX which boots on legacy BIOS.
(I think it is wrong by not giving APPEND an own line, so that ISOLINUX
would recognize it as configuration directive. See
https://wiki.syslinux.org/wiki/index.php?title=Config
)
On Tue, 11 Oct 2022 12:02:47 +0200 you wrote:
> ... > I would like to be helped by Thomas,because I trust
> ... > in his high level of skills.
Now i want to improve my skills by learning what exactly did the
trick for you. So i ask for the favor that you test whether "APPEND" is
needed for success.
(And further i ask for the favor to give me a link to that Cubic preseed
documentation.)
Mario Marietto
Oct 13, 2022, 2:50:05 PM10/13/22
to
You are right. It works without using the APPEND option,like this : (inside the file grub.cfg)
menuentry "Custom Graphical Debian Installer" {
linux /d-i/gtk/vmlinuz file=/cdrom/preseed/preseed.cfg auto=true video=vesa:ywrap,mtrr vga=788 "${loopback}"
initrd /d-i/gtk/initrd.gz
linux /d-i/gtk/vmlinuz file=/cdrom/preseed/preseed.cfg auto=true video=vesa:ywrap,mtrr vga=788 "${loopback}"
initrd /d-i/gtk/initrd.gz
}
anyway,I don't know if it's correct to use something like this in the ISOLINUX/menu.cfg file :
LABEL Custom Graphical Debian Installer
SAY "Booting Custom Graphical Debian Installer..."
linux /d-i/gtk/vmlinuz
APPEND boot=casper file=/cdrom/preseed/preseed.cfg auto=true initrd=/d-i/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788
SAY "Booting Custom Graphical Debian Installer..."
linux /d-i/gtk/vmlinuz
APPEND boot=casper file=/cdrom/preseed/preseed.cfg auto=true initrd=/d-i/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788
the APPEND parameter that you see was there by default. Is that correct ? Otherwise,is something like this ok ?
linux /d-i/gtk/vmlinuz boot=casper file=/cdrom/preseed/preseed.cfg auto=true initrd=/d-i/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788
Mario.
Thomas Schmitt
Oct 13, 2022, 3:20:05 PM10/13/22
to
Hi,
Mario Marietto wrote:
> You are right. It works without using the APPEND option
Yeah. Once again guessed right. :))
> I don't know if it's correct to use something like this in the
ISOLINUX/menu.cfg file :
> LABEL Custom Graphical Debian Installer
> SAY "Booting Custom Graphical Debian Installer..."
> linux /d-i/gtk/vmlinuz
> APPEND boot=casper file=/cdrom/preseed/preseed.cfg auto=true initrd=/d-i/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788
(I think there is again a surplus "append" in the "APPEND" line.)
Let's read
https://wiki.syslinux.org/wiki/index.php?title=Config
"APPEND options...
Add one or more options to the kernel command line. These are added
to both, automatic and manual boots. The options are added at the
very beginning of the kernel command line, usually permitting
explicitly-entered kernel options to override them. This is the
equivalent of the LILO "append" option.
...
LINUX image
Load image as a Linux-like kernel. MEMDISK is an example of a non-Linux
kernel loaded in a Linux-like fashion."
So with ISOLINUX, one has to add the kernel arguments by APPEND and the
initrd by kernel argument "initrd=".
With GRUB2 one adds the kernel arguments to the "linux" command line but
the initrd is specified by a separate "initrd" command.
(Further there are still Legacy GRUB configuration examples around
in files named "menu.lst".)
> Otherwise,is something like this ok ?
> linux /d-i/gtk/vmlinuz boot=casper file=/cdrom/preseed/preseed.cfg auto=true initrd=/d-i/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788
Only if i ignore the surplus "append". :))
Then i stumble over "boot=casper".
The text
https://www.kernel.org/doc/html/v5.10/admin-guide/kernel-parameters.html
does not list a "boot=" option.
It might be that some software in the Live ISO looks into something like
the pseudo-file
/proc/cmdline
and acts if it finds "boot=casper" in the content of line "BOOT_IMAGE=".
Mario Marietto wrote:
> You are right. It works without using the APPEND option
> I don't know if it's correct to use something like this in the
ISOLINUX/menu.cfg file :
> LABEL Custom Graphical Debian Installer
> SAY "Booting Custom Graphical Debian Installer..."
> linux /d-i/gtk/vmlinuz
> APPEND boot=casper file=/cdrom/preseed/preseed.cfg auto=true initrd=/d-i/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788
Let's read
https://wiki.syslinux.org/wiki/index.php?title=Config
"APPEND options...
Add one or more options to the kernel command line. These are added
to both, automatic and manual boots. The options are added at the
very beginning of the kernel command line, usually permitting
explicitly-entered kernel options to override them. This is the
equivalent of the LILO "append" option.
...
LINUX image
Load image as a Linux-like kernel. MEMDISK is an example of a non-Linux
kernel loaded in a Linux-like fashion."
So with ISOLINUX, one has to add the kernel arguments by APPEND and the
initrd by kernel argument "initrd=".
With GRUB2 one adds the kernel arguments to the "linux" command line but
the initrd is specified by a separate "initrd" command.
(Further there are still Legacy GRUB configuration examples around
in files named "menu.lst".)
> Otherwise,is something like this ok ?
> linux /d-i/gtk/vmlinuz boot=casper file=/cdrom/preseed/preseed.cfg auto=true initrd=/d-i/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788
Then i stumble over "boot=casper".
The text
https://www.kernel.org/doc/html/v5.10/admin-guide/kernel-parameters.html
does not list a "boot=" option.
It might be that some software in the Live ISO looks into something like
the pseudo-file
/proc/cmdline
and acts if it finds "boot=casper" in the content of line "BOOT_IMAGE=".
Mario Marietto
Oct 13, 2022, 4:10:05 PM10/13/22
to
Is it like this ?
LABEL Custom Graphical Debian Installer
SAY "Booting Custom Graphical Debian Installer..."
linux /d-i/gtk/vmlinuz
SAY "Booting Custom Graphical Debian Installer..."
linux /d-i/gtk/vmlinuz
APPEND file=/cdrom/preseed/preseed.cfg auto=true initrd=/d-i/gtk/initrd.gz video=vesa:ywrap,mtrr vga=788
anyway,using another append shouldn't be wrong because the debian developers used,not me,in this way :
LABEL Graphical Debian Installer
SAY "Booting Graphical Debian Installer..."
linux /d-i/gtk/vmlinuz
APPEND initrd=/d-i/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788
SAY "Booting Graphical Debian Installer..."
linux /d-i/gtk/vmlinuz
APPEND initrd=/d-i/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788
but it is also true that here they have omitted it :
LABEL Debian Installer with Speech Synthesis
SAY "Booting Debian Installer with Speech Synthesis..."
linux /d-i/gtk/vmlinuz
SAY "Booting Debian Installer with Speech Synthesis..."
linux /d-i/gtk/vmlinuz
APPEND initrd=/d-i/gtk/initrd.gz speakup.synth=soft
so,I don't know. Maybe both the solutions should be ok.
Mario.
Thomas Schmitt
Oct 13, 2022, 4:40:05 PM10/13/22
to
Hi,
Mario Marietto wrote:
> anyway,using another append shouldn't be wrong because the debian developers
> used,not me,in this way
Oh. In this case we should not bet against their wisdom.
If it is by mistake, then it is harmless and heavily tested during the
last years.
(Regrettably i have not many old Live ISOs and half of them are "standard",
i.e. without GUI. I see the line with the unexplained "append" in
debian-live-9.2.0-amd64-cinnamon.iso .
Maybe one of the subscribed DDs has nostalgic memories from the time when
the graphic installer was introduced ?)
Mario Marietto wrote:
> anyway,using another append shouldn't be wrong because the debian developers
> used,not me,in this way
If it is by mistake, then it is harmless and heavily tested during the
last years.
(Regrettably i have not many old Live ISOs and half of them are "standard",
i.e. without GUI. I see the line with the unexplained "append" in
debian-live-9.2.0-amd64-cinnamon.iso .
Maybe one of the subscribed DDs has nostalgic memories from the time when
the graphic installer was introduced ?)
Mario Marietto
Oct 13, 2022, 5:00:06 PM10/13/22
to
😂
Mario.
Mario Marietto
Oct 15, 2022, 2:50:06 PM10/15/22
to
Hello to everyone.
I'm trying to customize the debian 11 and I'm creating a derivative distro for debian 11. I've changed a lot of logos,images and pictures,but not everything. For example I'm not able to understand which file belongs to the image and the logo that you see in this picture : https://ibb.co/SvbvsyR ; thanks.
Mario.
Mario Marietto
Oct 15, 2022, 5:10:05 PM10/15/22
to
Hello.
I have understood that the graphic files I need to change are inside the file called "initrd.gz" that's inside this folder :
/home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/d-i/gtk/
I should decompress it and I will have the file called "initrd",that's a cpio file. The images that I should edit are inside this archive / folders :
initrd/usr/share/graphics
and they are called : logo_debian.png and logo_debian_dark.png ;
at this point this is what I did to add two new image files inside the archive in the same position of the old ones :
chmod +w -R /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/d-i/gtk/
echo logo_debian_dark.png | cpio -H newc -o -A -F initrd/usr/share/graphics
but unfortunately this is not the proper command to issue :
cpio: can't open initrd/usr/share/graphics: Is not a directory
how to fix that ?
Mario.
Thomas Schmitt
Oct 16, 2022, 5:00:06 AM10/16/22
to
Hi,
Mario Marietto wrote:
> echo logo_debian_dark.png | cpio -H newc -o -A -F initrd/usr/share/graphics
to the uncompressed initrd.
> The images that I should edit are inside this archive / folders :
> initrd/usr/share/graphics
Are you sure about the first path component "initrd/" ?
I see the path without it:
$ gunzip < /mnt/iso/d-i/gtk/initrd.gz | cpio -t | fgrep logo_debian_dark.png
264529 blocks
usr/share/graphics/logo_debian_dark.png
So i expect that you want to create a new copy of that file inside the
initrd. If so, then you have to write its desired path into stdin of cpio
echo usr/share/graphics/logo_debian_dark.png | cpio -H newc -o -A -F \
/home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/d-i/gtk/initrd
Since cpio seems to offer no opportunities for grafting files to arbitrary
paths, you have to cd to some playground directory, create the directories
of the path usr/share/graphics/, and put your .png into the "graphics"
directory. Then run above echo|cpio pipe.
Mario Marietto wrote:
> echo logo_debian_dark.png | cpio -H newc -o -A -F initrd/usr/share/graphics
> cpio: can't open initrd/usr/share/graphics: Is not a directory
cpio option -F expects the path to the archive as argument. I.e. the path
to the uncompressed initrd.
> The images that I should edit are inside this archive / folders :
> initrd/usr/share/graphics
I see the path without it:
$ gunzip < /mnt/iso/d-i/gtk/initrd.gz | cpio -t | fgrep logo_debian_dark.png
264529 blocks
usr/share/graphics/logo_debian_dark.png
So i expect that you want to create a new copy of that file inside the
initrd. If so, then you have to write its desired path into stdin of cpio
echo usr/share/graphics/logo_debian_dark.png | cpio -H newc -o -A -F \
/home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/d-i/gtk/initrd
Since cpio seems to offer no opportunities for grafting files to arbitrary
paths, you have to cd to some playground directory, create the directories
of the path usr/share/graphics/, and put your .png into the "graphics"
directory. Then run above echo|cpio pipe.
Mario Marietto
Oct 16, 2022, 11:30:06 AM10/16/22
to
Thanks very much. It worked : https://ibb.co/GHHDQ3H ; I'm at a good point by creating this derivative debian distro.
Mario.
David Wright
Oct 16, 2022, 2:20:05 PM10/16/22
to
On Sun 16 Oct 2022 at 17:24:05 (+0200), Mario Marietto wrote:
> Il giorno dom 16 ott 2022 alle ore 10:50 Thomas Schmitt ha scritto:
> > >
> > > initrd/usr/share/graphics
> > >
should give names to your edited files that indicate what they are:
/your/ images for /your/ derivative. Add them to the archive and
change the symlinks there. You should end up with something like:
drwxr-xr-x 2 root root 0 Mar 22 2022 usr/share/graphics
-rw-r--r-- 1 root root 14649 Feb 15 2021 usr/share/graphics/logo_debian.png
-rw-r--r-- 1 root root 14649 Feb 15 2021 usr/share/graphics/logo_debian_dark.png
-rw-r--r-- 1 root root 12345 Oct 15 23:59 usr/share/graphics/logo_marietto.png
-rw-r--r-- 1 root root 12345 Oct 15 23:59 usr/share/graphics/logo_marietto_dark.png
lrwxrwxrwx 1 root root 15 Feb 15 2021 usr/share/graphics/logo_installer.png -> logo_marietto.png
lrwxrwxrwx 1 root root 20 Feb 15 2021 usr/share/graphics/logo_installer_dark.png -> logo_marietto_dark.png
> > If so, then you have to write its desired path into stdin of cpio
> >
> > echo usr/share/graphics/logo_debian_dark.png | cpio -H newc -o -A -F \
> >
> > /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/d-i/gtk/initrd
> >
> > Since cpio seems to offer no opportunities for grafting files to arbitrary
> > paths, you have to cd to some playground directory, create the directories
> > of the path usr/share/graphics/, and put your .png into the "graphics"
> > directory. Then run above echo|cpio pipe.
>
David.
> Il giorno dom 16 ott 2022 alle ore 10:50 Thomas Schmitt ha scritto:
> > On Sat 15 Oct 2022 at 23:03:41 (+0200), Mario Marietto wrote:
> > > echo logo_debian_dark.png | cpio -H newc -o -A -F initrd/usr/share/graphics
> > > cpio: can't open initrd/usr/share/graphics: Is not a directory
> >
> > cpio option -F expects the path to the archive as argument. I.e. the path
> > to the uncompressed initrd.
> >
> > > The images that I should edit are inside this archive / folders :
> > > initrd/usr/share/graphics
> >
> > Are you sure about the first path component "initrd/" ?
> > I see the path without it:
> >
> > $ gunzip < /mnt/iso/d-i/gtk/initrd.gz | cpio -t | fgrep
> > logo_debian_dark.png
> > 264529 blocks
> > usr/share/graphics/logo_debian_dark.png
> >
> > > echo logo_debian_dark.png | cpio -H newc -o -A -F initrd/usr/share/graphics
> > > cpio: can't open initrd/usr/share/graphics: Is not a directory
> >
> > cpio option -F expects the path to the archive as argument. I.e. the path
> > to the uncompressed initrd.
> >
> > > The images that I should edit are inside this archive / folders :
> > > initrd/usr/share/graphics
> >
> > Are you sure about the first path component "initrd/" ?
> > I see the path without it:
> >
> > $ gunzip < /mnt/iso/d-i/gtk/initrd.gz | cpio -t | fgrep
> > logo_debian_dark.png
> > 264529 blocks
> > usr/share/graphics/logo_debian_dark.png
> >
> > > I should decompress it and I will have the file called "initrd",that's a
> > > cpio file. The images that I should edit are inside this archive / folders :
> > >
> > > initrd/usr/share/graphics
> > >
> > > and they are called : logo_debian.png and logo_debian_dark.png ;
> > >
> > > at this point this is what I did to add two new image files inside the
> > > archive in the same position of the old ones :
> >
> > >
> > > at this point this is what I did to add two new image files inside the
> > > archive in the same position of the old ones :
> >
> > So i expect that you want to create a new copy of that file inside the
> > initrd.
No, that would be dishonest: they are no longer Debian logos. You
> > initrd.
should give names to your edited files that indicate what they are:
/your/ images for /your/ derivative. Add them to the archive and
change the symlinks there. You should end up with something like:
drwxr-xr-x 2 root root 0 Mar 22 2022 usr/share/graphics
-rw-r--r-- 1 root root 14649 Feb 15 2021 usr/share/graphics/logo_debian.png
-rw-r--r-- 1 root root 14649 Feb 15 2021 usr/share/graphics/logo_debian_dark.png
-rw-r--r-- 1 root root 12345 Oct 15 23:59 usr/share/graphics/logo_marietto.png
-rw-r--r-- 1 root root 12345 Oct 15 23:59 usr/share/graphics/logo_marietto_dark.png
lrwxrwxrwx 1 root root 15 Feb 15 2021 usr/share/graphics/logo_installer.png -> logo_marietto.png
lrwxrwxrwx 1 root root 20 Feb 15 2021 usr/share/graphics/logo_installer_dark.png -> logo_marietto_dark.png
> > If so, then you have to write its desired path into stdin of cpio
> >
> > echo usr/share/graphics/logo_debian_dark.png | cpio -H newc -o -A -F \
> >
> > /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/d-i/gtk/initrd
> >
> > Since cpio seems to offer no opportunities for grafting files to arbitrary
> > paths, you have to cd to some playground directory, create the directories
> > of the path usr/share/graphics/, and put your .png into the "graphics"
> > directory. Then run above echo|cpio pipe.
>
> Thanks very much. It worked : https://ibb.co/GHHDQ3H ; I'm at a good point
> by creating this derivative debian distro.
Cheers,
> by creating this derivative debian distro.
David.
Thomas Schmitt
Oct 17, 2022, 7:50:05 AM10/17/22
to
Hi,
David Wright wrote:
> they are no longer Debian logos. You
> should give names to your edited files that indicate what they are:
> /your/ images for /your/ derivative. Add them to the archive and
> change the symlinks there.
I found
https://wiki.debian.org/Derivatives/Guidelines
which Mario Marietto should check.
Naming of files is not mentioned, afaics.
But there is much emphasis on not using "Debian" in the name of the
"business". This demand applies to various software packages and artwork,
too:
https://wiki.debian.org/Derivatives/Guidelines#De-.2FRe-branding
I wonder whether a preseeded Debian Live ISO constitutes a derived distro
and Mario Marietto's preseeding project qualifies as "business".
The changes of which i know use an official Debian mechanism to shorten
or hardcode the installation process. The Live personality is completely
unchanged, afaik.
So for now the only non-Debian thing is the title
"BridgeVmOS Debian Custom"
in
https://ibb.co/GHHDQ3H
It looks like a project name and thus could be regarded as "business".
I wonder whether a title like
"Debian , preseeded by BridgeVmOS"
would be ok.
Well, before following the Guideline advise
"Consult the DebianProjectLeader meanwhile on a case-by-case basis"
Mario Marietto should probably list the changes in his ISO towards the
original ISO. I know of:
- Introducing a preseed file.
- Changing logo files in the initrd.
- (Packing up the ISO with xorrisofs options which are equivalent to
those currently used by Debian Live, as far as boot capabilities are
concerned. But Debian could move to other layouts for booting.)
Such a list could then be the base of decisions.
David Wright wrote:
> they are no longer Debian logos. You
> should give names to your edited files that indicate what they are:
> /your/ images for /your/ derivative. Add them to the archive and
> change the symlinks there.
https://wiki.debian.org/Derivatives/Guidelines
which Mario Marietto should check.
Naming of files is not mentioned, afaics.
But there is much emphasis on not using "Debian" in the name of the
"business". This demand applies to various software packages and artwork,
too:
https://wiki.debian.org/Derivatives/Guidelines#De-.2FRe-branding
I wonder whether a preseeded Debian Live ISO constitutes a derived distro
and Mario Marietto's preseeding project qualifies as "business".
The changes of which i know use an official Debian mechanism to shorten
or hardcode the installation process. The Live personality is completely
unchanged, afaik.
So for now the only non-Debian thing is the title
"BridgeVmOS Debian Custom"
in
https://ibb.co/GHHDQ3H
It looks like a project name and thus could be regarded as "business".
I wonder whether a title like
"Debian , preseeded by BridgeVmOS"
would be ok.
Well, before following the Guideline advise
"Consult the DebianProjectLeader meanwhile on a case-by-case basis"
Mario Marietto should probably list the changes in his ISO towards the
original ISO. I know of:
- Introducing a preseed file.
- Changing logo files in the initrd.
- (Packing up the ISO with xorrisofs options which are equivalent to
those currently used by Debian Live, as far as boot capabilities are
concerned. But Debian could move to other layouts for booting.)
Such a list could then be the base of decisions.
Mario Marietto
Oct 17, 2022, 12:40:05 PM10/17/22
to
Hello to everyone.
I'm building my debian derivative distro not for business purposes,but to be useful to someone. Maybe I will ask for some money as a donation,but I'm not even sure. When I will have created the first stable version,I will put it in my github with all the scripts that I have added inside the ISO image. I've read the guidelines and I've asked for clarifications to the legal debian department. They seemed to be very open in relation with the Debian logo usage,because it is open source,contrary to that of Ubuntu / Canonical and so I've chosen Debian. Since my goal is not to earn money,I put the emphasis on the name of "my" distro,but at the same time I kept the word Debian inside. It does not seem that this behavior is against some rules. What do you think ? I'm not using a complicated preseed file. I'm using more configuration files ad hoc for the goal that I want to achieve (to create a debian distro ready for passing thru every nvidia gpu which work out of the box + various tools for achieving that goal and some premade configurations to use different kind of virtualization tools). I want to share the project with you,also. When I am satisfied,I will put the first ISO on my github + all the config files added and I would like to know what you think about it. To be honest,the Debian representative that I'm talking with does not reply fast and he / she does not seem to ask a decent amount of details.
Mario.
Andrew M.A. Cater
Oct 17, 2022, 2:00:05 PM10/17/22
to
[Title of the mail changed to reflect a new subject and topic following
the suggestions in the FAQ and mailing list code of conduct.]
Forwarded to the list as I sent this only to Mario by mistake.
On Mon, Oct 17, 2022 at 06:29:45PM +0200, Mario Marietto wrote:
> Hello to everyone.
>
Hi Mario,
> I'm building my debian derivative distro not for business purposes,but to
> be useful to someone. Maybe I will ask for some money as a donation,but I'm
> not even sure. When I will have created the first stable version,I will put
> it in my github with all the scripts that I have added inside the ISO
> image.
Money isn't really the issue here.
Don't forget about the need to comply with licences on distribution of
source and so on. Do track _exactly_ the changes you make from Debian -
it will help you enormously.
> I've read the guidelines and I've asked for clarifications to the
> legal debian department. They seemed to be very open in relation with the
> Debian logo usage,because it is open source,contrary to that of Ubuntu /
> Canonical and so I've chosen Debian.
See also the Debian trademark guidelines: https://www.debian.org/trademark
> Since my goal is not to earn money,I
> put the emphasis on the name of "my" distro,but at the same time I kept the
> word Debian inside. It does not seem that this behavior is against some
> rules. What do you think ?
You do need to chat to the trademark folks - Debian is usually fairly open
but it is important to get it right. Debian holds trademarks in the US, EU
China and Japan as a minimum. https://www.debian.org/trademark#trademarks
> I'm not using a complicated preseed file. I'm
> using more configuration files ad hoc for the goal that I want to achieve
> (to create a debian distro ready for passing thru every nvidia gpu which
> work out of the box + various tools for achieving that goal and some
> premade configurations to use different kind of virtualization tools).
You need to be very careful indeed that you can distribute all the code you
need to do this: you may also need to talk to Nvidia to work out how to get
them to distribute firmware updates and so on to you.
Likewise for the visualisation tools - many of these are proprietary and you'll
need to be able to distribute these to your users and also be absolutely clear
that distributing them together on the same media doesn't upset any of the
individual vendors.
> I
> want to share the project with you,also. When I am satisfied,I will put the
> first ISO on my github + all the config files added and I would like to
> know what you think about it. To be honest,the Debian representative that
> I'm talking with does not reply fast and he / she does not seem to ask a
> decent amount of details.
I think you need to check really clearly what the references on the Debian
wiki give: I think you need to think carefully about how much you want to
commit to this. If it didn't involve debian-live AND non-free code, I'd
suggest that you talked closely to others about making this a Debian Pure
Blend. As it is, I don't think that's an option.
There's a lot to do as well as you possibly can before you can pass the
results of your work to a single user, I'm afraid. Debian-legal folk will
respond but you may need to be absolutely clear in your own mind exactly
what you're doing and the extent to which your learning curve will
get steeper to produce the solution. You may also want to talk to folk who
Ot you're doing and the extent to which your learning curve will
get steeper to produce the solution. You may also want to talk to folk who
are already building and distributing distributions based on Debian-live.
Distrowatch.com may help - LWN's distribtion's page is now almost a year out
of date - but both of these may provide pointers to others who've done this
before you.
With every good wish, as ever,
Andy Cater
the suggestions in the FAQ and mailing list code of conduct.]
Forwarded to the list as I sent this only to Mario by mistake.
On Mon, Oct 17, 2022 at 06:29:45PM +0200, Mario Marietto wrote:
> Hello to everyone.
>
Hi Mario,
> I'm building my debian derivative distro not for business purposes,but to
> be useful to someone. Maybe I will ask for some money as a donation,but I'm
> not even sure. When I will have created the first stable version,I will put
> it in my github with all the scripts that I have added inside the ISO
> image.
Don't forget about the need to comply with licences on distribution of
source and so on. Do track _exactly_ the changes you make from Debian -
it will help you enormously.
> I've read the guidelines and I've asked for clarifications to the
> legal debian department. They seemed to be very open in relation with the
> Debian logo usage,because it is open source,contrary to that of Ubuntu /
> Canonical and so I've chosen Debian.
> Since my goal is not to earn money,I
> put the emphasis on the name of "my" distro,but at the same time I kept the
> word Debian inside. It does not seem that this behavior is against some
> rules. What do you think ?
but it is important to get it right. Debian holds trademarks in the US, EU
China and Japan as a minimum. https://www.debian.org/trademark#trademarks
> I'm not using a complicated preseed file. I'm
> using more configuration files ad hoc for the goal that I want to achieve
> (to create a debian distro ready for passing thru every nvidia gpu which
> work out of the box + various tools for achieving that goal and some
> premade configurations to use different kind of virtualization tools).
need to do this: you may also need to talk to Nvidia to work out how to get
them to distribute firmware updates and so on to you.
Likewise for the visualisation tools - many of these are proprietary and you'll
need to be able to distribute these to your users and also be absolutely clear
that distributing them together on the same media doesn't upset any of the
individual vendors.
> I
> want to share the project with you,also. When I am satisfied,I will put the
> first ISO on my github + all the config files added and I would like to
> know what you think about it. To be honest,the Debian representative that
> I'm talking with does not reply fast and he / she does not seem to ask a
> decent amount of details.
wiki give: I think you need to think carefully about how much you want to
commit to this. If it didn't involve debian-live AND non-free code, I'd
suggest that you talked closely to others about making this a Debian Pure
Blend. As it is, I don't think that's an option.
There's a lot to do as well as you possibly can before you can pass the
results of your work to a single user, I'm afraid. Debian-legal folk will
respond but you may need to be absolutely clear in your own mind exactly
what you're doing and the extent to which your learning curve will
get steeper to produce the solution. You may also want to talk to folk who
Ot you're doing and the extent to which your learning curve will
get steeper to produce the solution. You may also want to talk to folk who
are already building and distributing distributions based on Debian-live.
Distrowatch.com may help - LWN's distribtion's page is now almost a year out
of date - but both of these may provide pointers to others who've done this
before you.
With every good wish, as ever,
Andy Cater
Mario Marietto
Oct 17, 2022, 2:20:05 PM10/17/22
to
It seems complicated to understand what I can do and what I can't. So,my idea is to prepare everything and then I will give my github repo (maybe configured as a private repo) to a debian legal representative hoping that he/she will tell me precisely where the project needs to be changed. But I also think that before talking with them,I need that some experienced user tries to pass his nvidia gpu installing "my" distro,to be sure that it works. What do you think ?
Mario.
Curt
Oct 18, 2022, 8:40:06 AM10/18/22
to
On 2022-10-17, Mario Marietto <mariet...@gmail.com> wrote:
>
> Hello to everyone.
>
> I'm building my debian derivative distro not for business purposes,but to
> be useful to someone. Maybe I will ask for some money as a donation,but I'm
In what way would it be more useful, or useful in a different way for
>
> Hello to everyone.
>
> I'm building my debian derivative distro not for business purposes,but to
> be useful to someone. Maybe I will ask for some money as a donation,but I'm
different purposes, than Debian itself?
I didn't read the entirety of your voluminous and verbose thread, so
maybe I missed this fundamental precision somewhere buried within its
depths.
Mario Marietto
Oct 18, 2022, 9:40:06 AM10/18/22
to
Your last comment does not seem to be properly nice,when you say "your verbose thread". Anyway,this is what you missed : "I want to achieve (to create a debian distro ready for
passing through every nvidia gpu which works out of the box + various tools
for achieving that goal and some pre-made configurations to use different
kinds of virtualization tools". This is because the basic debian ISO is not configured to do that and I see that a lot of users usually onfigures their installed OS manually. But since this takes time,I've thought about preparing a whole Debian ISO that does it automatically,only with a little effort by the users.
Mario.
Mario Marietto
Oct 21, 2022, 7:10:06 PM10/21/22
to
Hello again to everyone. I've tried many times to change the pictures that I'd previously added inside the initrd file located inside the folder "/home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/live/initrd" of my "BridgeVmOS-live-11.5.0-2022.10.07-amd64-xfce.iso" image file and it seems that the new pictures stick inside the cpio archive,but only until I "burn" a new ISO image with Cubic. The problem occurs after having burnt the new ISO image file created with CUBIC. When I look inside the folder / live / initrd.gz/ initrd / usr / share / plymouth / themes / homeworld , I don't see the new pictures,but I still see the older ones,the images that I have added inside the archive some time ago. Likely I forgot some crucial steps I did in the past. To achieve the goal I'm issuing the following commands :
mkdir -p /usr/share/plymouth/themes/homeworld
cp debian.png /usr/share/plymouth/themes/homeworld
chmod +w -R /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/live
gunzip /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/live/initrd.gz
echo /usr/share/plymouth/themes/homeworld/logo.png | cpio -H newc -o -A -F /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/live/initrd
echo /usr/share/plymouth/themes/homeworld/debian.png | cpio -H newc -o -A -F /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/live/initrd
gzip initrd
chmod -w -R /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/live
Can someone give me a look if there are some mistakes between those commands ?
Furthermore,I would like to know how to remove a file that's stored inside a cpio archive (in this case initrd / initrd.gz),because after some intense searching I didn't find what could be the method. I've only read a lot of complicated and useless instructions. The problem is that the archive is always configured read only even if I set it +w. It does not let me remove or drag and drop any file from outside to inside of it. Thanks to everyone.
Mario.
Mario Marietto
Oct 21, 2022, 7:50:05 PM10/21/22
to
At least I found what's the correct command to issue :
echo /usr/share/plymouth/debian-logo.png | cpio -H newc -o -A -F initrd
Below you can see what's the real problem : inside the archive there are two files with the same name. They seem to be different because their kb are different,but I have opened both files with "engrampa" and I saw that they are the same picture. I really don't understand this bizarre behavior : ----> https://ibb.co/CQgpHYm
Mario.
David Wright
Oct 22, 2022, 12:20:05 AM10/22/22
to
On Sat 22 Oct 2022 at 01:46:05 (+0200), Mario Marietto wrote:
>
> Below you can see what's the real problem : inside the archive there are
> two files with the same name. They seem to be different because their kb
> are different,but I have opened both files with "engrampa" and I saw that
> they are the same picture. I really don't understand this bizarre behavior
I think you've missed the fact that cpio's lineage is a /tape/ archive,
>
> Below you can see what's the real problem : inside the archive there are
> two files with the same name. They seem to be different because their kb
> are different,but I have opened both files with "engrampa" and I saw that
> they are the same picture. I really don't understand this bizarre behavior
not a random access device. Demonstration using some small well-known
files that have been copied into /tmp/:
$ find /tmp/resolv.conf /tmp/papersize /tmp/networks -print | cpio -ov > arc.cpio
/tmp/resolv.conf
/tmp/papersize
/tmp/networks
1 block
$
# Overwrite papersize with new contents:
$ cp -ip /etc/host.conf /tmp/papersize
cp: overwrite '/tmp/papersize'? y
$
# Now add the papersize file again, but with its new contents:
$ find /tmp/papersize -print | cpio -ov -A -F arc.cpio
/tmp/papersize
1 block
$
# Listing:
$ cpio -t < arc.cpio
/tmp/resolv.conf
/tmp/papersize
/tmp/networks
/tmp/papersize
1 block
$
# Extract papersize:
$ cpio -iv --to-stdout /tmp/papersize < arc.cpio
letter
/tmp/papersize
multi on
/tmp/papersize
1 block
$
# Both copies are there. Dump the entire "tape":
$ hex arc.cpio
00000000 c7 71 05 08 ba ff a4 81 e8 03 e8 03 01 00 00 00 |.q..............|
00000010 53 63 e7 41 11 00 00 00 17 00 2f 74 6d 70 2f 72 |Sc.A....../tmp/r|
00000020 65 73 6f 6c 76 2e 63 6f 6e 66 00 00 6e 61 6d 65 |esolv.conf..name|
00000030 73 65 72 76 65 72 20 31 39 32 2e 31 36 38 2e 31 |server 192.168.1|
00000040 2e 31 0a 00 c7 71 05 08 bb ff a4 81 e8 03 e8 03 |.1...q..........|
00000050 01 00 00 00 5b 62 c6 75 0f 00 00 00 07 00 2f 74 |....[b.u....../t|
00000060 6d 70 2f 70 61 70 65 72 73 69 7a 65 00 00 6c 65 |mp/papersize..le|
00000070 74 74 65 72 0a 00 c7 71 05 08 bc ff a4 81 e8 03 |tter...q........|
00000080 e8 03 01 00 00 00 5b 62 60 6d 0e 00 00 00 3c 00 |......[b`m....<.|
00000090 2f 74 6d 70 2f 6e 65 74 77 6f 72 6b 73 00 64 65 |/tmp/networks.de|
000000a0 66 61 75 6c 74 09 09 30 2e 30 2e 30 2e 30 0a 6c |fault..0.0.0.0.l|
000000b0 6f 6f 70 62 61 63 6b 09 31 32 37 2e 30 2e 30 2e |oopback.127.0.0.|
000000c0 30 0a 6c 69 6e 6b 2d 6c 6f 63 61 6c 09 31 36 39 |0.link-local.169|
000000d0 2e 32 35 34 2e 30 2e 30 0a 0a c7 71 05 08 bb ff |.254.0.0...q....|
000000e0 a4 81 e8 03 e8 03 01 00 00 00 d7 44 e1 74 0f 00 |...........D.t..|
000000f0 00 00 09 00 2f 74 6d 70 2f 70 61 70 65 72 73 69 |..../tmp/papersi|
00000100 7a 65 00 00 6d 75 6c 74 69 20 6f 6e 0a 00 c7 71 |ze..multi on...q|
00000110 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 |................|
00000120 00 00 0b 00 00 00 00 00 54 52 41 49 4c 45 52 21 |........TRAILER!|
00000130 21 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |!!..............|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
$
Cheers,
David.
Thomas Schmitt
Oct 22, 2022, 3:10:05 AM10/22/22
to
Hi,
Mario Marietto wrote:
> echo /usr/share/plymouth/themes/homeworld/logo.png | cpio -H newc -o -A -F
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/live/initrd
Didn't you strive for manipulating the initrd in /d-i/gtk/initrd.gz of
the ISO ?
(Are you still with debian-live-11.5.0-amd64-xfce.iso , where i see
no /live/initrd.gz but /live/initrd.img-5.10.0-18-amd64 ?)
> echo /usr/share/plymouth/debian-logo.png | cpio -H newc -o -A -F initrd
I see in both initrds only relative paths.
In /live/initrd.img-5.10.0-18-amd64 :
.
bin
conf
conf/arch.conf
In /d-i/gtk/initrd.gz :
bin
bin/anna
bin/anna-install
So i would strive for such a path with the appended file:
cd / ; echo usr/share/plymouth/debian-logo.png | cpio ...
> Furthermore,I would like to know how to remove a file that's stored inside a
> cpio archive
For that you have to unpack the cpio archive, do the desired manipulations,
and pack up the archive from the manipulated tree.
(This will also avoid multiple occurences of the same file path, of which
the last one survives when unpacking the archive.)
So it's about time you read
https://www.gnu.org/software/cpio/manual/cpio.html
which proposes for unpacking:
cpio -idv < tree.cpio
Do this in some playground directory. "tree.cpio" is the placeholder name
for your decompressed archive. If you have absolute paths in the archive
you need option --no-absolute-filenames.
The manual proposes for packing up the manipulated archive:
find . -print -depth | cpio -ov > tree.cpio
Option -v will cause both operations to report all file paths.
You might want to omit it.
Mario Marietto wrote:
> echo /usr/share/plymouth/themes/homeworld/logo.png | cpio -H newc -o -A -F
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/live/initrd
the ISO ?
(Are you still with debian-live-11.5.0-amd64-xfce.iso , where i see
no /live/initrd.gz but /live/initrd.img-5.10.0-18-amd64 ?)
> echo /usr/share/plymouth/debian-logo.png | cpio -H newc -o -A -F initrd
In /live/initrd.img-5.10.0-18-amd64 :
.
bin
conf
conf/arch.conf
In /d-i/gtk/initrd.gz :
bin
bin/anna
bin/anna-install
So i would strive for such a path with the appended file:
cd / ; echo usr/share/plymouth/debian-logo.png | cpio ...
> Furthermore,I would like to know how to remove a file that's stored inside a
> cpio archive
and pack up the archive from the manipulated tree.
(This will also avoid multiple occurences of the same file path, of which
the last one survives when unpacking the archive.)
So it's about time you read
https://www.gnu.org/software/cpio/manual/cpio.html
which proposes for unpacking:
cpio -idv < tree.cpio
Do this in some playground directory. "tree.cpio" is the placeholder name
for your decompressed archive. If you have absolute paths in the archive
you need option --no-absolute-filenames.
The manual proposes for packing up the manipulated archive:
find . -print -depth | cpio -ov > tree.cpio
Option -v will cause both operations to report all file paths.
You might want to omit it.
Mario Marietto
Oct 22, 2022, 8:40:06 AM10/22/22
to
>Didn't you strive for manipulating the initrd in /d-i/gtk/initrd.gz of the ISO ?
I have already changed the pictures inside the /d-i/gtk/initrd.gz file,now I'm trying to change the pictures inside the /live/initrd.gz file. The initrd.img-5.10.0-18-amd64 file is in the /custom-root/boot folder,but I never changed the images inside of this file. Despite this,at some point of debian booting,I see the old picture that I have added inside the /live/initrd.gz file and I know that the image that I should change is inside there. I have followed your suggestions,doing something like this :
gunzip /live/initrd.gz
cpio -idv < /live/initrd
cd initrd
find . -print -depth | cpio -ov > ../initrd
gzip initrd
BUT after having "burned" another ISO image using Cubic,I've seen that it still uses the old images that I have previously added inside the /live/initrd file. I don't understand why ? It seems that this file is re-generated taking the files from somewhere else.
>Are you still with debian-live-11.5.0-amd64-xfce.iso , where I see no /live/initrd.gz but /live/initrd.img-5.10.0-18-amd64 ?
Inside the "live" folder I have the following files :
config-5.10.0-18-amd64
filesystem.size
initrd-unpacked
initrd.gz
vmlinuz
filesystem.manifest
filesystem.squashfs
initrd
System.map-5.10.0-18-amd64
There isn't any "initrd.img-5.10.0-18-amd64" file in that folder. BUT on the custom-root/boot folder I have these files :
config-5.10.0-18-amd64 initrd.img-5.10.0-19-amd64 vmlinuz-5.10.0-18-amd64
config-5.10.0-19-amd64 initrd.img-5.19.0-15.2-liquorix-amd64 vmlinuz-5.10.0-19-amd64
config-5.19.0-15.2-liquorix-amd64 System.map-5.10.0-18-amd64 vmlinuz-5.19.0-15.2-liquorix-amd64
initrd.img-5.10.0-18-amd64 System.map-5.10.0-19-amd64
initrd.img-5.10.0-18-amd64-sos System.map-5.19.0-15.2-liquorix-amd64
config-5.10.0-19-amd64 initrd.img-5.19.0-15.2-liquorix-amd64 vmlinuz-5.10.0-19-amd64
config-5.19.0-15.2-liquorix-amd64 System.map-5.10.0-18-amd64 vmlinuz-5.19.0-15.2-liquorix-amd64
initrd.img-5.10.0-18-amd64 System.map-5.10.0-19-amd64
initrd.img-5.10.0-18-amd64-sos System.map-5.19.0-15.2-liquorix-amd64
and on the custom-disk/boot folder I have these files :
config-5.10.0-18-amd64 initrd.img-5.10.0-19-amd64 vmlinuz-5.10.0-18-amd64
config-5.10.0-19-amd64 initrd.img-5.19.0-15.2-liquorix-amd64 vmlinuz-5.10.0-19-amd64
config-5.19.0-15.2-liquorix-amd64 System.map-5.10.0-18-amd64 vmlinuz-5.19.0-15.2-liquorix-amd64
grub System.map-5.10.0-19-amd64
initrd.img-5.10.0-18-amd64 System.map-5.19.0-15.2-liquorix-amd64
config-5.10.0-19-amd64 initrd.img-5.19.0-15.2-liquorix-amd64 vmlinuz-5.10.0-19-amd64
config-5.19.0-15.2-liquorix-amd64 System.map-5.10.0-18-amd64 vmlinuz-5.19.0-15.2-liquorix-amd64
grub System.map-5.10.0-19-amd64
initrd.img-5.10.0-18-amd64 System.map-5.19.0-15.2-liquorix-amd64
So. What's my problem ? I hope you understood,because I'm getting tired of getting the same wrong result. I have burned the ISO image thousands of times.
Mario.
Thomas Schmitt
Oct 22, 2022, 11:20:06 AM10/22/22
to
Hi,
Mario Marietto wrote:
> I'm trying to change the pictures inside the /live/initrd.gz file.
I really wonder where this file comes from.
> I have followed your suggestions,doing something like this :
> gunzip /live/initrd.gz
I also wonder about the absolute path "/live/initrd.gz".
You have a directory "/live" on your system ?
> cpio -idv < /live/initrd
It depends on the paths inside the cpio archive where the files end up.
Better first check by
cpio -t < /live/initrd | less
> cd initrd
So it did unpack a top directory ./initrd" ?
> find . -print -depth | cpio -ov > ../initrd
And is not the "../initrd" here the directory "initrd" into which you
just descended ?
I don't dare to imagine what happens if you succeed with directing
cpio's output to the parent directory of the current working directory.
But doesn't this fail with a complaint from the shell that you cannot
redirect to a directory ?
> gzip initrd
I guess there is a "cd .." missing before this ?
> BUT after having "burned" another ISO image using Cubic,I've seen that it
> still uses the old images that I have previously added inside the
> /live/initrd file. I don't understand why ? It seems that this file is
> re-generated taking the files from somewhere else.
Prime suspect would be Cubic. The "u" in in its name means "Ubuntu".
So it probably makes assumptions which the Debian Live ISO does not
fulfill. Did you follow the advise of "Cubic PPA (cubic-wizard)" in
https://answers.launchpad.net/cubic/+question/703422
to ask your question on the "official web site" ?
> Inside the "live" folder I have the following files :
> config-5.10.0-18-amd64
> filesystem.size
> initrd-unpacked
> initrd.gz
> vmlinuz
> filesystem.manifest
> filesystem.squashfs
> initrd
> System.map-5.10.0-18-amd64
Of those i see in debian-live-11.5.0-amd64-xfce.iso only three:
config-5.10.0-18-amd64 , filesystem.squashfs , System.map-5.10.0-18-amd64
sudo mount debian-live-11.5.0-amd64-xfce.iso /mnt/iso
du -s /mnt/iso/live/*
yields
1 /mnt/iso/live/System.map-5.10.0-18-amd64
231 /mnt/iso/live/config-5.10.0-18-amd64
2194208 /mnt/iso/live/filesystem.squashfs
48618 /mnt/iso/live/initrd.img-5.10.0-18-amd64
6799 /mnt/iso/live/vmlinuz-5.10.0-18-amd64
Looking for files named "initrd*" by
find /mnt/iso -name 'initrd*'
yields
/mnt/iso/d-i/gtk/initrd.gz
/mnt/iso/d-i/initrd.gz
/mnt/iso/live/initrd.img-5.10.0-18-amd64
/mnt/iso/pool/main/k/kickseed/initrd-kickseed_0.63_all.udeb
/mnt/iso/pool/main/p/preseed/initrd-preseed_1.109_all.udeb
> So. What's my problem ?
It could be that you try to squeeze the square block into the round hole.
Either eliminate Cubic from your proceedings or ask its developer via
https://github.com/PJ-Singh-001/Cubic/issues
Mario Marietto wrote:
> I'm trying to change the pictures inside the /live/initrd.gz file.
> I have followed your suggestions,doing something like this :
> gunzip /live/initrd.gz
You have a directory "/live" on your system ?
> cpio -idv < /live/initrd
It depends on the paths inside the cpio archive where the files end up.
Better first check by
cpio -t < /live/initrd | less
> cd initrd
So it did unpack a top directory ./initrd" ?
> find . -print -depth | cpio -ov > ../initrd
just descended ?
I don't dare to imagine what happens if you succeed with directing
cpio's output to the parent directory of the current working directory.
But doesn't this fail with a complaint from the shell that you cannot
redirect to a directory ?
> gzip initrd
I guess there is a "cd .." missing before this ?
> BUT after having "burned" another ISO image using Cubic,I've seen that it
> still uses the old images that I have previously added inside the
> /live/initrd file. I don't understand why ? It seems that this file is
> re-generated taking the files from somewhere else.
So it probably makes assumptions which the Debian Live ISO does not
fulfill. Did you follow the advise of "Cubic PPA (cubic-wizard)" in
https://answers.launchpad.net/cubic/+question/703422
to ask your question on the "official web site" ?
> Inside the "live" folder I have the following files :
> config-5.10.0-18-amd64
> filesystem.size
> initrd-unpacked
> initrd.gz
> vmlinuz
> filesystem.manifest
> filesystem.squashfs
> initrd
> System.map-5.10.0-18-amd64
config-5.10.0-18-amd64 , filesystem.squashfs , System.map-5.10.0-18-amd64
sudo mount debian-live-11.5.0-amd64-xfce.iso /mnt/iso
du -s /mnt/iso/live/*
yields
1 /mnt/iso/live/System.map-5.10.0-18-amd64
231 /mnt/iso/live/config-5.10.0-18-amd64
2194208 /mnt/iso/live/filesystem.squashfs
48618 /mnt/iso/live/initrd.img-5.10.0-18-amd64
6799 /mnt/iso/live/vmlinuz-5.10.0-18-amd64
Looking for files named "initrd*" by
find /mnt/iso -name 'initrd*'
yields
/mnt/iso/d-i/gtk/initrd.gz
/mnt/iso/d-i/initrd.gz
/mnt/iso/live/initrd.img-5.10.0-18-amd64
/mnt/iso/pool/main/k/kickseed/initrd-kickseed_0.63_all.udeb
/mnt/iso/pool/main/p/preseed/initrd-preseed_1.109_all.udeb
> So. What's my problem ?
Either eliminate Cubic from your proceedings or ask its developer via
https://github.com/PJ-Singh-001/Cubic/issues
Andrew M.A. Cater
Oct 22, 2022, 12:10:05 PM10/22/22
to
On Sat, Oct 22, 2022 at 05:13:18PM +0200, Thomas Schmitt wrote:
> Hi,
>
> Mario Marietto wrote:
> > I'm trying to change the pictures inside the /live/initrd.gz file.
>
> I really wonder where this file comes from.
>
>
> Hi,
>
> Mario Marietto wrote:
> > I'm trying to change the pictures inside the /live/initrd.gz file.
>
> I really wonder where this file comes from.
>
>
> > BUT after having "burned" another ISO image using Cubic,I've seen that it
> > still uses the old images that I have previously added inside the
> > /live/initrd file. I don't understand why ? It seems that this file is
> > re-generated taking the files from somewhere else.
>
> Prime suspect would be Cubic. The "u" in in its name means "Ubuntu".
> So it probably makes assumptions which the Debian Live ISO does not
> fulfill. Did you follow the advise of "Cubic PPA (cubic-wizard)" in
> https://answers.launchpad.net/cubic/+question/703422
> to ask your question on the "official web site" ?
>
>
Further to this: if you are dealing with Debian-live images as your base,
> > still uses the old images that I have previously added inside the
> > /live/initrd file. I don't understand why ? It seems that this file is
> > re-generated taking the files from somewhere else.
>
> Prime suspect would be Cubic. The "u" in in its name means "Ubuntu".
> So it probably makes assumptions which the Debian Live ISO does not
> fulfill. Did you follow the advise of "Cubic PPA (cubic-wizard)" in
> https://answers.launchpad.net/cubic/+question/703422
> to ask your question on the "official web site" ?
>
>
use Debian tools. If you're dealing with Ubuntu images use Ubuntu-based
PPAs. In general, they really don't mix - to the extent that there's
a whole section on the Debian wiki to this effect.
https://wiki.debian.org/DontBreakDebian
The number of people working on Debian-live images at any one time is
small: if you can't raise anyone, then I might also suggest having
a chat with Roland Clobus who is working on making live images
work reproducibly with the Reproducible build project.
https://wiki.debian.org/DebianLive
I see you're already contributing on the debian-live mailing list
so should find the appropriate people there. highvoltage, of course,
is also the Debian Project leader so is very busy with everything
else and not necessarily debian-live build problems.
>
>
> > So. What's my problem ?
>
> It could be that you try to squeeze the square block into the round hole.
> Either eliminate Cubic from your proceedings or ask its developer via
> https://github.com/PJ-Singh-001/Cubic/issues
>
>
> Have a nice day :)
>
> Thomas
>
Mario Marietto
Oct 22, 2022, 4:50:05 PM10/22/22
to
This is what I did. I gone into this folder : /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/ and I have renamed the file "initrd.gz" into "initrd_.gz" and I've burnt a new ISO image. I have soon realized that that file has been regenerated. The initrd_.gz file disappeared and a new initrd.gz file appeared when,in CUBIC,I have chosen which kernel bootstrap,as you can see here : https://ibb.co/Xy0nKtL ; So. I suppose that the file that I should alter is called "initrd.img-5.10.0-19-amd64" because I have chosen that kernel version on the Cubic tab. And this is what I tried to do,but it didn't work. This is the commands that I have issued :
cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot
gunzip initrd.img-5.10.0-19-amd64.gz : has been produced a cpio file called : initrd.img-5.10.0-19-amd64
mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
cpio -idv < initrd.img-5.10.0-19-amd64_ : it has been unpacked and then I've copied the files inside a folder called initrd.img-5.10.0-19-amd64
cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/
cp /usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/
cp /usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
cp /usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64-
cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64-
find . -print -depth | cpio -ov > ../initrd.img-5.10.0-19-amd64 : generated the cpio file called initrd.img-5.10.0-19-amd64
cd ..
gzip initrd.img-5.10.0-19-amd64 : generated the gzip file called "initrd.img-5.10.0-19-amd64"
cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
cp /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64.gz /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
size of the new (initrd.img-5.10.0-19-amd64) file is 178.4 MiB (187,099,720 byte),of the old one is : 78.8 MiB (82,661,551 byte) ; so probably there is something not good if the sizes are so different ?
Anyway,I've burned a new ISO image with cubic and I've tried to boot it,but I've got the following error : https://ibb.co/GCBFcpK
--
Mario.
Mario Marietto
Oct 22, 2022, 7:00:06 PM10/22/22
to
The technique to unpack the files from the cpio archive with :
cpio -idv < tree.cpio
cpio -idv < tree.cpio
and then packing them up with :
find . -print -depth | cpio -ov > tree.cpio
didn't work for some unknown reason. But the technique below worked :
mkdir -p /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/cpio
cp /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/initrd.img-5.10.0-18-amd64.gz /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/cpio
cp /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/initrd.img-5.10.0-19-amd64.gz /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/cpio
cp /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/initrd.img-5.19.0-15.2-liquorix-amd64.gz /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/cpio
cd /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/cpio
gunzip initrd.img-5.10.0-18-amd64.gz
gunzip initrd.img-5.10.0-19-amd64.gz
gunzip initrd.img-5.19.0-15.2-liquorix-amd64.gz
echo /usr/share/plymouth/themes/homeworld/debian.png | cpio -H newc -o -A -F initrd.img-5.10.0-18-amd64
echo /usr/share/plymouth/themes/homeworld/debian.png | cpio -H newc -o -A -F initrd.img-5.10.0-19-amd64
echo /usr/share/plymouth/themes/homeworld/debian.png | cpio -H newc -o -A -F initrd.img-5.19.0-15.2-liquorix-amd64
echo /usr/share/plymouth/themes/homeworld/logo.png | cpio -H newc -o -A -F initrd.img-5.10.0-19-amd64
echo /usr/share/plymouth/themes/homeworld/logo.png | cpio -H newc -o -A -F initrd.img-5.19.0-15.2-liquorix-amd64
echo /usr/share/plymouth/themes/homeworld/logo.png | cpio -H newc -o -A -F initrd.img-5.10.0-18-amd64
gzip initrd.img-5.10.0-18-amd64
gzip initrd.img-5.10.0-19-amd64
gzip initrd.img-5.19.0-15.2-liquorix-amd64
cp initrd.img-5.10.0-18-amd64.gz /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
cp initrd.img-5.10.0-19-amd64.gz /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
cp initrd.img-5.19.0-15.2-liquorix-amd64.gz /root/Scrivania/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
Mario.
Thomas Schmitt
Oct 24, 2022, 7:40:06 AM10/24/22
to
Hi,
Mario Marietto wrote:
> But the technique below worked :
So your initrd problems are solved now and you managed to modify a Debian
Live ISO by help of Cubic ?
Mario Marietto wrote:
> But the technique below worked :
Live ISO by help of Cubic ?
Mario Marietto
Oct 24, 2022, 1:20:05 PM10/24/22
to
Almost,but not fully. Because I've realized that as soon as a new kernel has been installed by the user,logos and images should be added automatically inside the initrd.img* file. For this reason,I've created the bash script below. It works,I've tested it. Now I should understand where to place it and which stage of the linux booting is the better one to invoke it. I would like to read your suggestions. Thanks.
#!/bin/bash
if [ "`id -u`" -ne 0 ]; then
echo "Switching from `id -un` to root"
exec sudo "$0"
exit 99
fi
# Lets check the kernel version
function kernels-check() {
CURRENT_KERNEL_VERSION_LIQUORIX=$(uname --kernel-release | cut --delimiter="-" --fields=3)
if [ "$CURRENT_KERNEL_VERSION_LIQUORIX" = "liquorix" ]; then
CURRENT_KERNEL_VERSION_GZ='initrd.img-'$(uname --kernel-release | cut --delimiter="-" --fields=1-3)'-amd64.gz'
CURRENT_KERNEL_VERSION_NO_GZ='initrd.img-'$(uname --kernel-release | cut --delimiter="-" --fields=1-3)'-amd64'
else
CURRENT_KERNEL_VERSION_GZ='initrd.img-'$(uname --kernel-release | cut --delimiter="-" --fields=1-2)'-amd64.gz'
CURRENT_KERNEL_VERSION_NO_GZ='initrd.img-'$(uname --kernel-release | cut --delimiter="-" --fields=1-2)'-amd64'
fi
echo $CURRENT_KERNEL_VERSION_GZ
echo $CURRENT_KERNEL_VERSION_NO_GZ
cp $CURRENT_KERNEL_VERSION_GZ /boot/old
gunzip /boot/old/$CURRENT_KERNEL_VERSION_GZ
echo /usr/share/plymouth/themes/homeworld/debian.png | cpio -H newc -o -A -F /boot/old/$CURRENT_KERNEL_VERSION_NO_GZ
echo /usr/share/plymouth/themes/homeworld/logo.png | cpio -H newc -o -A -F /boot/old/$CURRENT_KERNEL_VERSION_NO_GZ
echo /usr/share/plymouth/debian-logo.png | cpio -H newc -o -A -F /boot/old/$CURRENT_KERNEL_VERSION_NO_GZ
gzip /boot/old/$CURRENT_KERNEL_VERSION_NO_GZ
cp /boot/old/$CURRENT_KERNEL_VERSION_GZ /boot
}
kernels-check
Mario.
Mario Marietto
Oct 24, 2022, 3:50:05 PM10/24/22
to
I've renamed the previous script as "check-kernels" and I've saved it on /usr/sbin ; I've added this line inside the file /etc/sudoers :
ALL ALL = NOPASSWD: /usr/sbin/check-kernels
and I've created the file below that I have saved inside the folder /etc/xdg/autostart :
check-nvidia-kernel.desktop
[Desktop Entry]
Version=1.0
Type=Application
Name=check_kernels
GenericName=Add logo and images inside the installed kernel
Comment=Add logo and images inside the installed kernel
Exec=/usr/sbin/check-kernels
Icon=applications-biology
Path=/usr/sbin
Terminal=false
StartupNotify=false
Version=1.0
Type=Application
Name=check_kernels
GenericName=Add logo and images inside the installed kernel
Comment=Add logo and images inside the installed kernel
Exec=/usr/sbin/check-kernels
Icon=applications-biology
Path=/usr/sbin
Terminal=false
StartupNotify=false
Dunno if it is correct.
Mario.
Thomas Schmitt
Oct 25, 2022, 3:30:04 PM10/25/22
to
Hi,
Mario Marietto wrote:
> I've realized that as soon as a
> new kernel has been installed by the user,logos and images
> should be added automatically inside the initrd.img* file. For
> this reason,I've created the bash script below. It works,I've
> tested it. Now I should understand where to place it and which
> stage of the linux booting is the better one to invoke it.
> I would like to read your suggestions.
I have to confess that i quite lost track of your adventure.
But if you want to execute your script each time the system boots, won't
your initrds grow and grow and grow ? cpio -A does not overwrite old files
in the archive but just appends a new version of the file.
At least i cannot spot code which would detect a newly installed kernel.
Mario Marietto wrote:
> I've realized that as soon as a
> new kernel has been installed by the user,logos and images
> should be added automatically inside the initrd.img* file. For
> this reason,I've created the bash script below. It works,I've
> tested it. Now I should understand where to place it and which
> stage of the linux booting is the better one to invoke it.
> I would like to read your suggestions.
But if you want to execute your script each time the system boots, won't
your initrds grow and grow and grow ? cpio -A does not overwrite old files
in the archive but just appends a new version of the file.
At least i cannot spot code which would detect a newly installed kernel.
Curt
Oct 25, 2022, 3:40:04 PM10/25/22
to
On 2022-10-25, Thomas Schmitt <scdb...@gmx.net> wrote:
> Hi,
>
> Mario Marietto wrote:
>> I've realized that as soon as a
>> new kernel has been installed by the user,logos and images
>> should be added automatically inside the initrd.img* file. For
>> this reason,I've created the bash script below. It works,I've
>> tested it. Now I should understand where to place it and which
>> stage of the linux booting is the better one to invoke it.
>> I would like to read your suggestions.
>
> I have to confess that i quite lost track of your adventure.
+1
> Hi,
>
> Mario Marietto wrote:
>> I've realized that as soon as a
>> new kernel has been installed by the user,logos and images
>> should be added automatically inside the initrd.img* file. For
>> this reason,I've created the bash script below. It works,I've
>> tested it. Now I should understand where to place it and which
>> stage of the linux booting is the better one to invoke it.
>> I would like to read your suggestions.
>
> I have to confess that i quite lost track of your adventure.
Mario Marietto
Oct 25, 2022, 4:10:04 PM10/25/22
to
You are right. The kernel file grows and grows and grows. I never said that it's perfect. You seem to understand well what I'm trying to do and you are able to give good suggestions. It's me that I'm not a pro. I'm a hobbyist. Anyway,you suggested the road to take. It seems that there isn't any CPIO parameter that overwrites the old image. Is this correct ? I remember that the old method (unpack and repack the files inside the kernel image) failed. I'm not able to understand why. Some one of you gave a look at the commands that I have used ? Men,I try to do my best,but as I said,I'm not a pro. I presume that,if there isn't any CPIO parameter that overwrites the old image,the only chance that I have to avoid that the kernel file grows forever is to unpack,delete the unwanted files and repack it. If you agree with that,I wish to use that method. But to do that I need someone of you give me some indication about how it didn't work. Below I have repeated the commands that I have used,since the older ones may get lost in the space :
cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot
gunzip initrd.img-5.10.0-19-amd64.gz : has been produced a cpio file called : initrd.img-5.10.0-19-amd64
mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
cpio -idv < initrd.img-5.10.0-19-amd64_ : it has been unpacked and then I've copied the files inside a folder called initrd.img-5.10.0-19-amd64
cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/
cp /usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/
cp /usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
cp /usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64-
cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64-
find . -print -depth | cpio -ov > ../initrd.img-5.10.0-19-amd64 : generated the cpio file called initrd.img-5.10.0-19-amd64
cd ..
gzip initrd.img-5.10.0-19-amd64 : generated the gzip file called "initrd.img-5.10.0-19-amd64"
cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
cp /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64.gz /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
size
of the new (initrd.img-5.10.0-19-amd64) file is 178.4 MiB (187,099,720
byte),of the old one is : 78.8 MiB (82,661,551 byte) ; so probably there
is something not good if the sizes are so different ? I tried to boot the new ISO image generated by cubic but I've got the following error : https://ibb.co/GCBFcpK
that's it. Or maybe another solution is to append a new image inside the kernel image only when a new kernel is detected. In this case I need to study deeply how to do that. At the moment I have no idea.
Mario.
David Wright
Oct 25, 2022, 4:40:05 PM10/25/22
to
I wrote this a few days ago, but then you posted a follow-up to the
same post that used a different method, and so I never bothered to
send this.
I don't know how other people's tolerance compares with mine, but
I tried to follow some of what you did and was frustrated by what
seemed to be inconsistencies, so I gave up.
Anyway, seeing that others are lost, for one reason or another,
I just thought I'd let you see my criticisms, in case they're
of any help. They're easily dealt with and will make your postings
more robust and easier to understand, for some at least.
I haven't used cpio myself since the turn of the millenium, when
I used to frequently clone one system from another (I had a number
of identical machines). So on reading about your duplicate filenames,
the first thing I did was confirm my understanding by checking with
a toy example (posted earlier). I would suggest you play with toys
likewise, concentrating on one aspect with each toy, before you
put it all together.
On Sat 22 Oct 2022 at 22:45:20 (+0200), Mario Marietto wrote:
instead of just writing a narrative. And if you put a timestamp and
$PWD into your prompt, and listed the files in directories as you
generated them, then you and we both could audit what you've done.
> cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot
I don't think you ever move higher than /home/ziomario/Scrivania/PassT-Cubic/Debian-new/
so there's no need to clutter the post by typing it over and over.
$PWD = custom-disk/boot/
> gunzip initrd.img-5.10.0-19-amd64.gz : has been produced a cpio file called
> : initrd.img-5.10.0-19-amd64
Hmm. Well that's the first oddity. Where did the gzipped initrd.img
come from?
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
A .cpio custom-disk/boot/initrd.img-5.10.0-19-amd64_
> cpio -idv < initrd.img-5.10.0-19-amd64_ : it has been unpacked and then
> I've copied the files inside a folder called initrd.img-5.10.0-19-amd64
I'd like to see your copy command. Anyway …
$PWD = custom-disk/boot/
A .cpio custom-disk/boot/initrd.img-5.10.0-19-amd64_
A tree rooted at custom-disk/boot/initrd.img-5.10.0-19-amd64
> cd
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/
In the tree rooted at custom-disk/boot/initrd.img-5.10.0-19-amd64,
$PWD = custom-disk/boot/initrd.img-5.10.0-19-amd64/
> cp /usr/share/plymouth/debian-logo.png
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/
>
> cp /usr/share/plymouth/themes/homeworld/debian.png
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
>
> cp /usr/share/plymouth/themes/homeworld/logo.png
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
In the tree rooted at custom-disk/boot/initrd.img-5.10.0-19-amd64,
$PWD = custom-disk/boot/initrd.img-5.10.0-19-amd64/
in which there is a directory called usr/share/plymouth/
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64-
$PWD = custom-disk/boot/initrd.img-5.10.0-19-amd64/
This suggests that as well as usr/share/plymouth/, there was something called
initrd.img-5.10.0-19-amd64, now called initrd.img-5.10.0-19-amd64-
at the same level as usr/…
Where did that file come from?
> cd
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64-
Now, has initrd.img-5.10.0-19-amd64- popped up a level?
Presumably there was a missed cd command.
> find . -print -depth | cpio -ov > ../initrd.img-5.10.0-19-amd64 : generated
> the cpio file called initrd.img-5.10.0-19-amd64
>
> cd ..
>
> gzip initrd.img-5.10.0-19-amd64 : generated the gzip file called "
> initrd.img-5.10.0-19-amd64"
So you gzipped foo and it gave you foo, not foo.gz?
> cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
>
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
So is this the old one? Is that what you started this post with?
We were never shown what custom-disk/boot/initrd.img-5.10.0-19-amd64.gz
was, nor whether it originated from somewhere in custom-root/boot/.
> cp /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64.gz
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
Now, custom-disk/boot/initrd.img-5.10.0-19-amd64.gz has got its .gz
extension. That was presumably a transcribing error?
> size of the new (initrd.img-5.10.0-19-amd64) file is 178.4 MiB (187,099,720
Is this file ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ the gzipped one, or the
uncompressed one, or do the two files initrd.img-5.10.0-19-amd64 and
initrd.img-5.10.0-19-amd64.gz represent the same contents?
> byte),of the old one is : 78.8 MiB (82,661,551 byte) ; so probably there is
> something not good if the sizes are so different ?
Well, all my comments might seem like nitpicking, but the trouble is
that without the actual output, I don't have a clue what you /really/
did, only what you thought you did. There may be any amount of difference.
> Anyway,I've burned a new ISO image with cubic and I've tried to boot it,but
> I've got the following error : https://ibb.co/GCBFcpK
I see you've written another post, in which you say it worked.
That's good. But you will forgive me if I don't check it, because
again it's just a transcript, not the actual output. The only reason
I looked through this one was because it started with that strange
initrd.img-5.10.0-19-amd64.gz filename. My understanding is that
initrd files are /either/ .img or .gz but not both.
Cheers,
David.
same post that used a different method, and so I never bothered to
send this.
I don't know how other people's tolerance compares with mine, but
I tried to follow some of what you did and was frustrated by what
seemed to be inconsistencies, so I gave up.
Anyway, seeing that others are lost, for one reason or another,
I just thought I'd let you see my criticisms, in case they're
of any help. They're easily dealt with and will make your postings
more robust and easier to understand, for some at least.
I haven't used cpio myself since the turn of the millenium, when
I used to frequently clone one system from another (I had a number
of identical machines). So on reading about your duplicate filenames,
the first thing I did was confirm my understanding by checking with
a toy example (posted earlier). I would suggest you play with toys
likewise, concentrating on one aspect with each toy, before you
put it all together.
On Sat 22 Oct 2022 at 22:45:20 (+0200), Mario Marietto wrote:
> This is what I did. I gone into this folder :
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/ and I
> have renamed the file "initrd.gz" into "initrd_.gz" and I've burnt a new
> ISO image. I have soon realized that that file has been regenerated. The
> initrd_.gz file disappeared and a new initrd.gz file appeared when,in
> CUBIC,I have chosen which kernel bootstrap,as you can see here :
> https://ibb.co/Xy0nKtL ; So. I suppose that the file that I should alter is
> called "initrd.img-5.10.0-19-amd64" because I have chosen that kernel
> version on the Cubic tab. And this is what I tried to do,but it didn't
> work. This is the commands that I have issued :
I don't know why you don't cut and paste the output of your commands,
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/ and I
> have renamed the file "initrd.gz" into "initrd_.gz" and I've burnt a new
> ISO image. I have soon realized that that file has been regenerated. The
> initrd_.gz file disappeared and a new initrd.gz file appeared when,in
> CUBIC,I have chosen which kernel bootstrap,as you can see here :
> https://ibb.co/Xy0nKtL ; So. I suppose that the file that I should alter is
> called "initrd.img-5.10.0-19-amd64" because I have chosen that kernel
> version on the Cubic tab. And this is what I tried to do,but it didn't
> work. This is the commands that I have issued :
instead of just writing a narrative. And if you put a timestamp and
$PWD into your prompt, and listed the files in directories as you
generated them, then you and we both could audit what you've done.
> cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot
I don't think you ever move higher than /home/ziomario/Scrivania/PassT-Cubic/Debian-new/
so there's no need to clutter the post by typing it over and over.
$PWD = custom-disk/boot/
> gunzip initrd.img-5.10.0-19-amd64.gz : has been produced a cpio file called
> : initrd.img-5.10.0-19-amd64
come from?
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
A .cpio custom-disk/boot/initrd.img-5.10.0-19-amd64_
> cpio -idv < initrd.img-5.10.0-19-amd64_ : it has been unpacked and then
> I've copied the files inside a folder called initrd.img-5.10.0-19-amd64
$PWD = custom-disk/boot/
A .cpio custom-disk/boot/initrd.img-5.10.0-19-amd64_
A tree rooted at custom-disk/boot/initrd.img-5.10.0-19-amd64
> cd
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/
In the tree rooted at custom-disk/boot/initrd.img-5.10.0-19-amd64,
$PWD = custom-disk/boot/initrd.img-5.10.0-19-amd64/
> cp /usr/share/plymouth/debian-logo.png
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/
>
> cp /usr/share/plymouth/themes/homeworld/debian.png
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
>
> cp /usr/share/plymouth/themes/homeworld/logo.png
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
$PWD = custom-disk/boot/initrd.img-5.10.0-19-amd64/
in which there is a directory called usr/share/plymouth/
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64-
$PWD = custom-disk/boot/initrd.img-5.10.0-19-amd64/
This suggests that as well as usr/share/plymouth/, there was something called
initrd.img-5.10.0-19-amd64, now called initrd.img-5.10.0-19-amd64-
at the same level as usr/…
Where did that file come from?
> cd
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64-
Now, has initrd.img-5.10.0-19-amd64- popped up a level?
Presumably there was a missed cd command.
> find . -print -depth | cpio -ov > ../initrd.img-5.10.0-19-amd64 : generated
> the cpio file called initrd.img-5.10.0-19-amd64
>
> cd ..
>
> gzip initrd.img-5.10.0-19-amd64 : generated the gzip file called "
> initrd.img-5.10.0-19-amd64"
> cd /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
>
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
We were never shown what custom-disk/boot/initrd.img-5.10.0-19-amd64.gz
was, nor whether it originated from somewhere in custom-root/boot/.
> cp /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/boot/initrd.img-5.10.0-19-amd64.gz
> /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-root/boot/
Now, custom-disk/boot/initrd.img-5.10.0-19-amd64.gz has got its .gz
extension. That was presumably a transcribing error?
> size of the new (initrd.img-5.10.0-19-amd64) file is 178.4 MiB (187,099,720
uncompressed one, or do the two files initrd.img-5.10.0-19-amd64 and
initrd.img-5.10.0-19-amd64.gz represent the same contents?
> byte),of the old one is : 78.8 MiB (82,661,551 byte) ; so probably there is
> something not good if the sizes are so different ?
that without the actual output, I don't have a clue what you /really/
did, only what you thought you did. There may be any amount of difference.
> Anyway,I've burned a new ISO image with cubic and I've tried to boot it,but
> I've got the following error : https://ibb.co/GCBFcpK
That's good. But you will forgive me if I don't check it, because
again it's just a transcript, not the actual output. The only reason
I looked through this one was because it started with that strange
initrd.img-5.10.0-19-amd64.gz filename. My understanding is that
initrd files are /either/ .img or .gz but not both.
Cheers,
David.
Thomas Schmitt
Oct 25, 2022, 5:00:05 PM10/25/22
to
Hi,
Mario Marietto wrote:
> You seem to understand well what I'm trying to do and you are
> able to give good suggestions.
Probably i only have a good run of guessing here.
> It seems that there isn't any CPIO
> parameter that overwrites the old image. Is this correct ?
I am not aware of any. The nature of a sequential archive does not invite
for random access changes.
> I remember that
> the old method (unpack and repack the files inside the kernel image) failed.
> I'm not able to understand why.
Understanding what special detail spoils this normally well working
method whould probably be helpful for your goals. You'd have to compare
what's in a working appended initrd and one that was freshly packed up
and does not work. (cpio -t <initrd)
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64-
> find [...] | cpio -ov > ../initrd.img-5.10.0-19-amd64
I find your re-usal of that lengthy file name confusing.
Consider to give the various intermediate archives and directories shorter
names and to use the name initrd.img-5.10.0-19-amd64.gz only at the start
and the end of your procedure.
Hopefully this will make more clear what causes the difference in size.
Comparing the cpio -t of both initrds might give important hints.
> Or maybe another solution is to append a new image inside the
> kernel image only when a new kernel is detected.
How about storing the paths and checksums of vmlinuz and initrd in a file
(or two) and comparing them with the checksums when the system boots up ?
md5sum should suffice to detect any change.
You'd have to determine the exact paths of the files to checksum. Maybe
they even change by the installation events, so that you have to repeat
that determination after each installation events.
You's also have to find a safe and persistent spot in the filesystem which
does not get influenced by installation events, where you can store the
file with the recorded paths and checksums.
Mario Marietto wrote:
> You seem to understand well what I'm trying to do and you are
> able to give good suggestions.
> It seems that there isn't any CPIO
> parameter that overwrites the old image. Is this correct ?
for random access changes.
> I remember that
> the old method (unpack and repack the files inside the kernel image) failed.
> I'm not able to understand why.
method whould probably be helpful for your goals. You'd have to compare
what's in a working appended initrd and one that was freshly packed up
and does not work. (cpio -t <initrd)
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64-
> find [...] | cpio -ov > ../initrd.img-5.10.0-19-amd64
I find your re-usal of that lengthy file name confusing.
Consider to give the various intermediate archives and directories shorter
names and to use the name initrd.img-5.10.0-19-amd64.gz only at the start
and the end of your procedure.
Hopefully this will make more clear what causes the difference in size.
Comparing the cpio -t of both initrds might give important hints.
> Or maybe another solution is to append a new image inside the
> kernel image only when a new kernel is detected.
(or two) and comparing them with the checksums when the system boots up ?
md5sum should suffice to detect any change.
You'd have to determine the exact paths of the files to checksum. Maybe
they even change by the installation events, so that you have to repeat
that determination after each installation events.
You's also have to find a safe and persistent spot in the filesystem which
does not get influenced by installation events, where you can store the
file with the recorded paths and checksums.
Mario Marietto
Oct 26, 2022, 5:10:06 PM10/26/22
to
Hello to everyone.
I'm trying to understand the reasons why the kernel file that I generate does not work correctly. Maybe I've understood something,but I don't have a clear picture of the problem. I want to try to explain what's wrong using my method of expression because I find it easier. A more "advanced" way may be able to help you,but it will not help me and the result will be that we will not understand each other. So. I've created the folder called "kernels" like this :
mkdir -p /home/ziomario/Scrivania/PassT-Cubic/kernels/
inside of it I have copied the following kernel file :
initrd.img-5.10.0-18-amd64.gz
it is unaltered. I haven't added any logos and pictures inside of it. After this,I have created two more folders :
mkdir -p /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped
mkdir -p /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
and then I did :
cd /home/ziomario/Scrivania/PassT-Cubic/kernels/
gunzip -k initrd.img-5.10.0-18-amd64.gz
cpio -idv < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
gunzip -k initrd.img-5.10.0-18-amd64.gz
cpio -idv < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
Every time I give the latest command (the cpio one),something odd happens and I don't understand the reason. Inside the folder "/usr/share/plymouth/themes/homeworld",two new files are created : debian.png and logo.png. The first one is correct. I mean,this is one of the pictures that I want to add inside the kernel file. But the second file,logo.png is wrong. It is an old picture that I used sometime ago and that I don't use anymore because I created a new logo. Let's say that the folder "/usr/share/plymouth" and "/usr/share/plymouth/themes/underworld" are two folders that I have created on my host os and inside of them I have stored the correct pictures that I want to add inside the kernel file. Later in the process,I issue the below commands to copy the correct images inside the kernel file before re-packing it.
cp /usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/
cp /usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/themes/homeworld
cp /usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/themes/homeworld
At the moment I haven't reached that step because the cpio command (cpio -idv < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64) behavior is not expected.
Since I'm using unaltered kernel files,I don't know where the cpio command (cpio -idv < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64) gets those images when I run it. And most of all,I don't know why those pictures are copied inside the folder "/usr/share/plymouth/themes/underworld",overwriting the already existing pictures that are already there. As I repeat,those files aren't stored inside the kernel file (initrd.img-5.10.0-18-amd64),because it is unaltered and it contains only the default debian pictures,which are different from mine. I hope that I have been clear. Sorry I don't have another way to explain what happens other than my narrative.
Mario.
Mario Marietto
Oct 26, 2022, 6:30:06 PM10/26/22
to
Please,check the images below. The image 1 and 2 come from the kernel file unpacked with the cpio command (cpio -idv < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64),while on the picture n. 3 You can see all the pictures that are inside the kernel file when I have opened it with engrampa. I don't know where the truth is. I see only contradictory information. Something is lying : who is ? cpio or engrampa ?
Mario.
David Wright
Oct 26, 2022, 7:10:05 PM10/26/22
to
On Thu 27 Oct 2022 at 00:21:50 (+0200), Mario Marietto wrote:
> Please,check the images below. The image 1 and 2 come from the kernel file
> unpacked with the cpio command (cpio -idv < initrd.img-5.10.0-18-amd64 -D
> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64),while
> on the picture n. 3 You can see all the pictures that are inside the kernel
> file when I have opened it with engrampa. I don't know where the truth is.
> I see only contradictory information. Something is lying : who is ? cpio or
> engrampa ?
>
> 1) https://ibb.co/0mCFCW7
> 2) https://ibb.co/pjGsTY5
> 3) https://ibb.co/k3TMFsk
Have you read https://github.com/mate-desktop/engrampa/issues/191
> Please,check the images below. The image 1 and 2 come from the kernel file
> unpacked with the cpio command (cpio -idv < initrd.img-5.10.0-18-amd64 -D
> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64),while
> on the picture n. 3 You can see all the pictures that are inside the kernel
> file when I have opened it with engrampa. I don't know where the truth is.
> I see only contradictory information. Something is lying : who is ? cpio or
> engrampa ?
>
> 1) https://ibb.co/0mCFCW7
> 2) https://ibb.co/pjGsTY5
> 3) https://ibb.co/k3TMFsk
You may be working outside the limits of defined behaviour
when you create .cpio files with duplicate entries. That's
doesn't make much sense when you intend to distribute the
product to other people/systems.
Cheers,
David.
Mario Marietto
Oct 26, 2022, 7:50:05 PM10/26/22
to
Hello David,
I don't want to bother you,but did you read my first message ? You replied only to the second one and I don't know if you have read or understood the first one. I ask because it seems there may be some other problems explained there. Do you want to give it a look ? Thank you very much.
Mario.
David Wright
Oct 27, 2022, 1:00:05 AM10/27/22
to
On Thu 27 Oct 2022 at 01:48:44 (+0200), Mario Marietto wrote:
precisely what they show, as I've never used engrampa. But there's
one thing about #3 that I don't like the look of: The window
labelled "Posizione:" shows "/usr/share/plymouth/themes/homeworld",
but I assume that it refers to what's inside the cpio archive called
"initrd.img-5.10.0-18-amd64" highlighted in the window above.
If that's a conventional initrd, then I would expect "Posizione:"
to show "usr/share/plymouth/themes/homeworld", because I don't recall
ever seeing an absolute filename in an initrd. This could lead to your
writing to or reading from unexpected places in your filesystem,
depending on whoami. (Running these commands as root might perhaps be
one reason why you're writing /home/ziomario/… … … almost throughout).
That could be a red herring, but unlike mc, which may have to prefix
a filename with "/" to show it /is/ a directory, engrampa doesn't
need that indication here, because it puts a "/" after homeworld,
which shows the same thing.
Anyway, contrast:
$ find /etc/resolv.conf /etc/networks -print | cpio -ov > /tmp/absolute.cpio
/etc/resolv.conf
/etc/networks
1 block
$ find /etc/resolv.conf /etc/networks -print | cpio -ov --no-absolute-filenames > /tmp/relative.cpio
cpio: Removing leading `/' from member names
/etc/resolv.conf
/etc/networks
1 block
$
which list as:
$ cpio -t < /tmp/absolute.cpio
/etc/resolv.conf
/etc/networks
1 block
$ cpio -t < /tmp/relative.cpio
etc/resolv.conf
etc/networks
1 block
$
You should be using files that look like relative.cpio.
Cheers,
David.
> Il giorno gio 27 ott 2022 alle ore 01:01 David Wright ha scritto:
> > On Thu 27 Oct 2022 at 00:21:50 (+0200), Mario Marietto wrote:
> > > Please,check the images below. The image 1 and 2 come from the kernel
> > file
> > > unpacked with the cpio command (cpio -idv < initrd.img-5.10.0-18-amd64 -D
> > >
> > /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64),while
> > > on the picture n. 3 You can see all the pictures that are inside the
> > kernel
> > > file when I have opened it with engrampa. I don't know where the truth
> > is.
> > > I see only contradictory information. Something is lying : who is ? cpio
> > or
> > > engrampa ?
> > >
> > > 1) https://ibb.co/0mCFCW7
> > > 2) https://ibb.co/pjGsTY5
> > > 3) https://ibb.co/k3TMFsk
> >
> > Have you read https://github.com/mate-desktop/engrampa/issues/191
> >
> > You may be working outside the limits of defined behaviour
> > when you create .cpio files with duplicate entries. That's
> > doesn't make much sense when you intend to distribute the
> > product to other people/systems.
> >
> > On Thu 27 Oct 2022 at 00:21:50 (+0200), Mario Marietto wrote:
> > > Please,check the images below. The image 1 and 2 come from the kernel
> > file
> > > unpacked with the cpio command (cpio -idv < initrd.img-5.10.0-18-amd64 -D
> > >
> > /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64),while
> > > on the picture n. 3 You can see all the pictures that are inside the
> > kernel
> > > file when I have opened it with engrampa. I don't know where the truth
> > is.
> > > I see only contradictory information. Something is lying : who is ? cpio
> > or
> > > engrampa ?
> > >
> > > 1) https://ibb.co/0mCFCW7
> > > 2) https://ibb.co/pjGsTY5
> > > 3) https://ibb.co/k3TMFsk
> >
> > Have you read https://github.com/mate-desktop/engrampa/issues/191
> >
> > You may be working outside the limits of defined behaviour
> > when you create .cpio files with duplicate entries. That's
> > doesn't make much sense when you intend to distribute the
> > product to other people/systems.
> >
> I don't want to bother you,but did you read my first message ? You replied
> only to the second one and I don't know if you have read or understood the
> first one. I ask because it seems there may be some other problems
> explained there. Do you want to give it a look ? Thank you very much.
Well, I've taken another look at your images. I have to guess
> only to the second one and I don't know if you have read or understood the
> first one. I ask because it seems there may be some other problems
> explained there. Do you want to give it a look ? Thank you very much.
precisely what they show, as I've never used engrampa. But there's
one thing about #3 that I don't like the look of: The window
labelled "Posizione:" shows "/usr/share/plymouth/themes/homeworld",
but I assume that it refers to what's inside the cpio archive called
"initrd.img-5.10.0-18-amd64" highlighted in the window above.
If that's a conventional initrd, then I would expect "Posizione:"
to show "usr/share/plymouth/themes/homeworld", because I don't recall
ever seeing an absolute filename in an initrd. This could lead to your
writing to or reading from unexpected places in your filesystem,
depending on whoami. (Running these commands as root might perhaps be
one reason why you're writing /home/ziomario/… … … almost throughout).
That could be a red herring, but unlike mc, which may have to prefix
a filename with "/" to show it /is/ a directory, engrampa doesn't
need that indication here, because it puts a "/" after homeworld,
which shows the same thing.
Anyway, contrast:
$ find /etc/resolv.conf /etc/networks -print | cpio -ov > /tmp/absolute.cpio
/etc/resolv.conf
/etc/networks
1 block
$ find /etc/resolv.conf /etc/networks -print | cpio -ov --no-absolute-filenames > /tmp/relative.cpio
cpio: Removing leading `/' from member names
/etc/resolv.conf
/etc/networks
1 block
$
which list as:
$ cpio -t < /tmp/absolute.cpio
/etc/resolv.conf
/etc/networks
1 block
$ cpio -t < /tmp/relative.cpio
etc/resolv.conf
etc/networks
1 block
$
You should be using files that look like relative.cpio.
Cheers,
David.
Mario Marietto
Oct 27, 2022, 8:30:05 AM10/27/22
to
Don't care about :
rm /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/debian-logo*.png
rm /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/debian-logo*.png
rm /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/debian-logo*.png
rm /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/debian-logo*.png
rm /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/debian-logo*.png
I didn't issue those commands. I've copied and pasted them by mistake.
Il giorno gio 27 ott 2022 alle ore 14:22 Mario Marietto <mariet...@gmail.com> ha scritto:
I tried to follow your directions,using cp usr/share/plymouth/debian-logo.png instead of cp /usr/share/plymouth/debian-logo.png. I hope that this is what you intend. So,below there are the commands that I have issued :
cd /home/ziomario/Scrivania/PassT-Cubic/kernels/
gunzip -k initrd.img-5.10.0-18-amd64.gz
gunzip -k initrd.img-5.10.0-19-amd64.gz
gunzip -k initrd.img-5.19.0-15.2-liquorix-amd64.gz
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64
cpio -idv < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
cpio -idv < initrd.img-5.10.0-19-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64
cpio -idv < initrd.img-5.19.0-15.2-liquorix-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64
rm /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/debian-logo*.png
rm /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/debian-logo*.png
rm /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/debian-logo*.png
cp usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/cp usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/themes/homeworldcp usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/themes/homeworldcp usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/cp usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworldcp usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
cp usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/
cp usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/themes/homeworld
cp usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/themes/homeworld
mv initrd.img-5.10.0-18-amd64.gz initrd.img-5.10.0-18-amd64.gz-old
mv initrd.img-5.10.0-19-amd64.gz initrd.img-5.10.0-19-amd64.gz-old
mv initrd.img-5.19.0-15.2-liquorix-amd64 initrd.img-5.19.0-15.2-liquorix-amd64-old
cd /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
cd /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64
cd /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64find . -print -depth | cpio -o > ../../initrd.img-5.10.0-18-amd64find: warning: you have specified the global option -depth after the argument -print, but global options are not positional, i.e., -depth affects tests specified before it as well as those specified after it. Please specify global options before other arguments.
893621 blocksfind . -print -depth | cpio -o > ../../initrd.img-5.10.0-19-amd64find: warning: you have specified the global option -depth after the argument -print, but global options are not positional, i.e., -depth affects tests specified before it as well as those specified after it. Please specify global options before other arguments.
893621 blocksfind . -print -depth | cpio -o > ../../initrd.img-5.19.0-15.2-liquorix-amd64find: warning: you have specified the global option -depth after the argument -print, but global options are not positional, i.e., -depth affects tests specified before it as well as those specified after it. Please specify global options before other arguments.893621 blockscd ../..
gzip initrd.img-5.10.0-18-amd64
gzip initrd.img-5.10.0-19-amd64gzip initrd.img-5.19.0-15.2-liquorix-amd64
no. Unfortunately the produced kernel files are not able to boot. In Fact the size is bigger than the original ones. This is the error reported :I don't know why. Inside the kernel files It seems that everything is ok. I have placed the wrong files in my google drive. Maybe you want to test them on your side ? Thanks for your very very useful support. I can tell for sure that the quality and your patience are the best that I found on the internet.
--Mario.
--
Mario.
Mario Marietto
Oct 27, 2022, 8:30:05 AM10/27/22
to
I tried to follow your directions,using cp usr/share/plymouth/debian-logo.png instead of cp /usr/share/plymouth/debian-logo.png. I hope that this is what you intend. So,below there are the commands that I have issued :
cd /home/ziomario/Scrivania/PassT-Cubic/kernels/
gunzip -k initrd.img-5.10.0-18-amd64.gz
gunzip -k initrd.img-5.10.0-19-amd64.gz
gunzip -k initrd.img-5.19.0-15.2-liquorix-amd64.gz
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64
gunzip -k initrd.img-5.19.0-15.2-liquorix-amd64.gz
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64
cpio -idv < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
Mario.
David Wright
Oct 27, 2022, 2:50:05 PM10/27/22
to
On Thu 27 Oct 2022 at 14:22:45 (+0200), Mario Marietto wrote:
> I tried to follow your directions,using cp
> usr/share/plymouth/debian-logo.png instead of cp
> /usr/share/plymouth/debian-logo.png. I hope that this is what you intend.
Not really. As far as cp is concerned, it copies file1 to file2,
> I tried to follow your directions,using cp
> usr/share/plymouth/debian-logo.png instead of cp
> /usr/share/plymouth/debian-logo.png. I hope that this is what you intend.
or files1…n to directoryD, and dropping the initial "/" will
have no effect if PWD is /, and a dramtic effect if PWD is elsewhere.
That's pretty basic, though I will say that I would be using cp -ip
throughout, in order to maintain the files' metadata, like their
timestamps. This makes it easier to check the provenance of files
when listed: original files will be old, and files you're playing
with will be new, in general. (cpio would also need -m.)
What my post was about is whether the initial "/" appears in the
pathnames inside the .cpio archive. Typically, .cpio archives are
built so that the pathnames inside it are relative. If you make
them with absolute paths, you may get surprises when you unpack them.
Here's my toy example:
/tmp/one/two/three$ find /tmp -name [hot]\* 2>/dev/null
/tmp
/tmp/hosts.deny
/tmp/hosts.allow
/tmp/one
/tmp/one/two
/tmp/one/two/three
/tmp/one/two/three$ find /tmp/host* | cpio -ov --no-absolute-filenames > /tmp/relative.cpio
cpio: Removing leading `/' from member names
/tmp/hosts.allow
/tmp/hosts.deny
3 blocks
/tmp/one/two/three$ find /tmp/host* | cpio -ov > /tmp/absolute.cpio
/tmp/hosts.allow
/tmp/hosts.deny
3 blocks
/tmp/one/two/three$ rm -i /tmp/host*
rm: remove regular file '/tmp/hosts.allow'? y
rm: remove regular file '/tmp/hosts.deny'? y
/tmp/one/two/three$ find /tmp -name [hot]\* 2>/dev/null
/tmp
/tmp/one
/tmp/one/two
/tmp/one/two/three
/tmp/one/two/three$
So I now have two archives in /tmp, each containing the two well-known
original files that I then deleted from the filesystem. I'm currently
in /tmp/one/two/three/ (hence the prompt).
Here's what will happen in a typical use of cpio archives:
/tmp/one/two/three$ cpio -idv -D /tmp/one/two < /tmp/relative.cpio
tmp/hosts.allow
tmp/hosts.deny
3 blocks
/tmp/one/two/three$ find /tmp -name [hot]\* 2>/dev/null
/tmp
/tmp/one
/tmp/one/two
/tmp/one/two/tmp
/tmp/one/two/tmp/hosts.deny
/tmp/one/two/tmp/hosts.allow
/tmp/one/two/three
/tmp/one/two/three$
So the files have been placed where expected, in /tmp/one/two/tmp,
where /tmp/one/two comes from -D, and tmp/ comes out of the archive.
Cleanup:
/tmp/one/two/three$ rm -i /tmp/one/two/tmp/hosts.* ; rmdir /tmp/one/two/tmp/
rm: remove regular file '/tmp/one/two/tmp/hosts.allow'? y
rm: remove regular file '/tmp/one/two/tmp/hosts.deny'? y
/tmp/one/two/three$ find /tmp -name [hot]\* 2>/dev/null
/tmp
/tmp/one
/tmp/one/two
/tmp/one/two/three
/tmp/one/two/three$
Here's what happens when you use an archive with absolute pathnames
inside it:
/tmp/one/two/three$ cpio -idv -D /tmp/one/two < /tmp/absolute.cpio
/tmp/hosts.allow
/tmp/hosts.deny
3 blocks
/tmp/one/two/three$ find /tmp -name [hot]\* 2>/dev/null
/tmp
/tmp/hosts.deny
/tmp/hosts.allow
/tmp/one
/tmp/one/two
/tmp/one/two/three
/tmp/one/two/three$
The files are placed in the "wrong" place, under /tmp, and not /tmp/one/two/tmp/.
> So,below there are the commands that I have issued :
>
>
> no. Unfortunately the produced kernel files are not able to boot. In Fact
> the size is bigger than the original ones. This is the error reported :
>
> https://ibb.co/rm5WRSz
>
> I don't know why. Inside the kernel files It seems that everything is ok. I
> have placed the wrong files in my google drive. Maybe you want to test them
> on your side ? Thanks for your very very useful support. I can tell for
> sure that the quality and your patience are the best that I found on the
> internet.
>
> https://drive.google.com/drive/folders/16z5INJTSB3YcpzE980q9eqRIRVG02-JH?usp=sharing
I haven't checked all the many commands in the many posts submitted.
> no. Unfortunately the produced kernel files are not able to boot. In Fact
> the size is bigger than the original ones. This is the error reported :
>
> https://ibb.co/rm5WRSz
>
> I don't know why. Inside the kernel files It seems that everything is ok. I
> have placed the wrong files in my google drive. Maybe you want to test them
> on your side ? Thanks for your very very useful support. I can tell for
> sure that the quality and your patience are the best that I found on the
> internet.
>
> https://drive.google.com/drive/folders/16z5INJTSB3YcpzE980q9eqRIRVG02-JH?usp=sharing
But I think I have seen along the way some cases where you've
archived absolute paths. Again, I haven't checked the fate of those
archives and where you might have unpacked them.
As I have shown already, it is a simple matter for you to list .cpio
archives, and it makes sense to check them all out. Here's an example
of a command that should produce just one line unless there are
absolute pathnames present:
~$ cpio -t < /tmp/relative.cpio | grep '^/' # conventional
3 blocks
~$ cpio -t < /tmp/absolute.cpio | grep '^/' # unconventional
3 blocks
/tmp/hosts.allow
/tmp/hosts.deny
~$
Cheers,
David.
Mario Marietto
Oct 27, 2022, 4:40:06 PM10/27/22
to
You are extremely technical or cpio is extremely technical. Or both,I don't know. For sure I'm a hobbyist and I have trouble understanding some technical concepts. So,I'm not sure that I have understood. But I tried to follow your directions,issuing the commands below. But I've got the same error as before : https://ibb.co/rm5WRSz
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64
mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64
mkdir -p usr/share/plymouth/
mkdir -p usr/share/plymouth/themes/homeworld/
cd /home/ziomario/Scrivania/PassT-Cubic/kernels/
gunzip -k initrd.img-5.10.0-18-amd64.gz
gunzip -k initrd.img-5.10.0-19-amd64.gz
gunzip -k initrd.img-5.19.0-15.2-liquorix-amd64.gz
cpio -idvm < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
cp -p usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/
cp -p usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/
cp -p usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/
cp -p usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/themes/homeworld
cp -p usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/themes/homeworld
cpio -idvm < initrd.img-5.10.0-19-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64
cpio -idvm < initrd.img-5.19.0-15.2-liquorix-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64
cp -p usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/
cp -p usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/themes/homeworld
cp -p usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/themes/homeworld
cp -p usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/
cp -p usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
cp -p usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld
cp -p usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/
cp -p usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/themes/homeworld
cp -p usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/themes/homeworld
mv initrd.img-5.10.0-18-amd64.gz initrd.img-5.10.0-18-amd64.gz-old
mv initrd.img-5.10.0-19-amd64.gz initrd.img-5.10.0-19-amd64.gz-old
mv initrd.img-5.19.0-15.2-liquorix-amd64 initrd.img-5.19.0-15.2-liquorix-amd64-old
cd /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64
cd /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64
cd /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64
find . -print -depth | cpio -o > ../../initrd.img-5.10.0-18-amd64
find . -print -depth | cpio -o > ../../initrd.img-5.10.0-19-amd64
find . -print -depth | cpio -o > ../../initrd.img-5.19.0-15.2-liquorix-amd64
cd ../..
gzip initrd.img-5.10.0-18-amd64
gzip initrd.img-5.10.0-19-amd64
gzip initrd.img-5.19.0-15.2-liquorix-amd64
gzip initrd.img-5.10.0-18-amd64
gzip initrd.img-5.10.0-19-amd64
gzip initrd.img-5.19.0-15.2-liquorix-amd64
Mario.
Mario Marietto
Oct 27, 2022, 5:30:05 PM10/27/22
to
Maybe it won't boot because I should sign again the new kernel file produced ?
Mario.
Mario Marietto
Oct 27, 2022, 8:10:05 PM10/27/22
to
I've found the error. This command is not good :
find . -print -depth | cpio -o > ../../initrd.img-5.10.0-18-amd64
this one can allow the new generated kernel image to boot :
find . | cpio --create --format='newc' > ../../initrd.img-5.10.0-18-amd64
I'm not a pro,as I said,but I suspect that the first command misses the part " --format='newc' ". What do you think ? Do you confirm ?
Mario.
Max Nikulin
Oct 27, 2022, 10:40:04 PM10/27/22
to
On 28/10/2022 07:07, Mario Marietto wrote:
>
> find . | cpio --create
I rarely use cpio, but recently there was a thread on tar and unwanted
hard links in the created archive. "find" output mixes regular files and
directories. If the archiver recursively walks through received
directories then result may differ from expectations.
>
> find . | cpio --create
I rarely use cpio, but recently there was a thread on tar and unwanted
hard links in the created archive. "find" output mixes regular files and
directories. If the archiver recursively walks through received
directories then result may differ from expectations.
Mario Marietto
Oct 28, 2022, 4:50:05 AM10/28/22
to
If I have understood correctly,is this the correct form ?
find . -print -depth | cpio --create --format='newc' > ../../initrd.img-5.10.0-18-amd64
Mario.
Mario Marietto
Oct 28, 2022, 5:40:05 AM10/28/22
to
There are some kb of difference between the files produced by the two techniques :
79.3 MiB (83,106,001 byte) : find . -print -depth | cpio --create --format='newc' > ../../initrd.img-5.10.0-18-amd64
79.3 MiB (83,108,291 byte) : find . | cpio --create --format='newc' > ../../initrd.img-5.10.0-18-amd64
Mario.
Mario Marietto
Oct 28, 2022, 6:20:06 AM10/28/22
to
Hello. Both these commands :
# find . -print -depth | cpio --create --format='newc' > ../../initrd.img-5.19.0-15.2-liquorix-amd64
# find . | cpio --create --format='newc' > ../../initrd.img-5.10.0-18-amd64
produce this warning :
find: warning: you have specified the global option -depth after the argument -print, but global options are not positional, i.e., -depth affects tests specified before it as well as those specified after it. Please specify global options before other arguments.
It is a warning,not an error. But why does it happens ? Can I "fx" it ?
Mario.
Thomas Schmitt
Oct 28, 2022, 6:50:05 AM10/28/22
to
Hi,
Mario Marietto wrote:
> There are some kb of difference between the files produced by the two
> techniques :
> 79.3 MiB (83,106,001 byte) : find . -print -depth | cpio --create
> --format='newc' > ../../initrd.img-5.10.0-18-amd64
> 79.3 MiB (83,108,291 byte) : find . | cpio --create --format='newc' >
> ../../initrd.img-5.10.0-18-amd64
I would only worry if cpio -t would show significant differences.
The find option -depth influences the sequence of names. So i would do:
find . -print -depth | cpio ...
cat ../../initrd.img-5.10.0-18-amd64 | cpio -t | sort >/tmp/with_depth
find . | cpio ...
cat ../../initrd.img-5.10.0-18-amd64 | cpio -t | sort >/tmp/without_depth
diff /tmp/with_depth /tmp/without_depth | less
If the content is the same, then no differences should be reported.
The documentation of cpio states that the find run with -depth is to prefer.
The '-depth' option forces 'find' to print of the entries in a
directory before printing the directory itself. This limits the effects
of restrictive directory permissions by printing the directory entries
in a directory before the directory name itself.
Probably this means that at restore time potential write resctrictions
of the directory will only be applied after the files of the directory
have been copied out of the cpio archive into the directory.
> find: warning: you have specified the global option -depth after the
> argument -print, but global options are not positional, i.e., -depth affects
> tests specified before it as well as those specified after it. Please
> specify global options before other arguments.
>
> It is a warning,not an error. But why does it happens ? Can I "fx" it ?
Follow the program's advise and do not put -print before -depth.
I get no warning with
find . -depth 2>&1 | less
find . -depth -print 2>&1 | less
-print is surplus here, anyways. man find says:
find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression]
...
If no expression is given, the expression -print is used
(Do you really get that warning from
find . 2>&1 | less
? There is no -depth to complain about, and my local find does not warn.)
Mario Marietto wrote:
> There are some kb of difference between the files produced by the two
> techniques :
> 79.3 MiB (83,106,001 byte) : find . -print -depth | cpio --create
> --format='newc' > ../../initrd.img-5.10.0-18-amd64
> 79.3 MiB (83,108,291 byte) : find . | cpio --create --format='newc' >
> ../../initrd.img-5.10.0-18-amd64
The find option -depth influences the sequence of names. So i would do:
find . -print -depth | cpio ...
cat ../../initrd.img-5.10.0-18-amd64 | cpio -t | sort >/tmp/with_depth
find . | cpio ...
cat ../../initrd.img-5.10.0-18-amd64 | cpio -t | sort >/tmp/without_depth
diff /tmp/with_depth /tmp/without_depth | less
If the content is the same, then no differences should be reported.
The documentation of cpio states that the find run with -depth is to prefer.
The '-depth' option forces 'find' to print of the entries in a
directory before printing the directory itself. This limits the effects
of restrictive directory permissions by printing the directory entries
in a directory before the directory name itself.
Probably this means that at restore time potential write resctrictions
of the directory will only be applied after the files of the directory
have been copied out of the cpio archive into the directory.
> find: warning: you have specified the global option -depth after the
> argument -print, but global options are not positional, i.e., -depth affects
> tests specified before it as well as those specified after it. Please
> specify global options before other arguments.
>
> It is a warning,not an error. But why does it happens ? Can I "fx" it ?
I get no warning with
find . -depth 2>&1 | less
find . -depth -print 2>&1 | less
-print is surplus here, anyways. man find says:
find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression]
...
If no expression is given, the expression -print is used
(Do you really get that warning from
find . 2>&1 | less
? There is no -depth to complain about, and my local find does not warn.)
Mario Marietto
Oct 28, 2022, 7:50:05 AM10/28/22
to
This command does not reports the warning :
find . -depth -print | cpio --create --format='newc' > ../../initrd.img-5.10.0-19-amd64
554538 blocks.
and :
# cat initrd.img-5.10.0-19-amd64-depth | cpio -t | sort >/tmp/with_depth
554538 blocks
554538 blocks
# cat initrd.img-5.10.0-19-amd64-depth | cpio -t | sort >/tmp/no_depth
554538 blocks
554538 blocks
# diff with_depth no_depth | less
no difference.
Mario.
Charles Curley
Oct 28, 2022, 9:50:05 AM10/28/22
to
find … -type f …
That will select only files, not directories, symlinks, devices, etc.
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
Mario Marietto
Oct 28, 2022, 10:00:05 AM10/28/22
to
Hello Charles.
Can you write the full command ? I don't understand what you mean with "
find … -type f …". I'm orienting myself to use this :
find . -depth | cpio --create --format='newc' > /boot/$CURRENT_KERNEL_VERSION_NO_GZ
as suggested by Thomas. In this command I don't see any "-type f". Very much.
Mario.
Charles Curley
Oct 28, 2022, 10:30:06 AM10/28/22
to
On Fri, 28 Oct 2022 15:54:00 +0200
Mario Marietto <mariet...@gmail.com> wrote:
> Hello Charles.
>
> Can you write the full command ? I don't understand what you mean
> with " find … -type f …". I'm orienting myself to use this :
>
> find . -depth | cpio --create --format='newc' >
> /boot/$CURRENT_KERNEL_VERSION_NO_GZ
>
> as suggested by Thomas. In this command I don't see any "-type f".
> Very much.
I have not tested this, but try
Mario Marietto <mariet...@gmail.com> wrote:
> Hello Charles.
>
> Can you write the full command ? I don't understand what you mean
> with " find … -type f …". I'm orienting myself to use this :
>
> find . -depth | cpio --create --format='newc' >
> /boot/$CURRENT_KERNEL_VERSION_NO_GZ
>
> as suggested by Thomas. In this command I don't see any "-type f".
> Very much.
find . -depth -type f | cpio …
Greg Wooledge
Oct 28, 2022, 10:50:05 AM10/28/22
to
There's no issue with the snippet quoted above. Of course, this cpio
command is incomplete (it needs a redirection to an archive file or
something), but the part that's shown is fine.
unicorn:~$ mkdir /tmp/x && cd "$_"
unicorn:/tmp/x$ mkdir dir; touch dir/file{1,2}
unicorn:/tmp/x$ find . | cpio --create | cpio -ivt
1 block
drwxr-xr-x 3 greg greg 0 Oct 28 10:46 .
drwxr-xr-x 2 greg greg 0 Oct 28 10:46 dir
-rw-r--r-- 1 greg greg 0 Oct 28 10:46 dir/file2
-rw-r--r-- 1 greg greg 0 Oct 28 10:46 dir/file1
1 block
See? No duplicates. Unlike GNU tar, which recurses into the directory
in addition to receiving the already-recursed files from find:
unicorn:/tmp/x$ find . | tar -cf - --files-from=- | tar tvf -
drwxr-xr-x greg/greg 0 2022-10-28 10:46 ./
drwxr-xr-x greg/greg 0 2022-10-28 10:46 ./dir/
-rw-r--r-- greg/greg 0 2022-10-28 10:46 ./dir/file2
-rw-r--r-- greg/greg 0 2022-10-28 10:46 ./dir/file1
drwxr-xr-x greg/greg 0 2022-10-28 10:46 ./dir/
hrw-r--r-- greg/greg 0 2022-10-28 10:46 ./dir/file2 link to ./dir/file2
hrw-r--r-- greg/greg 0 2022-10-28 10:46 ./dir/file1 link to ./dir/file1
hrw-r--r-- greg/greg 0 2022-10-28 10:46 ./dir/file2 link to ./dir/file2
hrw-r--r-- greg/greg 0 2022-10-28 10:46 ./dir/file1 link to ./dir/file1
Mario Marietto
Oct 28, 2022, 11:10:06 AM10/28/22
to
Greg,are you talking about this :
find . -depth -type f | cpio --create --format='newc' > ../../initrd.img-5.10.0-18-amd64
or this :
find . -depth | cpio --create --format='newc' > ../../initrd.img-5.10.0-18-amd64
or are they equivalent ? Thanks.
Mario.
David Wright
Oct 28, 2022, 11:20:05 AM10/28/22
to
On Fri 28 Oct 2022 at 12:44:43 (+0200), Thomas Schmitt wrote:
> Mario Marietto wrote:
> > There are some kb of difference between the files produced by the two
> > techniques :
> > 79.3 MiB (83,106,001 byte) : find . -print -depth | cpio --create
> > --format='newc' > ../../initrd.img-5.10.0-18-amd64
> > 79.3 MiB (83,108,291 byte) : find . | cpio --create --format='newc' >
> > ../../initrd.img-5.10.0-18-amd64
>
> I would only worry if cpio -t would show significant differences.
> The find option -depth influences the sequence of names. So i would do:
>
> find . -print -depth | cpio ...
>
> cat ../../initrd.img-5.10.0-18-amd64 | cpio -t | sort >/tmp/with_depth
>
> find . | cpio ...
>
> cat ../../initrd.img-5.10.0-18-amd64 | cpio -t | sort >/tmp/without_depth
>
> diff /tmp/with_depth /tmp/without_depth | less
>
> If the content is the same, then no differences should be reported.
>
>
> The documentation of cpio states that the find run with -depth is to prefer.
>
> The '-depth' option forces 'find' to print of the entries in a
> directory before printing the directory itself. This limits the effects
> of restrictive directory permissions by printing the directory entries
> in a directory before the directory name itself.
>
> Probably this means that at restore time potential write resctrictions
> of the directory will only be applied after the files of the directory
> have been copied out of the cpio archive into the directory.
Disclaimer: I don't have any recent experience with cpio beyond
> Mario Marietto wrote:
> > There are some kb of difference between the files produced by the two
> > techniques :
> > 79.3 MiB (83,106,001 byte) : find . -print -depth | cpio --create
> > --format='newc' > ../../initrd.img-5.10.0-18-amd64
> > 79.3 MiB (83,108,291 byte) : find . | cpio --create --format='newc' >
> > ../../initrd.img-5.10.0-18-amd64
>
> I would only worry if cpio -t would show significant differences.
> The find option -depth influences the sequence of names. So i would do:
>
> find . -print -depth | cpio ...
>
> cat ../../initrd.img-5.10.0-18-amd64 | cpio -t | sort >/tmp/with_depth
>
> find . | cpio ...
>
> cat ../../initrd.img-5.10.0-18-amd64 | cpio -t | sort >/tmp/without_depth
>
> diff /tmp/with_depth /tmp/without_depth | less
>
> If the content is the same, then no differences should be reported.
>
>
> The documentation of cpio states that the find run with -depth is to prefer.
>
> The '-depth' option forces 'find' to print of the entries in a
> directory before printing the directory itself. This limits the effects
> of restrictive directory permissions by printing the directory entries
> in a directory before the directory name itself.
>
> Probably this means that at restore time potential write resctrictions
> of the directory will only be applied after the files of the directory
> have been copied out of the cpio archive into the directory.
the examples I have posted here, and of course its routine use
by mkinitramfs. Most of my use in the distant past was pass-through
copying of sometimes active filesystems in preference (at that time)
to cp -a and tar. And I have no experience of building bootable
images, again except with routine system administration.
But a couple of observations. Taking the initrd.gz from
install.amd/gtk in 11.3.0 netinst as an example, I notice that
the entries are in sort order, so directories come first.
Presumably, this doesn't cause any issue because every entry has
at least rw permission for the user.
The same is true for my initrd in /boot/grub, with a couple of
provisos: I believe there are two cpio archives in a typical
initrd.img-*-amd64, the kernel microcode and the rest. And within
the rest, there appears to be a busybox-like binary with about
250 links tacked on the end under the name usr/sbin/watchdog,
and the links to it are listed in reverse order (with the obvious
exception of "watchdog" itself).
So if the presence of -depth is significant, and causes an issue
when unpacking, it suggests a permissions problem in the tree
that's being packed.
> > find: warning: you have specified the global option -depth after the
> > argument -print, but global options are not positional, i.e., -depth affects
> > tests specified before it as well as those specified after it. Please
> > specify global options before other arguments.
> >
> > It is a warning,not an error. But why does it happens ? Can I "fx" it ?
>
> Follow the program's advise and do not put -print before -depth.
> I get no warning with
>
> find . -depth 2>&1 | less
>
> find . -depth -print 2>&1 | less
>
> -print is surplus here, anyways. man find says:
>
> find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression]
> ...
> If no expression is given, the expression -print is used
>
>
> (Do you really get that warning from
> find . 2>&1 | less
> ? There is no -depth to complain about, and my local find does not warn.)
console output, rather than giving us a paraphrased narrative
of what they (might) have done.
On Fri 28 Oct 2022 at 07:47:02 (-0600), Charles Curley wrote:
> On Fri, 28 Oct 2022 09:32:00 +0700 Max Nikulin wrote:
> > On 28/10/2022 07:07, Mario Marietto wrote:
> > >
> > > find . | cpio --create
> > I rarely use cpio, but recently there was a thread on tar and
> > unwanted hard links in the created archive. "find" output mixes
> > regular files and directories. If the archiver recursively walks
> > through received directories then result may differ from expectations.
Note that the aforementioned typical /boot/initrd.img-*-amd64
> > On 28/10/2022 07:07, Mario Marietto wrote:
> > >
> > > find . | cpio --create
> > I rarely use cpio, but recently there was a thread on tar and
> > unwanted hard links in the created archive. "find" output mixes
> > regular files and directories. If the archiver recursively walks
> > through received directories then result may differ from expectations.
is stuffed with hard links.
> Right. To avoid picking up directories, use
>
> find … -type f …
>
> That will select only files, not directories, symlinks, devices, etc.
device files and symlinks.
Cheers,
David.
Mario Marietto
Oct 28, 2022, 12:20:06 PM10/28/22
to
Ok. Thanks to everyone for the valuable help. In the end I have developed this elementary script. I feel like a dwarf on the shoulders of giants,but that's it :
#!/bin/bash
if [ "`id -u`" -ne 0 ]; then
echo "Switching from `id -un` to root"
exec sudo "$0"
exit 99
fi
# Lets check the kernel version
function kernels-check() {
CURRENT_KERNEL_VERSION_LIQUORIX=$(uname --kernel-release | cut --delimiter="-" --fields=3)
if [ "$CURRENT_KERNEL_VERSION_LIQUORIX" = "liquorix" ]; then
CURRENT_KERNEL_VERSION='initrd.img-'$(uname --kernel-release | cut --delimiter="-" --fields=1-3)
else
CURRENT_KERNEL_VERSION='initrd.img-'$(uname --kernel-release | cut --delimiter="-" --fields=1-2)
fi
rm -r /boot/unzipped/$CURRENT_KERNEL_VERSION'-amd64'
mkdir /boot/unzipped/$CURRENT_KERNEL_VERSION'-amd64'
gunzip -k /boot/$CURRENT_KERNEL_VERSION'-amd64.gz'
cpio -idvm < /boot/$CURRENT_KERNEL_VERSION'-amd64' -D /boot/unzipped/$CURRENT_KERNEL_VERSION'-amd64'
cp -p /usr/share/plymouth/debian-logo.png /boot/unzipped/$CURRENT_KERNEL_VERSION'-amd64'/usr/share/plymouth/
cp -p /usr/share/plymouth/themes/homeworld/debian.png /boot/unzipped/$CURRENT_KERNEL_VERSION'-amd64'/usr/share/plymouth/themes/homeworld
cp -p /usr/share/plymouth/themes/homeworld/logo.png /boot/unzipped/$CURRENT_KERNEL_VERSION'-amd64'/usr/share/plymouth/themes/homeworld
cd /boot/unzipped/$CURRENT_KERNEL_VERSION'-amd64'
find . -depth | cpio --create --format='newc' > /boot/$CURRENT_KERNEL_VERSION'-amd64'
gzip --force /boot/$CURRENT_KERNEL_VERSION'-amd64'
}
kernels-check
Mario.
It is loading more messages.
0 new messages