[gentoo-user] Re: Upgrading from 5.14 to 6.0 version
On 2022-11-14, Michael wrote: > Shutting down your desktop applications and rebooting with a new > kernel takes no longer than a couple of minutes. On my systems it typically takes about 15-20 seconds. I try to reboot at least once a month when I have some spare time -- just to make sure I can. What I don't want to happen is that some mishandled upgrade has broken my system so that it won't boot properly, but I don't know about until months later when I'm in the middle of something urgent and the power glitches. Then I spend several hours I don't have trying to figure out what's wrong. [Been there, done that, it's _not_ fun.] If you wait years between reboots, and it doesn't go well when you do have to reboot, there are usually a lot of possible causes. The same applies to X11: I like to restart it every week or so just to make sure nothing's been broken by recent upgrades. It's a _lot_ easier to find/fix a problem when the upgrade that caused it is recent (and there's only the one problem). If you wait long enough, you end up with multiple problems that sometimes aggravate each other. -- Grant
Re: [gentoo-user] Re: Upgrading from 5.14 to 6.0 version
Michael wrote: > On Monday, 14 November 2022 21:05:57 GMT Dale wrote: > >> Thing is, I may go a year, sometimes more, without updating the kernel. >> If I rebooted often, I could see using a LTS kernel. If a kernel can >> run for months with no problems, it's stable enough for me. Plus my >> hardware works. > Keeping the same kernel running for long periods can leave you exposed to > security vulnerabilities. Either stable or LTS kernels will be similarly > exposed, if their latest backported versions are not booted with. I > appreciate you're not running a public server so your profile is not as much > at risk, but bad code in some application which hasn't been patched up could > still leave you exposed. > > >> I have even built a kernel but never actually booted it. By the time I >> get around to rebooting, I've had to build another kernel. I generally >> always work from a known stable config tho. The only reason I wouldn't >> is if I build a new system and have to start from scratch. I've also >> had times when I had to update because my video drivers wouldn't build >> with a older kernel version that I'm running. That doesn't happen to >> often but I recall running into that at least once. > Shutting down your desktop applications and rebooting with a new kernel takes > no longer than a couple of minutes. I mean even busy bank customer web > portals have planned downtime. > That may be true. I used to not mind rebooting as much but since I started having to use the init thingy, I only do it when really necessary. Those init thingys have left a long term bad taste in my mouth. If I could, I'd likely never reboot. Thing is, sometimes I have a power outage and just have too. The other thing, my computer is my entertainment system as well. My TV runs close to 24/7. I may pause a video if I'm outside or something but other than that, it is playing something about all the time. I do go to town each Thursday morning to get my shots and pick up groceries. Because of my lengthy time between trips anywhere, I put a trickle charger on my car. Sitting for a week wasn't doing the battery any good. Another reason my system runs even if I'm not home, downloading of files. I'm almost always downloading something. It's how I entertain myself after all. ;-) Basically, this system is busy doing things, multiple things, almost all the time. >> Either way, biggest question was if there was some known breakage >> between my old version and a newer version. Maybe the one I tried just >> had some weird problem that only affected me or I just missed something >> during the oldconfig. I wish I could recall the error. Who knows on >> that. >> >> Thanks. >> >> Dale >> >> :-) :-) > Did you diff your current good kernel .config and the new failed to boot > kernel .config, to find out what options/modules have changed. Besides any > booting errors, this could point you to something which was missed in the new > kernel, or perhaps shouldn't have been configured. That's how I go about > finding the cause of a non-booting kernel in the rare occasions I end up with > a lemon. I tried to boot with new kernel, saw the error, rebooted into a older kernel and carried on. That was several months ago so no clue what the error was. Dale :-) :-)
Re: [gentoo-user] Re: Upgrading from 5.14 to 6.0 version
On 14/11/2022 21:44, Michael wrote: Shutting down your desktop applications and rebooting with a new kernel takes no longer than a couple of minutes. I mean even busy bank customer web portals have planned downtime. There's a lot more to it than that ... The reason I don't run new kernels all the time, is that finding the time to actually copy the old config, make, make modules, make install, fix grub, sort out problems, reboot, is actually quite hard. It's not just a few minutes ... Cheers, Wol
Re: [gentoo-user] Re: Upgrading from 5.14 to 6.0 version
On Monday, 14 November 2022 21:05:57 GMT Dale wrote: > Thing is, I may go a year, sometimes more, without updating the kernel. > If I rebooted often, I could see using a LTS kernel. If a kernel can > run for months with no problems, it's stable enough for me. Plus my > hardware works. Keeping the same kernel running for long periods can leave you exposed to security vulnerabilities. Either stable or LTS kernels will be similarly exposed, if their latest backported versions are not booted with. I appreciate you're not running a public server so your profile is not as much at risk, but bad code in some application which hasn't been patched up could still leave you exposed. > I have even built a kernel but never actually booted it. By the time I > get around to rebooting, I've had to build another kernel. I generally > always work from a known stable config tho. The only reason I wouldn't > is if I build a new system and have to start from scratch. I've also > had times when I had to update because my video drivers wouldn't build > with a older kernel version that I'm running. That doesn't happen to > often but I recall running into that at least once. Shutting down your desktop applications and rebooting with a new kernel takes no longer than a couple of minutes. I mean even busy bank customer web portals have planned downtime. > Either way, biggest question was if there was some known breakage > between my old version and a newer version. Maybe the one I tried just > had some weird problem that only affected me or I just missed something > during the oldconfig. I wish I could recall the error. Who knows on > that. > > Thanks. > > Dale > > :-) :-) Did you diff your current good kernel .config and the new failed to boot kernel .config, to find out what options/modules have changed. Besides any booting errors, this could point you to something which was missed in the new kernel, or perhaps shouldn't have been configured. That's how I go about finding the cause of a non-booting kernel in the rare occasions I end up with a lemon. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Upgrading from 5.14 to 6.0 version
On Mon, Nov 14, 2022 at 2:06 PM Dale wrote: > > Nikos Chantziaras wrote: > > On 12/11/2022 23:37, Dale wrote: > >> Usually, I try to update about once a year. I don't change hardware > >> much. > > > > The main reason I suggested LTS is because that, *when* you decide to > > do a @world update, you will get the latest LTS of the same main > > version you're already using. For example you'll go from 5.15.20 to > > 5.15.78. And that means you won't have to bother with an array of > > endless "make oldconfig" questions. There'll be like one or two at > > most, which is trivial to deal with. > > > > I've been using LTS kernels for years now, and I never looked back. > > "make oldconfig" usually doesn't say anything, making it a > > ridiculously fast and no-brainer update, and yet I get the latest > > bugfixes and security fixes. > > > > It just works :-) > > > > > > > > > Thing is, I may go a year, sometimes more, without updating the kernel. > If I rebooted often, I could see using a LTS kernel. If a kernel can > run for months with no problems, it's stable enough for me. Plus my > hardware works. > > I have even built a kernel but never actually booted it. By the time I > get around to rebooting, I've had to build another kernel. I generally > always work from a known stable config tho. The only reason I wouldn't > is if I build a new system and have to start from scratch. I've also > had times when I had to update because my video drivers wouldn't build > with a older kernel version that I'm running. That doesn't happen to > often but I recall running into that at least once. > > Either way, biggest question was if there was some known breakage > between my old version and a newer version. Maybe the one I tried just > had some weird problem that only affected me or I just missed something > during the oldconfig. I wish I could recall the error. Who knows on > that. > > Thanks. > > Dale > > :-) :-) > > Dale, While I completely understand your 'reboot once a year' POV, I think you might *possibly* be missing the point Nikos and others are making. If you are on 5.14.XX you aren't currently using a LTS kernel. The LTS kernels would be the 5.10 and 5.15 series, according to kernel.org. If you don't CARE what kernel you are running then why not build 5.15.78 which is currently the most recent LTS kernel. If there are updates to that series for bug & security fixes then once you have built 5.15.78 (WHETHER YOU RUN IT OR NOT) then further updates to that series won't be a big deal and probably don't even require much of a config change or a tool chain change. It WILL be easy. You would move forward going from 5.14.15 to 5.15.78. If you don't NEED something in 6.0.5 or 6.0.8 then why bother? Once you have 5.15.78 built and installed it's there if you reboot. If you don't reboot then you'll go on building 5.15 kernels until some newer LTS kernel is named. It is truly an easy way to manage the kernel part of running Linux. Good luck, Mark
Re: [gentoo-user] Re: Upgrading from 5.14 to 6.0 version
Nikos Chantziaras wrote: > On 12/11/2022 23:37, Dale wrote: >> Usually, I try to update about once a year. I don't change hardware >> much. > > The main reason I suggested LTS is because that, *when* you decide to > do a @world update, you will get the latest LTS of the same main > version you're already using. For example you'll go from 5.15.20 to > 5.15.78. And that means you won't have to bother with an array of > endless "make oldconfig" questions. There'll be like one or two at > most, which is trivial to deal with. > > I've been using LTS kernels for years now, and I never looked back. > "make oldconfig" usually doesn't say anything, making it a > ridiculously fast and no-brainer update, and yet I get the latest > bugfixes and security fixes. > > It just works :-) > > > Thing is, I may go a year, sometimes more, without updating the kernel. If I rebooted often, I could see using a LTS kernel. If a kernel can run for months with no problems, it's stable enough for me. Plus my hardware works. I have even built a kernel but never actually booted it. By the time I get around to rebooting, I've had to build another kernel. I generally always work from a known stable config tho. The only reason I wouldn't is if I build a new system and have to start from scratch. I've also had times when I had to update because my video drivers wouldn't build with a older kernel version that I'm running. That doesn't happen to often but I recall running into that at least once. Either way, biggest question was if there was some known breakage between my old version and a newer version. Maybe the one I tried just had some weird problem that only affected me or I just missed something during the oldconfig. I wish I could recall the error. Who knows on that. Thanks. Dale :-) :-)
[gentoo-user] Re: Upgrading from 5.14 to 6.0 version
On 12/11/2022 23:37, Dale wrote: Usually, I try to update about once a year. I don't change hardware much. The main reason I suggested LTS is because that, *when* you decide to do a @world update, you will get the latest LTS of the same main version you're already using. For example you'll go from 5.15.20 to 5.15.78. And that means you won't have to bother with an array of endless "make oldconfig" questions. There'll be like one or two at most, which is trivial to deal with. I've been using LTS kernels for years now, and I never looked back. "make oldconfig" usually doesn't say anything, making it a ridiculously fast and no-brainer update, and yet I get the latest bugfixes and security fixes. It just works :-)
RE: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file?
> > > -Original Message- > From: Grant Edwards > Sent: Saturday, November 12, 2022 7:55 PM > To: gentoo-user@lists.gentoo.org > Subject: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file? > > On 2022-11-12, Michael wrote: > > > Have your questions been answered satisfactorily by Lawrence's contribution? > > Yes, Lawrence's experiment answered the my question: e2fsck adds the bad > block to the "bad block" inode and leaves it also allocated to the existing > file. > > Presumably if you don't allow it to clone the block, reading that file will > return an error when it gets to the bad block. Once you delete that file, the > bad block will never get reallocated by the filesystem since it still belongs > to the bad block inode. > > The failing SSD that prompted the question has now been replaced and a fresh > Gentoo system installed on the new drive. I never did figure out which files > contained the bad blocks (there were 37 bad blocks, IIRC). They apparently > didn't belong to any of the files I copied over to the replacement drive. > > The old drive was a Samsung 850 EVO SATA drive, and the new one is a Samsung > 980 PRO M.2 drive. The new one is noticably faster than the old one (which in > turn was way faster than the spinning platter drive it had replaced). > > -- > Grant Multiply-allocated blocks won't cause an error by themselves. They can just cause strange and unexpected munging of your data if two files are scribbling on the same patch of disk. So if you leave it allocated to both then you can use a more intelligent tool to either coax one more read out of it or potentially replace the lost data with some substitute. I'm not sure what fsck will do with a read error while cloning the block since my test "disk" wasn't actually bad. Presumably fill the bad section with nulls. LMP
