at 24. i decided to do the upgrade to Core 162 which unfortunately ended with Ipfire not booting any more.
System : Atom C2550, Supermicro A1SAM-2550F
OS : Dom0, Debian Buster
Hypervisor : Xen 4.11.4
The update process went perfectly through without any issues:
Dec 24 18:25:46 ipfire pakfire: PAKFIRE INFO: IPFire Pakfire 2.27-x86_64 started!
Dec 24 18:25:46 ipfire pakfire: CORE INFO: core-list.db is 66281 seconds old. - DEBUG: force
Dec 24 18:25:46 ipfire pakfire: DOWNLOAD STARTED: lists/core-list.db
Dec 24 18:25:46 ipfire pakfire: MIRROR INFO: 24 servers found in list
Dec 24 18:25:46 ipfire pakfire: DOWNLOAD INFO: Host: ipfire.infania.net (HTTPS) - File: pakfire2/2.27-x86_64/lists/core-list.db
Dec 24 18:25:46 ipfire pakfire: DOWNLOAD INFO: pakfire2/2.27-x86_64/lists/core-list.db has size of 903 bytes
Dec 24 18:25:47 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
Dec 24 18:25:47 ipfire pakfire: DOWNLOAD INFO: File received. Start checking signature...
Dec 24 18:25:47 ipfire pakfire: DOWNLOAD INFO: Signature of core-list.db is fine.
Dec 24 18:25:47 ipfire pakfire: DOWNLOAD FINISHED: pakfire2/2.27-x86_64/lists/core-list.db
Dec 24 18:25:47 ipfire pakfire: CORE UPGR: Upgrading from release 161 to 162
Dec 24 18:25:47 ipfire pakfire: DOWNLOAD STARTED: meta/meta-core-upgrade-162
Dec 24 18:25:47 ipfire pakfire: MIRROR INFO: 24 servers found in list
Dec 24 18:25:47 ipfire pakfire: DOWNLOAD INFO: Host: mirror.cedia.org.ec (HTTPS) - File: ipfire/pakfire2/2.27-x86_64/meta/meta-core-upgrade-162
Dec 24 18:25:48 ipfire pakfire: DOWNLOAD INFO: ipfire/pakfire2/2.27-x86_64/meta/meta-core-upgrade-162 has size of 997 bytes
Dec 24 18:25:49 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
Dec 24 18:25:49 ipfire pakfire: DOWNLOAD INFO: File received. Start checking signature...
Dec 24 18:25:49 ipfire pakfire: DOWNLOAD INFO: Signature of meta-core-upgrade-162 is fine.
Dec 24 18:25:49 ipfire pakfire: DOWNLOAD FINISHED: ipfire/pakfire2/2.27-x86_64/meta/meta-core-upgrade-162
Dec 24 18:25:49 ipfire pakfire: DOWNLOAD STARTED: paks/core-upgrade-2.27-162.ipfire
Dec 24 18:25:49 ipfire pakfire: MIRROR INFO: 24 servers found in list
Dec 24 18:25:49 ipfire pakfire: DOWNLOAD INFO: Host: mirror.uta.edu.ec (HTTPS) - File: ipfire/pakfire2/2.27-x86_64/paks/core-upgrade-2.27-162.ipfire
Dec 24 18:25:50 ipfire pakfire: DOWNLOAD INFO: ipfire/pakfire2/2.27-x86_64/paks/core-upgrade-2.27-162.ipfire has size of 80142736 bytes
Dec 24 18:26:27 ipfire pakfire: DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
Dec 24 18:26:28 ipfire pakfire: DOWNLOAD INFO: File received. Start checking signature...
Dec 24 18:26:29 ipfire pakfire: DOWNLOAD INFO: Signature of core-upgrade-2.27-162.ipfire is fine.
Dec 24 18:26:29 ipfire pakfire: DOWNLOAD FINISHED: ipfire/pakfire2/2.27-x86_64/paks/core-upgrade-2.27-162.ipfire
Dec 24 18:26:29 ipfire pakfire: PAKFIRE UPGR: core-upgrade-162: Decrypting...
Dec 24 18:26:29 ipfire pakfire: CLEANUP: tmp
Dec 24 18:26:29 ipfire pakfire: DECRYPT STARTED: core-upgrade-162
Dec 24 18:26:31 ipfire pakfire: DECRYPT FINISHED: core-upgrade-162 - Status: 0
Dec 24 18:26:32 ipfire pakfire: PAKFIRE UPGR: core-upgrade-162: Upgrading files and running post-upgrading scripts...
Dec 24 18:27:15 ipfire pakfire: CLEANUP: tmp
Dec 24 18:27:15 ipfire pakfire: PAKFIRE UPGR: core-upgrade-162: Finished.
Dec 24 18:27:15 ipfire pakfire: CORE INFO: core-list.db is 88 seconds old. - DEBUG: noforce
Dec 24 18:27:15 ipfire pakfire: PAKFIRE INFO: Pakfire has finished. Closing.
But after rebooting the system doesnāt came up again.
Altough the kernel seems to be compiled with all neccessary options to be needed for an paravitualized machine, at least as far as my understanding reaches, according to Ipfire 2.x Kernel 5.15.6 commit
During the boot process Ipfire isnāt started with paravirtualized kernel which i suspect to be the main reason:
Boot on core 162:
Booting kernel on Xen
Xen version: 4.11.4 (preserve-AD)
took me quite some time to be able to give you that info.
For me itās the first time looking into an initramfs.
Looks like at least the xen_blkfront drivers are missing, somewhat as i assumed as in the dracut shell i also had no blkid to look for what drives are available:
I donāt believe so.
I am really not experienced with kernel stuff, but i think the main culprit is the kernel isnāt able to access the storage as Michael Tremer stated before.
If i am not wrong the Blockdevice driver is needed for the kernel to access the storage.
It seems to be compiled in as module, but the modules arenāt in the initramfs.
For sure Arne Fitzenreiter will find out whats going wrong.
Hi,
I have a simular problem (Update from .161 to .162 on XEN). Drucat is not finding the disk.
I just tried a fresh flush-image with the some error message.
Some more info I may/can share?
Best regards
B. Hafenwasser
log from console:
Key type dns_resolver registered
IPI shorthand broadcast: enabled
AVX2 version of gcm_enc/dec engaged.
AES CTR mode by8 optimization enabled
sched_clock: Marking stable (1054978441, 416028)->(1056815452, -1420983)
registered taskstats version 1
Loading compiled-in X.509 certificates
Loaded X.509 cert āIPFire.org: Build time autogenerated kernel key: a6a6963e785feaad5e1c5e6a9340b157a331b013ā
xenbus_probe_frontend: Device with no driver: device/vbd/51744
xenbus_probe_frontend: Device with no driver: device/vif/0
xenbus_probe_frontend: Device with no driver: device/vif/1
xenbus_probe_frontend: Device with no driver: device/vif/2
Freeing unused kernel image (initmem) memory: 2100K
Write protecting the kernel read-only data: 22528k
Freeing unused kernel image (text/rodata gap) memory: 2036K
Freeing unused kernel image (rodata/data gap) memory: 1780K
x86/mm: Checked W+X mappings: passed, no W+X pages found.
Run /init as init process
dracut: dracut-038
udevd[258]: starting eudev-3.2.6
setfont: putfont: 512,8x16:failed: -1
putfont: PIO_FONTX: Inappropriate ioctl for device
dracut Warning: Could not boot.
dracut Warning: Could not boot.
dracut Warning: /dev/disk/by-uuid/f23d4e7b-f53e-4814-89dd-a6dbc374989e does not exist
dracut Warning: /dev/disk/by-uuid/f23d4e7b-f53e-4814-89dd-a6dbc374989e does not exist
Generating ā/run/initramfs/rdsosreport.txtā
You might want to save ā/run/initramfs/rdsosreport.txtā to a USB stick or /boot
after mounting them and attach it to a bug report.
To get more debug information in the report,
reboot with ārd.debugā added to the kernel command line.
Hi,
i donāt think further info is needed.
As mentioned above the block-device drivers for XEN are missing in the initramfs, probably a simple packaging error.
We just have to wait for an corrected kernel and stay on core_161 meanwhile.
Hi Sysiphus
I have the same issue and could confirm, it is a missing driver in the initramdisk. The kernel 5.15 boots fine but cannot mount the root filesystem due to missing xen-blkfront driver.
To add the missing driver to the initrd, mkinitrd is your friend. The following command creates a working initramdisk with needed xen-blkfront driver (āforce is needed to overwrite the existing ramdisk): mkinitrd --force --with=xen-blkfront /boot/initramfs-5.15.6-ipfire.img 5.15.6-ipfire
This command must be run in a still running system after upgrade to 162 prior rebooting or in a chroot environment. Therefore, mount the root partition for instance in /mnt/root first, then the boot partition correspondingly under /mnt/root/boot and bind /proc and /sys to the tree with: sudo mount -o bind /proc /mnt/root/proc sudo mount -o bind /sys /mnt/root/sys
Finally use chroot to enter the ipfire environment: sudo chroot /mnt/root
This has nothing to do with the kernel module. On non VGA consoles this error is normal since the last coreutils (i think) update. There is no font that you can configue and the old putfont binary has ignored the error.
Ups. The xen-blkfront module is new older kernels donāt have it.
I will add this to the dracut config in the next update.
upgraded form 161 to 163 (after upgrade form 161 to 162 failed with the problem described here)
same problem during upgrade from form 161 to 163 ā¦ missing xen_blkfront
examined the update-core-upgrade-163.log
found
Failed to install module xen_blkfront
Failed to install module reiserfs
found that the upgrade script is using dracut --force --early-microcode --strip --verbose --xz
to build the initrd
but this will build only the āoldā initrd from current running kernel which is 5.10.76-ipfire
i just run (before rebooting after upgrade) dracut --force --early-microcode --strip --verbose --xz --kver 5.15.6-ipfire
which created the initramfs-5.15.6-ipfire.img
This initramfs now includes the xen-blkfront.ko.xz module
Maybe would be better to use ādracut --regenerate-allā in the upgrade script?
Hope this post can help others to solve booting problems with Xen
BTW: i have also the message āCould not find āstripā. Not stripping the initramfs.ā
Not sure that the new modules are stripped!
19161884 initramfs-5.15.6-ipfire.img
11347044 initramfs-5.10.76-ipfire.img
new initramfs is really largeā¦ (maybe the new kernelā¦)
Thatās great. Also, since you are running IPFire on Xen, may I ask you to test upcoming Core Updates and report if anything is wrong there?
Our Xen userbase is not very large, and we usually get no feedback from that group in the testing phase. Therefore, it would be great to see more people testing IPFire Core Updates before they are released.
Yes, thatās the reason. The kernel does not become smaller over timeā¦
Um, this should have been fixed by this commit in Core Update 163. Odd to see dracut is missing this oneā¦
Yes this commit will put the driver to the list.
But the dracut command you are using will only recreate the initrd for the currently running kernel.
Which in my case was the old 5.10.76-ipfire one. So i get the message Kernel version 5.10.76-ipfire has no module directory /lib/modules/5.10.76-ipfire
/lib/modules/5.10.76-ipfire was deleted at this point.
The new initrd was missing `the modules
Failed to install module xen_blkfront
Failed to install module reiserfs
In case not changing the kernel everthing would be ok i assume
ādracut --regenerate-allā will regenerate āallā initrdās of all installed kernels.
Or you may use the ākver option and specify the new Kernel Version.
Ok i will try to check the core updates earlier (before release) if possible. Switched to testingā¦
There should be not many differences from ipfire on Xen to other systems.
The included xen_blkfront (needed in initrd) and xen_netfront might be the only ones.
And even this can be avoided by using standard drivers by performance decrease.
Hi
I was also hit by the same problem today, upgrading from 160 to 163, and running on xen (xcp-ng).
I had to revert to 160 again, since I only found this thread afterwards.
Should I report a new bug for this, so it could be fixed for core164, and then I can test that it works (I could also switch to use the testing version of 164), since Iām still on core 160.
Itās been the first time in many years that an upgrade has left my virtual ipfire system unbootable (but Iāve only recently switched from kvm to xen based).
