Re: unexpected kernel reboot (3)
On Mon, 2018-07-16 at 12:09 +0200, Dmitry Vyukov wrote: > On Fri, Jul 13, 2018 at 11:58 PM, Andrew Morton > wrote: > > On Fri, 13 Jul 2018 14:39:02 -0700 syzbot < > > syzbot+cce9ef2dd25246f81...@syzkaller.appspotmail.com> wrote: > > > > > Hello, > > > > > > syzbot found the following crash on: > > > > hm, I don't think I've seen an "unexpected reboot" report before. > > > > Can you expand on specifically what happened here? Did the machine > > simply magically reboot itself? Or did an external monitor whack it, > > or... > > We put some user-space workload (not involving reboot syscall), and > the machine suddenly rebooted. We don't know what triggered the > reboot, we only see the consequences. We've seen few such bugs before, > e.g.: > https://syzkaller.appspot.com/bug?id=4f1db8b5e7dfcca55e20931aec0ee707c5cafc99 > Usually it involves KVM. Potentially it's a bug in the outer > kernel/VMM, it may or may not be present in tip kernel. I have been using GCE with my custom VirtualBox -created reiser4 root fs VMs since at least 2018, long term mainly as web servers with LAMP / LEMP -- including some Ruby apps with Postgresql -- and short term to build our Debian Linux kernels. I have not experienced 'suddenly rebooted' scenarios. Note that I have been usin Intel CPUs at the Los Angeles zone us-west2-a, as well as us-east1-b zone, and AMD Epyc CPUs at us-central1-a zone, without abnormalities (other than it's becoming more expensive ;-) As a matter of fact, I am currently testing a Debian'ized reiser4 (AMD Epyc - flavored reizer4 label) -enabled Linux kernel 5.10.15-2 which has logged 17 days +hours already and sustaining most of the apps already mentioned. < https://metztli.it/buster/r4-5.10.15-gce.png > > > > > Does this test distinguish from a kernel which simply locks up? > > Yes. If you look at the log: > > https://syzkaller.appspot.com/x/log.txt?x=17c6a6d040 > > We've booted the machine, started running a program, and them boom! it > reboots without any other diagnostics. It's not a hang. > > > > > > HEAD commit: 1e4b044d2251 Linux 4.18-rc4 > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=17c6a6d040 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=cce9ef2dd25246f815ee > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=165012c240 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1571462c40 > > > > I assume the "C reproducer" is irrelevant here. > > > > Is it reproducible? > > Yes, it is reproducible and the C reproducer is relevant. > If syzbot provides a reproducer, it means that it booted a clean > machine, run the provided program (nothing else besides typical init > code and ssh/scp invocation) and that's the kernel output it observed > running this exact program. > However in this case, the exact setup can be relevant. syzbot uses GCE > VMs, it may or may not reproduce with other VMMs/physical hardware, > sometimes such bugs depend on exact CPU type. > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+cce9ef2dd25246f81...@syzkaller.appspotmail.com > > > > > > output_len: 0x092459b0 > > > kernel_total_size: 0x0a505000 > > > trampoline_32bit: 0x0009d000 > > > > > > Decompressing Linux... Parsing ELF... done. > > > Booting the kernel. > > > [ 0.00] Linux version 4.18.0-rc4+ (syzkaller@ci) (gcc version 8.0.1 > > > 20180413 (experimental) (GCC)) #138 SMP Mon Jul 9 10:45:11 UTC 2018 > > > [ 0.00] Command line: BOOT_IMAGE=/vmlinuz root=/dev/sda1 > > > console=ttyS0 earlyprintk=serial vsyscall=native rodata=n > > > ftrace_dump_on_oops=orig_cpu oops=panic panic_on_warn=1 nmi_watchdog=panic > > > panic=86400 workqueue.watchdog_thresh=140 kvm-intel.nested=1 > > > > > > ... > > > > > > regulatory database > > > [ 4.519364] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' > > > [ 4.520839] platform regulatory.0: Direct firmware load for > > > regulatory.db failed with error -2 > > > [ 4.522155] cfg80211: failed to load regulatory.db > > > [ 4.522185] ALSA device list: > > > [ 4.523499] #0: Dummy 1 > > > [ 4.523951] #1: Loopback 1 > > > [ 4.524389] #2: Virtual MIDI Card 1 > > > [ 4.825991] input: ImExPS/2 Generic Explorer Mouse as > > > /devices/platform/i8042/serio1/input/input4 > > > [ 4.829533] md: Waiting for all devices to be available before > > > autodetect > > > [ 4.830562] md: If you don't use raid, use raid=noautodetect > > > [ 4.835237] md: Autodetecting RAID arrays. > > > [ 4.835882] md: autorun ... > > > [ 4.836364] md: ... autorun DONE. > > > > Can we assume that the failure occurred in or immediately after the MD code, > > or might some output have been truncated? > >
Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
On Fri, 2021-02-19 at 00:12 -0800, Jose R Rodriguez wrote: > On Tue, 2021-02-16 at 21:02 +0100, Edward Shishkin wrote: > > > > > > On 02/16/2021 04:56 PM, Jose R Rodriguez wrote: > > > On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote: > > > > On 02/08/2021 01:54 PM, Metztli Information Technology wrote: > > > > > On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin < > > > > > edward.shish...@gmail.com> wrote: > > > > > > > > > > > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote: > > > > > > > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed- > > > > > > > > > > > > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as > > > > > > > usual -- to generate a kernel component for my Debian-Installer > > > > > > > (d-i). > > > > > > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5- > > > > > > > unstable. > > > > > > > > > > > > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated > > > > > > > one set of components for d-i I built the d-i image. > > > > > > > > > > > > > > Fact is, the installer throws an error in *both* bare metal and > > > > > > > VirtualBox 6.1.16: > > > > > > > ... > > > > > > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap- > > > > > > > base' selected > > > > > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap -- > > > > > > > components=main --debian-installer --resolve-deps -- > > > > > > > keyring=/usr/share/keyrings/archive.gpg buster /target > > > > > > > http://deb.debian.org/debian/ > > > > > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: > > > > > > > /target/test-exec: Invalid argument > > > > > > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not > > > > > > > supported for file /test-exec (pid: 10077 comm: debootstrap) > > > > > > > Dec 22 20:19:56 debootstrap: E: NOEXEC > > > > > > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target > > > > > > > '/target' mounted with noexec or nodev > > > > > > > Dec 22 20:20:12 base-installer: error: exiting on error base- > > > > > > > installer/debootstrap-failed > > > > > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring > > > > > > > 'bootstrap-base' failed with error code 1 > > > > > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item > > > > > > > 'bootstrap-base' failed. > > > > > > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the > > > > > > > package description for brltty-udeb > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > Apparently, d-i [Debian-installer] complains about being unable > > > > > > > to set the test file executable and causes the error when 1 is > > > > > > > returned. > > > > > > > Notwithstanding, I manually verified that I am able to touch a > > > > > > > file and set it +x executable. > > > > > > > > > > > > > > Furthermore, tricking the function return value to 0 I am able > > > > > > > to make d-i continue with the latest SFRN5 installation (see > > > > > > > [*trick*] below); yet, subsequently halts again with > > > > > > > an apparently related error --can not proceed any further. > > > > > > > > > > > > > > Digging deeper with dmesg, we can see that apparently it is the > > > > > > > kernel which cannot 'read' properly. Please find a partial > > > > > > > dmesg log with relevant output > > > > > > > from an attempt on my physical development machine. > > > > > > > ... > > > > > > > [ 508.614488] Loading Reiser4 (Software Framework Release: > > > > > > > 5.1.3). See reiser4.wiki.kernel.org for a description of > > > > > > > Reiser4. > > > > > > > [ 508.661951] SGI XFS with ACLs, se
Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote: > On 02/08/2021 01:54 PM, Metztli Information Technology wrote: > > On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin < > > edward.shish...@gmail.com> wrote: > > > > > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote: > > > > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed- > > > > > > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as > > > > usual -- to generate a kernel component for my Debian-Installer > > > > (d-i). > > > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5- > > > > unstable. > > > > > > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated > > > > one set of components for d-i I built the d-i image. > > > > > > > > Fact is, the installer throws an error in *both* bare metal and > > > > VirtualBox 6.1.16: > > > > ... > > > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap- > > > > base' selected > > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap -- > > > > components=main --debian-installer --resolve-deps -- > > > > keyring=/usr/share/keyrings/archive.gpg buster /target > > > > http://deb.debian.org/debian/ > > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: > > > > /target/test-exec: Invalid argument > > > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not > > > > supported for file /test-exec (pid: 10077 comm: debootstrap) > > > > Dec 22 20:19:56 debootstrap: E: NOEXEC > > > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target > > > > '/target' mounted with noexec or nodev > > > > Dec 22 20:20:12 base-installer: error: exiting on error base- > > > > installer/debootstrap-failed > > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring > > > > 'bootstrap-base' failed with error code 1 > > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item > > > > 'bootstrap-base' failed. > > > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the > > > > package description for brltty-udeb > > > > > > > > > > [...] > > > > > > > > > > > Apparently, d-i [Debian-installer] complains about being unable > > > > to set the test file executable and causes the error when 1 is > > > > returned. > > > > Notwithstanding, I manually verified that I am able to touch a > > > > file and set it +x executable. > > > > > > > > Furthermore, tricking the function return value to 0 I am able > > > > to make d-i continue with the latest SFRN5 installation (see > > > > [*trick*] below); yet, subsequently halts again with > > > > an apparently related error --can not proceed any further. > > > > > > > > Digging deeper with dmesg, we can see that apparently it is the > > > > kernel which cannot 'read' properly. Please find a partial > > > > dmesg log with relevant output > > > > from an attempt on my physical development machine. > > > > ... > > > > [ 508.614488] Loading Reiser4 (Software Framework Release: > > > > 5.1.3). See reiser4.wiki.kernel.org for a description of > > > > Reiser4. > > > > [ 508.661951] SGI XFS with ACLs, security attributes, > > > > realtime, quota, no debug enabled > > > > [ 509.326270] device-mapper: uevent: version 1.0.3 > > > > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) > > > > initialised: dm-de...@redhat.com > > > > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6 > > > > [ 509.915300] sdb: sdb1 sdb2 sdb3 > > > > [ 511.973360] sdb: sdb1 sdb2 sdb3 > > > > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 > > > > extents:1 across:9765884k FS > > > > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol > > > > (fs/reiser4/init_volume.c:222)[edward-1932]: > > > > [ 636.240812] NOTICE: brick /dev/sda6 has been registered > > > > [ 636.243003] reiser4 (sda6): found disk format 5.1.3. > > > > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction > > > > Model. > > > > [ 643.759980] reiser4: brick /dev/sda6 activated > > > > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using > > > > the ext4 subsystem > > > > [ 643.813474] EXT4-fs (sda1): mounted filesystem without > > > > journal. Opts: (null) > > > > [ 643.813488] ext2 filesystem being mounted at /target/boot > > > > supports timestamps until 2038 (0x7fff) > > > > [ 648.168730] kernel read not supported for file /test-exec > > > > (pid: 9876 comm: debootstrap) [*trick*] > > > > [ 898.761385] reiser4: brick /dev/sda6 deactivated > > > > [ 991.001332] reiser4 (sda6): found disk format 5.1.3. > > > > [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction > > > > Model. > > > > [ 999.093480] reiser4: brick /dev/sda6 activated > > > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using > > > > the ext4 subsystem > > > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without > > > > journal. Opts: (null) > > > > [ 1009.362737] ext2 filesystem being mounted at /target/boot > > > > supports timestamps until 2038 (0x7fff) > > > > [ 6373.748413] kernel read not
