Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
Grant Edwards wrote: > On 2024-04-17, Dale wrote: > >> I still use Nvidia and use nvidia drivers. I to run into problems >> on occasion with drivers and kernels. When you switched from >> Nvidia, what did you switch too? Do you still use drivers you >> install or kernel drivers? > All in-tree kernel drivers for integrated GPUs: > > * Intel UHD Graphics 620 > * Intel HD Graphics 4000 > * Intel Xeon E3-1200 > * AMD Picasso Radeon Vega > > After I had to recycle my second perfectly functional NVidia card > simply because NVidia stopped driver support, I got fed up. I tried > the open-source nvidia drivers for those cards, but could never get > multiple screens to work. > >> How well does the video system work? In other words, plenty fast >> enough for what you do. > They're all fast enough for what I do (no heavy gaming, but I do play > with an RC flight simulator). All will drive at least two digital > monitors. The last machine that had an NVidia card removed is also > the oldest of the machines (Gigabyte Z77X-UD5H Intel i5-3570K w/ HD > 4000 graphics), and it's happily driving three monitors (1 HDMI, 1 > DVI, 1 DP). > > When running the flight-sim, the newest of them (the AMD/Radeon) is > noticeably smoother and runs at higher frame rates than the older Intel > GPUs. I didn't really have any complaints about the older ones, but I > don't expect a real gamer would have been satisfied with the Intel > ones. > >> I don't do any sort of heavy gaming. Since I have a nice game on my >> cell phone now, I play it almost all the time. I can't recall >> playing a game of solitaire on my computer in a long while. My >> biggest thing, two video ports, one for monitor and one for TV. >> Most TV videos aren't very high def but some are 1080P. That's all >> my TV can handle. > They all seem to handle HD video playback just fine. > > How many and what type of monitors can be driven is very much > dependent on the motherboard. > > -- > Grant > > > I've often thought of trying ATI or something but just never did. My video cards tend to age out too because of driver issues. From a cost perspective, I kinda get it. Still, I hate pitching a otherwise working card. Thanks for the info. More stuff to think on. Dale :-) :-)
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
Grant Edwards wrote: > > 2) Lack of support for old hardware when running a newer kernels. > > I used to run into this when running nvidia-drivers. > Gentoo-sources would mark a new kernel stable, but my video board > would not be supported by nvidia-drivers versions that were > supported for that new stable kernel. I would mask newer kernels > until and run older "longterm" kernels as long as I could. I would > evenually be forced to buy a new video card. After going through > that cycle a couple times, I swore off NVidia video cards and > life's been much eaiser since. > I still use Nvidia and use nvidia drivers. I to run into problems on occasion with drivers and kernels. When you switched from Nvidia, what did you switch too? Do you still use drivers you install or kernel drivers? How well does the video system work? In other words, plenty fast enough for what you do. I don't do any sort of heavy gaming. Since I have a nice game on my cell phone now, I play it almost all the time. I can't recall playing a game of solitaire on my computer in a long while. My biggest thing, two video ports, one for monitor and one for TV. Most TV videos aren't very high def but some are 1080P. That's all my TV can handle. Just exploring options. Dale :-) :-)
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
On 17/04/2024 10:10, Michael wrote: I am not sure the assumption "... aging hardware possibly can less and less cope with newer and newer kernels" is correct. As already mentioned newer kernels have both security and bug fixes. As long as you stick with stable gentoo-sources you'll have these in your system. Later kernels also come with additional kernel drivers for new(er) hardware. You may not need/want these drivers if you do not run the latest hardware. Using 'make oldconfig' allows you to exclude such new drivers, but include new security options and/or functionality as desired. Given that I remember the announcement that the linux kernel's memory requirements had increased to 6MB - in the days when Fedora et al demanded gigabytes simply to be able to run - I think almost any ancient hardware you can actually buy will be able to run the linux kernel no probs. You might have difficulty compiling it, though, now 386 support has been pretty much dropped from the toolchain. Have they dropped i686 as well? Cheers, Wol
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
On Wednesday, 17 April 2024 11:37:04 BST Dr Rainer Woitok wrote:
> Grant,
>
> On Tuesday, 2024-04-16 19:26:25 -, you wrote:
> > ...
> > That means that all gentoo-sources stable kernels are "longterm"
> > kernel versions on kernel.org. It does not mean that all "longterm"
> > kernel versions from kernel.org are available as "stable" in
> > gentoo-sources.
> >
> > It is a statement that "gentoo-sources stable" is a subset of
> > "kernel.org longterm".
>
> This sort of deteriorates into a debate about words rather than meanings
> without explaining HOW LONG such a series of related kernels are main-
> tained and provided. After all, "longterm" or "LTS" suggest that these
> lines of developement are less short-lived than others. To give an ex-
> ample: the oldest "longterm" kernels listed on "kernel.org" are 4.19.*,
> 5.4.* and 5.10.*. Of these only 5.10.* is still available from Gentoo.
>
> Digging through my Gentoo installation logs, I can see that 4.19.72 was
> one of the first kernels I built myself. This was somewhen in the mid-
> dle of 2019, that is, not yet five years back. And this kernel line has
> already vanished from Gentoo. So what time span are we talking about
> when we say "LTS Gentoo kernel"? Roughly four, three or two years? And
> why is the support provided by Gentoo significantly shorter than that by
> "kernel.org"?
>
> Sincerely,
> Rainer
LTS kernels were being supported for ~6 years, although the projected EOL I
see here indicates later LTS releases may not be supported for as long:
https://www.kernel.org/category/releases.html
The stable gentoo-sources are tree cleaned more frequently, so the oldest
stable release for amd64 in portage is now 5.10.212:
$ eix gentoo-sources
[I] sys-kernel/gentoo-sources
Available versions:
(5.10.208) *5.10.208^bs
(5.10.212) 5.10.212^bs
(5.10.213) ~5.10.213^bs
(5.10.214) ~5.10.214^bs
(5.10.215) ~5.10.215^bs
(5.15.147) *5.15.147^bs
(5.15.151) 5.15.151^bs
(5.15.152) ~5.15.152^bs
(5.15.153) ~5.15.153^bs
(5.15.154) ~5.15.154^bs
(5.15.155) ~5.15.155^bs
(6.1.74) *6.1.74^bs
(6.1.81) 6.1.81^bs
(6.1.83) ~6.1.83^bs
(6.1.84) ~6.1.84^bs
(6.1.85) ~6.1.85^bs
(6.1.86) ~6.1.86^bs
(6.6.13) *6.6.13^bs
(6.6.21) 6.6.21^bs
(6.6.24) ~6.6.24^bs
(6.6.25) ~6.6.25^bs
(6.6.26) ~6.6.26^bs
(6.6.26-r1) ~6.6.26-r1^bs
(6.6.27) ~6.6.27^bs
(6.8.3) ~6.8.3^bs
(6.8.4) ~6.8.4^bs
(6.8.5) ~6.8.5^bs
(6.8.5-r1) ~6.8.5-r1^bs
(6.8.6) ~6.8.6^bs
{build experimental symlink}
Installed versions: 6.6.21(6.6.21)^bs(03:21:20 24/03/24)(-build -
experimental -symlink)
Homepage:https://dev.gentoo.org/~mpagano/genpatches
Description: Full sources including the Gentoo patchset for the
6.8 kernel tree
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
On Tuesday, 16 April 2024 20:26:25 BST Grant Edwards wrote: > On 2024-04-16, Dr Rainer Woitok wrote: > > Arve, > > > > On Tuesday, 2024-04-16 15:53:48 +0200, you wrote: > >> ... > >> Only LTS kernels get stabilised, so this information is readily > >> available. > > > > I'm sure I don't understand this: According to "https://www.kernel.org/; > > kernel 6.6.27 is "longterm", but according to "eix" the most recent > > 6.6.* kernels are 6.6.22 and 6.6.23 which both are non-stable (well, I > > ran my last "sync" immediately before the profile upgrade, so this might > > not be current). I'm still using stable kernel 6.6.13 as my backup ker- > > nel, but this kernel is no longer provided by Gentoo. So, what precise- > > ly does LTS or "longterm" mean? LTS stands for Long Term Support and it means the kernel maintainers will continue to backport bug fixes and security patches into the LTS kernels from the Mainline tree, as they progress in their development of the kernel code. When they do this backporting they bump the LTS kernel version, e.g. from 6.6.24 to 6.6.25. They will not go into this prolonged maintenance effort with the kernel's 'Stable' tree, which has a higher churn as it acquires the Mainline kernels as soon as the latter are signed for release. > That means that all gentoo-sources stable kernels are "longterm" > kernel versions on kernel.org. It does not mean that all "longterm" > kernel versions from kernel.org are available as "stable" in > gentoo-sources. > > It is a statement that "gentoo-sources stable" is a subset of > "kernel.org longterm". > > It is not a statement that the two sets are identical. > > In other words: > >"ONLY LTS kernels get stabilized." > > is a different statement from > >"ALL LTS kernels get stabilized." > > The former is true. The latter is not. Yes, precisely. This happens because Gentoo acquire the latest LTS kernel, apply various Gentoo related patches, test and eventually mark as stable the corresponding version of the gentoo-sources in portage. This process incurs some inevitable delay compared with the LTS kernel tree releases, but nevertheless the stable gentoo-sources follow the LTS releases. > > But, to get back to the beginning of this discussion: if there is a > > risk that my aging hardware possibly can less and less cope with > > newer and newer kernels, should I put something like > > > >>=sys-kernel/gentoo-sources-6.7.0 > > > > into file "package.mask" to stay with "longterm" 6.6.* kernels? > > Yes: if you want to avoid getting upgraded to 6.8 when it gets > kernel.org "longterm" status and gentoo-sources "stable" status, then > a statement like that in in package.mask will keep you on > gentoo-sources 6.6 kernels (which are "longterm" on kernel.org). > > Again: not all longterm 6.6.x kernel versions get marked as "stable" > for gentoo-sources. If you have not enabled the testing keyword for > gentoo-sources, then you'll only get the 6.6.x kernel versions that > the gentoo-sources maintainers have declared as "stable". > > -- > Grant I am not sure the assumption "... aging hardware possibly can less and less cope with newer and newer kernels" is correct. As already mentioned newer kernels have both security and bug fixes. As long as you stick with stable gentoo-sources you'll have these in your system. Later kernels also come with additional kernel drivers for new(er) hardware. You may not need/want these drivers if you do not run the latest hardware. Using 'make oldconfig' allows you to exclude such new drivers, but include new security options and/or functionality as desired. It can happen for new code to introduce some software regression. However, this is not limited to old hardware. If there is no workaround, or some patch you can apply manually to your kernel from a later release, then by all means you can mask later minor LTS releases *for a little while only* and keep an eye open for the latest releases which could have addressed the bug you suffered from. PS. Regarding your earlier question about different make *config commands and their meaning you can check the latest make help page: $ cd /usr/src/linux $ make help Then take a look at the section "Configuration targets". signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
Grant Edwards wrote: > On 2024-04-16, Arve Barsnes wrote: >> On Tue, 16 Apr 2024 at 15:29, Dr Rainer Woitok >> wrote: My understanding is the gentoo-sources kernels are aligned with the LTS upstream releases. >>> Right, they use the same version numbers. But you can't see from just >>> looking at the available "gentoo-sources" which one is LTS and which one >>> is not. You have to consult "https://www.kernel.org/; to get this in- >>> formation. >> Only LTS kernels get stabilised, so this information is readily available. > "Stablized" as in the corresponding gentoo-sources ebuild is marked as > stable. [Not to be confused with Linux "stable" kernels -- not all of > which end up with LTS status.] > > Getnoo-sources also includes "stable" but not "LTS" Linux kernels, but > the gentoo-sources ebuild for those is always "testing". > > IOW, if you install gentoo-sources, and don't keyword it to allow > "testing" ebuilds, then you won't get anything other than LTS kernel > sources. That's some helpful info. That helps me too. Dale :-) :-)
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
Arve Barsnes wrote: > On Tue, 16 Apr 2024 at 15:29, Dr Rainer Woitok > wrote: >>> My understanding is the gentoo-sources kernels are aligned with the LTS >>> upstream releases. >> Right, they use the same version numbers. But you can't see from just >> looking at the available "gentoo-sources" which one is LTS and which one >> is not. You have to consult "https://www.kernel.org/; to get this in- >> formation. > Only LTS kernels get stabilised, so this information is readily available. > > Regards, > Arve I've never understood what is supported long term either. I use gentoo-sources. I've never figured out just how to pick a kernel that is supposed to be stable for the larger version. In other words, only security and bug fixes, no new hardware. Right now, 6.8.5 is the highest version in the tree here but there are more versions of it to come. So, I tend to go back to 6.7.X and pick the highest version of that. The first two digits used to mean something but I think that changed a long time ago. I try to avoid the absolute latest because my video drivers tend to lag behind a little. They won't emerge for anything very new sometimes. That's why I go back a little as described above. Thing is, I have no idea if that is the right way or if it really even matters if I pick 6.8.1 over 6.7.12 or vice versa. I wish they were clearly marked somehow myself. Something in the name that shows it is stable. Given I rarely have problems with kernels, maybe none of this matters. Thing is, I plan to build a new rig soon. Might help then. Maybe. Dale :-) :-)
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
On 4/16/24 7:15 AM, Michael wrote: On Tuesday, 16 April 2024 11:55:20 BST Dale wrote: If you update often, it shouldn't take long answer the questions. If you do like me and don't update often, it may take longer but no more time than it would if you updated often and added all the time together. As far as I know, if one manually updates their kernel, make oldconfig is the safest and recommended method. You are prompted for new drivers/options and can see if they apply to you or not. If you don't want to update that way, I think there is a kernel that does it's own thing. I think it is sort of like boot media uses. If the time needed to answer all the questions isn't there, that may be a option to look into. It's called genkernel. I've never used it but read it works. The sys-kernel/genkernel package will automatically build & install your kernel and initramfs in /boot, but it will NOT prepare a kernel configuration tuned to your hardware and desired options. It uses a generic default configuration safe for most circumstances. The user can tweak the default configuration to suit their needs and genkernel will use that. I manually run make xconfig (after running make olddefconfig) and have genkernel set to not use it's default config, sticking to the .config in the kernel tree (/usr/src/linux.) That's been working fine for me for many years.
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
On Tue, 16 Apr 2024 at 15:29, Dr Rainer Woitok wrote: > > My understanding is the gentoo-sources kernels are aligned with the LTS > > upstream releases. > > Right, they use the same version numbers. But you can't see from just > looking at the available "gentoo-sources" which one is LTS and which one > is not. You have to consult "https://www.kernel.org/; to get this in- > formation. Only LTS kernels get stabilised, so this information is readily available. Regards, Arve
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
Michael wrote: > On Tuesday, 16 April 2024 11:55:20 BST Dale wrote: > >> If you update often, it shouldn't take long answer the questions. If >> you do like me and don't update often, it may take longer but no more >> time than it would if you updated often and added all the time >> together. As far as I know, if one manually updates their kernel, make >> oldconfig is the safest and recommended method. You are prompted for >> new drivers/options and can see if they apply to you or not. If you >> don't want to update that way, I think there is a kernel that does it's >> own thing. I think it is sort of like boot media uses. If the time >> needed to answer all the questions isn't there, that may be a option to >> look into. It's called genkernel. I've never used it but read it works. > The sys-kernel/genkernel package will automatically build & install your > kernel and initramfs in /boot, but it will NOT prepare a kernel configuration > tuned to your hardware and desired options. It uses a generic default > configuration safe for most circumstances. The user can tweak the default > configuration to suit their needs and genkernel will use that. > > For quick(er) and automated kernel update and installation there are the > gentoo *distribution kernels*: > > https://wiki.gentoo.org/wiki/Project:Distribution_Kernel > > > I thought genkernel was the one. Looking at your link, that would be a option more closely to what I thought genkernel was. So, genkernel requires more effort than I thought and distribution kernel is the more "automatic" way. Now to remember that. :/ I still like my old way. It works. It's rare that it fails. It's been years since I couldn't boot up due to a bad kernel. Still good to have options tho. Not everyone is like me. Thank goodness for that. ROFL Dale :-) :-)
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
On Tuesday, 16 April 2024 11:55:20 BST Dale wrote: > If you update often, it shouldn't take long answer the questions. If > you do like me and don't update often, it may take longer but no more > time than it would if you updated often and added all the time > together. As far as I know, if one manually updates their kernel, make > oldconfig is the safest and recommended method. You are prompted for > new drivers/options and can see if they apply to you or not. If you > don't want to update that way, I think there is a kernel that does it's > own thing. I think it is sort of like boot media uses. If the time > needed to answer all the questions isn't there, that may be a option to > look into. It's called genkernel. I've never used it but read it works. The sys-kernel/genkernel package will automatically build & install your kernel and initramfs in /boot, but it will NOT prepare a kernel configuration tuned to your hardware and desired options. It uses a generic default configuration safe for most circumstances. The user can tweak the default configuration to suit their needs and genkernel will use that. For quick(er) and automated kernel update and installation there are the gentoo *distribution kernels*: https://wiki.gentoo.org/wiki/Project:Distribution_Kernel > In short, make oldconfig is the recommended way as far as I know. In my > opinion, it is the safest way to know what you are going to get. Links > for more info. > > https://wiki.gentoo.org/wiki/Kernel/Upgrade > > https://wiki.gentoo.org/wiki/Kernel/Configuration > > Someone else may have a different opinion, even a better one. This is > how I always do it and kernel failure is rare. Hope it helps. > > Dale > > :-) :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
Dr Rainer Woitok wrote: > Michael, > > On Monday, 2024-04-15 12:48:34 +0100, you wrote: > >> ... >> Why have you set your /boot to be mounted at boot? > Well, I think, I then just followed the Gentoo Handbook. But I see your > point of saving time which could be better used to successfully unmount > the "/home/" partition. I'll change my "/etc/fstab" file as well as a > few of my scripts. Thanks for pointing that out :-) > >> ... >> MoBo firmware can be notoriously buggy and is >> typically frozen/abandoned within a couple of years by the OEMs. In >> addition, >> kernel code changes and any previous symbiosis with the firmware can fall >> apart with a later kernel release. > Hm, this sounds a bit like "never change your running kernel", doesn't > it? But this brings up two related questions: > > 1. Why does Gentoo not somehow mark LTS kernels either in the version >number or in the slot name? This would make it easier to prevent the >installation of too modern kernels. > > 2. I'm building new kernels with "make olddefconfig" rather than "make >oldconfig" because I thought providing default values to new configu- >ration variables is a good idea. But what precisely does "make old- >config" do with new configuration variables instead? Just leaving >them out? But what's the difference between not defining a configu- >ration variable and setting it to a default value? Or is "make old- >config" really the way to generate more conservative kernels which do >not as quickly overburden aging motherboards? > > Sincerely, > Rainer I rarely update my kernel given I don't reboot much. I am working on that tho. I've updated my kernel three times recently but never rebooted to use any of them. If power fails and I have to reboot, they are there at least. All of us should update when we can. I been using Gentoo since around 2003. I started out making my kernel from scratch and updating the manual way. I also install the manual way with my own naming scheme, just close enough for dracut and grub to recognize them. I've always used make oldconfig and for most of the driver questions, I answer no. Given I start with a kernel config that already contains everything I need, it is rare that I need anything new. So, I rarely need any of the new drivers. You are likely the same. I think there is a option for it to default to no or yes for all the questions automatically but not all questions are yes or no and sometimes you may need a yes. To me, it's best to use make oldconfig and answer each question. That way you can catch something you can use but you also catch those questions that need a numbered option, 1, 2, 3, 4 or something. If you update often, it shouldn't take long answer the questions. If you do like me and don't update often, it may take longer but no more time than it would if you updated often and added all the time together. As far as I know, if one manually updates their kernel, make oldconfig is the safest and recommended method. You are prompted for new drivers/options and can see if they apply to you or not. If you don't want to update that way, I think there is a kernel that does it's own thing. I think it is sort of like boot media uses. If the time needed to answer all the questions isn't there, that may be a option to look into. It's called genkernel. I've never used it but read it works. In short, make oldconfig is the recommended way as far as I know. In my opinion, it is the safest way to know what you are going to get. Links for more info. https://wiki.gentoo.org/wiki/Kernel/Upgrade https://wiki.gentoo.org/wiki/Kernel/Configuration Someone else may have a different opinion, even a better one. This is how I always do it and kernel failure is rare. Hope it helps. Dale :-) :-)
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
On Tuesday, 16 April 2024 10:04:43 BST Dr Rainer Woitok wrote: > Michael, > > On Monday, 2024-04-15 12:48:34 +0100, you wrote: > > ... > > Why have you set your /boot to be mounted at boot? > > Well, I think, I then just followed the Gentoo Handbook. But I see your > point of saving time which could be better used to successfully unmount > the "/home/" partition. I'll change my "/etc/fstab" file as well as a > few of my scripts. Thanks for pointing that out :-) > > > ... > > > > MoBo firmware can be notoriously buggy and is > > > > typically frozen/abandoned within a couple of years by the OEMs. In > > addition, kernel code changes and any previous symbiosis with the > > firmware can fall apart with a later kernel release. > > Hm, this sounds a bit like "never change your running kernel", doesn't > it? Not really, because a newer kernel has any security patches, plus it can include bug fixes. You won't know if a later release fixes or breaks something on your system until you tried it. > But this brings up two related questions: > > 1. Why does Gentoo not somehow mark LTS kernels either in the version >number or in the slot name? This would make it easier to prevent the >installation of too modern kernels. My understanding is the gentoo-sources kernels are aligned with the LTS upstream releases. > 2. I'm building new kernels with "make olddefconfig" rather than "make >oldconfig" because I thought providing default values to new configu- >ration variables is a good idea. It is a good idea if the new config items are something you need/want on your system and in addition if the default setting suits your needs. >But what precisely does "make old- >config" do with new configuration variables instead? Just leaving >them out? But what's the difference between not defining a configu- >ration variable and setting it to a default value? Or is "make old- >config" really the way to generate more conservative kernels which do >not as quickly overburden aging motherboards? The make oldconfig script will identify new config items not present in your old kernel config, show which is the default option and ask you to interactively select which one you prefer; e.g. SPECULATION_MITIGATIONS [Y/n/m/?] (NEW) The default option above has been identified as Y, if the devs have determined this is a safe default for the arch. You can hit Enter to select Y, or type 'n' for no, 'm' for module, or '?' to read the extended description and help for this option before you make up your mind. With make olddefconfig the option 'Y' will be automatically selected without asking your input. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
On Sunday, 14 April 2024 19:41:41 BST Dr Rainer Woitok wrote:
> Greetings,
>
> On Friday, 2024-01-05 18:46:09 +0100, I myself wrote:
> > ...
> > since a few month or so off and on my laptop fails to resume from hiber-
> > nation due to the "dirty bit" being set on the ext4 "/home" partition.
>
> I was reading this flickering by on the screen, and it wasn't quite cor-
> rect. Meanwhile I found this in my "openrc.log":
>
>fsck.fat 4.2 (2021-01-31)
>There are differences between boot sector and its backup.
>This is mostly harmless. Differences: (offset:original/backup)
> 65:01/00
> Not automatically fixing this.
>Dirty bit is set. Fs was not properly unmounted and some data may be
> corrupt. Automatically removing dirty bit.
>*** Filesystem was changed ***
>Writing changes.
>/dev/sda1: 368 files, 116600/258078 clusters
Why have you set your /boot to be mounted at boot?
You can run 'fsck.fat -v /dev/sda1' after you unmount it to remove the dirty
bit (if not already removed) and then change your fstab to 'noauto'. Just
remember to remount /boot before you make any changes to your boot manager/
kernels.
>/dev/sdb1: recovering journal
>/dev/sdb1: Clearing orphaned inode 54789026 (uid=1000, gid=1000,
> mode=0100600, size=32768) /dev/sdb1: Clearing orphaned inode 54788311
> (uid=1000, gid=1000, mode=0100600, size=553900) /dev/sdb1: clean,
> 172662/61054976 files, 36598898/244190385 blocks * Filesystems repaired
>
> So one cause always is some problem on disk "/dev/sda1/" ("/boot/") and
> another cause are one or more orphaned inodes on disk "/dev/sdb1/"
> ("/home/"). But while the values of offset, original and backup for
> "/dev/sda1/" are always the same when this happens, the number of or-
> phaned inodes on "/dev/sdb1/" and the inodes itself change from occur-
> rence to occurrence. Besides it only happens sporadically when resuming
> from hibernation, not every time. More precisely, the problem surfaces
> when resuming from hibernation but could as well be caused during the
> hibernation process itself.
>
> Does this ring some bell somewhere what could cause this?
>
> Sincerely,
> Rainer
Unlike the /boot partition, the /home partition has data written to it
regularly. The ext4 fs does not perform atomic writes - it is not a CoW fs.
Therefore a sudden unsync'ed shutdown could leave it in a state of corruption
- IF for some reason data in memory is not either fully written to disk or
retained in memory. The way ACPI interacts with firmware *should* ensure the
S3 system state does not suspend I/O operations halfway through an inline
write operation ... but ... MoBo firmware can be notoriously buggy and is
typically frozen/abandoned within a couple of years by the OEMs. In addition,
kernel code changes and any previous symbiosis with the firmware can fall
apart with a later kernel release.
On one PC of mine, with the same MoBo/CPU and the same version firmware, I
have over the years experienced a whole repertoire of random problems resuming
from suspend. At this point in time I avoid placing this PC in sleep, because
it always crashes with a Firefox related segfault, some time after waking up.
Check if the situation with /dev/sdb1 improves when you leave your /boot
unmounted. This may make more process time available for the system to finish
I/O operations, which may then allow /dev/sdb1 to suspend cleanly.
signature.asc
Description: This is a digitally signed message part.
