pi3p16s154 is nvme0n1p16 ext4 root filesystem LABEL.
crypto is not employed anywhere on the PC.
5.14.21-150400.19 kernel boots normally.
5.14.21-150400.22 kernel is not recognizing USB stick insertion, so
there's no way I know to get /run/initramfs/rdsosreport.txt onto a
stick for susepasting, and susepaste isn't in the emergency shell.
Neither does the shell include grep. I rebuilt initrd with
add_dracutmodules+=debug but still no susepaste or grep, or lsblk, or
fdisk, or improvement.
Selected excerpts from rdsosreport.txt:
systemd-modules-load.service: Failed with result 'exit-code'.
Failed to start Load Kernel Modules.
systemd-modules-load...Failed to look up module alias 'sg': Function not implemented
condition check resulted in dracut pre-trigger hook being skipped
dracut-initqueue...Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks: /lib/dracut/hooks/initqueue/finished/devexists-/dev/disk/by-label-pi3p16s154.sh "if ! grep After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup(a)*.service 2>/dev/null; then [ -e " /dev/disk/by-label/pi3p16s154" ]
Warning: dracut-initqueue: starting timeout scripts
Warning: Could not boot.
systemd: Starting Dracut Emergency Shell....
Is there anything above that suggests why the .22 initrd failed to
enable nvme / filesystem to be found?
https://paste.opensuse.org/57952814 is output from lsinitrd /boot/initrd.
I did essentially the same dup to 15.4 a week ago on another PC
with same Intel b250 chipset, also UEFI & nvme, and no trouble.
I copied each of 3 .22 initrds from the first PC to the second.
The first boots normally. The second not, initially stopping at
starting dracut initqueue hook, winding up in emergency shell.
So did the #3 initrd. The initrd from the update last week copied
to today's also fails in same manner.
The big difference between the two PCs: the problem PC contains 2
HDDs with multiple partitions, about half of which comprise several
mdraid devices, none of which have anything to do with booting the
problem 15.4 installation.
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Dear openSUSE experts,
I have crahed system that I want to reinstall via USB install of
Tumbleweed withou format partitions
On the system there were/are some directory links with absolute path
made like/in style of
mv /usr/share/"someDir" /home/partOfShare
ln -s /home//partOfShare/"someDir" /usr/share
I was recovered most of the install failures by replacing
absolute links to relavive links via
ln -s ../../partOfShare/"someDir" .
BUT during install
there are failed install filesystem package
lua script fialed (:%prein/filesystem..") No such file o directory
Only other erros are missing /bin/sh, even if there is working binary
(not link) in /mnt/bin whene using installer. but every error message
I asume that %postinst may be problem as well.
I cannot find content of %preinst variable, so I cannot find which
directory to check for bad link.
I there anzbody who is able and allowed to send me directorz where to
find content of %preinst variable, please?
Thank you for any data that helps me to find not corect path
I look forward hearing from you
Searching for the package postfix-policyd-spf-perl for Leap 15.4 architecture
armv7l, I found:
with version for almost all openSUSE versions: openSUSE_Leap_15.0 till
openSUSE_Leap_15.3, and SLE_15 till SLE_15_SP4, but Leap 15.4 is only
mentioned as 15.4. Fortunately it is a noarch packet, so most likely they are
all almost the same.
But still, is this last one meant for Leap 15.4? It would be more consistent
if it is named openSUSE_Leap_15.4.
Freek de Kruijf
a freshly updated 15.4 RC (via zypper dup some day(s) ago) suddenly
asks for a decision on this suse packages signing key in yast2 module
when going into the online update configuration gui.
what the heck?
YaST2 - online_update_configuration @ tux01
Loading the Package Manager...
x Load Sources
=> Refresh Sources
- Rebuild Cache
- Load Data
Untrusted GnuPG Key │
││The owner of the key may
┬ The following GnuPG key has been found in repository │
││distribute updates, packages, and
│ Update repository with updates from SUSE Linux Enterprise 15│
││package repositories that your
│ (http://download.opensuse.org/update/leap/15.4/sle/): │
││system will trust and offer for
││installation and update without
│ │ID: 70AF9E8139DB7C82 ─│
││any further warning. In this way,
│ │Name: SuSE Package Signing Key ││
││importing the key into your
│ │Fingerprint: FEAB 5025 39D8 46DB 2C09 61CA 70AF 9E81 39DB ││
││keyring of trusted keys allows
││key owner to have a certain
amount│ You can choose to import it into your keyring of trusted │
││of control over the software on
│ public keys, meaning that you trust the owner of the key. │
│ You should be sure that you can trust the owner and that │
│ the key really belongs to that owner before importing it. │
││A warning dialog opens for every
Downloading: 3 KiB/s (on average 3 KiB/s) -
i have not clicked or selected anything i only fired up yast2 and went
into that module to check the state of online updates and if they were
what now? why? :( what IS the advices and best practices work flow
actually for the END USER on these matters deciding about keys and
their acceptance and trust when messing or just working with the
normal default repos on the various opensuse leap systems? I just fail
to understand how a normal user would need to make up decisions of
trust and everything that goes into this.
I am very dissatistfied with these matters :(
Am Dienstag, 17. Mai 2022, 17:23:51 CEST schrieben Sie:
> I've seen this kind of stuck jobs a couple of times in the past years.
> Just running the job will very likely succeed.
> Not sure about the reason, but the following seems to give a hint:
> > [ 5439s] or the build host has a kernel or hardware problem...
this occurs as well on localhost.
As Andreas wrote, this started some ~2 month ago, after it initially build
fine (otherwise it would not make its way into Factory).
I would like to collect some ideas about shrinking and resizing (expanding) of
Background: On a SD card, e.g. 16GB for a Raspi, the last partition is empty
for the most part:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 14,8G 0 disk
├─mmcblk0p1 179:1 0 64M 0 part
├─mmcblk0p2 179:2 0 2G 0 part
└─mmcblk0p3 179:3 0 12,8G 0 part
resize2fs -M should do the job of manual shrinking (in case of ext4)
When the system is started again, the file system should be automatically
expanded to the max available size on the SD card.
Any proposal how to achieve this?
ever since my trial with 15.4 beta clean install, there were a few
packages that only gotton installed hours days etc after the initial
deployment of 15.4beta.
why where these packages trickling into this system, I had thought the
publishing concept was to release a beta and then again the whole deal
of packages for RC stage and for final goldmaster or something?
was the set of packages for beta not very much completed or released
as whole as these select packages came trickling in?