Re: system stops
On Tuesday, January 29, 2019 03:58:21 AM to...@tuxteam.de wrote: > On Mon, Jan 28, 2019 at 02:07:05PM -0500, rhkra...@gmail.com wrote: > > [...] > > > You should read all of wikipedia before using a piece of software? Or > > some selection based on words you can remember / think of? > > You can leave out that page on fern [1]. And that other on slime mold [2] That helps, thanks ;-) > (Uh-oh. Now everyone knows I've been procrastinating :-/ Uh, I won't say anything > > [1] https://en.wikipedia.org/wiki/Fern > [2] https://en.wikipedia.org/wiki/Slime_mold > -- t
Re: system stops
On Mon, Jan 28, 2019 at 02:07:05PM -0500, rhkra...@gmail.com wrote: [...] > You should read all of wikipedia before using a piece of software? Or some > selection based on words you can remember / think of? You can leave out that page on fern [1]. And that other on slime mold [2] (Uh-oh. Now everyone knows I've been procrastinating :-/ [1] https://en.wikipedia.org/wiki/Fern [2] https://en.wikipedia.org/wiki/Slime_mold -- t signature.asc Description: Digital signature
Re: system stops
On 29/01/2019 01:17, David Christensen wrote: > On 1/28/19 10:41 AM, John Darrah wrote: >> On 1/28/2019 10:21 AM, David Christensen wrote: >>> On 1/28/19 1:18 AM, Paul Sutton wrote: On 28/01/2019 00:55, David Christensen wrote: > On 1/27/19 12:11 PM, BELAHCENE Abdelkader wrote: >> Sometimes (maybe often) when I leave the system for a times without >> touching it, when I come back, the system is frozen , juste the >> pointer of >> mouse can move, but nothing else, keyboard doesn't respond, even >> ctrl+alt+F1 , or F2, ... >> So the only thing todo is stop button. > > Install the package: > > openssh-server > > > Configure your host and/or network so that you can log in over the > network. Holding alt-sysrq (print screen key usually) and then typing RSEIUB may also restart the system but cleanly as in unmounting file systems etc. however I agree with the above option too. >>> >>> Where is that documented? >>> >> Right here: https://en.wikipedia.org/wiki/Magic_SysRq_key > > Why RSEIUB, rather than REISUB as recommended by Wikipedia? > > > David > I remember the mnemonic as Raising Skinny Elephants Is Utterly Boring. (RSEIUB) Paul -- Paul Sutton http://www.zleap.net https://www.linkedin.com/in/zleap/ signature.asc Description: OpenPGP digital signature
Re: system stops
On Mon, 2019-01-28 at 15:43 -0500, rhkra...@gmail.com wrote: > On Monday, January 28, 2019 02:45:26 PM John Darrah wrote: > > On 1/28/2019 11:08 AM, rhkra...@gmail.com wrote: > > > I don't consider that documentation. > > > Is this better?: > > https://www.kernel.org/doc/html/v4.18/admin-guide/sysrq.html > > Yes, thank you! Debian kernels don't seem to have the process killing and debug dump keys disabled by default... # cat /boot/config-4.9.0-8-amd64 | grep SYSRQ CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x01b6 I guess it was decided that the disabled options could allow unauthorised users access to sensitive information and programs. -- Tixy
Re: system stops
On 28/01/2019 18.18, Paul Sutton wrote: On 1/27/19 12:11 PM, BELAHCENE Abdelkader wrote: Sometimes (maybe often) when I leave the system for a times without touching it, when I come back, the system is frozen , juste the pointer of mouse can move, but nothing else, keyboard doesn't respond, even ctrl+alt+F1 , or F2, ... So the only thing todo is stop button. Holding alt-sysrq (print screen key usually) and then typing RSEIUB may also restart the system but cleanly as in unmounting file systems etc. Unfortunately in this case the keyboard is not responding, so RSEISUB (boots and braces) probably won't help. (It's a good thing to try though.) -- John
Re: system stops
On 1/28/19 10:41 AM, John Darrah wrote: On 1/28/2019 10:21 AM, David Christensen wrote: On 1/28/19 1:18 AM, Paul Sutton wrote: On 28/01/2019 00:55, David Christensen wrote: On 1/27/19 12:11 PM, BELAHCENE Abdelkader wrote: Sometimes (maybe often) when I leave the system for a times without touching it, when I come back, the system is frozen , juste the pointer of mouse can move, but nothing else, keyboard doesn't respond, even ctrl+alt+F1 , or F2, ... So the only thing todo is stop button. Install the package: openssh-server Configure your host and/or network so that you can log in over the network. Holding alt-sysrq (print screen key usually) and then typing RSEIUB may also restart the system but cleanly as in unmounting file systems etc. however I agree with the above option too. Where is that documented? Right here: https://en.wikipedia.org/wiki/Magic_SysRq_key Why RSEIUB, rather than REISUB as recommended by Wikipedia? David
Re: system stops
On Monday, January 28, 2019 02:45:26 PM John Darrah wrote: > On 1/28/2019 11:08 AM, rhkra...@gmail.com wrote: > > I don't consider that documentation. > Is this better?: > https://www.kernel.org/doc/html/v4.18/admin-guide/sysrq.html Yes, thank you!
Re: system stops
On 1/28/2019 11:08 AM, rhkra...@gmail.com wrote: Hmm, it might be my day to be disagreeable, and I'm not the OP, nor (iirc) have I posted in this thread prior to this, but ... On Monday, January 28, 2019 01:41:41 PM John Darrah wrote: On 1/28/2019 10:21 AM, David Christensen wrote: Where is that documented? David Right here: https://en.wikipedia.org/wiki/Magic_SysRq_key I don't consider that documentation. You should read all of wikipedia before using a piece of software? Or some selection based on words you can remember / think of? (I guess I don't doubt that it is documented somewhere in something that I would consider documentation (like a man page associated with Linux or the specific app), but an entry in wikipedia is not documentation. Hmm, should I wait and rethink before posting this -- nah, even if I wait, at most I'll do something like add some musing just like this ;-) Is this better?: https://www.kernel.org/doc/html/v4.18/admin-guide/sysrq.html -- john
Re: system stops
Hmm, it might be my day to be disagreeable, and I'm not the OP, nor (iirc) have I posted in this thread prior to this, but ... On Monday, January 28, 2019 01:41:41 PM John Darrah wrote: > On 1/28/2019 10:21 AM, David Christensen wrote: > > Where is that documented? > > > > > > David > > Right here: https://en.wikipedia.org/wiki/Magic_SysRq_key I don't consider that documentation. You should read all of wikipedia before using a piece of software? Or some selection based on words you can remember / think of? (I guess I don't doubt that it is documented somewhere in something that I would consider documentation (like a man page associated with Linux or the specific app), but an entry in wikipedia is not documentation. Hmm, should I wait and rethink before posting this -- nah, even if I wait, at most I'll do something like add some musing just like this ;-)
Re: system stops
On 1/28/2019 10:21 AM, David Christensen wrote: On 1/28/19 1:18 AM, Paul Sutton wrote: On 28/01/2019 00:55, David Christensen wrote: On 1/27/19 12:11 PM, BELAHCENE Abdelkader wrote: Sometimes (maybe often) when I leave the system for a times without touching it, when I come back, the system is frozen , juste the pointer of mouse can move, but nothing else, keyboard doesn't respond, even ctrl+alt+F1 , or F2, ... So the only thing todo is stop button. Install the package: openssh-server Configure your host and/or network so that you can log in over the network. Holding alt-sysrq (print screen key usually) and then typing RSEIUB may also restart the system but cleanly as in unmounting file systems etc. however I agree with the above option too. Where is that documented? David Right here: https://en.wikipedia.org/wiki/Magic_SysRq_key -- john
Re: system stops
On 1/28/19 1:18 AM, Paul Sutton wrote: On 28/01/2019 00:55, David Christensen wrote: On 1/27/19 12:11 PM, BELAHCENE Abdelkader wrote: Sometimes (maybe often) when I leave the system for a times without touching it, when I come back, the system is frozen , juste the pointer of mouse can move, but nothing else, keyboard doesn't respond, even ctrl+alt+F1 , or F2, ... So the only thing todo is stop button. Install the package: openssh-server Configure your host and/or network so that you can log in over the network. Holding alt-sysrq (print screen key usually) and then typing RSEIUB may also restart the system but cleanly as in unmounting file systems etc. however I agree with the above option too. Where is that documented? David
Re: system stops
On 28/01/2019 00:55, David Christensen wrote: > On 1/27/19 12:11 PM, BELAHCENE Abdelkader wrote: >> Sometimes (maybe often) when I leave the system for a times without >> touching it, when I come back, the system is frozen , juste the >> pointer of >> mouse can move, but nothing else, keyboard doesn't respond, even >> ctrl+alt+F1 , or F2, ... >> So the only thing todo is stop button. > > Install the package: > > openssh-server > > > Configure your host and/or network so that you can log in over the > network. > > > David Holding alt-sysrq (print screen key usually) and then typing RSEIUB may also restart the system but cleanly as in unmounting file systems etc. however I agree with the above option too. -- Paul Sutton http://www.zleap.net https://www.linkedin.com/in/zleap/ signature.asc Description: OpenPGP digital signature
Re: system stops
On Sun 27 Jan 2019 at 20:23:38 (-0500), Cindy-Sue Causey wrote: > On 1/27/19, Cindy-Sue Causey wrote: > > > > AND THAT... just reminded me that there was a thread where someone > > here said something I'd never remembered hearing before... There's a > > spot related to I THINK initramfs or something LIKE that > > (initrd.img??) where we can accidentally be carrying over a wrong UUID > > (or possibly PARTUUID, LABEL, etc) declaration. > > > > That would, for example, happen if we copied over a live session from > > one partition to another. It's well known that we immediately need to > > change declarations in /etc/fstab to represent the new partition. This > > other, though, just might answer some questions like this that have > > otherwise long gone unsolved in the past.. > > > > OR NOT. *grin* > > > Sorry, I did it AGAIN. Left out the rationale for even bringing that up. > > Whichever kind Debian User brought that topic up in last couple months > said that it's a place where our systems would be tapping into when > bringing things up to speed. If the wrong declaration is sitting in > that position, our systems will stall while they're scratching their > heads trying to figure out what to do next when they can't find that > wrong UUID (or possibly PARTUUID or LABEL) that was accidentally > carried over from another partition or suchly.. Sounds like you're referring to /etc/initramfs-tools/conf.d/resume which needs to be present in the initramfs as well as the filesystem. Cheers, David.
Re: system stops
On 1/27/19, Cindy-Sue Causey wrote: > > AND THAT... just reminded me that there was a thread where someone > here said something I'd never remembered hearing before... There's a > spot related to I THINK initramfs or something LIKE that > (initrd.img??) where we can accidentally be carrying over a wrong UUID > (or possibly PARTUUID, LABEL, etc) declaration. > > That would, for example, happen if we copied over a live session from > one partition to another. It's well known that we immediately need to > change declarations in /etc/fstab to represent the new partition. This > other, though, just might answer some questions like this that have > otherwise long gone unsolved in the past.. > > OR NOT. *grin* Sorry, I did it AGAIN. Left out the rationale for even bringing that up. Whichever kind Debian User brought that topic up in last couple months said that it's a place where our systems would be tapping into when bringing things up to speed. If the wrong declaration is sitting in that position, our systems will stall while they're scratching their heads trying to figure out what to do next when they can't find that wrong UUID (or possibly PARTUUID or LABEL) that was accidentally carried over from another partition or suchly.. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: system stops
On 1/27/19, Jens Holzhäuser wrote: > On Sun, Jan 27, 2019 at 09:11:33PM +0100, BELAHCENE Abdelkader wrote: >> Sometimes (maybe often) when I leave the system for a times without >> touching it, when I come back, the system is frozen , juste the pointer >> of >> mouse can move, but nothing else, keyboard doesn't respond, even >> ctrl+alt+F1 , or F2, ... > > >> Jan 27 20:29:52 mx kernel: [11477.409506] PM: suspend exit > [...] >> Jan 27 20:29:52 mx kernel: [11476.619289] sd 0:0:0:0: [sda] Starting disk > [...] >> Jan 27 20:29:52 mx kernel: [11476.091515] ACPI: Waking up from system >> sleep state S3 > [...] >> Jan 27 20:29:52 mx kernel: [11476.082190] ACPI: Low-level resume complete > > Looks like your system is waking up from being suspended/hibernated. > > Try disabling suspension/hibernation and see if that prevents the issue. > Something with the power management and system resume might not be > working correctly. That's what I was thinking, too. Then, if it looks like all of that is set for it to just sit there instead of shutting down, it's ok to say, nope, it's still doing it Because mine does, too. I'll go off and do a few chores then come back to it. It's obvious that it has still gone into some level of bystanding mode in spite of my own settings. It takes its absolute sweet time coming back out of it, too. I had to change mine to not go into sleep/hibernation at all because it just would not recover too frequently. Hitting that power button was repeatedly the only way to recover in my case, too. AND THAT... just reminded me that there was a thread where someone here said something I'd never remembered hearing before... There's a spot related to I THINK initramfs or something LIKE that (initrd.img??) where we can accidentally be carrying over a wrong UUID (or possibly PARTUUID, LABEL, etc) declaration. That would, for example, happen if we copied over a live session from one partition to another. It's well known that we immediately need to change declarations in /etc/fstab to represent the new partition. This other, though, just might answer some questions like this that have otherwise long gone unsolved in the past.. OR NOT. *grin* As an aside, can we address that by simply updating initramfs via that command that was just provided in that one thread a couple days ago? Maybe that's something we're supposed to be doing after copying over to a new partition, and some of us just hadn't seen that memo yet? Or would that not help because we still need to manually change that particular "declaration" first before we update... if it's even about update-initramfs in the first place? :) One other thing I've noticed lately is about things like shutting programs down to bring them back up and having it just sit there for the longest time before things finally happen. I started watching "free -m" during those times IF there was enough memory available to even run that command, GRIN. Time and again I've sat here and watched it SLOWLY pull things out of swap and put it back I PRESUME into "ram"... and THEN it FINALLY shuts the program on down. :) While what I just wrote is about shutting programs down, I've imagined it playing some potentially similar part in spending the same amount of time watching it come back up from a hibernation it was never expected to take in the first place. :D Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: system stops
On 1/27/19 12:11 PM, BELAHCENE Abdelkader wrote: Sometimes (maybe often) when I leave the system for a times without touching it, when I come back, the system is frozen , juste the pointer of mouse can move, but nothing else, keyboard doesn't respond, even ctrl+alt+F1 , or F2, ... So the only thing todo is stop button. Install the package: openssh-server Configure your host and/or network so that you can log in over the network. David
Re: system stops
On Sun, Jan 27, 2019 at 09:11:33PM +0100, BELAHCENE Abdelkader wrote: > Sometimes (maybe often) when I leave the system for a times without > touching it, when I come back, the system is frozen , juste the pointer of > mouse can move, but nothing else, keyboard doesn't respond, even > ctrl+alt+F1 , or F2, ... > Jan 27 20:29:52 mx kernel: [11477.409506] PM: suspend exit [...] > Jan 27 20:29:52 mx kernel: [11476.619289] sd 0:0:0:0: [sda] Starting disk [...] > Jan 27 20:29:52 mx kernel: [11476.091515] ACPI: Waking up from system sleep > state S3 [...] > Jan 27 20:29:52 mx kernel: [11476.082190] ACPI: Low-level resume complete Looks like your system is waking up from being suspended/hibernated. Try disabling suspension/hibernation and see if that prevents the issue. Something with the power management and system resume might not be working correctly. I am not very familiar with Linux hibernation, so there's not much more I can help with here. Jens
system stops
HI, uname -a gives Linux mx 4.19.0-1-amd64 #1 SMP Debian 4.19.5-2~mx17+1 (2018-12-12) x86_64 GNU/Linux Sometimes (maybe often) when I leave the system for a times without touching it, when I come back, the system is frozen , juste the pointer of mouse can move, but nothing else, keyboard doesn't respond, even ctrl+alt+F1 , or F2, ... So the only thing todo is stop button. Here is some lines from messages (last line before the shutdown), hope that someone can help me by reading this log before the stopping system ( at 20:29). Jan 27 20:29:52 mx kernel: [11479.565256] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0489-e032.hcd not found Jan 27 20:29:52 mx kernel: [11479.565248] bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0 489-e032.hcd failed with error -2 Jan 27 20:29:52 mx kernel: [11478.719457] ata1.00: configured for UDMA/133 Jan 27 20:29:52 mx kernel: [11478.513494] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jan 27 20:29:52 mx kernel: [11477.409506] PM: suspend exit Jan 27 20:29:52 mx kernel: [11477.374637] Bluetooth: hci0: BCM20702A1 (001.002.014) build Jan 27 20:29:52 mx kernel: [11477.373634] Bluetooth: hci0: BCM20702A Jan 27 20:29:52 mx kernel: [11477.356632] Bluetooth: hci0: BCM: features 0x07 Jan 27 20:29:52 mx kernel: [11477.355640] Bluetooth: hci0: BCM: chip id 63 Jan 27 20:29:52 mx kernel: [11477.245215] Restarting tasks ... done. Jan 27 20:29:52 mx kernel: [11477.245213] OOM killer enabled. Jan 27 20:29:52 mx kernel: [11477.164547] usb 1-1.4: reset high-speed USB device number 5 using ehci -pci Jan 27 20:29:52 mx kernel: [11477.106796] ata3.00: configured for UDMA/100 Jan 27 20:29:52 mx kernel: [11477.105193] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Jan 27 20:29:52 mx kernel: [11477.022519] usb 1-1.3: reset full-speed USB device number 4 using ehci -pci Jan 27 20:29:52 mx kernel: [11477.018509] usb 4-1.6: reset high-speed USB device number 3 using ehci -pci Jan 27 20:29:52 mx kernel: [11476.837625] ACPI: button: The lid device is not compliant to SW_LID. Jan 27 20:29:52 mx kernel: [11476.619289] sd 0:0:0:0: [sda] Starting disk Jan 27 20:29:52 mx kernel: [11476.608519] ACPI: EC: event unblocked Jan 27 20:29:52 mx kernel: [11476.594662] ACPI: EC: interrupt unblocked Jan 27 20:29:52 mx kernel: [11476.091515] ACPI: Waking up from system sleep state S3 Jan 27 20:29:52 mx kernel: [11476.088916] CPU1 is up Jan 27 20:29:52 mx kernel: [11476.088582] cache: parent cpu1 should not be sleeping Jan 27 20:29:52 mx kernel: [11476.083485] smpboot: Booting Node 0 Processor 1 APIC 0x2 Jan 27 20:29:52 mx kernel: [11476.083484] x86: Booting SMP configuration: Jan 27 20:29:52 mx kernel: [11476.083445] Enabling non-boot CPUs ... Jan 27 20:29:52 mx kernel: [11476.082238] PM: Restoring platform NVS memory Jan 27 20:29:52 mx kernel: [11476.082238] ACPI: EC: EC started Jan 27 20:29:52 mx kernel: [11476.082190] ACPI: Low-level resume complete Sorry if the list is long. Thanks a lot regards
Re: Re: Stretch System Stops Boot Process Immediately After Grub Screen (me too!)
> Sorry to see that you're having this problem. I'm stymied as to why it might > happen with a VM. I had assumed that the new kernel had stopped supporting > some piece of hardware in my rather unusual little notebook computer. > The same day the kernel was updated on my system, pc-grub was also updated. > Since the boot failure occurs at the point where grub finishes and the system > load begins I wasn't sure whether the problem was the new kernel or the new > grub. > I've got a bunch of medical stuff happening right now, so simply don't have > time to spend making live images and diagnosing / fixing. > Just wanted to drop a note to express sympathy, and to point out that I was > running the amd64 kernel on one 64 bit system and the 686-PAE kernel on two > i386 systems. In my case, it was one of the i386 systems that stopped > working, but the really ancient system continued working. In your case IIRC > it's an amd64 VM that has failed. I'm perplexed as to how a single kernel > change would affect both of these systems and leave so many other hardware > and VM combinations unscathed. > But then again, I'm easily perplexed these days. > Good luck! > JP Of course I can't be sure if the kernel change itself has caused the problem or if it is grub related. Too many things were changed in the one big update that brought this on. I found one other person having a similar problem over on the Debian user forums: http://forums.debian.net/viewtopic.php?f=10&t=130252 Their solution was to update to an experimental 4.8 kernel. I'm able to boot the machine to kernel 4.6.0 and keep moving. So I guess I'll just wait and see. Thanks for the support. --Mike
Re: Stretch System Stops Boot Process Immediately After Grub Screen (me too!)
On 11/03/2016 03:26 PM, Mike Conde wrote: Have you checked your boot partition - does it have enough free space? I don't have a separate boot partition, just one main partition that is 40GB in capacity and 40% full. Sorry to see that you're having this problem. I'm stymied as to why it might happen with a VM. I had assumed that the new kernel had stopped supporting some piece of hardware in my rather unusual little notebook computer. The same day the kernel was updated on my system, pc-grub was also updated. Since the boot failure occurs at the point where grub finishes and the system load begins I wasn't sure whether the problem was the new kernel or the new grub. I've got a bunch of medical stuff happening right now, so simply don't have time to spend making live images and diagnosing / fixing. Just wanted to drop a note to express sympathy, and to point out that I was running the amd64 kernel on one 64 bit system and the 686-PAE kernel on two i386 systems. In my case, it was one of the i386 systems that stopped working, but the really ancient system continued working. In your case IIRC it's an amd64 VM that has failed. I'm perplexed as to how a single kernel change would affect both of these systems and leave so many other hardware and VM combinations unscathed. But then again, I'm easily perplexed these days. Good luck! JP
Re: Re: Stretch System Stops Boot Process Immediately After Grub Screen (me too!)
> Have you checked your boot partition - does it have enough free space? I don't have a separate boot partition, just one main partition that is 40GB in capacity and 40% full.
Re: Stretch System Stops Boot Process Immediately After Grub Screen (me too!)
Mike Conde wrote: > I am having exactly the same problem as Jape Person's post from Oct 22 > 2016, except my hardware environment is completely different. > > I am running Debian testing/Stretch 64-bit on a virtual machine under > virtualbox. The host OS is Windows 7 64-bit. > > I don't know exactly which kernel update was the culprit because I got > behind on my updates, but I think the problem appeared sometime around > 4.7.6 or so. > > I still have a 4.6 kernel image on the VM so I am able to boot to that > just fine. > > To be specific, after the grub menu disappears the screen goes blank and > there is no further activity, no matter how long I wait. Choosing > recovery > mode in grub does not change anything. Also redirecting the console out a > serial port doesn't provide any info -- no serial data is transmitted. > > I thought this might be a virtualbox compatibility problem, but since > someone else is experiencing the same thing on a non-VM machine I now > suspect the kernel. > > Should I post this as a bug somewere, and if so where? > > Thanks! > > --Mike Conde Have you checked your boot partition - does it have enough free space?
Stretch System Stops Boot Process Immediately After Grub Screen (me too!)
I am having exactly the same problem as Jape Person's post from Oct 22 2016, except my hardware environment is completely different. I am running Debian testing/Stretch 64-bit on a virtual machine under virtualbox. The host OS is Windows 7 64-bit. I don't know exactly which kernel update was the culprit because I got behind on my updates, but I think the problem appeared sometime around 4.7.6 or so. I still have a 4.6 kernel image on the VM so I am able to boot to that just fine. To be specific, after the grub menu disappears the screen goes blank and there is no further activity, no matter how long I wait. Choosing recovery mode in grub does not change anything. Also redirecting the console out a serial port doesn't provide any info -- no serial data is transmitted. I thought this might be a virtualbox compatibility problem, but since someone else is experiencing the same thing on a non-VM machine I now suspect the kernel. Should I post this as a bug somewere, and if so where? Thanks! --Mike Conde
Re: Stretch System Stops Boot Process Immediately After Grub Screen
On 10/23/2016 05:26 PM, Frank wrote: Op 23-10-16 om 22:47 schreef Felix Miata: I don't remember having any Stretch installations with fewer than two installed kernels. The currently booted one, originally installed 51 weeks ago, has 6 installed. I've yet to discover any doc suggesting anything about any possibility of automatic removal of old kernels from Debian Testing installations. This is exactly what happens when the binary package version number does not change. The 4.7.6 kernel came in packages with version number 4.7.0-1. So did the 4.7.8 one [1]. This means 4.7.8 simply overwrote 4.7.6. This sort of thing has been happening on my Testing system for years. The older ones I have are 4.6.0-1, 4.5.0-2 and 4.5.0-1. Regards, Frank 1: https://tracker.debian.org/pkg/linux The arrangement has been working for me for quite some time, but it may have bit me in the behind this time around. Thank you for the link. I should have been paying more attention.
Re: Stretch System Stops Boot Process Immediately After Grub Screen
Op 23-10-16 om 22:47 schreef Felix Miata: I don't remember having any Stretch installations with fewer than two installed kernels. The currently booted one, originally installed 51 weeks ago, has 6 installed. I've yet to discover any doc suggesting anything about any possibility of automatic removal of old kernels from Debian Testing installations. This is exactly what happens when the binary package version number does not change. The 4.7.6 kernel came in packages with version number 4.7.0-1. So did the 4.7.8 one [1]. This means 4.7.8 simply overwrote 4.7.6. This sort of thing has been happening on my Testing system for years. The older ones I have are 4.6.0-1, 4.5.0-2 and 4.5.0-1. Regards, Frank 1: https://tracker.debian.org/pkg/linux
Re: Stretch System Stops Boot Process Immediately After Grub Screen
On 10/23/2016 04:47 PM, Felix Miata wrote: Jape Person composed on 2016-10-23 14:33 (UTC-0400): Felix Miata wrote: Does the same thing happen booting the previous kernel (4.6?)? Nope. The problem occurred on the first reboot after the upgrade from 4.7.6-1 to 4.7.8-1. The upgrade process didn't leave 4.7.6-1 in place so I could fall back. I don't remember just when I started seeing that upgrade behavioral change in Debian. I used to always use the new kernel for a week or so, and then I would have to use apt to remove the old one if it was no longer needed. I don't remember having any Stretch installations with fewer than two installed kernels. The currently booted one, originally installed 51 weeks ago, has 6 installed. I've yet to discover any doc suggesting anything about any possibility of automatic removal of old kernels from Debian Testing installations. Could it be that the pae kernel your CF-R3 is running is not the recommended kernel for that CPU, and that has something to do with replacement on kernel upgrade instead of simply adding new? During new installations of Debian my systems I chose: linux-image-686-pae for the i386 systems linux-image-amd64 for the 64 bit systems Those new installations offer me the latest available kernel from the Stretch repository for each type of system. At some time in recent months I installed the linux-image-686-pae on the trouble machine. Since that time it has tracked the latest linux-image package just like the two other i386 systems and the amd64 system. I have seen all of these systems keep the older kernel when a "major" kernel version change has occurred in the repository. In those cases I have kept the older kernel around until I was sure it was okay. But for small kernel version jumps the next reboot just shows me the new kernel, the old one having evidently been replaced. Maybe the time is now opportune for an arch upgrade. The supply of devs working 32-bit seems to be shrinking quickly towards critical mass. 32-bit seems to be soon if not already in process of being removed from Stretch: http://news.softpedia.com/news/debian-is-dropping-support-for-older-32-bit-hardware-architectures-in-debian-9-503832.shtml If you mean I should replace the old equipment, I was planning on doing so. The oldest system in my collection is a Sony Viao video workstation that I believe came with Windows 98 on it. I think it is 17 or 18 years old, and is simply one of the best pieces of hardware of any kind I've ever owned. It has run 24/7 since I purchased it. I'm probably going to buy some Libreboot T400s, or I might get some Intel NUCs, if I think Debian's repositories will support that newer hardware. It's a shame, though, to have perfectly useful pieces like the Panasonic CF-R3 be relegated to obsolete software. The thing is a gem. It's tiny even by modern netbook standards but is fast and powerful. It was a marvel when it was introduced, and it's still no slouch. I appreciate your observations and suggestions. Regards, JP
Re: Stretch System Stops Boot Process Immediately After Grub Screen
Jape Person composed on 2016-10-23 14:33 (UTC-0400): Felix Miata wrote: Does the same thing happen booting the previous kernel (4.6?)? Nope. The problem occurred on the first reboot after the upgrade from 4.7.6-1 to 4.7.8-1. The upgrade process didn't leave 4.7.6-1 in place so I could fall back. I don't remember just when I started seeing that upgrade behavioral change in Debian. I used to always use the new kernel for a week or so, and then I would have to use apt to remove the old one if it was no longer needed. I don't remember having any Stretch installations with fewer than two installed kernels. The currently booted one, originally installed 51 weeks ago, has 6 installed. I've yet to discover any doc suggesting anything about any possibility of automatic removal of old kernels from Debian Testing installations. Could it be that the pae kernel your CF-R3 is running is not the recommended kernel for that CPU, and that has something to do with replacement on kernel upgrade instead of simply adding new? Maybe the time is now opportune for an arch upgrade. The supply of devs working 32-bit seems to be shrinking quickly towards critical mass. 32-bit seems to be soon if not already in process of being removed from Stretch: http://news.softpedia.com/news/debian-is-dropping-support-for-older-32-bit-hardware-architectures-in-debian-9-503832.shtml -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Stretch System Stops Boot Process Immediately After Grub Screen
On 10/23/2016 01:33 PM, Felix Miata wrote: James P. Wallen composed on 2016-10-23 12:14 (UTC-0400): On 10/22/2016 18:10 (UTC-0400), Jape Person wrote: It's confusing to see a response from a different person writing as if he was responding to himself. The confusion is caused by my idiotic tendency to confuse which e-mail account I'm using at any given moment. I generally use a separate e-mail account for mailing lists to help with organizational chores. Sorry about that. I did indeed respond to myself using a different e-mail account. Be that as it may, have either of you tried intercepting Grub and unquieting the boot process? Remove quiet, and either change splash to splash=0 or remove splash entirely. Then proceed to boot, and see what if anything shows up on screen besides a blinking underline cursor in the upper left corner. Yes, both of us have tried making changes in the boot process. Heh. There is simply no change in the experience when removing quiet or using nomodeset. The disk access stops instantly when the grub screen disappears. No keyboard controls are effective. The fact that just touching the power switch results in instant shut-down makes me think that the kernel has not even started to load. But computers are faster than I am, so I realize that this issue could be happening at the end of grub or the beginning of the kernel load. Does the same thing happen booting the previous kernel (4.6?)? Nope. The problem occurred on the first reboot after the upgrade from 4.7.6-1 to 4.7.8-1. The upgrade process didn't leave 4.7.6-1 in place so I could fall back. I don't remember just when I started seeing that upgrade behavioral change in Debian. I used to always use the new kernel for a week or so, and then I would have to use apt to remove the old one if it was no longer needed. Have you tried giving it 10 or more minutes before assuming boot won't complete? I have a Stretch installation last updated about three weeks ago, which installed a 4.7 kernel of 26 Sept. Booting it just now took >4.5 minutes to get from the Grub selection to seeing boot messages appear on screen, but from the point messages started appearing, boot proceeded normally. I have >20 multiboot PCs with various distros. I've been encountering this type of boot delay, sometimes as long as more than 13 minutes, with random kernel/initrd pairs in several different distros, for going on two years. It's happened only when Dracut builds the initrd, and only with 64 bit installations. Whenever I've asked anywhere about this I've gotten zero useful response, if any response at all. I've left it at the blinking cursor for hours without seeing any change. I have also been seeing the same odd boot delays (and shutdown delays) on my 64 bit installation for months in Stretch. The delays are not consistent in behavior or duration. I have not been able to find any way to gather useful data. Yeah, kind of annoying. But it's different from what I'm seeing on this i386 installation. Incidentally, sometimes on the amd64 image on another machine I've switched to TTY1 following logon to the GUI and seen systemd countdown messages for starting of various daemons still going on after the boot has apparently succeeded. No intention of providing flame bait here, but if anything like daemon startup failures was happening before the switch to systemd, I was happily ignorant of it until I actually needed the daemon, and it didn't slow my boot or shutdown processes. Just saying. ;-) Now I shall grin, duck, and run. http://markmail.org/message/yj3l3uphno3cgpgp is probably where I first asked publicly. I'll check out your link to see if there's any way I can a) learn something, b) contribute something, c) blame it all on a politician. Thanks, JP
Re: Stretch System Stops Boot Process Immediately After Grub Screen
On 10/23/2016 01:21 PM, Børge Holen wrote: I have to use the nomodeset from time to time where the f*** gfx card has unresolved issues with itself. Atleast it lets me boot to a prompt. Now thinking of it, I have no blinking cursor, I just get a black screen... So different issue all together and I am just rambling on Yes, I think this is a different issue. Once the grub screen disappears there is no disk access at all. I just get the blinking underline cursor in the top left corner of the screen. Using nomodeset, nosplash/splash=0, removing quiet -- none of these changes to the boot line of grub in any combination results in any change. The system simply stops accessing its hard drive and I get the black screen with the blinking underline cursor. Since a touch on the power button results in a system beep and immediate powerdown, I'm thinking it's possible that the system has not even started to load the kernel. When I have time to make some live images, I'll test to see what's going on. Regards, JP
Re: Stretch System Stops Boot Process Immediately After Grub Screen
On 10/23/2016 01:03 PM, Michael Lange wrote: On Sun, 23 Oct 2016 12:14:39 -0400 "James P. Wallen" wrote: Double checked to see if I was right about the video subsystem. It is not ATI, it is Intel integrated. No docs on this thing. It was never officially sold in U.S., where I live currently. Since I can't boot it to usable state, I can't (easily) find out exactly which video it uses. It's probably destine for re-installation anyway. I was just surprised to see such a failure occur after upgrade. If the device has worked with other kernel versions before, you could boot from an USB drive, do a chroot and install a kernel that works, this should be a pretty straightforward procedure. Thanks, Michael. Yes, I posted originally from another e-mail account, so I'm sorry for any confusion that may have caused in the thread. I am planning to boot from a live image on USB key to try chrooting onto the system drive to fix it. I'll probably try update-grub first just in case something weird happened to grub-pc during that part of the upgrade. I could install a different kernel, but I'd prefer working on the system before doing that to see if there's a way to make the current kernel in testing work. I'm kind of surprised that a minor kernel change of this type (probably) resulted in this problem. I'm not sure just what Debian's policy on kernel upgrades is. With major version changes, I think, the upgrade process leaves the old kernel in place so you can fall back on it if the new one fails. But minor revisions to the kernel just install the new kernel in place of the old one. I only noticed this change in upgrade policy -- if that is, indeed, what it is -- over the past couple of years. This computer is definitely a corner case hardware-wise. The straight replacement of the kernel seems to have backfired in this case for this particular machine. Many thanks for your suggestion. And if anyone has seen a bug report that might be pertinent, I'd appreciate a pointer. I've searched briefly, but found nothing. Regards, JP
Re: Stretch System Stops Boot Process Immediately After Grub Screen
James P. Wallen composed on 2016-10-23 12:14 (UTC-0400): On 10/22/2016 18:10 (UTC-0400), Jape Person wrote: It's confusing to see a response from a different person writing as if he was responding to himself. Be that as it may, have either of you tried intercepting Grub and unquieting the boot process? Remove quiet, and either change splash to splash=0 or remove splash entirely. Then proceed to boot, and see what if anything shows up on screen besides a blinking underline cursor in the upper left corner. Does the same thing happen booting the previous kernel (4.6?)? Have you tried giving it 10 or more minutes before assuming boot won't complete? I have a Stretch installation last updated about three weeks ago, which installed a 4.7 kernel of 26 Sept. Booting it just now took >4.5 minutes to get from the Grub selection to seeing boot messages appear on screen, but from the point messages started appearing, boot proceeded normally. I have >20 multiboot PCs with various distros. I've been encountering this type of boot delay, sometimes as long as more than 13 minutes, with random kernel/initrd pairs in several different distros, for going on two years. It's happened only when Dracut builds the initrd, and only with 64 bit installations. Whenever I've asked anywhere about this I've gotten zero useful response, if any response at all. http://markmail.org/message/yj3l3uphno3cgpgp is probably where I first asked publicly. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Stretch System Stops Boot Process Immediately After Grub Screen
Heck I even remember a one-floppy live distribution that I had for just this purpose. On Sun, Oct 23, 2016 at 7:26 PM, Børge Holen wrote: > Have you tried booting off a live distribution and inserted the old kernel > and symlinked the libraries so you can rerun grub update? I remember we had > to do that with lilo whenever I tried new kernels and forgot all about > lilo. Cannot even remember the last time I did it, since I found the rescue > option in the installation disk. That option wasn't there back in the days > > On Sun, Oct 23, 2016 at 7:21 PM, Børge Holen > wrote: > >> I have to use the nomodeset from time to time where the f*** gfx card has >> unresolved issues with itself. Atleast it lets me boot to a prompt. Now >> thinking of it, I have no blinking cursor, I just get a black screen... So >> different issue all together and I am just rambling on >> >> On Sun, Oct 23, 2016 at 7:03 PM, Michael Lange >> wrote: >> >>> On Sun, 23 Oct 2016 12:14:39 -0400 >>> "James P. Wallen" wrote: >>> >>> > Double checked to see if I was right about the video subsystem. >>> > It is not ATI, it is Intel integrated. No docs on this thing. It >>> > was never officially sold in U.S., where I live currently. Since >>> > I can't boot it to usable state, I can't (easily) find out >>> > exactly which video it uses. >>> > >>> > It's probably destine for re-installation anyway. I was just >>> > surprised to see such a failure occur after upgrade. >>> >>> If the device has worked with other kernel versions before, you >>> could boot from an USB drive, do a chroot and install a kernel that >>> works, this should be a pretty straightforward procedure. >>> >>> Regards >>> >>> Michael >>> >>> >>> >>> .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . >>> .-. >>> >>> You canna change the laws of physics, Captain; I've got to have thirty >>> minutes! >>> >>> >> >
Re: Stretch System Stops Boot Process Immediately After Grub Screen
Have you tried booting off a live distribution and inserted the old kernel and symlinked the libraries so you can rerun grub update? I remember we had to do that with lilo whenever I tried new kernels and forgot all about lilo. Cannot even remember the last time I did it, since I found the rescue option in the installation disk. That option wasn't there back in the days On Sun, Oct 23, 2016 at 7:21 PM, Børge Holen wrote: > I have to use the nomodeset from time to time where the f*** gfx card has > unresolved issues with itself. Atleast it lets me boot to a prompt. Now > thinking of it, I have no blinking cursor, I just get a black screen... So > different issue all together and I am just rambling on > > On Sun, Oct 23, 2016 at 7:03 PM, Michael Lange > wrote: > >> On Sun, 23 Oct 2016 12:14:39 -0400 >> "James P. Wallen" wrote: >> >> > Double checked to see if I was right about the video subsystem. >> > It is not ATI, it is Intel integrated. No docs on this thing. It >> > was never officially sold in U.S., where I live currently. Since >> > I can't boot it to usable state, I can't (easily) find out >> > exactly which video it uses. >> > >> > It's probably destine for re-installation anyway. I was just >> > surprised to see such a failure occur after upgrade. >> >> If the device has worked with other kernel versions before, you >> could boot from an USB drive, do a chroot and install a kernel that >> works, this should be a pretty straightforward procedure. >> >> Regards >> >> Michael >> >> >> >> .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. >> >> You canna change the laws of physics, Captain; I've got to have thirty >> minutes! >> >> >
Re: Stretch System Stops Boot Process Immediately After Grub Screen
I have to use the nomodeset from time to time where the f*** gfx card has unresolved issues with itself. Atleast it lets me boot to a prompt. Now thinking of it, I have no blinking cursor, I just get a black screen... So different issue all together and I am just rambling on On Sun, Oct 23, 2016 at 7:03 PM, Michael Lange wrote: > On Sun, 23 Oct 2016 12:14:39 -0400 > "James P. Wallen" wrote: > > > Double checked to see if I was right about the video subsystem. > > It is not ATI, it is Intel integrated. No docs on this thing. It > > was never officially sold in U.S., where I live currently. Since > > I can't boot it to usable state, I can't (easily) find out > > exactly which video it uses. > > > > It's probably destine for re-installation anyway. I was just > > surprised to see such a failure occur after upgrade. > > If the device has worked with other kernel versions before, you > could boot from an USB drive, do a chroot and install a kernel that > works, this should be a pretty straightforward procedure. > > Regards > > Michael > > > > .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. > > You canna change the laws of physics, Captain; I've got to have thirty > minutes! > >
Re: Stretch System Stops Boot Process Immediately After Grub Screen
On Sun, 23 Oct 2016 12:14:39 -0400 "James P. Wallen" wrote: > Double checked to see if I was right about the video subsystem. > It is not ATI, it is Intel integrated. No docs on this thing. It > was never officially sold in U.S., where I live currently. Since > I can't boot it to usable state, I can't (easily) find out > exactly which video it uses. > > It's probably destine for re-installation anyway. I was just > surprised to see such a failure occur after upgrade. If the device has worked with other kernel versions before, you could boot from an USB drive, do a chroot and install a kernel that works, this should be a pretty straightforward procedure. Regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. You canna change the laws of physics, Captain; I've got to have thirty minutes!
Re: Stretch System Stops Boot Process Immediately After Grub Screen
Double checked to see if I was right about the video subsystem. It is not ATI, it is Intel integrated. No docs on this thing. It was never officially sold in U.S., where I live currently. Since I can't boot it to usable state, I can't (easily) find out exactly which video it uses. It's probably destine for re-installation anyway. I was just surprised to see such a failure occur after upgrade. On 10/22/2016 06:10 PM, Jape Person wrote: I've got a little Panasonic CF-R3 mini-laptop which has been kept fully up-to-date in testing every day since Etch was released. (I think the original installation is that old.) I've been using the linux-image-686-pae kernel on the system. The updates today included an update to linux-image-4.7.0-1-686-pae (4.7.8-1) and grub-pc (2.02-beta3-1). Upon reboot the system stops with a blinking underline cursor in the upper left corner. I suspect that the boot process stops immediately after grub. I cannot connect via ssh or even ping the system. Using Ctrl-Alt-Del has no effect, but touching the start-stop switch elicits a beep and immediate power-down. The same results are obtained if I use the grub menu to select recovery mode. A much older desktop system running testing and the same kernel was not adversely affected. I'm only reporting this for purposes of corroboration in case anyone else has seen something similar coincident with these updates. I'm in the midst of some business which will prevent me from delving into the failure right now. I'll get into it some time next week, perhaps. I'm planning to make a couple of different live images on USB keys so that I can boot the failed system to examine it and see if there's anything I might just fix on it. There were no error messages during the upgrade. I'm a bit more inclined to suspect the kernel upgrade than the grub-pc upgrade. This little unit has a strange hybrid video subsystem which shares system memory with the video subsystem. Everything on the system is early Intel Centrino era stuff, but with the video being ATI. Maybe it's weird enough that it caught a corner case with the kernel change. But the system has been in the rolling-upgrade mode for years, so something odd may have happened to grub-pc itself. I suppose chroot to the system drive and running update-grub is worth a shot. If anyone has a suggestion, I'm willing to try to learn. As I said, it will be a little while before I have time to actually dig into it. In the off chance I actually learn something, I'll post back to the thread. Thanks, JP
Stretch System Stops Boot Process Immediately After Grub Screen
I've got a little Panasonic CF-R3 mini-laptop which has been kept fully up-to-date in testing every day since Etch was released. (I think the original installation is that old.) I've been using the linux-image-686-pae kernel on the system. The updates today included an update to linux-image-4.7.0-1-686-pae (4.7.8-1) and grub-pc (2.02-beta3-1). Upon reboot the system stops with a blinking underline cursor in the upper left corner. I suspect that the boot process stops immediately after grub. I cannot connect via ssh or even ping the system. Using Ctrl-Alt-Del has no effect, but touching the start-stop switch elicits a beep and immediate power-down. The same results are obtained if I use the grub menu to select recovery mode. A much older desktop system running testing and the same kernel was not adversely affected. I'm only reporting this for purposes of corroboration in case anyone else has seen something similar coincident with these updates. I'm in the midst of some business which will prevent me from delving into the failure right now. I'll get into it some time next week, perhaps. I'm planning to make a couple of different live images on USB keys so that I can boot the failed system to examine it and see if there's anything I might just fix on it. There were no error messages during the upgrade. I'm a bit more inclined to suspect the kernel upgrade than the grub-pc upgrade. This little unit has a strange hybrid video subsystem which shares system memory with the video subsystem. Everything on the system is early Intel Centrino era stuff, but with the video being ATI. Maybe it's weird enough that it caught a corner case with the kernel change. But the system has been in the rolling-upgrade mode for years, so something odd may have happened to grub-pc itself. I suppose chroot to the system drive and running update-grub is worth a shot. If anyone has a suggestion, I'm willing to try to learn. As I said, it will be a little while before I have time to actually dig into it. In the off chance I actually learn something, I'll post back to the thread. Thanks, JP