Bullseye for ls-wvl boot loop
Closed this issue · 7 comments
just seen the new bullseye images for ls-wvl etc. usual process stock, connect with acp drop the uImage.buffalo and initrd.buffalo into /boot. Reboot and it never recovers, just boot loops. Have to go back to stock to recover. Cheers Shaz...
That is disappointing to hear.
One thing to check is the filesize of your *.buffalo files, folks often save the github page's html rather than the boot files themselves. That's usually the issue for a boot loop in this situation. Using the files for the wrong device would also cause a boot loop. That doesn't come up as much but verifying LS-WVL vs LS-WXL on both the device and files couldn't hurt.
Sadly, I don't have a working LS-WVL to test with. If the issue really is with the Bullseye installer you could also try one of the older installers which was known to work. I'm fairly sure folks have successfully installed on LS-WVL at some point but I don't have any details/stats for such things.
If my Bullseye images really aren't working for LS-WVL it might be worth trying my Buster or even Stretch images.
Another thing you could try if all of the above fails are the images that Debian hosts for this generation of device. They aren't particularly well maintained but last I knew the Stretch/Buster images worked (just lacking some of my fixes). I'd have to look back over discord logs but I think the Bullseye one may have even worked for someone.
Those can be found at:
https://deb.debian.org/debian/dists/bullseye/main/installer-armel/current/images/kirkwood/network-console/buffalo/ls-wvl/
https://deb.debian.org/debian/dists/buster/main/installer-armel/current/images/kirkwood/network-console/buffalo/ls-wvl/
https://deb.debian.org/debian/dists/stretch/main/installer-armel/current/images/kirkwood/network-console/buffalo/ls-wvl/
If you do confirm that my Bullseye images aren't working for this device and find that one of the other images does work please let me know. Even without a device to test with I might be able to figure out why one image would work when another doesn't.
Thanks....one thing I have noticed is the size of initrd.buffalo, its 6.5 and 7.3Mb for Stretch and Buster respectively but only 5.9Mb for Bullseye... is there an issue there perhaps with the sizes ?
Yes the discussion on discord was with me, regarding the updating from buster to bullseye, I switched back the initrd.buffalo and/or the uImage.buffalo around to get it working again....but this is clean build of stock so I guess I can try the stock to buster to bulleye method and try these once already over to debian. Might try that this weekend.
ah okay, so you have succeeded with buster/etc before. probably means you're past the easy stuff though it never hurts to check.
The size difference with my initrd's is intentional..... and a bit of a long story. A few of the oldest devices I support have a hard 7MB limit for initrd, the bootloader actually segfaults if it tries to load a bigger one....no idea why. As such I put more effort into keeping it small than Debian's equivalent. I achieved a lot of that in the latest update by moving a bunch of drivers into the installer kernel rather than as modules that end up in the initrd.
Once you're up on Buster there are a few things we could look at which might help, A big one is kernel modules. If somehow that model relies on a device driver that the other devices I tested didn't I might just need to add it to my kernel build for the installer. we could also play with combinations of DTB and kernel image, maybe the one I'm using needs to be updated/recompiled for the current kernel in some way.
tried it...buster2bullseye then change the initrd and uImage, so the upgrade started well.....got all the way to bullseye from buster using your buster iinitrd and uImage, the upgrade to bullseye running without the temp sensor due to debian 5.10.120-1 as before.
Then tried with your bullseye initrd and uImage for wvl downloads and it returns to boot looping.
I changed one at time but only the initrd would seem to start booting partly, uImage from your download triggers the boot loop, tried two different wxl and wvl and they do the same thing, with your initrd it brings up the nic activity but we never get beyond the nic flashing, no ping or dhcp nor ssh. Revert back to the debian release bullseye versions and it all boots fine....same as my previous wvl and qvl, ie we have Bullseye but have lost the the temp sensor so loose variable fancontrol.....such is life!
Thanks I will look to possibly retiring them eventually. Many Ta's
Someone had a similar ssue on a device that I have available for testing. It turns out the latest set of Bullseye images that were generated a few weeks ago had a broken kernel.
Corrected issues have now been generated/posted. There's a good chance this will fix the issue you've encountered as well. Let me know if your get a chance to try them out.
cheers....for that... I will return to the wvl at the next opportunity....currently trying to get a Netgear nv+ v2 to debian so fun fun fun.
I've also been unable to use your LS-WVL Bullseye images on my LS-WV2.0TL.
At one point I got the installer working, but it kept failing at the package level, throwing errors about not being able to find any mirrors regardless of the setting. There was some error about an apt or dpkg process already running when I logged in on the console.
I had to abort and tried it again, but it just went into emergency mode and wouldn't boot anything. I've now tried using your Buster installer (wouldn't boot, went into emergency mode), using deboostrap for Bullseye (wouldn't boot, went into emergency mode), trying to restore the original firmware using the updater by reformatting the drive (the partitions all seemed be there, and it gets recognized as an md device on my Ubuntu server, but putting the disks back in the LS-WV2.0TL just caused a boot loop after the firmware reloaded: blinking blue boot light, restart, repeat).
I'm now in the middle of trying to get a debootstrap image for Buster (I had to remove the bsdextrautils package from the script to generate the image). Not sure how much more time I should devote to this, as it's eaten up a good day plus. Just very annoying I can't ANY image to boot now.