Set course for 3.03 release

Type journalctl and scroll down to squashes lines, and make a photo of your screen then attach it here.

@ben79 you can also try to adding rd.debug to boot line (and remove quiet to get more output at screen) so you can find a log file called something as /run/initramfs/rdsosreport.log (I apologize I canā€™t remember the exact name now) with useful infos.

Here is the new ISO.

https://abf.openmandriva.org/platforms/3.0/products/38/product_build_lists/1358

iā€™ve updated zstd patches, which may have been the culprit.

Quick test in virtualbox, I got the dracut prompt also for 1358 like it happened for 1356.

This from ISO build ID 1358. In VirtualBox.

Thanks for the screen, I have same error.
Iā€™ll try to ask zstd developers for a help.

Bug reported SQUASHFS error: failed to initialize zstd decompressor Ā· Issue #799 Ā· facebook/zstd Ā· GitHub

According to zstd maintainer issue is on ā€œourā€ side, as he is not able to reproduce it.

@Colin @bero can you please take a look on this issue?

Back from holiday Saturday will look then. Tests I did on holiday before laptop broke indicated image corruption.
Colin

Iā€™m hoping we can get KNewStuff fixed:

https://issues.openmandriva.org/show_bug.cgi?id=2205

knewstuff still reports it is missing configuration files for foo.knsrc files.

Edit: Donā€™t know if the fix is here or earlier?

1 Like

Starting seperate thread for Knewstuff here.

https://issues.openmandriva.org/show_bug.cgi?id=2205

Postedit: This is now fixed.

TPG; So far I have done the following. Built the iso using the --quicken flag in omdv-build-iso (with zstd) enabled. This flag uses no compression but passed the zstd compressor flag. The system booted.
Next I built without the flag and it still failed within dracut. The error was the same as those reported previously.
While in dracut I unloaded the squashfs kernel module (modprobe -r squashfs) and then reloaded (modprobe squashfs)
The module loaded cleanly without error. I tried this a couple of times and the result is consistant. I checked the mounts and and the squashfs image was mounted correctly.
There is only one other clue that I have. Iā€™ve noticed in previous months that itā€™s not possible to mount the isos that have been copied to a memory stick this always used to be possible I thought this might possible be related so I did some tests.

If the filesystem is being misidentified in some way this may constitute data corruption but for the life of me I cannot work out how this is happening. Does mksquashfs somehow inherit the filesystem driver from the local chroot? My ~home is on an F2FS drive partition.
Of course itā€™s probable that this issue is entirely unrelated since isoā€™s built with xz are still functional.

sd 8:0:0:0: [sde] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB)
[Sat Aug 26 17:59:58 2017] sde: sde1 sde2
[Sat Aug 26 17:59:58 2017] ISOFS: Unable to identify CD-ROM format.
[Sat Aug 26 18:00:08 2017] ISOFS: Unable to identify CD-ROM format.
[Sat Aug 26 18:04:50 2017] F2FS-fs (sde1): Magic Mismatch, valid(0xf2f52010) - read(0x89e44589)
[Sat Aug 26 18:04:50 2017] F2FS-fs (sde1): Canā€™t find valid F2FS filesystem in 1th superblock
[Sat Aug 26 18:04:50 2017] F2FS-fs (sde1): Magic Mismatch, valid(0xf2f52010) - read(0xb9d87cc8)
[Sat Aug 26 18:04:50 2017] F2FS-fs (sde1): Canā€™t find valid F2FS filesystem in 2th superblock
[Sat Aug 26 18:04:50 2017] F2FS-fs (sde1): Magic Mismatch, valid(0xf2f52010) - read(0x89e44589)
[Sat Aug 26 18:04:50 2017] F2FS-fs (sde1): Canā€™t find valid F2FS filesystem in 1th superblock
[Sat Aug 26 18:04:50 2017] F2FS-fs (sde1): Magic Mismatch, valid(0xf2f52010) - read(0xb9d87cc8)
[Sat Aug 26 18:04:50 2017] F2FS-fs (sde1): Canā€™t find valid F2FS filesystem in 2th superblock

Also a simple test unsquashing the filesystem revealed this.

unsquashfs squashfs.img
Parallel unsquashfs: Using 8 processors
206621 inodes (236463 blocks) to write

write_file: failed to create file squashfs-root/etc/locale/da_DK.ISO-8859-15/LC_TIME, because Too many open files
[===============================================================================================================================================/ ] 236462/236463 99%

Checking aginst the original chroot shows that this file was not created. Our current file limit is 1024 shown by ulimit -a.

I ran the identical test using xz compression and got a similar error although it failed on a different file in /etc/locale .
Since xz compression works I guess it canā€™t be that this is the problem. I wonder if we should raise the open file limit because dracut runs a load of shell scripts in the initrd and I guess it it could cause an issue even though itā€™s the kernel thatā€™s doing the unsquashing.

Iā€™ve done loads more work but am no nearer a solution.
I injected unsquashfs into the initrd and was able to demonstrate that the squashfs.img had not been corrupted between itā€™s creation and transfer to the iso.
I also tried leaving out the blocksize from the mksquashfs command line to allow the program to determine the default but it made no difference.

I also generated a squashfs.im using the --quicken flag which disables any compression of the squashfs but still allows you to define the compressor. The iso booted with this setting.
I can only conclude from these tests that mksquashfs is creating a squashfs.img header that the kernel decompressor cannot read and therefore cannot set the appropriate values to do the decompression.

I note from the kernel sources that there is a compressor as well as a decompressor it it possible that the maintainer has been doing his/her testing using the kernel and has not tried ā€œcrossā€ creation and decompression using squashfs-tools to create and the kernel to decompress.
IMHO The fault lies in an incompatibility between the kernel and mksquashfs

As a last ditch attempt to fix the zstd kernel decompression I renewed the crypto pactch from the zstd source tree and fixed the Makefile part where it was not applying. This combined with debug patch created a working kernel and after removing the -b option from mksquashfs invocation gave identical numbers to those of the maintainer. I then backed out the debug patch and rebuilt the kernel locally and it still worked.
I committed to github and a new build is in progress. Hopefully this will resolve the issue and we can build some new isos.

A new iso that includes a fixed kernel with hopefully working zstd compression and a dract with the dash syntax error fixed is building https://abf.openmandriva.org/platforms/3.0/products/38/product_build_lists/1386.
Hopefully it will just work.

Very quick test on UEFI computer with USB 3.0 flash drive. Boots to Live does not boot to Install.
In Live mode installation to hardware worked.

So substantial progress.

Installed successfully on Virtual Box. No problems encountered. Will try a live PC this afternoon.

Iā€™m thinking and hoping we get some thorough testing. Concerned about such a big change.

Iā€™m seeing for instance kernels not wanting to boot. Seeing this with 4.11.3-desktop-2omv and 4.12.6-desktop-4omv. Currently only 4.12.6-desktop-2omv is booting. Will let Yā€™all know more when/if I know more.

ISO 1386 in virtualbox: boots in live mode, and installs properly from ā€œInstallā€ ISO menu.

ISO 1386 on a live non-EFI pc. Same as Ben79. When I selected install - calamares crashed, but if I boot to live then run calamares all works.

So it seems BIOS boots may be problematic now and still the Calamares issue persists. Please keep the reports coming. Expecially check the calamares install outside of the live image several times my experience in the past is that sometimes it works and sometimes it doesnā€™t.

Did some testing here last night-
In Virtualbox boots both in live mode and install mode in both BIOS and EFI modes
On real EFI hardware with nVidia it boots both live mode and install mode without issue.

On BIOS based hardware there is are issues-
With an nVidia based box I can boot to live without issue however booting to install starts calamares and then it immediately closes. Maybe it has a problem reading the BIOS?

Things get bizarre when trying to start in simple graphics mode for the live boot systemd always stops at the system tuning daemon start the same behaviour also occurs when booting to install in simple graphics mode.

Finally on an Intel graphics based eepc I could not boot to live in full graphics mode
systemd seems to halt at Starting Network Manager Script service. The machine is not locked up alt-ctrl-del will reboot it.
When booted to install the process fails at starting the xserver. Looking at the error messages it does not load the intel module and later on there is a message about requiring OpenGl-2.1 or greater
It looks like thereā€™s a missing package like the intel Xserver module.
In the basic graphics live mode it does boot but monitor detection seems to be broken on this system so the screen has an unusably low resolution.

There is something wrong with Intel I think but Iā€™ve no idea where to start looking for the issue.

Itā€™s Sunday so time to ask the questions, again. There are new ISOā€™s made every Sunday, lately under user HisShadow. Probably a scheduled automatic thing like a cron job. In the past the accepted procedure for testing was to always test the most recent ISO and label any observations specifically mentioning the ISO build ID number. Like ā€œBooted Lx 3.03beta 64 bit ISO # 1390 ā€˜Liveā€™ and absolutely everything just worked.ā€ or whatever may have transpired.

I presume we continue with this protocol?

And a big old fashioned Thank You to HisShadow and itchka for making new ISOā€™s available. And a big old fashioned Thank You to itchka for fixing the boot problem with zstd compression.

2 Likes