[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Some of the parameters used in my genisoimage command don't produce a bootable ISO image



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

Il giorno ven 28 ott 2022 alle ore 17:18 David Wright <deblis@lionunicorn.co.uk> ha scritto:
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
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.)

That question reinforces my point that the OP should be pasting
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
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.

Note that the aforementioned install.amd/gtk/initrd.gz contains
device files and symlinks.

Cheers,
David.



--
Mario.

Reply to: