• 6.7.1 Upgrade = Kernel Panic on boot


    geekazoid
    • Solved Urgent

    Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) after updating to 6.7.1 from 6.6.2

    Also not being able to roll back an update and boot the old image is a bug too IMO.

    Same condition and description as this reddit post.

     

     




    User Feedback

    Recommended Comments

    I suspect the upgraded files were not written successfully to the USB stick.   I would recommend downloading the ZIP version of the release from the Limetech site and extracting all the bz* type files over-writing the versions on the flash drive.

     

    You can also roll back the update by copying all the files from the ‘previous’ folder on the USB stick back to the root of the USB stick.

    • Like 2
    Link to comment

    >I suspect the upgraded files were not written successfully to the USB stick.

    The upgrade process was successful, no errors in the summary.

    Link to comment
    2 hours ago, geekazoid said:

    >I suspect the upgraded files were not written successfully to the USB stick.

    The upgrade process was successful, no errors in the summary.

    I was not saying that the upgrade process did not appear to complete correctly.    I am suggesting that the files did not in fact all get written successfully to the USB stick since the error you mention suggests an error reading from the USB stick.

    • Like 1
    Link to comment

    So, I went ahead and tried manually creating a USB and it still gave the same kernel panic. Out of curiosity, I booted the same USB on my laptop and it booted successfully.

    Link to comment

    Are you suggesting that there was a change to remove USB 3.0 support?

    I don't believe that I have any USB 2.0 ports, let alone any that can boot UEFI... I'll see if I can use the management card ports for booting.

    Link to comment
    9 minutes ago, geekazoid said:

    Are you suggesting that there was a change to remove USB 3.0 support?

    I don't believe that I have any USB 2.0 ports, let alone any that can boot UEFI... I'll see if I can use the management card ports for booting.

    It was worth a try. The kernel doesn’t deal well with XHCI for whatever reason and often times gets unmounted on boot. So it’s always best to use a 2.0 port.

    • Like 1
    Link to comment

    Had time to work on this early this morning.

    I did some regression testing and I'm going to stick with the USB 3 boot because its been working for years now and I noticed that if I build a new bootable USB drive it won't detect it in BIOS until it has been put in a USB 3 port for POST. After that it has added it to UEFI list and works. The USB 2 ports in my mobo are not designed for booting, they are designed to be dedicated to console keyboard/mouse and BIOS updates. USB 3 is the norm now and it should be fully supported.

    I made two USB keys to do some isolation. I used the manual method in both cases. One fresh key with 6.6 and one fresh key with 6.7.1. No config files merged. Each time I detected and selected the "new" EFI device in BIOS and then did a save and reset before trying to boot from it. Both booted cleanly.

    I then manually replaced 6.7.1 files over my licensed key, leaving my config directory intact and deleting EFI directory, then ran make_bootable.bat. My system booted 6.7.1 cleanly with my original key.

    So what we've learned is that:
    - the updater doesn't validate its work, which sucks
    - the updater doesn't provide a mechanism for rollback, which sucks
    - the updater doesn't tell you that it sucks, which sucks
    - don't use the updater anymore, shutdown your system and backup the entire key then do a manual update, always run make_bootable.bat and re-select it as primary EFI boot device in your BIOS

    Have a nice day.

    Link to comment

    I’m certainly happy you got it working again but it could be the updater failed because it’s on a USB 3.0 port. While, yes, USB 3.0 SHOULD work. Things are never that simple. If you peruse the forums you’ll see lots of people who have USB dismount issues on 3.0 which is usually solved by moving to a 2.0 port.

     

    I can’t say for certain that it had a hand in your problem but to discount it out of hand is a bit arrogant and unscientific.

    • Like 1
    Link to comment

    New info:

    I just reviewed the ports on the back of my ASUS Z10PE-D16 WS and it turns out that I've been booting from USB 2 this whole time.

    There are eight USB ports on the back panel of my PC. Four (not six as I thought) are USB 2 ports, but two are allocated to a "management" role and behave a little differently than the rest. Those two are to be avoided for booting from. However the next two below are in fact plain old USB 2 and that is where my Unraid boot flash drive has always been. I may have even taken the advice you are giving back in the original build and forgot the specifics over time.

    The issue I saw with recognizing new UEFI flash drives does not exist with these two USB 2 ports so I have an operable solution. I'll keep using USB 2 for my flash drive.

    To be clear, USB 3 was in fact never used in my troubleshooting or when the update was done - my mistake there. USB 3 is not root cause of the issue I experienced (can't speak for others with same error), but lets assume that your advice is sound - boot from USB 2!

    Edited by geekazoid
    words
    Link to comment
    1 hour ago, geekazoid said:

    the updater doesn't provide a mechanism for rollback, which sucks

    The updater DOES provide a mechanism for rollback, but it is not of much use if you cannot boot in the first place.

     

    1 hour ago, geekazoid said:

    the updater doesn't validate its work, which sucks

    I think the updater assumes that if the checksum on the download was good; it got no error unpacking the release and then writing it to the USB stick that everything is OK.   This has not been an issue in the past but a failed updte does seem to have been more frequent in the last few releases.   Something must have changed to cause this but quite what it might be I have no idea.

     

    I wonder if there is any benefit of adding an option to the Boot Menu that allows for booting the previous release?  

    Edited by itimpi
    Link to comment

    There certainly is value to that, which is why it's standard on all Linux releases. Update kernel, reboot to kernel, uninstall old kernel if all went well. Also pretty much any system with a system image approach like this would have a "Slot" for the old image so you could always roll back.

    At a glance, this isn't that hard to do but would imply some new changes for sure. Not major ones but there'd have to be a filesystem change. It could perhaps be implemented by way of a backup image directory in root that was always an option to boot from in the bootloader menu.

    Link to comment


    Most Linux systems are installed to a hard disk with files all over the place.which complicates roll-back.    On Unraid which really only installs itself at boot time into RAM it I s trivial for thebUser to do it themselves as it just involves copying the contents of the ‘previous’ folder on the USB stick back to the root.

    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.