Latest initrd.gz initrd.gz won't boot with USB Save/2.6.39.4
Latest initrd.gz initrd.gz won't boot with USB Save/2.6.39.4
Hi, I've just built my first puplet using Woof. It's based on Iguleder's NexPup work, which is in fact seeing the exact same problem. Wary 5.1.4.1, Lupu 5.25, and puppy variants using older init scripts don't have this problem.
Motherboard is an Intel d945gsejt. I'm installed to USB flash from the ISO using Unetbootin. This is the standard technique I've used with many puplets.
Initial boot without a save file works fine. Save file creation also seems to work fine upon shutdown.
The problem occurs on the second boot. Only one save file exists on the USB flash drive. Somehow the init script finds the file twice, so the menu to select a save file comes up. This would only be a minor annoyance, except that the keyboard appears to not be initialized, so there's no way to continue past that point.
edit: I think this initrd.gz specific, but it may not be specific to the init script itself, as I just diffed the Wary/Next init scripts and they're using the same version.
Motherboard is an Intel d945gsejt. I'm installed to USB flash from the ISO using Unetbootin. This is the standard technique I've used with many puplets.
Initial boot without a save file works fine. Save file creation also seems to work fine upon shutdown.
The problem occurs on the second boot. Only one save file exists on the USB flash drive. Somehow the init script finds the file twice, so the menu to select a save file comes up. This would only be a minor annoyance, except that the keyboard appears to not be initialized, so there's no way to continue past that point.
edit: I think this initrd.gz specific, but it may not be specific to the init script itself, as I just diffed the Wary/Next init scripts and they're using the same version.
Last edited by ldolse on Wed 28 Sep 2011, 18:08, edited 1 time in total.
Looks like the issue may be related to the fact that the latest woof isn't adding all the same drivers for 2.6.39.4 as Woof is adding for older kernels.
Here's what I'm seeing (comparison of drivers in initrd.gz):
In Wary 5.1.4.1 but missing from Woof 2.39.4:
In Woof 2.39.4 but missing from Wary 5.1.4.1
Here's what I'm seeing (comparison of drivers in initrd.gz):
In Wary 5.1.4.1 but missing from Woof 2.39.4:
- /mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/input/mouse/psmouse.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/leds/led-class.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/pcmcia/rsrc_nonstatic.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/fs/nls/nls_cp437.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/fs/nls/nls_iso8859-1.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/pcmcia/rsrc_nonstatic.ko.gz
In Woof 2.39.4 but missing from Wary 5.1.4.1
- /mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/crypto/aes_generic.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/crypto/cbc.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/crypto/crypto_blkcipher.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-a4tech.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-apple.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-belkin.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-cherry.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-chicony.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-cypress.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-ezkey.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-logitech.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-microsoft.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-monterey.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/hid-samsung.ko.gz
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/usbhid
/mnt/work/pup_music_server/initrd/initrd/lib/modules/krnl-ver/kernel/drivers/hid/usbhid/usbhid.ko.gz
http://www.murga-linux.com/puppy/viewto ... 545#470545
Post your syslinux.cfg rows.
ANd those missing usb kernel modules are missing because they are compiled in, not as modules. See Barrys blog, he has posted the reason about 1-2 monts ago.
Post your syslinux.cfg rows.
ANd those missing usb kernel modules are missing because they are compiled in, not as modules. See Barrys blog, he has posted the reason about 1-2 monts ago.
Syslinux.cfg is exactly the same as isolinux.cfg. I think the thread you linked is probably out of date, as I've booted numerous puplets built since Nov 2010 using pmedia=cd on usbflash.
Regarding the modules, that probably explains why Exprimo is partially working, if your modules are also compiled in - the keyboard works on the second boot with Exprimo, though it still has the problem with finding two instances of the same save file - perhaps a different module that didn't get compiled in on Exprimo?.
Not sure if that means that Iguleder's kernel should be considered incompatible with Puppy, or if Woof should handle kernel pets that have these items as modules.
I'll try building with the 2.6.39 pet that's in the official repository and see if it makes a difference.
Code: Select all
default puppy
display boot.msg
prompt 1
timeout 50
F1 boot.msg
F2 help.msg
F3 help2.msg
label puppy
kernel vmlinuz
append initrd=initrd.gz pmedia=cd
Not sure if that means that Iguleder's kernel should be considered incompatible with Puppy, or if Woof should handle kernel pets that have these items as modules.
I'll try building with the 2.6.39 pet that's in the official repository and see if it makes a difference.
I still recommend to change it as append initrd=initrd.gz pmedia=usbflash
I have those modules built in. Barry searched the usb booting problem and building usb modules in, not as modules is better and ensures better that boot time detection works.
I dont know how Iguleder has built his kernel.
Use Barrys kernels in his builds. Not in Dpups, Slackos or Lucid Puppies. The kernel want that the gcc version is the same in the used distro as it was when the kernel was compiled. Otherwise you cant compile any modules with that kernel. It might work, probably it wont.
I have those modules built in. Barry searched the usb booting problem and building usb modules in, not as modules is better and ensures better that boot time detection works.
I dont know how Iguleder has built his kernel.
Use Barrys kernels in his builds. Not in Dpups, Slackos or Lucid Puppies. The kernel want that the gcc version is the same in the used distro as it was when the kernel was compiled. Otherwise you cant compile any modules with that kernel. It might work, probably it wont.
Reading through Barry's blog to find the relevant posts on compiling in the modules, and found this post which may be relevant:
I have fixed the problem of booting from USB when there is no hard drive, so uploading Woof again.
I guess that might be an important item in my case - maybe the problem isn't quite fixed... I'm booting without a hard drive - the USB stick is my drive... I guess I can also stick a compact flash in a SATA adapter to see if that helps in the short term, but still need the puplet to be able to boot off usb.
I have fixed the problem of booting from USB when there is no hard drive, so uploading Woof again.
I guess that might be an important item in my case - maybe the problem isn't quite fixed... I'm booting without a hard drive - the USB stick is my drive... I guess I can also stick a compact flash in a SATA adapter to see if that helps in the short term, but still need the puplet to be able to boot off usb.
Issue resolved
I've got a potential fix. The function which searches for save files is called search_func in the init script. It's called twice, once to search ATA drives and once to search USB/whatever. The problem is basically that the USB drive that's being booted from is recognized as both an ATA device and a USB device the way the script works, causing the same device to be scanned twice. That must be related to changes in the latest kernel, as Wary 5.1.4.1 and other pre-2.6.39 puplets I've used with the same init revision don't exhibit this behavior.
You were right about pmedia=usbflash - that is one way to resolve the error as it causes search_func in the init script to exit early in one of the two cases. I'd rather see the script fixed though, and avoid an un-needed level of complexity for less techy users, since an iso is the primary means of delivering puplets, and people often transfer them directly to USB flash.
Anyway here is the proposed fix. Find this line in the init script:
And replace it with these two lines:
Basically check to see if you've already found the savefile before appending it to the list of save files. There are numerous ways to fix it, but it seems to me that sanity checking the existing list makes sense in case future variations of the same problem occur.
Is this forum the primary means of submitting patch requests/fixes for Woof?
You were right about pmedia=usbflash - that is one way to resolve the error as it causes search_func in the init script to exit early in one of the two cases. I'd rather see the script fixed though, and avoid an un-needed level of complexity for less techy users, since an iso is the primary means of delivering puplets, and people often transfer them directly to USB flash.
Anyway here is the proposed fix. Find this line in the init script:
Code: Select all
[ "$FND_PUPSAVES" ] && echo "$ONEDEV $ONEFS $FND_PUPSAVES" >> /tmp/PUPSAVES
Code: Select all
[ "$FND_PUPSAVES" ] && grep "$ONEDEV $ONEFS $FND_PUPSAVES" /tmp/PUPSAVES 1>/dev/null 2>1
[ $? -ne 0 ] && echo "$ONEDEV $ONEFS $FND_PUPSAVES">> /tmp/PUPSAVES
Is this forum the primary means of submitting patch requests/fixes for Woof?
Last edited by ldolse on Thu 29 Sep 2011, 20:36, edited 4 times in total.
Sometimes. But to get Barry Kaulers attention and feedback, I recommend you to PM post him in this forum. Describe the problem and your solution.
Check some time later if he has read your post. It disappears from outbox and pops up in sendbox. If your fix has got his attention, you get feedback and probably also he will write about it in his own blog.
Or you can post to his blog also.
Suggestion for woof fix or init script fix could be good opening.
Check some time later if he has read your post. It disappears from outbox and pops up in sendbox. If your fix has got his attention, you get feedback and probably also he will write about it in his own blog.
Or you can post to his blog also.
Suggestion for woof fix or init script fix could be good opening.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Idolse,
I put you fix into Woof, see my blog post:
http://bkhome.org/blog/?viewDetailed=02514
However, I am not happy with that and would like to find out what is really going on.
See the comments I posted on my blog, and some tests to try.
The code separates out USB and non-usb drives, so I don't see how the same partition can be scanned twice.
In fact, I am looking at the init sript now, the drives in the first scan are definitely excluded from the second scan.
I am sorry, but I cannot reproduce your problem.
I put you fix into Woof, see my blog post:
http://bkhome.org/blog/?viewDetailed=02514
However, I am not happy with that and would like to find out what is really going on.
See the comments I posted on my blog, and some tests to try.
The code separates out USB and non-usb drives, so I don't see how the same partition can be scanned twice.
In fact, I am looking at the init sript now, the drives in the first scan are definitely excluded from the second scan.
I am sorry, but I cannot reproduce your problem.
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
I have put some extra code into the 'init' script to try and find out what is going on. But, you guys who are getting that problem can try this now. Insert this code:
Code: Select all
if [ "$FND_PUPSAVES" ];then
#111003 ldolse: pemasu 2.6.39 kernel showing usb at also ata, causing double writes here...
grep "$ONEDEV $ONEFS $FND_PUPSAVES" /tmp/PUPSAVES >/dev/null 2>&1
if [ $? -ne 0 ];then
echo "$ONEDEV $ONEFS $FND_PUPSAVES" >> /tmp/PUPSAVES
else
echo
echo "AN ERROR HAS OCCURRED. After bootup, please send the content of
/initrd/tmp/ERRORUSBSCAN to Barry Kauler http://bkhome.org/blog.
Paising 30 seconds..." >/dev/console
echo "AN ERROR HAS OCCURRED. The 'init' script has found this twice:
$ONEDEV $ONEFS $FND_PUPSAVES
search_func param=${1}
ATADRIVES=${ATADRIVES}
PCPARTS=${PCPARTS}
LESSPARTS=${LESSPARTS}" > /tmp/ERRORUSBSCAN
sleep 30
fi
[url]https://bkhome.org/news/[/url]