Bug#1032027: linux: i_reserved_data_blocks (2) not cleared
Source: linux Severity: normal X-Debbugs-Cc: sergey.aleynikov+...@gmail.com Dear Maintainer, I have the following disk configuration: sda 8:00 14.6T 0 disk └─disk6254:00 14.6T 0 crypt └─disk6-part1254:10 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part sdb 8:16 0 14.6T 0 disk └─disk2254:80 14.6T 0 crypt └─disk2-part1254:90 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part sdc 8:32 0 14.6T 0 disk └─disk3254:60 14.6T 0 crypt └─disk3-part1254:70 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part sdd 8:48 0 14.6T 0 disk └─disk1254:10 0 14.6T 0 crypt └─disk1-part1254:11 0 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part sde 8:64 0 14.6T 0 disk └─disk4254:40 14.6T 0 crypt └─disk4-part1254:50 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part sdf 8:80 0 14.6T 0 disk └─disk5254:20 14.6T 0 crypt └─disk5-part1254:30 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part Device md0 is constructed on top of 6x cryptsetup disks as following: md0 : active raid6 dm-11[6] dm-9[4] dm-7[3] dm-5[2] dm-3[7] dm-1[0] 62499463424 blocks super 1.2 level 6, 64k chunk, algorithm 2 [6/6] [UU] Root filesystem is mounted from md0p1 with the following options: UUID=bff1f017-bca2-4acc-9b97-170474c5e198 / ext4 noatime,nodelalloc,barrier=1,data=ordered 0 1 I've recently observed the following error in dmesg: [163925.493694] EXT4-fs (md0p1): Inode 6562253 (b30df460): i_reserved_data_blocks (2) not cleared! It haven't repeated since. Messages preceeding it are from kvm, like this one: [163814.292207] kvm [31458]: ignored rdmsr: 0x1a2 data 0x0 Does this mean a filesystem corruption? Do I need to take any additional steps (like force fsck), or would it recover silently? -- System Information: Debian Release: 11.6 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/56 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#843118: RE: seabios: Unable to boot KVM guest with "-display none"
I've re-checked that with "-vga none" seabios@rel-1.14.0 the specific VM doesn't boot and still doesn't on master. And it boots with an old seabios@e38be2d (though compiling it now requires some effort). PS: both host & guest are now debian 10, qemu version is 4.2. Best regards, Sergey Aleynikov ср, 30 дек. 2020 г. в 12:08, Michael Tokarev : > > On Sat, 3 Feb 2018 02:45:18 +0300 Sergey Aleynikov > wrote: > > Hi Michael, > > > > I've also stumbled upon this issue. My host is Debian 9, guest is > > Debian 6. This issue happens with any Qemu version from 2.4 up to 2.11 > > - faulty Seabios doesn't work on any of them, good Seabios works on > > all of them. Guest kernel isn't even loaded - qemu gets stuck at 100% > > cpu. My command line to start VM is the following: > > ( https://bugs.debian.org/843118 ) > > Hi Sergey! > > I just stumbled upon an old and neglected bugreport where you already did > all the good work. Unfortunately it received almost no love and only after > 3 year I come across it again.. > > Can you check whenever this bug is still relevant with current version of > seabios, please? > > Thank you! > > /mjt
Bug#962147: xserver-xorg-video-ast: Package installs driver .so at path not found by Xorg
Package: xserver-xorg-video-ast Version: 1.1.5-1.1+b1 Severity: normal Dear Maintainer, * What led up to the situation? Running a machine with ASPEED AST2400 video. * What exactly did you do (or not do) that was effective (or ineffective)? Install this package, run 'startx'. * What was the outcome of this action? I observe the only available screen resolution to be 640x480. * What outcome did you expect instead? To be able to select all supported screen resolutions, up to 1920x1200. The problem, as I see it, is that the Xorg package won't look into /usr/lib/x86_64-linux-gnu/xorg/modules/drivers/ for drivers, only into /usr/lib/xorg/modules/drivers/, in which all other xserver-xorg-video-* already install them, see ls -al /usr/lib/xorg/modules/drivers/ | wc -l 25 Moving ast_drv.so into it solved this problem. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Mar 6 2014 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Mar 5 2019 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 06:00.0 VGA compatible controller [0300]: ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000] (rev 30) 83:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU106 [GeForce RTX 2060 SUPER] [10de:1f06] (rev a1) Xorg X server configuration file status: -rw-r--r-- 1 root root 87 Jun 27 2015 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- # NOXORGCONFEXISTED: No X.org configuration file existed when this backup was created. /etc/X11/xorg.conf.d does not exist. /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2 (2020-04-29) Xorg X server log files on system: -- -rw-r--r-- 1 root root 56904 Jun 3 23:13 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 1353.264] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [ 1353.265] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian [ 1353.265] Current Operating System: Linux fangorn 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 [ 1353.265] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 root=UUID=a340a5a0-24a4-4255-bab2-5cbeb945e180 ro quiet intel_iommu=on cgroup_enable=memory swapaccount=1 apparmor=0 nomodeset consoleblank=0 spec_store_bypass_disable=on l1tf=flush kvm-intel.vmentry_l1d_flush=cond nmi_watchdog=0 spectre_v2_user=off random.trust_cpu=off net.ifnames=0 [ 1353.266] Build Date: 05 March 2019 08:11:12PM [ 1353.266] xorg-server 2:1.20.4-1 (https://www.debian.org/support) [ 1353.266] Current version of pixman: 0.36.0 [ 1353.266]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 1353.266] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 1353.268] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun 3 23:13:18 2020 [ 1353.268] (==) Using config file: "/etc/X11/xorg.conf" [ 1353.268] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 1353.268] (==) ServerLayout "ServerLayout0" [ 1353.268] (==) No screen section available. Using defaults. [ 1353.268] (**) |-->Screen "Default Screen Section" (0) [ 1353.268] (**) | |-->Monitor "" [ 1353.269] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 1353.269] (**) Option "BlankTime" "0" [ 1353.269] (**) Option "StandbyTime" "0" [ 1353.269] (**) Option "SuspendTime" "0" [ 1353.269] (**) Option "OffTime" "0" [ 1353.269] (==) Automatically adding devices [ 1353.269] (==) Automatically enabling devices [ 1353.269] (==) Automatically adding GPU devices [ 1353.269] (==) Max clients allowed: 256, resource mask: 0x1f [ 1353.269] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 1353.269]Entry deleted from font path. [ 1353.269] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 1353.269] (==) ModulePath set to "/usr/lib/xorg/modules" [ 1353.269] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 1353.269] (II) Loader magic: 0x558410c31e20 [ 1353.269] (II) Module ABI versions: [ 1353.269]
Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container
> You should probably attach the output of > reportbug --template lxc > to this bug report so the lxc maintainers have some context. I'm attaching 'lxc-start -n testupg --logfile=lxc.log -l DEBUG' and 'reportbug --template lxc' outputs to this message. > Checking the existing bug reports, there are already a few which concern > sysvinit. > I would suggest that you check them out like > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869892 I've looked at them yesterday, just in case, and didn't see anything obviously related. For example, for this one, I already have cgroupfs-mount installed and /sys/fs/cgroup present. And while I see mounting errors for the container after upgrade (not the attached log, but the original container i've tried to upgrade), they do not seem to be an immediate cause for the startup failure. lxc.log Description: Binary data reportbug.log Description: Binary data
Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container
The init system that fails inside the container is the default one for both stretch/buster - systemd, that's why i've reported this issue here. LXC/init versions on the host haven't changed.
Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container
Source: systemd Version: 241-5 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I'm running LXC containers (lxc version 1:2.0.7-2+deb9u2) on debian stretch. I have several containers with different debian versions inside. After I've done stretch->buster upgrade in one of them, it stopped working with 'lxc-start: tools/lxc_start.c: main: 366 The container failed to start.' message. * What exactly did you do (or not do) that was effective (or ineffective)? This is a reproducible sequence: lxc-create -n testupg -t download # choose debian - stretch - amd64 lxc-start -n testupg lxc-attach -n testupg # inside container vi /etc/apt/sources.list # change stretch -> buster apt-get update apt-get dist-upgrade exit # outside of container lxc-stop -n testupg lxc-start -n testupg # won't work I'd expect containers to keep working after dist-upgrade. -- System Information: Debian Release: 9.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/56 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#908764: I/O stuck in jbd2_journal_commit_transaction
Package: linux-image Version: 4.9.0-8 After each reboot, all I/O on the machine gets stuck for a couple of minutes with the following output in dmesg: [94491.612134] INFO: task jbd2/dm-3-8:2335 blocked for more than 120 seconds. [94491.612136] Not tainted 4.9.0-8-amd64 #1 Debian 4.9.110-3+deb9u4 [94491.612136] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [94491.612137] jbd2/dm-3-8 D0 2335 2 0x [94491.612141] 92e66d7ab000 92f6acb85100 92e69f758980 [94491.612143] 92e69262e140 ab4cdb017ca0 83610ee9 92e68b979088 [94491.612145] 0246 92e69f758980 ab4cdb017d80 92f6acb85100 [94491.612147] Call Trace: [94491.612154] [] ? __schedule+0x239/0x6f0 [94491.612157] [] ? prepare_to_wait_event+0xf0/0xf0 [94491.612159] [] ? schedule+0x32/0x80 [94491.612169] [] ? jbd2_journal_commit_transaction+0x25f/0x17b0 [jbd2] [94491.612172] [] ? update_curr+0xe1/0x160 [94491.612174] [] ? account_entity_dequeue+0xa4/0xc0 [94491.612176] [] ? prepare_to_wait_event+0xf0/0xf0 [94491.612179] [] ? finish_task_switch+0x152/0x200 [94491.612182] [] ? kjournald2+0xc2/0x260 [jbd2] [94491.612184] [] ? prepare_to_wait_event+0xf0/0xf0 [94491.612187] [] ? commit_timeout+0x10/0x10 [jbd2] [94491.612189] [] ? kthread+0xd9/0xf0 [94491.612190] [] ? kthread_park+0x60/0x60 [94491.612192] [] ? ret_from_fork+0x57/0x70 [94491.612219] INFO: task kworker/u113:1:13607 blocked for more than 120 seconds. [94491.612220] Not tainted 4.9.0-8-amd64 #1 Debian 4.9.110-3+deb9u4 [94491.612220] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [94491.612221] kworker/u113:1 D0 13607 2 0x [94491.612227] Workqueue: writeback wb_workfn (flush-253:3) [94491.612228] 92e66d7ab000 92e5a29a1040 92e69f658980 [94491.612230] 92e692613040 ab4d1b9c78b0 83610ee9 [94491.612231] 0001 92e69f658980 ab4d1b9c78d0 92e5a29a1040 [94491.612233] Call Trace: [94491.612235] [] ? __schedule+0x239/0x6f0 [94491.612237] [] ? schedule+0x32/0x80 [94491.612240] [] ? wait_transaction_locked+0x86/0xc0 [jbd2] [94491.612241] [] ? prepare_to_wait_event+0xf0/0xf0 [94491.612244] [] ? add_transaction_credits+0x1b8/0x290 [jbd2] [94491.612246] [] ? start_this_handle+0x105/0x400 [jbd2] [94491.612250] [] ? kmem_cache_alloc+0xbc/0x530 [94491.612252] [] ? jbd2__journal_start+0xd9/0x1e0 [jbd2] [94491.612278] [] ? ext4_writepages+0x45b/0xd60 [ext4] [94491.612280] [] ? update_group_capacity+0x21/0x1c0 [94491.612283] [] ? cpumask_next_and+0x26/0x40 [94491.612285] [] ? __writeback_single_inode+0x3d/0x320 [94491.612286] [] ? writeback_sb_inodes+0x221/0x4f0 [94491.612288] [] ? __writeback_inodes_wb+0x87/0xb0 [94491.612290] [] ? wb_writeback+0x27e/0x310 [94491.612292] [] ? get_nr_inodes+0x3c/0x60 [94491.612293] [] ? wb_workfn+0x2b4/0x380 [94491.612295] [] ? process_one_work+0x18a/0x420 [94491.612296] [] ? worker_thread+0x4d/0x490 [94491.612297] [] ? process_one_work+0x420/0x420 [94491.612299] [] ? kthread+0xd9/0xf0 [94491.612301] [] ? kthread_park+0x60/0x60 [94491.612302] [] ? ret_from_fork+0x57/0x70 [94491.612303] INFO: task qemu-system-x86:13636 blocked for more than 120 seconds. [94491.612304] Not tainted 4.9.0-8-amd64 #1 Debian 4.9.110-3+deb9u4 [94491.612304] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [94491.612305] qemu-system-x86 D0 13636 1 0x [94491.612307] 92e66d7ab000 92e5a20f9040 92e69f798980 [94491.612308] 92e692633000 ab4d1ba37a40 83610ee9 836113d2 [94491.612310] 00ffab4d1ba37c10 92e69f798980 ab4d1ba37a60 92e5a20f9040 [94491.612311] Call Trace: [94491.612313] [] ? __schedule+0x239/0x6f0 [94491.612315] [] ? schedule+0x32/0x80 [94491.612316] [] ? schedule+0x32/0x80 [94491.612319] [] ? wait_transaction_locked+0x86/0xc0 [jbd2] [94491.612320] [] ? prepare_to_wait_event+0xf0/0xf0 [94491.612323] [] ? add_transaction_credits+0x1b8/0x290 [jbd2] [94491.612325] [] ? start_this_handle+0x105/0x400 [jbd2] [94491.612328] [] ? jbd2__journal_start+0xd9/0x1e0 [jbd2] [94491.612335] [] ? ext4_dirty_inode+0x2d/0x60 [ext4] [94491.612337] [] ? __mark_inode_dirty+0x16b/0x360 [94491.612339] [] ? generic_update_time+0x79/0xd0 [94491.612340] [] ? current_time+0x36/0x70 [94491.612342] [] ? file_update_time+0xbf/0x110 [94491.612343] [] ? poll_select_copy_remaining+0x150/0x150 [94491.612345] [] ? __generic_file_write_iter+0x99/0x1b0 [94491.612352] [] ? ext4_file_write_iter+0x90/0x370 [ext4] [94491.612354] [] ? import_iovec+0x37/0xd0 [94491.612357] [] ? aio_write+0xfb/0x150 [94491.612359] [] ? poll_select_copy_remaining+0x150/0x150 [94491.612360] [] ? kmem_cache_alloc+0xbc/0x530 [94491.612362] [] ? poll_select_copy_remaining+0x150/0x150 [94491.612364] [] ? __fget_light+0x21/0x60 [94491.612365] [] ?
Bug#843118: seabios: Unable to boot KVM guest with "-display none"
Hi Michael, I've also stumbled upon this issue. My host is Debian 9, guest is Debian 6. This issue happens with any Qemu version from 2.4 up to 2.11 - faulty Seabios doesn't work on any of them, good Seabios works on all of them. Guest kernel isn't even loaded - qemu gets stuck at 100% cpu. My command line to start VM is the following: qemu-system-x86_64 \ -enable-kvm \ -bios /opt/seabios/out/bios.bin \ -machine q35,mem-merge=on,vmport=off \ -m 2048 \ -nodefaults \ -no-hpet \ -rtc base=utc,clock=host \ -boot order=d \ -name "VM_NAME" \ -cpu host,kvm=off \ -smp 4,sockets=1,cores=4,threads=1 \ -drive file="disk.img",id=disk,format=raw,if=none,cache=directsync,aio=native \ -device virtio-blk-pci,drive=disk,scsi=off,config-wce=off \ -device virtio-net-pci,netdev=net0,mac=$("../qemu-mac-hasher.py" "VM_NAME"),mq=on,vectors=10 \ -netdev tap,id=net0,script="../ifup.sh",downscript="../ifdown.sh",vhost=on,queues=4 \ -vga none \ -nographic If I change '-vga none' to '-vga std', it works on all faulty Seabios versions. I've performed bisect on Seabios, and here's the result 1d9e87b937d646be1950695f9ead35100d5ebbe6 is the first bad commit commit 1d9e87b937d646be1950695f9ead35100d5ebbe6 Author: Gerd Hoffmann <kra...@redhat.com> Date: Fri Jun 26 09:44:00 2015 +0200 virtio: run drivers in 32bit mode virtio version 1.0 registers can (and actually do in the qemu implementation) live in mmio space. So we must run the blk and scsi virtio drivers in 32bit mode, otherwise we can't access them. This also allows to drop a bunch of GET_LOWFLAT calls from the virtio code in the following patches. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> :100644 100644 f97b1bd9f91df7417e7bd5a1ebd7182098a43296 e287530d0008e1d876a0bb9f9ff8a43266d7e1bd M Makefile :04 04 70b419ced4f58a39143c92897097a08b5548cbf4 93f7d4d939b5e0a14102a3cb718b1be5a2f12e60 M src Best regards, Sergey Aleynikov