Re: [gentoo-user] Mysterious silent remount / ro
On Sunday, 17 March 2019 17:15:26 GMT Mick wrote: > On Sunday, 17 March 2019 17:05:58 GMT Grant Taylor wrote: > > On 3/17/19 10:48 AM, Peter Humphrey wrote: > > > My little Atom box has a small rescue system which I boot once a week > > > to back up the main system. The backup script is a simple list of bash > > > commands to mount partitions and tar them to a USB disk. > > > > Please share a copy of the backup script. I've found the problem. I wrote the script many years ago, before cgroups were invented, and more recently my script was unmounting /sys/fs/cgroup/ along with the real partitions. I can't begin to imagine what chaos that would cause, but having squashed the bug I don't see the self-unmounting any more. The script starts with everything but the root filesystem unmounted, then mounts one partition at a time to tar it to a USB disk. The problem was a side-effect of the way I was first unmounting everything (don't ask). Sorry about the noise. It did cause me to look more carefully though. > > > While the backup is running I run another script to clean up after > > > any recent update, which involves removing surplus packages, running > > > eclean etc. > > > > Please share a copy of your cleanup script. > > > > > But! At least once per session I have to remount the root filesystem > > > read- > > > write because something, presumably tar, has caused it to be remounted > > > read- only. > > > > "tar" itself shouldn't alter mounts at all. > > > > It is possible that there could be a mount option that causes the file > > system to be remounted read-only if there is a problem accessing the > > file system. > > > > > Where do I start tracking this down? This behaviour was a factor in > > > my suspecting an SSD failure, but I've replaced that and still get the > > > same remounting. > > > > But such remounting is not likely on a new SSD. > > Yes, it would be unlikely. > > > I'd need to see the scripts to even hazard a guess as to what might be > > happening. > > Also, in your previous thread you mentioned you were about to run memtest to > discard the possibility of a faulty RAM. Did you run it overnight and what > did you get? After fixing my backup script I did run memtest through a few cycles, but it didn't find anything wrong. -- Regards, Peter.
Re: [gentoo-user] [SOLVED] Server fails to boot after update to 4.19.27-r1
On 2019-03-18 08:27, J. Roeleveld wrote: On March 17, 2019 5:04:13 PM UTC, Dan Johansson wrote: On 12.03.19 12:16, J. Roeleveld wrote: On Monday, March 11, 2019 9:31:58 PM CET Dan Johansson wrote: On 11.03.19 20:55, J. Roeleveld wrote: On March 10, 2019 1:24:14 PM UTC, Dan Johansson wrote: After updating a server from kernel-4.14.83 to 4.19.27-r1 (same problem with 4.19.23) the server will not boot. Grub starts fine and I can select the new kernel. The kernel starts booting and after mounting "/" and "/usr" (this is a server with a separate /usr") the boot-process hangs. Here are the last few lines displayed before it hangs: Initializing root device... Detected root: /dev/md127 Mounting /dev/md127 as root... Detected fstype: ext4 Using mount fstype: ext4 Using mount opts: -o ro 7.6104971 EXT4-fs (md127): mounted filesystem with ordered data mode. Opts (null) 7.6572671 init (5708) used greatest stack depth: 13280 bytes left Mounting /dev/dm-O as /usr: mount -t ext4 -o noatime,user_xattr,ro /deu/dm-O /newroot/usr 7.6909561 EXT4-fs (dm-0): INFO: recouery required on readonly filesystem 7.6925551 EXT4-fs (dm-0): write access will be enabled diming recouery 7.9169781 EXT4-fs (dm-0): recovery complete 7.9223701 EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: user_xattr 7.9233051 mount (5722) used greatest stack depth, 13000 bytes left /usr already mounted, skipping... Booting (initramfs) sep-usr init: running user requested applet As I said, the 4.14.83 kernel boots without problem with the same configuration. Any suggestions? I updated my servers last weekend and all moved to 4.19.27, 2 use ZFS for the filesystem, several are VMs on top of Xen. None had any issues. The messages you show make me think they are from an initrd, not the actual kernel. I would investigate that first and make sure your initrd is actually updated as well. Did you copy the text? Or did you manage to grab the output somehow? Also, which init system and initrd are you using? -- Joost The text was copied from a screenshot (IPMI-KVM). I am using sys-apps/openrc with sys-fs/eudev and I use genkernel to build the kernel and the initramfs. Yes, for me it also looks like it has to do with /ginit (busybox) or /sbin/init (sys-apps/sysvinit) and not the kernel. I also have a bunch of other servers which all updated fine to 4.19.?? I tried the suggestion from Hasan to run "make synconfig" but that did not change any option in .config. I'll try to rebuild kernel/init/busybox/intel-microcode again next weekend. Are you booting with the updated initramfs? Or perhaps still with the initramfs belonging to an older kernel? Does the server respond to SSH after a while? It might simply be that the login-prompt is not showing on the correct console. I was able to try a reboot today again, after rebuilding the kernel, busybox, sysvinit & intel-microcode but it still hanged on "sep-usr init: running user requested applet". When the server comes to this point all disk-activities ceases. Even waiting for about 20min did not change anything and the host did not even answer to ping. So, just as a test, I removed "init=/ginit" from the kernel-boot-line and voila - the server booted again without problem :-) So there seems to be some difference on how pre 4.19 kernels and post 4.19 kernels handles separate /usr installs. I am just glad it is solved. Thanks for all suggestions. Regards, Dan -- Dan Johansson *** This message is printed on 100% recycled electrons! *** What is "ginit"? I use 2 types of initramfs. One I created myself which is really simple. The other is created using 'bliss-initramfs'. Neither of these require me to set a special init-boot option. I am guessing the boot fails when it tries to start 'ginit'. /ginit is a init-wrapper gets installed from sys-apps/busybox if you have the use flag "sep-usr" enabled (this was setup years ago so I can not remember the URL to the Gentoo Wiki page describing the setup). This was needed on this host before when I had no initramfs, after changing to an "initramfs-setup" this is no longer needed but it was still working until kernel > 4.19. Regards Dan
[gentoo-user] Big Fat Yellow Warning when emerging/unmerging wine-vanilla.
Does someone know why I get these when emerging or unmerging wine-vanilla (as part of a @world upgrade followed by a depclean): >>> Unmerging (1 of 1) app-emulation/wine-vanilla-4.1... !!! Warning: Skipping wine-staging. No registered targets found. !!! Warning: Skipping wine-d3d9. No registered targets found. !!! Warning: Skipping wine-any. No registered targets found. Something that starts with "!!!" and is printed in bright, yellow letters seems very, very severe. Is something broken?
Re: [gentoo-user] [SOLVED] Server fails to boot after update to 4.19.27-r1
On March 17, 2019 5:04:13 PM UTC, Dan Johansson wrote: >On 12.03.19 12:16, J. Roeleveld wrote: >> On Monday, March 11, 2019 9:31:58 PM CET Dan Johansson wrote: >>> On 11.03.19 20:55, J. Roeleveld wrote: On March 10, 2019 1:24:14 PM UTC, Dan Johansson > wrote: > After updating a server from kernel-4.14.83 to 4.19.27-r1 (same >problem > > with 4.19.23) the server will not boot. > > Grub starts fine and I can select the new kernel. > The kernel starts booting and after mounting "/" and "/usr" (this >is a > server with a separate /usr") the boot-process hangs. > > Here are the last few lines displayed before it hangs: >>> Initializing root device... >>> Detected root: /dev/md127 >>> Mounting /dev/md127 as root... >>> Detected fstype: ext4 >>> Using mount fstype: ext4 >>> Using mount opts: -o ro >>> >7.6104971 EXT4-fs (md127): mounted filesystem with ordered >data > > mode. Opts (null) > >7.6572671 init (5708) used greatest stack depth: 13280 >bytes left >>> >>> Mounting /dev/dm-O as /usr: mount -t ext4 -o >noatime,user_xattr,ro > > /deu/dm-O /newroot/usr > >7.6909561 EXT4-fs (dm-0): INFO: recouery required on >readonly > > filesystem > >7.6925551 EXT4-fs (dm-0): write access will be enabled >diming > > recouery > >7.9169781 EXT4-fs (dm-0): recovery complete >7.9223701 EXT4-fs (dm-0): mounted filesystem with ordered >data > > mode. Opts: user_xattr > > 7.9233051 mount (5722) used greatest stack depth, 13000 >bytes left >>> >>> /usr already mounted, skipping... >>> Booting (initramfs) > > sep-usr init: running user requested applet > > > As I said, the 4.14.83 kernel boots without problem with the same > configuration. > > Any suggestions? I updated my servers last weekend and all moved to 4.19.27, 2 use >ZFS for the filesystem, several are VMs on top of Xen. None had any issues. The messages you show make me think they are from an initrd, not >the actual kernel. I would investigate that first and make sure your >initrd is actually updated as well. Did you copy the text? Or did you >manage to grab the output somehow? Also, which init system and initrd are you using? -- Joost >>> >>> The text was copied from a screenshot (IPMI-KVM). >>> I am using sys-apps/openrc with sys-fs/eudev and I use genkernel to >>> build the kernel and the initramfs. >>> >>> Yes, for me it also looks like it has to do with /ginit (busybox) or >>> /sbin/init (sys-apps/sysvinit) and not the kernel. >>> >>> I also have a bunch of other servers which all updated fine to >4.19.?? >>> >>> I tried the suggestion from Hasan to run "make synconfig" but that >did >>> not change any option in .config. >>> >>> I'll try to rebuild kernel/init/busybox/intel-microcode again next >weekend. >> >> Are you booting with the updated initramfs? Or perhaps still with the >initramfs belonging >> to an older kernel? >> >> Does the server respond to SSH after a while? It might simply be that >the login-prompt is >> not showing on the correct console. > >I was able to try a reboot today again, after rebuilding the kernel, >busybox, sysvinit & intel-microcode but it still hanged on "sep-usr >init: running user requested applet". When the server comes to this >point all disk-activities ceases. Even waiting for about 20min did not >change anything and the host did not even answer to ping. > >So, just as a test, I removed "init=/ginit" from the kernel-boot-line >and voila - the server booted again without problem :-) > >So there seems to be some difference on how pre 4.19 kernels and post >4.19 kernels handles separate /usr installs. > >I am just glad it is solved. >Thanks for all suggestions. > >Regards, >Dan > > > > > >-- >Dan Johansson >*** >This message is printed on 100% recycled electrons! >*** What is "ginit"? I use 2 types of initramfs. One I created myself which is really simple. The other is created using 'bliss-initramfs'. Neither of these require me to set a special init-boot option. I am guessing the boot fails when it tries to start 'ginit'. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
