The endless messages, where it hangs are like the following:

--- snip ----
[ 50.345798] FAT-fs (sdb1): IO charset ascii not found
[ 51.487966] FAT-fs (sdb11): IO charset ascii not found
mount: mounting /dev/sdb1 on /live/medium failed: Invalid argument
mount: mounting /dev/sdb11 on /live/medium failed: Invalid argument
....
....
....
and so on...

--- snap ----

Both named filesystems above are really not on /dev/sdb but on /dev/sda.

How can I fix it?

Thanks

Hans

CORRECTION:

The endless messages, where it hangs are like the following:

--- snip ----
[ 50.345798] FAT-fs (sdb1): IO charset ascii not found
[ 51.487966] FAT-fs (sda11): IO charset ascii not found
mount: mounting /dev/sdb1 on /live/medium failed: Invalid argument
mount: mounting /dev/sda11 on /live/medium failed: Invalid argument
....
....
....
and so on...

--- snap ----

Whilst /dev/sdb is the sd-card (where the correct filesystem.squashfs resides and should be found), /dev/sda11 is the harddrive, which should not be accessed.

It looks, like the sd-card can not be mounted, and so filesystem.squashfs cannot be found. Am I correct?

Any ideas, how can I fix it?

Thanks

Hans

Ok, i checked it out. Kali starts from the sd drive (or usb-drive as well), but at the point, when the filesystem.squashfs should be mounted, it hangs. So it is surely a kali bug, and NOT a bug of xboot!

I also checked the other livesystems, which are also debian based and are also started by xboot: All of them are working fine.

Also checked the kali startup command of grub: It is identical to the other livesystems on this card.

This all is telling me: It is really a problem by the build.

FYI here is the grub command of kali:

.linux /live/vmlinuz acpi_osi=Linux boot=live noconfig=sudo username=root hostname=kali ignore_uuid locales=de_DE.UTF-8 keyboard-layouts=de keyboard-variants=nodeadkeys live-media-path=/images/kalilinuxlxderollingi386/live initrd=/live/initrd.img

This is the same syntax as all livesystems!

As I cannot use kali-linux-live any more at all, please set the priority to "crash".

If needed, I can send relevant files from the filesystem.squashfs up here.

Thank you for any help.

Best regards

Hans

Hi Hans,

I tested a live-build ISO this morning, and had no issues at all. I am not familiar with XBOOT and would therefore suspect an issue with that, or something else in your build process. As of now, your bug report doesn't seem actionable on our part. If you can point out a specific bug with live-build, please feel free to re-open this report.

Sorry, that is too easy for me! Please check my problem and use XBOOT then with the built ISO.

When you build an ISO and burn it on DVD, then it is booting correctly, but when you boot from an SD-card or USB-stick using XBOOT, it crashes.

And I repeat: For years it worked well with XBOOT! So do not blame it, because that what changed is kali NOT XBOOT!

Do NOT use the downloadable version version 2016.2 for testing, but build a new one. The downloadable version 2016.2 is too old for the test.

Please use a fresh build!

I suppose, the problem might be easy to fix, but I am really stuck now. I do not know, where to look any more. Maybe it is a kernel problem? Don't know.

But there IS a bug, something very important has changed.

Please help!

Thank you very much!

Best

Hans

Hi Hans,

We are not familiar with XBOOT and do not support it. If you want to try to narrow down your bug, i recommend you use the supported method of getting your ISO onto usb, which is using the "dd" utility. If this still brings up the issue, we can confirm it's a Kali bug.

Hi
I have the same problem! And it is not dependant on XBOOT or some other boot program. I use YUMI (syslinux based,easy to use Windows program for multiboot usb). With FAT formated usb Kali-rolling(daily) won't boot
There is something wrong with this IO charset asci not found...
Other distros booting with no problem ( I've tried Gparted live (kernel 4.7.0.1 signed) and many others)
One solution is NTFS filesystem for boot media - it works,but NTFS is not recommended
Other - I made an experiment (on kali-light-rolling i386 kernel 4.8.5)- recompiled FAT kernel module with " CONFIG_FAT_DEFAULT_IOCHARSET="utf8" [this is the default config ot old kernels like Kali Sana ( kernel 4.0.4 ) ] , and recreate initrd and squashfs.. And the USB boots
I'll try to recreate initrd and squashfs with older version of live-boot and live-config,or try with kernel from official Debian

@ muts
dd or win32diskimager is BAD choice ( only one distro )
there is problem with Kali and this "IO charset" issue, and it's in distribution config,or some program
Also - autologin on kali-linux-lite-rolling-i386 don't works

And please add support for LZ4 squashfs "CONFIG_SQUASHFS_LZ4=y" (it's very fast),maybe also CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y ,or CONFIG_SQUASHFS_DECOMP_MULTI=y

Regards

Hi emil4o1,
so YUMI is also not working. Interesting. As far as I see, it is a kernelsproblem. XBOOT sadly is not working with NTFS.

So the solution would be, that the maintainers will create a new package with a kernel compiled with CONFIG_FAT_DEFAULT_IOCHARSET="utf8" built in.

And of course make a new package in the repo. I hope, they will read this here! :)

I checked for any differences between a working build and a none working build, but I could not discover a difference. However, the latest git changed a path in the config of latest live-build for kali. They put includes.chroot/lib/live
below includes.chroot/root/. I changed this back for testing purposes, but it did not effect the bug. On the other hand I do not know, if this changed is wanted or if it was a mistake. The ,aintainer of the git should check this.

I found no changelog for the git. Is there any one at all?

At next build I will try to use your hints and compress squashfs. My target machine is an EEEPC with a single core (two cores with hypertheading), let's see, if the ****MULTI_PERCPU=y will speed up things.

Best regards

Hans

Ok.. the problem is that live-boot-initramfs-tools don't add module "nls_ascii" to initrd.
This can be fixed easy by adding "manual_add_modules nls_ascii" in file /usr/share/initramfs-tools/hooks/live
and recreate initrd
or manual edit inird and add module

Nice, but that is a workaround.

But this should be fixed in the live-build-git of kali, so everybody got the benefits of t, don't you think so?

Best regards

Hans

Same problem here. kali-linux-2016-W36-amd64.iso was working fine, kali-linux-2016-W49-amd64.iso is not working on FAT32. The official dd method is not user friendly, I want to use the rest of the USB drive for other data and a multiboot. Why carry multiple USB drives, if you have a 32GB with all you need?

On USB only 'live' and 'isolinux' folder are needed. Rename isolinux.cfg to syslinux.cfg. The W36 version booted using syslinux on FAT32, the w49 only works from a EXT2 partition and extlinux bootloader.

I'm trying the suggestion: manual edit inird and add module nls_ascii

Can we not change something in the live-build environment? IMO thius should be the better way.

If someone knows, how to do this, I will be pleased to test it.

Hans

I'll handle a live-boot update soonish.

Hi Raphael,

thank you for working on it! I am looking forward to the patch. As soon it will be implemented, I will build a new ISO and report, if it is working again.

Thanks a lot and happy 2017!

Hans

This should be fixed with live-boot 20170112. I just uploaded it to Debian and I'll sync to kali once it's built and available in Debian unstable.

New live-boot is now in kali-rolling.