Bug#1032027: linux: i_reserved_data_blocks (2) not cleared

2023-02-26 Thread Sergey Aleynikov 
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"

2021-01-01 Thread Sergey Aleynikov 
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

2020-06-03 Thread Sergey Aleynikov 
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

2019-09-02 Thread Sergey Aleynikov 
> 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

2019-09-01 Thread Sergey Aleynikov 
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

2019-09-01 Thread Sergey Aleynikov 
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

2018-09-13 Thread Sergey Aleynikov 
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"

2018-02-02 Thread Sergey Aleynikov 
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