Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #173749 > unrolled thread

Stretch System Stops Boot Process Immediately After Grub Screen

Back to article view | Back to linux.debian.user

Contents

  Stretch System Stops Boot Process Immediately After Grub Screen Jape Person <japers@comcast.net> - 2016-10-23 00:20 +0200
    Re: Stretch System Stops Boot Process Immediately After Grub Screen "James P. Wallen" <jpwallen@comcast.net> - 2016-10-23 18:40 +0200
      Re: Stretch System Stops Boot Process Immediately After Grub Screen Michael Lange <klappnase@freenet.de> - 2016-10-23 19:10 +0200
        Re: Stretch System Stops Boot Process Immediately After Grub Screen Børge Holen <holen.borge@gmail.com> - 2016-10-23 19:30 +0200
        Re: Stretch System Stops Boot Process Immediately After Grub Screen Børge Holen <holen.borge@gmail.com> - 2016-10-23 19:30 +0200
          Re: Stretch System Stops Boot Process Immediately After Grub Screen Børge Holen <holen.borge@gmail.com> - 2016-10-23 19:30 +0200
          Re: Stretch System Stops Boot Process Immediately After Grub Screen Jape Person <japers@comcast.net> - 2016-10-23 20:20 +0200
        Re: Stretch System Stops Boot Process Immediately After Grub Screen Jape Person <japers@comcast.net> - 2016-10-23 19:50 +0200
      Re: Stretch System Stops Boot Process Immediately After Grub Screen Felix Miata <mrmazda@earthlink.net> - 2016-10-23 19:40 +0200
        Re: Stretch System Stops Boot Process Immediately After Grub Screen Jape Person <japers@comcast.net> - 2016-10-23 20:40 +0200
          Re: Stretch System Stops Boot Process Immediately After Grub Screen Felix Miata <mrmazda@earthlink.net> - 2016-10-23 22:50 +0200
            Re: Stretch System Stops Boot Process Immediately After Grub Screen Jape Person <japers@comcast.net> - 2016-10-23 23:20 +0200
            Re: Stretch System Stops Boot Process Immediately After Grub Screen Frank <zuiderduin@gmx.com> - 2016-10-23 23:30 +0200
              Re: Stretch System Stops Boot Process Immediately After Grub Screen Jape Person <japers@comcast.net> - 2016-10-23 23:40 +0200

#173749 — 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

[toc] | [next] | [standalone]

#173759

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
>
>

[toc] | [prev] | [next] | [standalone]

#173760

On Sun, 23 Oct 2016 12:14:39 -0400
"James P. Wallen" <jpwallen@comcast.net> 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!

[toc] | [prev] | [next] | [standalone]

#173761

[Multipart message — attachments visible in raw view] — view raw

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 <holen.borge@gmail.com> 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 <holen.borge@gmail.com>
> 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 <klappnase@freenet.de>
>> wrote:
>>
>>> On Sun, 23 Oct 2016 12:14:39 -0400
>>> "James P. Wallen" <jpwallen@comcast.net> 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!
>>>
>>>
>>
>

[toc] | [prev] | [next] | [standalone]

#173762

[Multipart message — attachments visible in raw view] — view raw

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 <klappnase@freenet.de> wrote:

> On Sun, 23 Oct 2016 12:14:39 -0400
> "James P. Wallen" <jpwallen@comcast.net> 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!
>
>

[toc] | [prev] | [next] | [standalone]

#173763

[Multipart message — attachments visible in raw view] — view raw

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 <holen.borge@gmail.com> 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 <klappnase@freenet.de>
> wrote:
>
>> On Sun, 23 Oct 2016 12:14:39 -0400
>> "James P. Wallen" <jpwallen@comcast.net> 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!
>>
>>
>

[toc] | [prev] | [next] | [standalone]

#173766

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

[toc] | [prev] | [next] | [standalone]

#173765

On 10/23/2016 01:03 PM, Michael Lange wrote:
> On Sun, 23 Oct 2016 12:14:39 -0400
> "James P. Wallen" <jpwallen@comcast.net> 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

[toc] | [prev] | [next] | [standalone]

#173764

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/

[toc] | [prev] | [next] | [standalone]

#173767

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

[toc] | [prev] | [next] | [standalone]

#173770

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/

[toc] | [prev] | [next] | [standalone]

#173773

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

[toc] | [prev] | [next] | [standalone]

#173775

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

[toc] | [prev] | [next] | [standalone]

#173776

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web