Legacy bootIng KLV extremely slow

[fredx181]

It's a while back that I tested KLV-Airedale on my old HP laptop, recently I did again.
Tested sr13. Booting is extremely slow (not just 'acceptable' slow), after loading vmlinuz it gets stuck for minutes on "running /init as init" (something like that) before it finally shows that the bootfrom partition is detected.
Then again a delay for minutes at "Please wait..." , delays also after the sfs's are detected and after "Welcome to Void" it finally runs 'normal'.
All together it took around 8 minutes before reaching the Desktop.

I suspected that it has to do with the kernel, so tried earlier version sr9 (has kernel 6.6), same delays happened.

Thought it may be the Void kernel that my laptop doesn't like, so tested swapping the kernel with the Debian Sid kernel (6.8) and ... bingo... no such delays anymore.

Can anyone perhaps reproduce this delay problem on old(er) hardware ? (perhaps my laptop is an exception ).
EDIT: I've tried several ways to boot, btw, e.g. using Ventoy (USB), manual install on HDD using grub4dos bootloader, all the same delays.

[geo_c]

It's a while back that I tested KLV-Airedale on my old HP laptop, recently I did again.
Tested sr13. Booting is extremely slow (not just 'acceptable' slow), after loading vmlinuz it gets stuck for minutes on "running /init as init" (something like that) before it finally shows that the bootfrom partition is detected.
Then again a delay for minutes at "Please wait..." , delays also after the sfs's are detected and after "Welcome to Void" it finally runs 'normal'.
All together it took around 8 minutes before reaching the Desktop.

I suspected that it has to do with the kernel, so tried earlier version sr9 (has kernel 6.6), same delays happened.

Thought it may be the Void kernel that my laptop doesn't like, so tested swapping the kernel with the Debian Sid kernel (6.8) and ... bingo... no such delays anymore.

Can anyone perhaps reproduce this delay problem on old(er) hardware ? (perhaps my laptop is an exception ).
EDIT: I've tried several ways to boot, btw, e.g. using Ventoy (USB), manual install on HDD using grub4dos bootloader, all the same delays.

Fred, I have swapped kernels around quite a bit after running into these kinds of problems, in particular the boot process waits at the "waiting for devices to settle..." message. And I found this to be the case with the later kernels.

Basically the most recent kernel that works on my old machines with Airedale reliably is 6.3.12 which is running fine on a DellXPS M1210, I don't know how old that model is, but between 15 and 20 years I think. But on the same machine 6.6.4_2 runs with spectr very well.

edit: the good news is that both these OS's run really fast and nice on the 1.6Ghz dual core with 3GB of ram.

[fredx181]

Thanks geo , still curious if anyone experienced that extreme slow boot as I described, also why booting with the Debian kernel worked ok for me and not with the Void kernel, probably hard to find out , I know.

[geo_c]

Thanks geo , still curious if anyone experienced that extreme slow boot as I described, also why booting with the Debian kernel worked ok for me and not with the Void kernel, probably hard to find out , I know.

I know absolutely nothing about building kernels, so I always kind of wondered at the various different kernels supplied with different builds and what determines the choice. I also wonder what's in each kernel in terms of drivers and the supplied modules.

Is there a way to get a sense for that just from the files supplied in an iso for instance? Or is there a command line way to see what's loaded or available in the running kernel?

[Clarity]

Hello @fredx181

Thanks geo , still curious ...

This report is a preliminary ISO file booting in a VM. A fuller report will be forthcoming.

Success in this prelim using the following stanzas for 2 KLV-Airedales running in the same virtual PC: Each KLVA version is booting to desktop within a minute.

Code: Select all

# qemu-system-x86_64 -name "KLV-A vSR11 ISO file" -enable-kvm -vga std -m 2G -smp 2 -device AC97 -net nic -net user -rtc base=localtime -cdrom KLV-Airedale-sr11.iso 
# qemu-system-x86_64 -name "KLV-A vSR13 ISO file" -enable-kvm -vga std -m 2G -smp 2 -device AC97 -net nic -net user -rtc base=localtime -cdrom KLV-Airedale-sr13.iso 

Try either of these stamzas on your end.

===========================================================
Edit: In the VM, KLVA boots from SG2D USB launch of the ISO file to desktop without issue. BUT booting from the slow USB, the time from KLV's menu to desktop is approx 20sec longer.

Code: Select all

qemu-system-x86_64 -name "KLV-A vSR13 ISO file from USB" -enable-kvm -vga std -m 2G -smp 2 -device AC97 -net nic -net user -rtc base=localtime /dev/sdc

animation2.gif (332.34 KiB) Viewed 1217 times

===========================================================

Edit2:In the VM, KLVA does NOT boot from Ventoy v0.96 USB launching of the ISO file. Traps prior to the console login message.

The QEMU stanza for the VM is the same as used for booting the SG2D USB, above.

animation3.gif (413.32 KiB) Viewed 1210 times

===========================================================
More environmental tests including bare-metal to follow within the hour.

[fredx181]

Hello @fredx181

Thanks geo , still curious ...

This report is a preliminary ISO file booting in a VM. A fuller report will be forthcoming.

My curiosity is about when booting on old hardware, bare-metal , not by using qemu or iso booting, if extreme long delays are happening.

Anyway, further testing and by using w_debug=0 at the kernel command line, lead me to the conclusion that booting gets stuck (delayed) on loading kernel modules from the init.
With Debiandog, some time ago I had similar problem (long delays) and experimented with changing the order of loaded modules from the init and got it fixed.

Fixed it now for KLV boot too, inspired by how I did on Debiandog, changed in the init script (in initrd.gz and rebuilt it) to:
EDIT: Added "fuse" to the list below, forgot earlier

Code: Select all

# Modules need loaded by initrd when using kernel from Void Linux
modp=0 # boolean true
for m in cb710 cb710_mmc cdrom ehci_hcd ehci_pci ext4 fat exfat libata ata_generic hid hid_generic isofs libahci loop mbcache mmc_block mmc_core nfs nfsv3 nfsv4 nls_ascii nls_cp437 nls_iso8859_1 nls_utf8 nvme nvme_core ohci_hcd scsi_mod sdhci sdhci_acpi sdhci_pci sdio_uart sd_mod sdricoh_cs sg squashfs sr_mod sunrpc tg3 tifm_core tifm_sd ahci ata_piix uas uhci_hcd uio usb_common usbcore usbhid usb_storage vfat via_sdmmc vub300 wbsd xhci_hcd xhci_pci xor xts pata_ali pata_amd pata_artop pata_atiixp pata_atp867x pata_cmd64x pata_efar pata_hpt366 pata_hpt37x pata_it8213 pata_it821x pata_jmicron pata_marvell pata_mpiix pata_netcell pata_ns87410 pata_ns87415 pata_oldpiix pata_pcmcia pata_pdc2027x pata_pdc202xx_old pata_rdc pata_rz1000 pata_sch pata_serverworks pata_sil680 pata_sis pata_triflex pata_via pcmcia pcmcia_core pdc_adma raid6_pq reiserfs sata_mv sata_nv sata_promise sata_qstor sata_sil sata_sil24 sata_sis sata_svw sata_sx4 sata_uli sata_via sata_vsc btrfs fuse;do

No ridiculous delay anymore I get by using that.
Something to consider (after testing this) changing to that in the init script @rockedge and or @wiak ?
edit: this may also fix when in some cases a kernel panic occurred, not sure though.
edit2: tested also now this configuration on my 'newesh' laptop, UEFI boot, and works fine too.

[rockedge]

@fredx181 Excellent find Fred, and a genius mod
I will add the changes in the KLV's next round of release. Might be able to add <Solved> to the topic title!

Perhaps @wiak can make the modification on the upstream initrd-latest that the build script(s) use.

[fredx181]

@fredx181 Excellent find Fred, and a genius mod
I will add the changes in the KLV's next round of release. Might be able to add <Solved> to the topic title!

Perhaps @wiak can make the modification on the upstream initrd-latest that the build script(s) use.

Well, it's not at all that I know exactly what I'm doing, to be honest, just result of experimenting and trial and error.
So please, first test a few times on different hardware before making it the default (again, as I said, my old laptop can be exception).

[Clarity]

when I see the upgraded ISO file (with the new INIT), and I will report experiences there, too, on the old hardware I have. Everything I test with is 2012 and before. I have a simple arrangement for quickly testings. For the last 6 months, all of my reports have centered around the 2 old PCs I have with nVidia video as they connect directly via HDMI. These negate a need for audio cables as well as cables for keyboard-mouse as those are wireless. Each of the PCs have 3 cables; power, HDMI and USB to a KVM sharing the peripherals to each PC ... selectively.

I also have 2 mini PCs, intel skylake i7 and an 8th gen I5 that I can use for tests, if necessary as well as an AIO AMD circa 2016.

[rockedge]

@Clarity You will be the first to test KLV-Airedale-sr14, which includes @fredx181' initrd modification.

We'll need to test it thoroughly. We'll see how KLV-Airedale-sr14 with a Void Linux 6.9.6_1 kernel operates on older machines. Could try it out with a huge kernel like the RT versions by modding the skeleton initrd

SHA1-MD5.txt

[Clarity]

Preliminary results
In a VM
Reaching desktop via ISO file, or via Ventoy or SG2D. Identical results in all 3 environments. Shutdowns works without issue.
BTW: 'Remove' button chosen to continue desktop operations.

Code: Select all

qemu-system-x86_64 -enable-kvm -vga std -m 2G -smp 2 -device AC97 -net nic -net user -rtc base=localtime -name "KLV-Airedale-sr14 via QEMU" -cdrom KLV-Airedale-sr14.iso 
qemu-system-x86_64 -enable-kvm -vga std -m 2G -smp 2 -device AC97 -net nic -net user -rtc base=localtime -name "KLV-Airedale-sr14 via QEMU" -hda /dev/sdd

Full report including bare-metal forthcoming.

SR14 ISO boot in VM.jpg (94.33 KiB) Viewed 1039 times

[fredx181]

Hi @rockedge Tested sr14 and it boots fine on my old and new laptop (only, as Clarity showed, for me too there's problem with CPU Graph)

Although I think that the recent module list in the init script should work in most/all cases, anyway here's a code (you may like to use) that will create an appropriate list of modules to load.
(again, similar used with Debiandog initramfs creating for years now, had no problems with it).
What it does is filter out only the modules that exist in the initramfs from a huge list of kernel modules (and it filters out possibly builtin modules).
That way, modules loading from the init may be faster (and possibly more safe) as the list will be synchronized with the existing modules in the initramfs that are created with the method you use (Tomas M method, I assume?).
On top, set the path to the decompressed (initramfs) directory and set the kernel version. A file "modulelist" will be created.

Code: Select all

INITRAMFS=/mnt/sda1/decompressed/  # < change this to the correct path of 'decompressed' folder (initramfs)
KERNEL=6.9.1_1   # < change this to the existing kernel version in the initramfs

## Create modulelist (to be sure that modprobe from the init does "only" existing modules at boot, faster and more safe)
for m in ablk_helper aes_i586 aes_x86_64 amd64_edac_mod arc4 aufs brd button cb710 cb710_mmc cciss cdrom crc16 crc32c_generic crc32_generic crc_itu_t cryptd crypto_simd DAC960 dm_mod dns_resolver drm drm_kms_helper ecb edac_core edac_mce_amd ehci_hcd ehci_pci exportfs ext2 ext4 f2fs fat exfat libata ata_generic fb_sys_fops ff_memless  fscache fscrypto fuse gf128mulv gpio_generic grace hfs hfsplus hid hid_generic hid_keytouch hid_logitech hid_ortek hid_primax hid_roccat hid_roccat_arvo hid_roccat_common hid_roccat_isku hid_roccat_lua hid_roccat_ryos hid_roccat_savu hid_samsung hid_sunplus i2c_algo_bit i2c_hid ip6_udp_tunnel irqbypass isofs jbd2 joydev kms_helper kvm libahci libcrc32c libphy lockd loop lrw mbcache mmc_block mmc_core mptsas mptscsih mptspi mtip32xx mxm_wmi nbd nfnetlink nfs nfsv3 nfsv4 nf_tables nls_ascii nls_cp437 nls_iso8859_1 nls_utf8 ntfs nvme nvme_core ohci_hcd parport  scsi_mod scsi_transport_fc scsi_transport_sas scsi_transport_spi sdhci sdhci_acpi sdhci_pci sdhci_pltfm sdio_uart sd_mod sdricoh_cs sg soundcore squashfs sr_mod sunrpc sx8 syscopyarea sysfillrect sysimgblt tg3 thermal tifm_core tifm_sd tpm tpm_infineon tpm_tis tpm_tis_core ahci ata_piix uas udf udp_tunnel ufshcd uhci_hcd uio ums_alauda ums_datafab ums_eneub6250 ums_freecom ums_isd200 ums_jumpshot ums_realtek ums_sddr09 ums_sddr55 ums_usbat usb_common usbcore usbhid usb_storage vfat via_sdmmc vub300 wbsd wmi wmi_bmof xfs xhci_hcd xhci_pci xor xts xxhash zstd_decompresspata_acpi pata_ali pata_amd pata_artop pata_atiixp pata_atp867x pata_cmd64x pata_cs5536 pata_efar pata_hpt366 pata_hpt37x pata_it8213 pata_it821x pata_jmicron pata_marvell pata_mpiix pata_netcell pata_ns87410 pata_ns87415 pata_oldpiix pata_opti pata_pcmcia pata_pdc2027x pata_pdc202xx_old pata_rdc pata_rz1000 pata_sch pata_serverworks pata_sil680 pata_sis pata_triflex pata_via pcmcia pcmcia_core pcmcia_rsrc pdc_adma pppox pps_core psmouse ptp raid6_pq reiserfs rng_core sata_mv sata_nv sata_promise sata_qstor sata_sil sata_sil24 sata_sis sata_svw sata_sx4 sata_uli sata_via sata_vsc btrfs; do
modprobe -S $KERNEL -d $INITRAMFS -Dq $m | grep -v builtin > /dev/null 2> /dev/null
[ $? -eq 0 ] && echo -n "$m " >> "$INITRAMFS/modulelist"
done

Nice way may be (having the file modulelist in the initramfs), then in the init script:

Code: Select all

# Modules need loaded by initrd when using kernel from Void Linux
modp=0 # boolean true
for m in $(cat modulelist); do

[rockedge]

@fredx181, @Clarity Thanks for the testing KLV-Airedale-sr14

The CPU Graph crash also appeared in KLV-Airedale-sr13.....I fixed it by editing the panel #1 and removed the cpu graph then added it in again fresh. This worked so I booted into a PFI mode (pseudo full install) and repeated the same step then squashed the upper_changes back into the rootfs SFS.

Why the CPU Graph is crashing in the first place is unknown.......but the fix works.

[rockedge]

@fredx181, @Clarity

Fixed the CPU Graph crashing. Still not sure what corrupted to make it start to crash during system start.
Repackaged the rootfs and the ISO. It is uploaded to the usual place.

Download -> KLV-Airedale-sr14 size is 898 M
SHA1-MD5.txt

Please test!!

@fredx181 where is the best place to put this code?

Will this have to be customized for every different path to /decompressed? My boot partition is /mnt/sda1 and the frugal install is on /mnt/sdc1

Code: Select all

INITRAMFS=/mnt/sda1/decompressed/  # < change this to the correct path of 'decompressed' folder (initramfs)
KERNEL=6.9.1_1   # < change this to the existing kernel version in the initramfs

[fredx181]

@fredx181, @Clarity

Fixed the CPU Graph crashing. Still not sure what corrupted to make it start to crash during system start.
Repackaged the rootfs and the ISO. It is uploaded to the usual place.

Download -> KLV-Airedale-sr14 size is 898 M
SHA1-MD5.txt

Please test!!

Tested sr14 now and no annoying message about CPU Graph anymore !
Users can always add it to the panel, I did btw and no problem after re-login.

[Clarity]

Would delaying the start of CPU Graph, after desktop arrival, be a circumvention for the time being; rather than leaving it to a user?

Curious

[Clarity]

Just notices something of interest. Booting the ISO file via this distros's GRUB2 options when launched from either USB; namely Ventoy or SG2D, I "see" the intelligence this KL development team has introduced in its INIT. This KL's Menu actually identifies what environment it is being launched from.

Wonderful, Outstanding, Easily Understood, Creative...

KLAH v1.5 ISO boot in VM(2).jpg (58.63 KiB) Viewed 927 times

KLAH v1.5 ISO boot in VM(1).jpg (50.5 KiB) Viewed 927 times

[Clarity]

Questions related to the above boot screens
Should GRUB2 booting have the following options to benefit user/use?

1. Boot to console option? Stop at console without starting desktop GUI

2. option to list boot parms?

Thoughts

[Clarity]

Found these issues when booting from boot launchers: Ventoy & SG2D.

Review boot changes.

KLAH v1.5 ISO boot in VM(5).jpg (36.62 KiB) Viewed 833 times

KLAH v1.5 ISO boot in VM(4).jpg (158.8 KiB) Viewed 833 times

KLAH v1.5 ISO boot in VM(3).jpg (96.25 KiB) Viewed 833 times

[fredx181]

@Clarity You are focusing much on booting with Qemu, Ventoy, SGD2.
So in my view it's off-topic, the subject that I intended and asked for to test is: booting from old hardware , bare-metal, legacy boot (= not UEFI).
(perhaps I wasn't clear enough in my first post)

[Clarity]

You're right. No offense taken.

I have added this to add to the information you share. To cover issues related to booting the distro from all of its paths.

My findings:

• If the problem is reported, try an see if it is universally apparent.

• If it is then a solution is universal.

• If it exist in a 'old' replica of a real PS (aka VM) then it often shows up in a real PC

• If it does not show up in a VM and shows up in a real PC, then it is firmware related in many/most cases.

This is what I have found in the past 4 decades.

I offered my findings, 1st, as a clue that this was not happening in a VM to assist a focused direction toward some solution. Or to give developers a chance to ID why its happening on one and not the other.

I had no intentions to derail, merely to assist.

I refrain from posting to this thread.

@fredx181, I ask: Should I remove the current findings I have posted on the 2 SR14 distros?
Should I remove the findings-results thus far?

[rockedge]

@fredx181 I have now in the latest KLV-Airedale-sr14 ISO with the modification to the initrd.gz and the very latest save2flash-1.9_0

This one should be right on track to be a topic really soon....

Should I remove the current findings I have posted on the 2 SR14 distros?
Should I remove the findings-results thus far?

No.

[fredx181]

@rockedge
The "fuse" kernel module isn't loaded in sr14, results in that appimages cannot run, unless you do modprobe fuse
My bad sorry, forgot to add to the list I posted earlier
Added it now to that list of kernel modules here: (see at EDIT):
viewtopic.php?p=124377#p124377

[rockedge]

@fredx181 Ahhh, I see! Okay I should fix that in the sr14 init in the initrd.gz and repackage......

[wiak]

@fredx181 Excellent find Fred, and a genius mod
I will add the changes in the KLV's next round of release. Might be able to add <Solved> to the topic title!

Perhaps @wiak can make the modification on the upstream initrd-latest that the build script(s) use.

Sorry, I missed all these posts...
What is it you want added to the initrd in terms of modules list? Is it just 'fuse' or is it something related to Thoman M method - I don't quite understand in my quick read. Something better than the simple for loop list would always be welcome (that for loop method was adopted from DebianDog early approach long ago).

[rockedge]

@wiak here is the gist of the modification made to the initrd.gz (init) then repackaged and inserted into sr14

Although I think that the recent module list in the init script should work in most/all cases, anyway here's a code (you may like to use) that will create an appropriate list of modules to load.
(again, similar used with Debiandog initramfs creating for years now, had no problems with it).
What it does is filter out only the modules that exist in the initramfs from a huge list of kernel modules (and it filters out possibly builtin modules).
That way, modules loading from the init may be faster (and possibly more safe) as the list will be synchronized with the existing modules in the initramfs that are created with the method you use (Tomas M method, I assume?).
On top, set the path to the decompressed (initramfs) directory and set the kernel version. A file "modulelist" will be created.

Code: Select all

INITRAMFS=/mnt/sda1/decompressed/  # < change this to the correct path of 'decompressed' folder (initramfs)
KERNEL=6.9.1_1   # < change this to the existing kernel version in the initramfs

## Create modulelist (to be sure that modprobe from the init does "only" existing modules at boot, faster and more safe)
for m in ablk_helper aes_i586 aes_x86_64 amd64_edac_mod arc4 aufs brd button cb710 cb710_mmc cciss cdrom crc16 crc32c_generic crc32_generic crc_itu_t cryptd crypto_simd DAC960 dm_mod dns_resolver drm drm_kms_helper ecb edac_core edac_mce_amd ehci_hcd ehci_pci exportfs ext2 ext4 f2fs fat exfat libata ata_generic fb_sys_fops ff_memless  fscache fscrypto fuse gf128mulv gpio_generic grace hfs hfsplus hid hid_generic hid_keytouch hid_logitech hid_ortek hid_primax hid_roccat hid_roccat_arvo hid_roccat_common hid_roccat_isku hid_roccat_lua hid_roccat_ryos hid_roccat_savu hid_samsung hid_sunplus i2c_algo_bit i2c_hid ip6_udp_tunnel irqbypass isofs jbd2 joydev kms_helper kvm libahci libcrc32c libphy lockd loop lrw mbcache mmc_block mmc_core mptsas mptscsih mptspi mtip32xx mxm_wmi nbd nfnetlink nfs nfsv3 nfsv4 nf_tables nls_ascii nls_cp437 nls_iso8859_1 nls_utf8 ntfs nvme nvme_core ohci_hcd parport  scsi_mod scsi_transport_fc scsi_transport_sas scsi_transport_spi sdhci sdhci_acpi sdhci_pci sdhci_pltfm sdio_uart sd_mod sdricoh_cs sg soundcore squashfs sr_mod sunrpc sx8 syscopyarea sysfillrect sysimgblt tg3 thermal tifm_core tifm_sd tpm tpm_infineon tpm_tis tpm_tis_core ahci ata_piix uas udf udp_tunnel ufshcd uhci_hcd uio ums_alauda ums_datafab ums_eneub6250 ums_freecom ums_isd200 ums_jumpshot ums_realtek ums_sddr09 ums_sddr55 ums_usbat usb_common usbcore usbhid usb_storage vfat via_sdmmc vub300 wbsd wmi wmi_bmof xfs xhci_hcd xhci_pci xor xts xxhash zstd_decompresspata_acpi pata_ali pata_amd pata_artop pata_atiixp pata_atp867x pata_cmd64x pata_cs5536 pata_efar pata_hpt366 pata_hpt37x pata_it8213 pata_it821x pata_jmicron pata_marvell pata_mpiix pata_netcell pata_ns87410 pata_ns87415 pata_oldpiix pata_opti pata_pcmcia pata_pdc2027x pata_pdc202xx_old pata_rdc pata_rz1000 pata_sch pata_serverworks pata_sil680 pata_sis pata_triflex pata_via pcmcia pcmcia_core pcmcia_rsrc pdc_adma pppox pps_core psmouse ptp raid6_pq reiserfs rng_core sata_mv sata_nv sata_promise sata_qstor sata_sil sata_sil24 sata_sis sata_svw sata_sx4 sata_uli sata_via sata_vsc btrfs; do
modprobe -S $KERNEL -d $INITRAMFS -Dq $m | grep -v builtin > /dev/null 2> /dev/null
[ $? -eq 0 ] && echo -n "$m " >> "$INITRAMFS/modulelist"
done

Nice way may be (having the file modulelist in the initramfs), then in the init script:

Code: Select all

# Modules need loaded by initrd when using kernel from Void Linux
modp=0 # boolean true
for m in $(cat modulelist); do

[fredx181]

@fredx181 Excellent find Fred, and a genius mod
I will add the changes in the KLV's next round of release. Might be able to add <Solved> to the topic title!

Perhaps @wiak can make the modification on the upstream initrd-latest that the build script(s) use.

What is it you want added to the initrd in terms of modules list? Is it just 'fuse' or is it something related to Thoman M method - I don't quite understand in my quick read.

Just the 'fuse' was what I forgot to add earlier to that list, initially the fix for me on old hardware was changing the order of modprobe'd modules: viewtopic.php?p=124377#p124377
Btw, I can recommend my proposal here viewtopic.php?p=124454#p124454, using it with Debiandog for some time now (it does a check for what kernel modules are actually existing inside the initramfs (created with the Tomas M method) to modprobe these (from list created) accordingly):
EDIT: I see now that @rockedge just posted at the same time about similar (edit: although that exactly is not implemented as "modification made to the initrd.gz" AFAIK).

EDITEDIT: The code from viewtopic.php?p=124454#p124454 to create the list works only with the 'full' modprobe from package kmod, NOT with the busybox modprobe (the busybox applet is as default included in recent KLV-Airedale) !!!!

[fredx181]

See EDITEDIT in my previous post, important.

[rockedge]

@fredx181 So what should I do? I am in the middle of adjusting the init in the initrd.gz to include fuse, which was originally included in the previous version.

Step by step where and what I should be modifying if anything please Fred, I am unsure what I am supposed to do. Details and locations please.

[wiak]

See EDITEDIT in my previous post, important.

2am and in bed half asleep...

So is it only Tomas M code modified FR initrd you are referring to or is it something also missing in skeleton FR initrd?. Without being able to check initrd right now Im assuming fuse missing in list and is module ordering part of it?