Hello.
It's me again. I have another question to ask,another problem to fix,this
time I'm really sure,it's easier to understand and to fix. When I load the
LIVE version of debian 11 (xfce edition),I can't login using the login and
password live / user,but I should use root / root. On the preseed file I'm
using root as password :
d-i passwd/root-password password root
d-i passwd/root-password-again password root
BUT,I have already tried to change root with another password,but it hasn't
affected the live session. I still should use root and root or it says
"access denied". I'm confused. Where are stored the default user and
password used by the LIVE ? and most of all,why has this information been
removed ? I think that I haven't modified it by my own will. Very thanks
for your help. I love Debian and the customer support behind it,that's
very precise and competent.
Il giorno ven 28 ott 2022 alle ore 18:15 Mario Marietto <
marietto2...@gmail.com> ha scritto:
> 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 <
> deb...@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.
>
--
Mario.
