We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

Omega2 reboot



  • @Lazar-Demin Thanks.
    Yesterday i tried version b141 but not working yet.
    I'will try when come back to home.



  • @Lazar-Demin Thanks! ❤

    Verified working with b145.



  • Reboot works with b145, but now poweroff also reboots the unit instead of powering off for me 😞 Using a 2+



  • @cusackph
    shutdown doesn't work either. How do we turn these things off?!



  • Hello,

    I have the same problem. When I want to turn off my Omega2+ (firmware v0.1.8-b145), I use halt (or poweroff) command. But these commands do not work and reboot the Omega2+.



  • @Mikaël-PIRIO said in Omega2 reboot:

    Hello,

    I have the same problem. When I want to turn off my Omega2+ (firmware v0.1.8-b145), I use halt (or poweroff) command. But these commands do not work and reboot the Omega2+.

    I can confirm this :(.


  • administrators

    @Brian-Robbins @SukkoPera @cusackph @Mikaël-PIRIO
    The nature of the kernel patch to enable rebooting seems to have this side-effect... How essential are the halt or poweroff commands for your workflows?

    Btw, I will be submitting a Pull Request to LEDE for the reboot kernel patch soon, will update you when it's in.



  • @Lazar-Demin
    Not essential, as long as I can be assured that simply unplugging or switching the Omega2+ off has no risk of file corruption


  • administrators

    @Brian-Robbins ya it should be safe to just switch it off. I usually just yank mine out of my laptop when I want to power it down.

    If you're feeling extra paranoid, run the sync command and allow it to finish before unplugging it.



  • @Lazar-Demin said in Omega2 reboot:

    I usually just yank mine out of my laptop when I want to power it down.

    Lol!!! But that's not very good for a USB key or SD card still mounted. Linux is not that robust.



  • @Lazar-Demin so you're going to submit a broken patch? Please don't. You can't just fix one thing and break another. The previous behaviour was more acceptable than the current one, as you turn off the Omega more often than you reboot it, at least at the current stage. So please revert the patch and look into the proper fix before you submit anything upstream.



  • @Lazar-Demin Please, consider fixing the poweroff and halt issues before summiting the Pull Request.



  • I just picked up my Omega2 / revision R1 / Firmware 0.1.9 (b149) today and also noticed the reboot-instead-of-shutdown behaviour. Is there a solution for this issue yet?



  • Hello,

    With firmware v0.1.9-b149, halt (or poweroff) always reboot my Omega2+ 😞.



  • The issues with the reboot flash state and problems with some of the proposed fixes are pretty clear.

    What is more a mystery is how a powerdown used to work. Was this an actual shutdown of the chip, or at least a drastic drop in power consumption by slowing a clock?

    Or was it just a one-way trip to what looked like an "off" state with no file systems mounted, from which externally cutting power would be fully appropriate?

    (Was a hypothetical trip to such a deadend state even a designed behavior, or just an emergent one of the chip trying and eternally failing to boot from a flash stuck in the wrong addressing mode?)

    And was it done by the kernel, by rebooting to U-Boot with flags to trigger special behavior there, or did the other (radio-related) CPU in the chip have a role in it?



  • the question i have when using shutdown is, there is roughly a 3 second period on my omega2+ after the power light goes off and before it comes back on. so if i do a shutdown, wait for the power light to go off, then remove the power plug, does this qualify as a "shutdown" in a legit sense? is it possible that damage to the filesystem will take place.?



  • The best time to pull power would be while the system is sitting in U-Boot; that's easily determined from the serial port, and you can probably correlate it to the state of the LEDs.

    In terms of fileystem corruption, this risk is already substantially lower than it would be on something like an SD card based raspberry pi.

    • The SPI NOR flash memory is used relatively bare; there's no hardware flash translation table that could mess up and scramble one part of the addressable space because another is being written to; if there are bugs, they are in visible, correctable software layers and the modes those configure the chip to. And unlike SD cars, the flash chips have real data sheets.

    • The critical storage - U-Boot, Linux, and the root filesystem are not normally operated in a writable fashion. This combined with the memory architecture should mean they are essentially always almost as safe from power loss as they would be on a system that has been shutdown in preparation for it.

    • The one thing that is writeable is the overalay partition, but this is a journaling file system that makes some degree of effort to make changes only in an interruption-safe manner. Still this is the weak point. However, fortunately the writable filesystem is a place you may be able to tolerate failure - safemode or a factory reset gets you a still bootable system, and you can reconfigure the network and transfer your backups of customizations to the board again.

    So orderly shutdown is a good idea when possible, but the consequences of a disorderly one are lesser than they would be on a different architecture.



  • thanks, Chris. another question, if i enter a dmesg , sometimes, usually after i have used a build for a period of time, the last line will be a warning of ~" vfat, filesystem is corrupt, try using fsck". when i've seen it i've wondered if this business of hacking a shutdown somehow is responsible for the corrupt filesystem that is being reported. do you have any other ideas about how this issue comes about?



  • What vfat filesystem?

    If you have a USB stick or an SD card added to the system, then you're potentially subject the all the various ways those can fail, unless your usage of it is optional enough that failure there is tolerable.

    In essence, with either of these before power loss you need to sync and unmount, just as you'd need to do "safely remove hardware" or drag to the trash or eject or whatever on a larger computer.

    The stock shutdown process (when it works) would hopefully include that, but it's worth being explicitly sure.

    Or just not using comparatively delicate storage, if you can avoid it.



  • i do ocassionally use an sd card. i must have left it in during a shutdown . i guess this means the things i would expect to be handled by the operating sytem are not being done. i need to pay more attention to what i'm doing.


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.