The new way of placing all the kernel modules in a zdrv has a downside.
While the 'init' script in 'initrd.gz' is running, the kernel thinks it has all these modules available, but none of them are there.
This is usually not a problem, because once the 'switch-root' is done at the end of 'init', they are all there. So by the time we get to a running system, all devices should be ok.
The problem occurs if 'init' attempts to us a device that requires one of these non-existing modules.
This does occur if the device is a keyboard, and the puppy being booted has multiple savefiles/savefolders. The keyboard does not work, no response to indicate which savefile/savefolder to use can be provided, and you're stuck.
This had happened to a few users of TahrPup 6.0 CE.
The only work around I am aware of, is to plugin a usb keyboard that does not require any kernel driver module.
Options:
1) Ignore it.
2) Put kernel modules back into 'initrd.gz'
3) Put 'hid' kernel modules back into 'initrd.gz'
4) Build all 'hid' modules into every kernel.
5) Modify 'init' to make the kernel modules that are in zdrv available to 'init'.
Any other options??
Since I have experienced this situation, I don't like option 1).
Options 2) and 3) virtually means abandoning the new method, so we loose a lot for only a small gain.
I don't know if option 4) is possible.
If option 5) were implemented, would it work in time, or would the user have to unplug the usb keyboard and plug it in again.?
What if it's not a detachable keyboard.?
I guess I'm concerned that the number of keyboards that require a kernel driver module could increase, rather than decline.
Unfortunately, I do not have any solution to offer.
I've briefly considered trying to implement 5) by loading the zdrv early, and symbolic linking it's 'lib/modules' directory into '/lib/modules'.
Thoughts??
gyro
Edit: Problem should also occur if an encrypted savefile is used. Can't type in the password.
New kerenel method - missing driver modules
New kerenel method - missing driver modules
Last edited by gyro on Mon 02 Mar 2015, 16:38, edited 2 times in total.
Hmm yes I remember when those split up hid modules where introduced.... (what happened before???..one hid module containing all the drivers IIRC) thing is that keyboard seems to be the only significant piece of hardware affected in a critical way without drivers in the initrd...the size penalty is minimal to support these hid beasties so leaving the original workaround in initrd seems to make the most sense. Anything else can literally wait.
Biggest hit on space appears to be wifi drivers and their firmware.
Perhaps these should be the target for separate packaging especially when half the time a user has to resort to a proprietry one..after all video works on a similar basis and no one questions having to get an nvidia or ati download.
Ok you need the internet to grab a package but if yer wifi is no go cos you need realteks STA then you have to download with something else anyway.
mike
Biggest hit on space appears to be wifi drivers and their firmware.
Perhaps these should be the target for separate packaging especially when half the time a user has to resort to a proprietry one..after all video works on a similar basis and no one questions having to get an nvidia or ati download.
Ok you need the internet to grab a package but if yer wifi is no go cos you need realteks STA then you have to download with something else anyway.
mike
While it's only the keyboard modules that are required, or even the 'hid' modules, the downside to storing any kernel driver modules in 'initrd.gz' is that if we replace 'vmlinuz' with a different kernel version, then the modules in 'initrd.gz' need to also be replaced, otherwise 'initrd.gz' contains modules that are possibly incompatible with the new kernel.mikeb wrote:so leaving the original workaround in initrd seems to make the most sense.
Replacing the 'initrd.gz' file for a new kernel version, could cause difficulties because the current 'initrd.gz' might have been modified for other reasons. Which suggests that a facility to replace the modules in 'initrd.gz' that is very easy to use, would be needed.
gyro
Hmm ok ... so is it the case that no modules are in the initrd now as otherwise changing them has to be done anyway with a new kernel.?
As an aside I did a hybrid that used the old manual insmod for the common modules and detected and loaded any hid ones needed.
Method c.... include modules in the kernel...if the slow flash dogma gets dropped that helps a lot.
Not sure how feasible that is for hid though....I suppose one module was an easier task.
I suppose the fickle nature of kernel choices does have its side effects.
mike
As an aside I did a hybrid that used the old manual insmod for the common modules and detected and loaded any hid ones needed.
Method c.... include modules in the kernel...if the slow flash dogma gets dropped that helps a lot.
Not sure how feasible that is for hid though....I suppose one module was an easier task.
I suppose the fickle nature of kernel choices does have its side effects.
mike
With the kernel in 'vmlinuz' and all the modules in 'zdrv', the kernel can be changed by replacing these 2 files. Only problem is no 'hid' modules during 'init'.mikeb wrote:Hmm ok ... so is it the case that no modules are in the initrd now as otherwise changing them has to be done anyway with a new kernel.?
gyro
Ok so the kernel must have the initrd modules built in so why not the hid...if you are going to swim, get wet...
Of course the complex method would be to mount and use the zdrv by the initrd...thats more in line with puppy philosophy.... or is that the current game.
Indeed what is the point of the current exercise..to save 200k and end up with a semi broken result?
I happen to think zdrv, adrv and the rest are a joke so i am a little biased.
I do have a current creation that has the kernel modules as a separate sfs but still add whats needed to the initrd...does not take that long but thats just me... so its vmlinuz....initrd...modules.sfs as a package. Plus as you mention there are kernel quirks all the time to handle which usually means peeing around with the initrd init anyway.
mike
mike
Of course the complex method would be to mount and use the zdrv by the initrd...thats more in line with puppy philosophy.... or is that the current game.
Indeed what is the point of the current exercise..to save 200k and end up with a semi broken result?
I happen to think zdrv, adrv and the rest are a joke so i am a little biased.
I do have a current creation that has the kernel modules as a separate sfs but still add whats needed to the initrd...does not take that long but thats just me... so its vmlinuz....initrd...modules.sfs as a package. Plus as you mention there are kernel quirks all the time to handle which usually means peeing around with the initrd init anyway.
mike
mike
So, you've already implemented something like option 3), substituting 'modules.sfs' for 'zdrv_nnnn.sfs'?mikeb wrote:I do have a current creation that has the kernel modules as a separate sfs but still add whats needed to the initrd...does not take that long but thats just me... so its vmlinuz....initrd...modules.sfs as a package.
gyro
Yes...seemed to make sense. I was building a kernel with KVM support so was easier to swap for testing.
After all its just another sfs module and even upsidedown layering makes no difference in this case.
But as mentioned I just made a fresh initrd to go with it.
Perhaps its worth mentioning I always name the initrd to match what its from...I know this can mess up some puppies detection scripts that look for the initrd but thats silly in the first place.
By doing so its easy to select to match the kernel via say menu.lst .
If puppy had some way to choose what sfs to load live via grub or syslinux like slax does then that could make a neat multi kernel method. Otherwise there is no harm in having modules from 2 separate kernels present at once apart from space wastage.
In short...new kernel comes as a 3 file package to slot into an existing install for example....seems neat enough.
mike
After all its just another sfs module and even upsidedown layering makes no difference in this case.
But as mentioned I just made a fresh initrd to go with it.
Perhaps its worth mentioning I always name the initrd to match what its from...I know this can mess up some puppies detection scripts that look for the initrd but thats silly in the first place.
By doing so its easy to select to match the kernel via say menu.lst .
If puppy had some way to choose what sfs to load live via grub or syslinux like slax does then that could make a neat multi kernel method. Otherwise there is no harm in having modules from 2 separate kernels present at once apart from space wastage.
In short...new kernel comes as a 3 file package to slot into an existing install for example....seems neat enough.
mike
Recompile kernel
Simplest solution is a partial 4).
Every time a problem is determined to be the result of a kernel module missing during 'init', recompile the kernel with that module built-in.
Anyone with the problem, downloads the new kernel, and replaces 'vmlinuz' and the 'zdrv'.
gyro
Every time a problem is determined to be the result of a kernel module missing during 'init', recompile the kernel with that module built-in.
Anyone with the problem, downloads the new kernel, and replaces 'vmlinuz' and the 'zdrv'.
gyro