Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot
Hello, On Wed, May 22, 2024 at 05:03:34PM -0400, Stefan Monnier wrote: > Hmm... I've been using a "plain old partition" for /boot (with > everything else in LVM) for "ever", originally because the boot loader > was not able to read LVM, and later out of habit. I was thinking of > finally moving /boot into an LV to make things simpler, but I see that > it'd still be playing with fire grub supports, for a long time: - / on LVM, with /boot within that filesystem - /boot on LVM, separately (it also worked with LILO, because LILO would record the exact address where the kernel & initrd was, regardless of abstractions layers :->) Recently, I have been playing with RAID-on-LVM (I was mostly using LVM on md before, which worked with grub), and it works too. Where grub fails, is if you have /boot on the same LVM volume group where any of the LVs "before him in order" have: - dm-integrity - specific metadata So yes, any advanced setup might break grub, and so the easiest is to have /boot on its separate partition again for the time being. Which makes two partitions of you also have an UEFI. > (AFAICT booting off of LVM was still not > supported by U-Boot either last time I checked). No idea about that one, sorry.
Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot
Hello, On Wed, May 22, 2024 at 10:13:06AM +, Andy Smith wrote: > metadata tags to some PVs prevented grub from assembling them, grub is indeed very fragile if you use dm-integrity anywhere on any of your LVs on the same VG where /boot is (or at least if in the list of LVs, the dm-integrity protected ones come first). I guess it's a general problem how grub2 parses LVM, yes, as soon as their are special things going on, it somehow breaks. However, if you don't have /boot on LVM, hand-fixing grub2 can be trivial, e.g. here on another system with /boot/efi on 1st disk's first partition and /boot on 2nd disk's first partition. linux (hd1,1)vmlinuz-5.10.0-29-amd64 root=/dev/mapper/vg1-root ro quiet initrd (hd1,1)initrd.img-5.10.0-29-amd64 boot (you even have completions in grub's interactive boot system) and it boots. Next step: I am going to make me a USB boot key for that system, in case (first using a simple mount of two partitions of the USB key on /boot, respectively /boot/efi (vfat), then update-grub, or if it breaks, completely by hand like above -- I have been using syslinux for the last 20 years or so for that purpose, but it gets apparently too complicated with Secure Boot and stuff). PS: I have from now on decided I will always use a /boot no longer on LVM but on a separate partition, like the /boot/efi, it seems, indeed, much less fragile. Aka, back to what I was doing a few years ago before my confidence in grub2 got apparently too high :)
Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot
Hello, On Wed, May 22, 2024 at 08:57:38AM +0200, Marc SCHAEFER wrote: > I will try this work-around and report back here. As I said, I can > live with /boot on RAID without dm-integrity, as long as the rest can be > dm-integrity+raid protected. So, enable dm-integrity on all LVs, including /, /var/lib/lxc, /scratch and swap, now boots without any issue with grub2 as long as /boot is NOT on the same VG where the dm-integrity over LVM RAID is enabled. This is OK for me, I don't need /boot on dm-integrity. update-grub gives out warning for every of the rimage subvolumes, but can still then reboot. I would guess the bug is thus in grub2, not yet supporting boot on a /boot not necessarily dm-integrityfied itself, but on a VG where any of the LV is. Are readers seconding conclusion? If yes, I could report a bug on grub2. Have a nice day. Details: root@ds-03:~# lvs -a LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert docker vg1 rwi-aor--- 500.00g 100.00 [docker_rimage_0]vg1 gwi-aor--- 500.00g [docker_rimage_0_iorig] 100.00 [docker_rimage_0_imeta] vg1 ewi-ao <4.07g [docker_rimage_0_iorig] vg1 -wi-ao 500.00g [docker_rimage_1]vg1 gwi-aor--- 500.00g [docker_rimage_1_iorig] 100.00 [docker_rimage_1_imeta] vg1 ewi-ao <4.07g [docker_rimage_1_iorig] vg1 -wi-ao 500.00g [docker_rmeta_0] vg1 ewi-aor--- 4.00m [docker_rmeta_1] vg1 ewi-aor--- 4.00m root vg1 rwi-aor--- 10.00g 100.00 [root_rimage_0] vg1 gwi-aor--- 10.00g [root_rimage_0_iorig] 100.00 [root_rimage_0_imeta]vg1 ewi-ao 148.00m [root_rimage_0_iorig]vg1 -wi-ao 10.00g [root_rimage_1] vg1 gwi-aor--- 10.00g [root_rimage_1_iorig] 100.00 [root_rimage_1_imeta]vg1 ewi-ao 148.00m [root_rimage_1_iorig]vg1 -wi-ao 10.00g [root_rmeta_0] vg1 ewi-aor--- 4.00m [root_rmeta_1] vg1 ewi-aor--- 4.00m scratch vg1 rwi-aor--- 10.00g 100.00 [scratch_rimage_0] vg1 gwi-aor--- 10.00g [scratch_rimage_0_iorig] 100.00 [scratch_rimage_0_imeta] vg1 ewi-ao 148.00m [scratch_rimage_0_iorig] vg1 -wi-ao 10.00g [scratch_rimage_1] vg1 gwi-aor--- 10.00g [scratch_rimage_1_iorig] 100.00 [scratch_rimage_1_imeta] vg1 ewi-ao 148.00m [scratch_rimage_1_iorig] vg1 -wi-ao 10.00g [scratch_rmeta_0]vg1 ewi-aor--- 4.00m [scratch_rmeta_1]vg1 ewi-aor--- 4.00m swap vg1 rwi-aor--- 8.00g 100.00 [swap_rimage_0] vg1 gwi-aor--- 8.00g [swap_rimage_0_iorig] 100.00 [swap_rimage_0_imeta]vg1 ewi-ao 132.00m [swap_rimage_0_iorig]vg1 -wi-ao 8.00g [swap_rimage_1] vg1 gwi-aor--- 8.00g [swap_rimage_1_iorig] 100.00 [swap_rimage_1_imeta]vg1 ewi
Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot
Additional info: On Wed, May 22, 2024 at 08:49:56AM +0200, Marc SCHAEFER wrote: > Having /boot on a LVM non enabled dm-integrity logical volume does not > work either, as soon as there is ANY LVM dm-integrity enabled logical > volume anywhere (even not linked to booting), grub2 complains (at boot > time or at update-grub) about the rimage LV. I found this [1], quoting: "I'd also like to share an issue I've discovered: if /boot's partition is a LV, then there must not be a raidintegrity LV anywhere before that LV inside the same VG. Otherwise, update-grub will show an error (disk `lvmid/.../...' not found) and GRUB cannot boot. So it's best if you put /boot into its own VG. (PS: Errors like unknown node '..._rimage_0 can be ignored.)" So, the work-around seems to be to simple have /boot not on a LVM VG where any LV has dm-integrity enabled. I will try this work-around and report back here. As I said, I can live with /boot on RAID without dm-integrity, as long as the rest can be dm-integrity+raid protected. [1] https://unix.stackexchange.com/questions/717763/lvm2-integrity-feature-breaks-lv-activation
Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot
Hello, On Tue, May 21, 2024 at 08:41:58PM +0200, Franco Martelli wrote: > I can only recommend you to read carefully the Wiki: > https://raid.wiki.kernel.org/index.php/Dm-integrity I did, and it looks it does not seem to document anything pertaining to my issue: 1) I don't use integritysetup (from LUKS), but LVM RAID PVs -- I don't use LUKS encryption anyway on that system 2) the issue is not the kernel not supporting it, because when the system is up, it works (I have done tests to destroy part of the underlying devices, they get detected and fixed correctly) 3) the issue is not with the initrd -- I added the dm-integrity module and rebuilt the initrd (and actually the bug happens before grub2 loads the kernel & init) -- or at least "not yet"! maybe this will fail later :) 4) actually the issue is just grub2, be it when the system is up (it complains about the special subvolumes) or at boot time Having /boot on a LVM non enabled dm-integrity logical volume does not work either, as soon as there is ANY LVM dm-integrity enabled logical volume anywhere (even not linked to booting), grub2 complains (at boot time or at update-grub) about the rimage LV.
Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot
Hello, 1. INITIAL SITUATION: WORKS (no dm-integrity at all) I have a Debian bookwork uptodate system that boots correctly with kernel 6.1.0-21-amd64. It is setup like this: - /dev/nvme1n1p1 is /boot/efi - /dev/nvme0n1p2 and /dev/nvme1n1p2 are the two LVM physical volumes - a volume group, vg1 is built with those PVs vg1 has a few LVs that have been created in RAID1 LVM mode: lvdisplay | egrep 'Path|Mirrored' LV Path/dev/vg1/root <-- this is / Mirrored volumes 2 LV Path/dev/vg1/swap Mirrored volumes 2 LV Path/dev/vg1/scratch Mirrored volumes 2 LV Path/dev/vg1/docker Mirrored volumes 2 As said, this boots without any issue. 2. ADDING dm-integrity WHILE BOOTED: works! Now, while booted, I can add dm-integrity to one of the volumes, let's say /dev/vg1/docker (this LV has absolutely no link with the boot process, except obviously it is listed in /etc/fstab -- it also fails the same way if even the swap is dm-integrit enabled, or /): lvconvert --raidintegrity y --raidintegritymode bitmap vg1/docker and wait a bit til the integrity is setup with lvs -a (100%) Obviously, this creates and uses a few rimage/rmeta sub LVs. Then I did this (after having boot issues): echo dm_integrity >> /etc/initramfs-tools/modules update-initramfs -u This did not change the below issue: 3. grub BOOT FAILS IF ANY LV HAS dm-integrity, EVEN IF NOT LINKED TO / if I reboot now, grub2 complains about rimage issues, clear the screen and then I am at the grub2 prompt. Booting is only possible with Debian rescue, disabling the dm-integrity on the above volume and rebooting. Note that you still can see the rimage/rmeta sub LVs (lvs -a), they are not deleted! (but no dm-integrity is activated). 4. update-grub GIVES WARNINGS Now, if I try to start update-grub while booted AND having enabled dm-integrity on the vg1/docker volume, I get: # update-grub Generating grub configuration file ... Found linux image: /boot/vmlinuz-6.1.0-21-amd64 Found initrd image: /boot/initrd.img-6.1.0-21-amd64 error: unknown node 'docker_rimage_0'. [ ... many ... ] /usr/sbin/grub-probe: error: disk `lvmid/xLE0OV-wQy7-88H9-yKCz-4DUQ-Toce-h9rQvk/FzCf1C-95eB-7B0f-DSrF-t1pg-66qp-hmP3nZ' not found. error: unknown node 'docker_rimage_0'. [ ... many ... ] [ this repeats a few times ] Found linux image: /boot/vmlinuz-6.1.0-10-amd64 Found initrd image: /boot/initrd.img-6.1.0-10-amd64 Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi Warning: os-prober will not be executed to detect other bootable partitions. [ there are none ] Systems on them will not be added to the GRUB boot configuration. Check GRUB_DISABLE_OS_PROBER documentation entry. Adding boot menu entry for UEFI Firmware Settings ... done Any idea what could be the problem? Any way to just make grub2 ignore the rimage (sub)volumes at setup and boot time? (I could live with / aka vg1/root not using dm-integrity, as long as the data/docker/etc volumes are integrity-protected) ? Or how to make grub 100% compatible with a vg1/root using dm-integrity (that would be obviously the final goal!) Thank you for any pointers!
Re: HDD long-term data storage with ensured integrity
On Fri, May 03, 2024 at 01:50:52PM -0700, David Christensen wrote: > Thank you for devising a benchmark and posting some data. :-) I did not do the comparison hosted on github. I just wrote the script which tests the dm-integrity on dm-raid error detection and error correction. > FreeBSD also offers a layered solution. From the top down: I prefer this approach, indeed.
Re: HDD long-term data storage with ensured integrity
On Mon, Apr 08, 2024 at 10:04:01PM +0200, Marc SCHAEFER wrote:
> For off-site long-term offline archiving, no, I am not using RAID.
Now, as I had to think a bit about ONLINE integrity, I found this
comparison:
https://github.com/t13a/dm-integrity-benchmarks
Contenders are btrfs, zfs, and notably ext4+dm-integrity+dm-raid
I tend to have a biais favoring UNIX layered solutions against
"all-into-one" solutions, and it seems that performance-wise,
it's also quite good.
I wrote this script to convince myself of auto-correction
of the ext4+dm-integrity+dm-raid layered approach.
It gives:
[ ... ]
[ 390.249699] md/raid1:mdX: read error corrected (8 sectors at 21064 on dm-11)
[ 390.249701] md/raid1:mdX: redirecting sector 20488 to other mirror: dm-7
[ 390.293807] md/raid1:mdX: dm-11: rescheduling sector 262168
[ 390.293988] md/raid1:mdX: read error corrected (8 sectors at 262320 on dm-11)
[ 390.294040] md/raid1:mdX: read error corrected (8 sectors at 262368 on dm-11)
[ 390.294125] md/raid1:mdX: read error corrected (8 sectors at 262456 on dm-11)
[ 390.294209] md/raid1:mdX: read error corrected (8 sectors at 262544 on dm-11)
[ 390.294287] md/raid1:mdX: read error corrected (8 sectors at 262624 on dm-11)
[ 390.294586] md/raid1:mdX: read error corrected (8 sectors at 263000 on dm-11)
[ 390.294712] md/raid1:mdX: redirecting sector 262168 to other mirror: dm-7
pretty much convicing.
So after testing btrfs and being not convinced, after doing some test on
a production zfs -- not convinced either -- I am going to ry
ext4+dm-integrity+dm-raid.
#! /bin/bash
set -e
function create_lo {
local f
f=$(losetup -f)
losetup $f $1
echo $f
}
# beware of the rm -r below!
tmp_dir=/tmp/$(basename $0)
mnt=/mnt
mkdir $tmp_dir
declare -a pvs
for p in pv1 pv2
do
truncate -s 250M $tmp_dir/$p
l=$(create_lo $tmp_dir/$p)
pvcreate $l
pvs+=($l)
done
vg=$(basename $0)-test
lv=test
vgcreate $vg ${pvs[*]}
vgdisplay $vg
lvcreate --type raid1 --raidintegrity y -m 1 -L 200M -n $lv $vg
lvdisplay $vg
# sync/integrity complete?
sleep 10
cat /proc/mdstat
echo
lvs -a -o name,copy_percent,devices $vg
echo
echo -n Type ENTER
read ignore
mkfs.ext4 -I 256 /dev/$vg/$lv
mount /dev/$vg/$lv $mnt
for f in $(seq 1 10)
do
# ignore errors
head -c 20M < /dev/random > $mnt/f_$f || true
done
(cd $mnt && find . -type f -print0 | xargs -0 md5sum > $tmp_dir/MD5SUMS)
# corrupting some data in one PV
count=5000
blocks=$(blockdev --getsz ${pvs[1]})
if [ $blocks -lt 32767 ]; then
factor=1
else
factor=$(( ($blocks - 1) / 32767))
fi
p=1
for i in $(seq 1 $count)
do
offset=$(($RANDOM * $factor))
echo ${pvs[$p]} $offset
dd if=/dev/random of=${pvs[$p]} bs=$(blockdev --getpbsz ${pvs[$p]})
seek=$offset count=1
# only doing on 1, not 0, since we have no way to avoid destroying the same
sector!
#p=$((1 - p))
done
dd if=/dev/$vg/$lv of=/dev/null bs=32M
dmesg | tail
umount $mnt
lvremove -y $vg/$lv
vgremove -y $vg
for p in ${pvs[*]}
do
pvremove $p
losetup -d $p
done
rm -r $tmp_dir
Re: SOLVED (was: Re: using mbuffer: what am i doing wrong?)
On Thu, Apr 11, 2024 at 04:14:33PM +0200, DdB wrote:
> - the resulting transfer is way faster than say ... ssh.
AFAIK ssh is mono-threaded (like OpenVPN, unless you use the kernel
module). wireguard is multi-threaded.
The symptom will be one CPU ("core") at 100% and the rest mostly
idle.
Re: using mbuffer: what am i doing wrong?
Hello, On Tue, Apr 09, 2024 at 03:13:01PM +0200, DdB wrote: > from my research, the abbreviated takeaway is: I never used mbuffer, I use buffer combined with netcat-traditional: # receiver (TCP server on port 8000) nc -l -p 8000 | buffer -S 1048576 -s 32768 -o /dev/null # sender (TCP client on ephemeral port) nc localhost 8000 < /dev/zero I just installed mbuffer: mbuffer -I 8000 -o /dev/null mbuffer -i /dev/zero -O 127.0.0.1:8000 and it also works. > > sudo netstat | grep $port > to return nothing yes, but those work: netstat -a | grep :8000 netstat --listen | grep :8000 Maybe it's just that by default netstat only shows sockets in the ESTABLISHED state and not in the LISTEN state. > What am i doing wrong? If there is a timeout, I would suggest to investigate firewalls on the server side.
Re: HDD long-term data storage with ensured integrity
Hello, On Mon, Apr 08, 2024 at 11:28:04AM -0700, David Christensen wrote: > So, an ext4 file system on an LVM logical volume? > > Why LVM? Are you implementing redundancy (RAID)? Is your data larger than > a single disk (concatenation/ JBOD)? Something else? For off-site long-term offline archiving, no, I am not using RAID. No, it's not LVM+md, just plain LVM for flexibility. Typically I use 16 TB hard drives, and I tend to use one LV per data source, the LV name being the data source and the date of the copy. Or sometimes I just copy a raw volume (ext4 or something else) to a LV. With smaller drives (4 TB) I tend to not use LVM, just plain ext4 on the raw disk. I almost never use partitionning. However, I tend to use luks encryption (per ext4 filesystem) when the drives are stored off-site. So it's either LVM -> LV -> LUKS -> ext4 or raw disk -> LUKS -> ext4. You can find some of the scripts I use to automate this off-site long-term archiving here: https://git.alphanet.ch/gitweb/?p=various;a=tree;f=offsite-archival/LVM-LUKS
Re: HDD long-term data storage with ensured integrity
For offline storage: On Tue, Apr 02, 2024 at 05:53:15AM -0700, David Christensen wrote: > Does anyone have any comments or suggestions regarding how to use magnetic > hard disk drives, commodity x86 computers, and Debian for long-term data > storage with ensured integrity? I use LVM on ext4, and I add a MD5SUMS file at the root. I then power up the drives at least once a year and check the MD5SUMS. A simple CRC could also work, obviously. So far, I have not detected MORE corruption with this method than the drive ECC itself (current drives & buses are much better than they used to be). When I have errors detected, I replace the file with another copy (I usually have multiple off-site copies, and sometimes even on-site online copies, but not always). When the errors add up, it is time to buy another drive, usually after 5+ years or even sometimes 10+ years. So, just re-reading the content might be enough, once a year or so. This is for HDD (for SDD I have no offline storage experience, it could be shorter).
Re: making Debian secure by default
Hello, On Fri, Mar 29, 2024 at 07:02:54PM +0100, Kamil Jo?ca wrote: > O-o, is there any simple test to check if I have infected version or > not? For example, under root: path="$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')" if hexdump -ve '1/1 "%.2x"' "$path" | grep -q f30f1efa554889f54c89ce5389fb81e700804883ec28488954241848894c2410 then echo probably vulnerable else echo probably not vulnerable fi NB: always think and read before typing root commands, or any commands you find on a forum or mailing-list :) More info: https://boehs.org/node/everything-i-know-about-the-xz-backdoor Interesting read about social interactions https://www.openwall.com/lists/oss-security/2024/03/29/4 ref for the code above https://www.openwall.com/lists/oss-security/2024/03/29/23 idea to confine the sshd -> systemd dependancy, in a specific process, because of the huge systemd attack surface
Re: making Debian secure by default
Hello, On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote: > Apparently the root of the security issue is that wall is a setguid program? a) wall must be able to write to your tty, which is not possible if wall is not installed setguid OR if people have sane permissions on their terminals (e.g. set to mesg n) b) in addition, for this exploit to run, command-not-found must be started with the not found command as argument: in the two Debian releases I just tried (buster and bookworm), with bash, command-not-found was not installed. The idea of the exploit is that you get a prompt for entering a sudo password, which is a simple text (which gets more convincing because of a recently introduced bug in wall which does not filter out terminal escape / control sequences), then you type the root password, which is presumably not the name of an existing command, so command-not-found PASSWORD is run, and someone on another terminal and user can do a ps to see that password argument if he is quick or polling. To fix this: a) don't type a root password / sudo password unless you know that it should happen b) don't allow others to write on your terminals, in particular if you run priviledged commands and expect sudo prompts c) patch wall so that its texts are always shown to be different from other program outputs (== filter out anything else than printable characters) THIS IS MY PREFERRED WORKAROUND :) (mixing controls (prompts) and data is always a very bad idea) d) don't have other users on your machine / use containers. > So. There is a program called 'mesg', hrmmm.. 30 years ago it was common practice to use wall (to signal stuff to users, e.g. used by shutdown(8)). > oof. Are there instructions somewhere on how to make Debian secure by > default? Looks like it is, by not installing command-not-found by default (apparently Ubuntu does). Presumably by chance.
Re: Debugging an USB array issue
Hello, On Fri, Mar 15, 2024 at 06:54:38PM +0100, to...@tuxteam.de wrote: > I may be stating the obvious, but have you made sure the USB hub > is providing enough power to keep your disks happy? It's a 60W external power supply, for 4 disks.
Re: Debugging an USB array issue
Hello, On Fri, Mar 15, 2024 at 01:30:08PM -0400, Dan Ritter wrote: > I have never had long-term happiness with multiple disks > connected via USB. I strongly recommend that you find a 4 or 8 > disk SATA/SAS PCIe card -- an LSI 2008, for example -- and connect > through that, instead. US prices are $40-45 new. Add $15 for an 8087-to-4xSATA > cable, you will have happiness for less than $75. Interesting. I will keep the idea in mind. I also had a prejudice against USB in the beginning. However: I have a similar disk array running 24h/24h for the last three years on a Debian buster with no problem. I am going to upgrade this system soon, so if there is something bad with bullseye's kernel I would love to learn about it :)
Debugging an USB array issue
Hello, on a Debian bullseye uptodate system [1], I experiment frequent (every 3-4 hours on heavy load) disk disconnections from a md RAID10 array with 4 drives connected to an USB 1M adapter [2]. Errors do not look like a timeout, but like a DMA error [3]. Immediately after, the disk reappears as a new drive name and can be re-added quickly to the md RAID array (I am doing those tests with a read-only mounted filesystem for obvious reasons). Initially, I was wondering if it was maybe a disk doing a too long recovery procedure, but it is to be noted that it's not always the same disk which has an error, and smartctl -a shows no recorded errors for any of the 4 drives [4]. The drives are connected to a SATA-to-USB enclosure [6]. This is on a 3.1 USB PCI-Express card [5]. I already applied this work-around (which does not seem to apply to a non-idle system): echo -1 > /sys/module/usbcore/parameters/autosuspend What would be your recommandations? I have thought about downgrading to a slower port (it should not be much different with 5000M), changing the cable, or maybe it's the enclosure? Or is this a known issue (maybe with the xhci_hd driver) and I should try another driver? Thank you for any idea or pointer. [1] Linux video 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64 GNU/Linux [2] /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 1M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 1M |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M |__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 1M |__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=uas, 1M |__ Port 1: Dev 6, If 0, Class=Mass Storage, Driver=uas, 1M |__ Port 4: Dev 10, If 0, Class=Mass Storage, Driver=uas, 1M |__ Port 2: Dev 7, If 0, Class=Mass Storage, Driver=uas, 1M |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M [3] Mar 15 17:08:06 video kernel: [ 6607.383180] xhci_hcd :01:00.0: WARN Set TR Deq Ptr cmd invalid because of stream ID configuration Mar 15 17:08:06 video kernel: [ 6607.386754] DMAR: DRHD: handling fault status reg 3 Mar 15 17:08:06 video kernel: [ 6607.386762] DMAR: [DMA Write] Request device [01:00.0] PASID fault addr f98be000 [fault reason 05] PTE Write access is not set Mar 15 17:08:06 video kernel: [ 6607.386774] sd 18:0:0:0: [sde] tag#5 data cmplt err -75 uas-tag 1 inflight: CMD Mar 15 17:08:06 video kernel: [ 6607.386780] sd 18:0:0:0: [sde] tag#5 CDB: Read(16) 88 00 00 00 00 01 5e 1d 88 00 00 00 01 00 00 00 Mar 15 17:08:06 video kernel: [ 6607.479406] xhci_hcd :01:00.0: WARN Event TRB for slot 12 ep 10 with no TDs queued? Mar 15 17:08:06 video kernel: [ 6607.479708] xhci_hcd :01:00.0: WARN Set TR deq ptr command for freed stream ID 38885 Mar 15 17:08:06 video kernel: [ 6607.510551] xhci_hcd :01:00.0: WARN Event TRB for slot 12 ep 10 with no TDs queued? [ ... many ... ] Mar 15 17:08:13 video kernel: [ 6614.443826] sd 18:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN Mar 15 17:08:13 video kernel: [ 6614.443829] sd 18:0:0:0: [sde] tag#2 CDB: ATA command pass through(12)/Blank a1 08 2e d0 01 00 4f c2 00 b0 00 00 Mar 15 17:08:13 video kernel: [ 6614.457969] xhci_hcd :01:00.0: WARN Event TRB for slot 12 ep 10 with no TDs queued? Mar 15 17:08:13 video kernel: [ 6614.458274] xhci_hcd :01:00.0: WARN Set TR deq ptr command for freed stream ID 38885 [ ... many ... ] Mar 15 17:08:25 video kernel: [ 6626.497696] sd 18:0:0:0: [sde] tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=19s Mar 15 17:08:25 video kernel: [ 6626.497725] sd 18:0:0:0: [sde] tag#5 Sense Key : Illegal Request [current] Mar 15 17:08:25 video kernel: [ 6626.497731] sd 18:0:0:0: [sde] tag#5 Add. Sense: Invalid command operation code Mar 15 17:08:25 video kernel: [ 6626.497739] sd 18:0:0:0: [sde] tag#5 CDB: Read(16) 88 00 00 00 00 01 5e 1d 88 00 00 00 01 00 00 00 Mar 15 17:08:25 video kernel: [ 6626.497746] blk_update_request: critical target error, dev sde, sector 5873960960 op 0x0:(READ) flags 0x0 phys_seg 32 prio class 0 Mar 15 17:08:25 video kernel: [ 6626.497755] md/raid10:md0: sde: rescheduling sector 11747394560 Mar 15 17:08:25 video kernel: [ 6626.497801] usb 3-1.1.4: stat urb: no pending cmd for uas-tag 3 Mar 15 17:08:25 video kernel: [ 6626.497807] md/raid10:md0: sdd: redirecting sector 11747394560 to another mirror Mar 15 17:08:25 video kernel: [ 6626.519426] xhci_hcd :01:00.0: WARN Event TRB for slot 12 ep 10 with no TDs queued? Mar 15 17:08:25 video kernel: [ 6626.519719] xhci_hcd :01:00.0: WARN Set TR deq ptr command for freed stream ID 38885 Mar 15 17:08:25 video kernel: [ 6626.550583] xhci_hcd :01:00.0: WARN Event TRB for slot 12 ep 10 with no TDs queued? Mar 15 17:08:25 video kernel: [ 6626.550875] xhci_hcd :01:00.0: WARN Set TR deq ptr command for freed
Re: Bullseye debian security support?
Hello, On Wed, May 31, 2023 at 11:37:34AM -0700, John Conover wrote: > How long will Debian Bullseye have debian security team support after > Bookworm is announced? LTS planning is here: https://wiki.debian.org/LTS bullseye will be LTS-supported til june 2026 (not yet clearly defined), but will only be handed to LTS in july 2024: until then, it's normal security support.
buster docker has issue with bookworm container
Hello,
I had a few issues with building a bookworm container using the
debian:bookworm image (problems with repository signatures and lzma
decompression errors) on a buster docker host.
The buster and bullseye containers seem to work like a charm though.
So I went the bullseye -> upgrade to bookworm path with the Dockerfile
below. I apply a work-around in the Dockerfile ("fixing" the error with the
cleaning of the apt archives in /etc/apt/apt.conf.d/docker-clean), and
it fixed the repository GPG errors (it seems the /etc/apt/sources.list
in the debian:bookworm has direct key references that do not exist/do
not contain the correct keys).
But, the apparently last problem I can't seem to fix is the following:
dpkg-deb (subprocess): decompressing archive
'/var/cache/apt/archives/util-linux_2.38.1-5+b1_amd64.deb' (size=1176996)
member 'control.tar': lzma error: Cannot allocate memory
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
dpkg-deb: error: tar subprocess returned error exit status 2
dpkg: error processing archive
/var/cache/apt/archives/util-linux_2.38.1-5+b1_amd64.deb (--unpack): dpkg-deb
--control subprocess returned error exit status 2
dpkg-deb (subprocess): decompressing archive
'/var/cache/apt/archives/util-linux-extra_2.38.1-5+b1_amd64.deb' (size=110520)
member 'control.tar': lzma error: Cannot allocate memory
tar: This does not look like a tar archive
This is reproducible, this is not a transient error.
It seems as if libzma does not have enough RAM to do the decompression
here. I found notably an issue with 32 bit address space, but this is
amd64.
Also, the container has no specific limits (it is not better with
docker build -m 100g), and free reports:
totalusedfree shared buff/cache available
Mem: 4024628 940056 208924 16012 3152384 3084572
Swap:7811068 2 7755516
So, is this some libzma config somewhere, or maybe a missing / changed
syscall which makes libzma thinks it does not have enough memory?
If I try to decompress, manually, with ar, then xz the above util-linux
downloaded deb, on a buster and bullseye container and there is no
issue, which seems to exclude a problem with cgroup limitations that I
didn't see.
Do you have maybe any idea (except upgrading the host to bullseye or
bookworm)?
Thank you.
FROM debian:bullseye
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update && apt-get -y dist-upgrade \
&& sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list \
&& rm -f /etc/apt/apt.conf.d/docker-clean \
&& apt-get update && apt-get -y upgrade \
&& echo update/upgrade done \
&& apt-get --purge -y autoremove \
&& echo purge done \
&& apt-get -y install procps \
&& free \
&& apt-get -y -u dist-upgrade \
&& echo dist-upgrade done \
&& apt-get install -y openssh-server rsyslog debian-goodies sudo vim
wget \
&& echo install done \
&& apt-get clean \
&& echo clean done
# disable klogd
RUN sed -i 's/^\(module.load="imklog"\)/#\1/' /etc/rsyslog.conf
# remove the privake key, will be generated by ds-admin ssh-base
# post-conf
# so that it is different for each VM
RUN rm /etc/ssh/ssh_host_*
COPY rc.local /etc/rc.local
RUN chmod 755 /etc/rc.local
# documentation
EXPOSE 22/tcp
CMD /etc/rc.local && tail -f /dev/null
Re: sysrq over *USB*
On Fri, Oct 15, 2021 at 09:02:50PM +0200, Marc SCHAEFER wrote: > Should I abandon all hope to make it work with USB, or should it work? Yes, sysrq can work with USB, but not with stock Debian kernels, because of [1]. Here is the work-around: 1) recompile kernel (see [2]) with the following options: CONFIG_USB=y CONFIG_USB_SERIAL=y CONFIG_USB_SERIAL_CONSOLE=y CONFIG_U_SERIAL_CONSOLE=y 2) configure /etc/default/grub with console=ttyUSB0,9600 console=tty0 and run upgrade-grub 3) I then get: # cat /proc/consoles tty0 -WU (EC p )4:1 ttyUSB0 -W- (E p ) 188:0 and I can then do sysrq from USB: schaefer@acer-1:~$ cu -l ttyUSB0 -s 9600 Connected. ~%break [ 1633.701624] sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) dump-ftrace-buffer(z) Also, the HDMI console still works (logs & sysrq). The problem and solution was found with help from the kernel-newbies mailing-list. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868352 [2] https://wiki.debian.org/BuildADebianKernelPackage
Re: sysrq over *USB*
Hello, On Fri, Oct 15, 2021 at 09:33:20PM -0500, Nicholas Geovanis wrote: > It's a side issue, not my main question, but If feel some details are > missing in > the "apu2 null modem" block-box there :-) It may be that your e-mail client is not handling ASCII art properly, you can look at the correct version here: https://lists.debian.org/debian-user/2021/10/msg00658.html Typically, the null modem is NOT the apu2. > But don't you need to have a running getty now? Listening on the > serial device file that should be associated with the USB source. I have tested with a cu on both sides, so the port is "open" anyway, if this is required. > Interesting project though. Any involvement here with MIDI-over-USB? No. > Tschuss [36 useless quote lines removed ]
sysrq over *USB*
Hello, I made the following setup work, that is I can send break and '?' (to get the magic sysrq help) or 's' to do an Emergency sync, and the kernel logs it: laptopapu2 USB serial port --- null modem --- ttyS0 internal 16550A (an apu2 is an embedded amd64 computer [4]) As it works, of course MAGIC_SYSRQ is enabled, including for serial ports, and the correct value is in the /proc pseudo-file. It works with the getty enabled or disabled. However, the following does not work to support magic sysrq, although bidirectionnal communication also works with cu [5], with the correct speed set: laptopapu2 USB serial port --- null modem --- USB serial port First, reading documentation, I thought that this would not be possible [1], but then, reading kernel source, it looks it should work with my adapter: Oct 11 14:30:56 apu2-init7 kernel: [9.915105] usb 2-2: pl2303 converter now attached to ttyUSB0 since the driver [2] contains code for magic sysrq, see line 993 for sysrq mode and line 892 for break handling, with implementation in [3] (lines 589-597). I am running Debian buster kernel 4.19.0-18-amd64 on the apu2. Should I abandon all hope to make it work with USB, or should it work? Thank your for any pointers. [1] https://www.kernel.org/doc/Documentation/admin-guide/sysrq.rst "On the serial console (PC style standard serial ports only)" [2] https://github.com/jplozi/linux-4.19/blob/loadbalancing/drivers/usb/serial/pl2303.c [3] https://github.com/jplozi/linux-4.19/blob/loadbalancing/drivers/usb/serial/generic.c [4] https://pcengines.ch/apu2.htm [5] https://linux.die.net/man/1/cu from the days before 2003 where I was doing UUCP cu -l ttyUSB0 -s 9600
Re: Debian jessie > buster IPv6 link scope change of behaviour
On Thu, Jan 21, 2021 at 06:23:56PM -0600, David Wright wrote:
> Yes, that documents what we normally observe as a %eth0 or %1 suffix
> for IPv6 addresses which selects the interface to use. "Requires"
> (unemphasised in the original) mean that it is necessary to identify a
> particular zone, but IMHO doesn't mean that a choice of zone is
My opinion is that link-local addresses are ambiguous and it is required
to find a mean to deambiguate those, either using a zone (interface
identifier) %postfix, or through a default zone).
Actually, my interpretation of what happened is wrong. If `ping'
exhibits a bizarre behaviour using apparently the first Ethernet
interface it sees, this is is not what other commands shows:
$ telnet fe80::1
Trying fe80::1...
telnet: Unable to connect to remote host: Invalid argument
That's good (to me).
schaefer@reliand:~$ telnet -6 fe80::1%eth1
Trying fe80::1%eth1...
[no error, NDP requests sent]
That's correct behaviour (to me).
ping however seems to do things itself and chooses an interface:
PING fe80::1(fe80::1) 56 data bytes
From fe80::9e8e:99ff:fe3c:5523%eth0: icmp_seq=1 Destination unreachable:
Address unreachable
(which in this case, obviously, is not the correct one, but how
could he guess? link-local v6 addresses ARE ambiguous -- should it
try all other interfaces each like Microsoft apparently does as you
mentionned? no -- and it doesn't!)
Also, a small code I wrote using getaddrinfo(3) and connect(2):
$ ./simple-client fe80::1 80
Trying connection to host fe80::1:80 ...
connect(): : Invalid argument
Could not connect.
vs
$ ./simple-client fe80::1%eth1 80
Trying connection to host fe80::1%eth1:80 ...
So its's not getaddrinfo(3) which does bad things either.
So it's must be ping's fault.
So, let's look at ping's manpage:
-I interface
interface is either an address, or an interface name. If interface
is an address, it sets source address to specified interface
address. If interface in an interface name, it sets source
interface to specified interface. NOTE: For IPv6, when doing ping
to a link-local scope address, link specification (by the
'%'-notation in destination, or by this option) can be used but it
is no longer required.
Oho, "is no longer required" ... why that?
Let's look at the source:
apt-get source iputils-ping # especially ping6-common.c
In ping6_run() there is all sort of code related to LINKLOCAL v6
addresses and using the `device' global, which is initialized
in ping.c if -I is used, and is NULL in my use case.
It seems firsthop.sin6_scope_id is set manually when required.
Reading:
https://tools.ietf.org/id/draft-smith-ipv6-link-locals-apps-00.html#rfc.section.5
(about sin6_scope_id) and
https://tools.ietf.org/id/draft-smith-ipv6-link-locals-apps-00.html#rfc.section.5
(about getaddrinfo)
which confirms that link-local addresses are returned by getaddrinfo()
without scope id, unless they have the scope as the %postfix. So you
need to supply it separately (-I ping option would do). However, ping
seems to get overly smart about this, opening a probe socket on
apparently the first interface it gets, and getting the interface from
it, it seems.
Demonstration:
$ ./a.out fe80::1
Trying connection to host fe80::1:80 ...
scope ID: 0
./a.out fe80::1%eth0
Trying connection to host fe80::1%eth1:80 ...
scope ID: 2
Code:
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv) {
if (argc < 2) {
fprintf(stderr, "%s v6-addr\n, %s: bad args.\n", argv[0], argv[0]);
return 2;
}
struct addrinfo hints;
struct addrinfo *result, *rp;
hints.ai_family = AF_UNSPEC; /* IPv4 or v6 */
hints.ai_socktype = SOCK_STREAM; /* TCP */
hints.ai_flags = 0;
hints.ai_protocol = 0; /* any protocol */
int s;
if ((s = getaddrinfo(argv[1], "http", , ))) {
fprintf(stderr, "getaddrinfo(): failed: %s.\n", gai_strerror(s));
}
else {
/* getaddrinfo() returns a list of address structures.
* Try each address until we successfully connect(2).
*/
for (rp = result; rp != NULL; rp = rp->ai_next) {
char ipname[INET6_ADDRSTRLEN]; /* len(addrv6) > len(addrv4) */
char servicename[6]; /* "65535\0" */
if (!getnameinfo(rp->ai_addr,
rp->ai_addrlen,
ipname,
sizeof(ipname),
servicename,
sizeof(servicename),
NI_NUMERICHOST|NI_NUMERICSERV)) {
printf("Trying connection to host %s:%s ...\n",
ipname,
servicename);
if (rp->ai_family == AF_INET6) {
printf("scope ID: %d\n", ((struct sockaddr_in6 *)
rp->ai_addr)->sin6_scope_id);
}
}
}
}
return 0;
}
Re: Debian jessie > buster IPv6 link scope change of behaviour
On Thu, Jan 21, 2021 at 08:04:05AM +0100, Marc SCHAEFER wrote: > fe80::1 is specifically a link-local scope, a bit like if you try to > access a class variable without telling in what class it is. Reading RFC-4291 [1], 2.5.6 (link-local addresses) and RFC-4007 [2] 6, Zones Indices: Because the same non-global address may be in use in more than one zone of the same scope (e.g., the use of link-local address fe80::1 in two separate physical links) and a node may have interfaces attached to different zones of the same scope (e.g., a router normally has multiple interfaces attached to different links), a node *requires* an internal means to identify to which zone a non-global address belongs. This is accomplished by assigning, within the node, a distinct "zone index" to each zone of the same scope to which that node is attached, and by allowing all internal uses of an address to be qualified by a zone index. Also: An implementation should also support the concept of a "default" zone for each scope. And, when supported, the index value zero at each scope SHOULD be reserved to mean "use the default zone". Unlike other zone indices, the default index does not contain any scope, and the scope is determined by the address that the default index accompanies. An implementation may additionally define a separate default zone for each scope. Those default indices can also be used as the zone qualifier for an address for which the node is attached to only one zone; e.g., when using global addresses. If I read well, recent Linux kernels might have decided that the first Ethernet interface is the default zone. Or at least this is how I understand the *requires* above. [1] https://tools.ietf.org/html/rfc4291#section-2.5.6 [2] https://tools.ietf.org/html/rfc4007
Re: Debian jessie > buster IPv6 link scope change of behaviour
On Wed, Jan 20, 2021 at 11:59:46PM -0600, David Wright wrote: > As far as the address is concerned, fe80::1 is perfectly formed, > but ambiguous. Is that what your jessie error message used to say? The error was one of the usual kernel errors (-EINVALID probably), see below. Actually, stretch does the same (Linux ns2 4.9.0-14-amd64 #1 SMP Debian 4.9.246-2 (2020-12-17) x86_64 GNU/Linux): root@ns2 ~ # ping6 fe80::1 connect: Invalid argument root@ns2 ~ # ping6 fe80::1%2 PING fe80::1%2(fe80::1%eth0) 56 data bytes 64 bytes from fe80::1%eth0: icmp_seq=1 ttl=255 time=0.423 ms 64 bytes from fe80::1%eth0: icmp_seq=2 ttl=255 time=0.332 ms 64 bytes from fe80::1%eth0: icmp_seq=3 ttl=255 time=0.305 ms 64 bytes from fe80::1%eth0: icmp_seq=4 ttl=255 time=0.355 ms fe80::1 is specifically a link-local scope, a bit like if you try to access a class variable without telling in what class it is.
Debian jessie > buster IPv6 link scope change of behaviour
Hello, I experiment a change of behaviour between the kernel of Debian jessie and Debian buster. Namely, before, ping6 fe80::1 would fail, since it is ambiguous (fe80::1 is a link scope, thus a zone/interface scope ID is required). With buster, it tries the first Ethernet interface, no error (unless NDP does not find it, obviously). The correct behaviour when specifying the zone (interface scope ID) is the same on both versions: ping6 fe80::1%eth0 # e.g. Is there something broken with my setup, or has something changed in the way the Linux kernel behaves when the required zone (interface scope ID) is not specified ? I found the idea of reporting an error when a scope is not given very correct, simple and pedagogic (aka jessie behaviour). Thank you for your help :) PS: I upgraded from jessie to buster, so I don't know when the behaviour change happened in the Linux kernel
leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 27 days
Hello,
I quickly grepped my DEBIAN-USER mailing-list file but did not find any
leapsecond in it, thus this message.
I get this error on all of my buster machines although I think they are
uptodate:
Dec 1 09:34:39 virtual ntpd[2432]: leapsecond file
('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 27 days
A quick Internet search shows this:
https://www.mail-archive.com/debian-glibc@lists.debian.org/msg59571.html
Apparently, the Debian distributed file will expire on 2020-12-28.
However, it seems the next Debian point release scheduled on 2020-12-05
contains an update for tzdata, so it should be fixed then.
Re: Kernel global lock in sr.c slows down parallel operations to multiple drive
On Tue, Nov 17, 2020 at 07:04:59AM -0500, The Wanderer wrote: > FWIW, I parsed this as "and possibly file a(nother) bug report[ about > this bug, since the one I thought I remembered having filed before seems > to have disappeared, if it ever existed in the first place]". Exactly, thank you for parsing! Actually I just found the old bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816211 Of course, as it was reported on a backport kernel, I guess no one cared :)
Kernel global lock in sr.c slows down parallel operations to multiple drive
Hello, In jessie, the kernel had a very annoying bug: if you did I/O on multiple sr devices, the global lock in sr.c would slow down to a crawl. E.g. 5 DVD-R written to in parallel gave the same performance as one writing; and ejecting the DVD in parallel was completely sequential. Based on this: https://unix.stackexchange.com/questions/411735/why-does-linux-kernel-driver-sr-c-sr-block-ioctl-do-mutex-lock and this: https://www.spinics.net/lists/linux-scsi/msg63706.html I patched my kernel, and the performance augmented drastically, you can watch the video here: https://www.youtube.com/watch?v=siDMzkRCTpQ=youtu.be or here: https://peertube.gaialabs.ch/videos/watch/7ad190bd-43d9-42dc-9336-984822db7cc3 I even think I reported that bug, but can't find it anymore. However, it seems the kernel used by buster has the same issue. I am now writing with BR drives (two of them) and I get abyssal performance. Anyone can confirm ? I will try to apply a similar patch and possibly report another bug.
Re: PCI-Express not mapping a card's memory
On Sun, Nov 08, 2020 at 05:54:14PM +0100, Marc SCHAEFER wrote: > What could I try to do? Thanks to some people around here (private replies), I tried: - finding an option in the BIOS about 64 bit PCI addresses, none found - setpci -s 01:00.0 COMMAND=0x02 - removing all cards, shuffling them around - upgrading the BIOS Unfortunately, it does not work. I thus replaced the mainboard from 2014 with one from 2017 and it works.
PCI-Express not mapping a card's memory
Hello, I have a Mellanox card, which is detected, however on one machine: 01:00.0 Network controller: Mellanox Technologies MT27500 Family [ConnectX-3] Subsystem: Mellanox Technologies MT27500 Family [ConnectX-3] Flags: fast devsel, IRQ 16 Memory at dfb0 (64-bit, non-prefetchable) [size=1M] Memory at (64-bit, prefetchable) and on another machine, it differs: Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at cf80 (64-bit, prefetchable) [size=8M] Obviously on the machine with , I get a driver error, where it works on the other. [1.257148] mlx4_core: Mellanox ConnectX core driver v4.0-0 [1.257163] mlx4_core: Initializing :01:00.0 [1.257196] mlx4_core :01:00.0: enabling device ( -> 0002) [1.257303] mlx4_core :01:00.0: Missing UAR, aborting I tried to use another 16x slot on the failing machine, and even to update the BIOS: no change. dmesg says: [0.438011] pci :01:00.0: [15b3:1003] type 00 class 0x028000 [0.438414] pci :01:00.0: reg 0x10: [mem 0xf7e0-0xf7ef 64bit] [0.438580] pci :01:00.0: reg 0x18: [mem 0xf000-0xf07f 64bit pref] [0.440372] pci :01:00.0: reg 0x134: [mem 0x-0x007f 64bit pref] [0.440373] pci :01:00.0: VF(n) BAR2 space: [mem 0x-0x07ff 64bit pref] (contains BAR2 for 16 VFs) [0.458296] pci :01:00.0: BAR 9: no space for [mem size 0x0800 64bit pref] [0.458298] pci :01:00.0: BAR 9: failed to assign [mem size 0x0800 64bit pref] [0.458382] pci :01:00.0: BAR 2: no space for [mem size 0x0080 64bit pref] [0.458383] pci :01:00.0: BAR 2: failed to assign [mem size 0x0080 64bit pref] [0.458384] pci :01:00.0: BAR 9: no space for [mem size 0x0800 64bit pref] [0.458385] pci :01:00.0: BAR 9: failed to assign [mem size 0x0800 64bit pref] [0.458491] pci :01:00.0: BAR 2: no space for [mem size 0x0080 64bit pref] [0.458492] pci :01:00.0: BAR 2: failed to assign [mem size 0x0080 64bit pref] [0.458493] pci :01:00.0: BAR 9: no space for [mem size 0x0800 64bit pref] [0.458494] pci :01:00.0: BAR 9: failed to assign [mem size 0x0800 64bit pref] [0.458495] pci :01:00.0: BAR 0: assigned [mem 0xdfb0-0xdfbf 64bit] [0.458627] pci :01:00.0: BAR 2: no space for [mem size 0x0080 64bit pref] [0.458627] pci :01:00.0: BAR 2: failed to assign [mem size 0x0080 64bit pref] [0.458629] pci :01:00.0: BAR 0: assigned [mem 0xdfb0-0xdfbf 64bit] [0.458759] pci :01:00.0: BAR 9: no space for [mem size 0x0800 64bit pref] [0.458760] pci :01:00.0: BAR 9: failed to assign [mem size 0x0800 64bit pref] I also tried to boot with an debian installer for testing and I had similar PCI messages above. What could I try to do? Chipset on the failed machine is somewhat older than on the working machine. Thank you for any idea or pointer.
Re: xterm no title (buster)
On Mon, Aug 10, 2020 at 07:03:26PM +0200, Marc SCHAEFER wrote: > Should I try with another window-manager? I will also double-check that > the other working buster MATE installation uses marco. The bug is NOT present with compiz. The bug IS NOT present on a fresh buster install with marco. I tried for i in .???*; do find $i -name '*marco*' -print; done to see if any local marco-specific config existed, but could not find any.
Re: xterm no title (buster)
On Mon, Aug 10, 2020 at 01:47:08PM +0200, to...@tuxteam.de wrote: > Have you tried another "classic" X program? For example xmag or xeyes? Yes, they fail miserably. > xterm in a special way, or the decorations of all "classic" X programs > fail in the same way. I would guess that. Should I try with another window-manager? I will also double-check that the other working buster MATE installation uses marco.
Re: xterm no title (buster)
On Sun, Aug 09, 2020 at 09:59:12AM +0200, to...@tuxteam.de wrote: > To verify/falsify that, you might run xprop on your xterm window. > The property you are looking for is called WM_NAME. You can even xprop | grep WM_NAME WM_NAME(STRING) = "schaefer@reliand: /home/schaefer" > use xprop to /set/ the window property -- this way you can be sure xprop -f WM_NAME 8s -set WM_NAME "toto" clicking on either the titleless xterm or an emacs changes nothing (*). NB: the xterm window title is seen on MATE's taskbar. > whether it's xterm who is forgetting to do the right thing (that > would be a bug to file against xterm) or it's your window manager > ignoring it. As I am the only one to experience this, it must be some configuration somewhere! > [2] https://en.wikipedia.org/wiki/ICCCM Thank you, definitely is an interesting reference. (*) examples often show xprop -set WM_NAME "toto" but it does not work (cannot convert WM_NAME argument to STRING or COMPOUND_TEXT), thus the -f
Re: xterm no title (buster)
On Sat, Aug 08, 2020 at 02:22:44PM -0700, Mike Kupfer wrote: > I assume you're using the system xterm, not something in /usr/local or > $HOME. yes schaefer@reliand:~$ which xterm /usr/bin/xterm (BTW was working nice before upgrade to buster) > Could the problem be locale-related? I have > > LANG=en_US.UTF-8 > XTERM_LOCALE=en_US.UTF-8 I tried setting the locale to LANG=fr_CH.UTF-8 XTERM_LOCALE=fr_CH.UTF-8 and clearing the other settings to no avail. I will do some tests tomorrow on a fresh buster install.
Re: xterm no title (buster)
> > What about if you use another window-manager and/or desktop-environment? > > I haven't tried that yet. I just tried twm and it says "Untitled" even with xterm -T abcd &
Re: xterm no title (buster)
On Sat, Aug 08, 2020 at 08:25:39AM -0400, Stefan Monnier wrote: > Does it affect other terminal emulators? no, mate-terminal is not affected. > Have you checked whether the problem also shows up for a freshly created > user (i.e. without any config of your own)? yes, it does. > What about if you use another window-manager and/or desktop-environment? I haven't tried that yet. also: On Sat, Aug 08, 2020 at 02:42:18PM +0200, to...@tuxteam.de wrote: > Xterm's title is most probably your window manager's job. What's yours? MATE marco.
Re: xterm no title (buster)
On Sat, Aug 08, 2020 at 09:47:56AM +, Long Wind wrote: > have you looked at .bashrc? Actually, I have sent the usual title escape sequence: it works in mate-terminal, but xterm's title remains blank. Thomas Schmitt : Also I tried the -T option, with no success. Running MATE in marco (buster).
xterm no title (buster)
Hello, I have a funny problem since I upgraded my laptop to buster: xterm does not have any title. It is the only window that has this problem. I did not see anything special in the .Xresources. Anyone having this issue ? Thank you for pointers.
Re: lxc-cgroup -n 11 cpuacct.stat is empty in buster
On Thu, Aug 08, 2019 at 12:23:15PM +0300, Reco wrote: > lxc-cgroup -n 11 -o /dev/stdout -l INFO cpuacct.stat > And you'll probably have to apply some amount of sed to the output. > Try it, you'll see what I'm talking about. Oh, yes. Should I have read the manpage more closely (for me a log file is not a program output :->) Thank you very much, it works like a charm. Oh, well, I will need to update some of the lxc scripts, but it doesn't look that difficult. Additional questions: should I contact the Debian maintainer of munin plugins, or the upstream, to contribute my lxc scripts (actually they are not mine, I modified them, found them on a mailing-list originally, I will need to clear that up first) ?
lxc-cgroup -n 11 cpuacct.stat is empty in buster
Hello, I just updated a jessie system to buster. Kudos to the packagers of lxc, the upgrade script worked and the containers work like a charm. However, I have an issue with some lxc munin plugins I use. Namely they don't show anything. It reduces to the following problem: lxc-cgroup -n 11 cpuacct.stat (and also lxc-cgroup -n 11 cpu.stat) is now empty (the same is valid for other cgroup stuff). before, it would output something like: user 9650090 system 1645066 I found this reported here: https://github.com/lxc/lxc/issues/2742 and here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929926 however, this is supposedly fixed in 1:3.1.0+really3.0.3-8 which is what is installed on my system. So, maybe it's a config option I missed ? lxc-checkconfig says: Kernel configuration found at /boot/config-4.19.0-5-amd64 --- Namespaces --- Namespaces: enabled Utsname namespace: enabled Ipc namespace: enabled Pid namespace: enabled User namespace: enabled Network namespace: enabled --- Control groups --- Cgroups: enabled Cgroup v1 mount points: /sys/fs/cgroup/systemd /sys/fs/cgroup/pids /sys/fs/cgroup/perf_event /sys/fs/cgroup/freezer /sys/fs/cgroup/cpu,cpuacct /sys/fs/cgroup/net_cls,net_prio /sys/fs/cgroup/blkio /sys/fs/cgroup/rdma /sys/fs/cgroup/devices /sys/fs/cgroup/memory /sys/fs/cgroup/cpuset Cgroup v2 mount points: /sys/fs/cgroup/unified Cgroup v1 clone_children flag: enabled Cgroup device: enabled Cgroup sched: enabled Cgroup cpu account: enabled Cgroup memory controller: enabled Cgroup cpuset: enabled --- Misc --- Veth pair device: enabled, loaded Macvlan: enabled, not loaded Vlan: enabled, not loaded Bridges: enabled, loaded Advanced netfilter: enabled, loaded CONFIG_NF_NAT_IPV4: enabled, loaded CONFIG_NF_NAT_IPV6: enabled, not loaded CONFIG_IP_NF_TARGET_MASQUERADE: enabled, not loaded CONFIG_IP6_NF_TARGET_MASQUERADE: enabled, not loaded CONFIG_NETFILTER_XT_TARGET_CHECKSUM: enabled, loaded CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled, not loaded FUSE (for use with lxcfs): enabled, loaded --- Checkpoint/Restore --- checkpoint restore: enabled CONFIG_FHANDLE: enabled CONFIG_EVENTFD: enabled CONFIG_EPOLL: enabled CONFIG_UNIX_DIAG: enabled CONFIG_INET_DIAG: enabled CONFIG_PACKET_DIAG: enabled CONFIG_NETLINK_DIAG: enabled File capabilities: Note : Before booting a new kernel, you can check its configuration usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig Would you have any idea how to fix this ? Thank you for your input.
Re: Captive network account (w/ login redirect) and HSTS
On Sun, Apr 02, 2017 at 03:20:56PM -0500, David Wright wrote: > IIRC I have in the past typed ip route show > and then pasted the IP of the default route into the browser. > Am I remembering correctly, and would that IP address obey > your conditions outlined earlier? That would work too, even if default router is not the captive portal itself. Let's put that in the doc.
Re: Captive network account (w/ login redirect) and HSTS
On Sun, Apr 02, 2017 at 07:51:40PM +0100, Brian wrote: > Probably the best place for this is the wiki. Anyone can create a page > on the topic of captive networks there. Maybe there one is in existence > which can be added to. Feel free to add to such a page or start a new > one. I did not find any, so I created: https://wiki.debian.org/CaptivePortal Thank you for the suggestion.
Captive network account (w/ login redirect) and HSTS
Hello, with a basic Debian jessie install and a recent Firefox, I observe the following: [1] Debian has no specific support for detecting captive networks (e.g. Android, iOS) and redirecting automatically the browser to the captive login page [2] launching Firefox on the default page doesn't work (doesn't get redirected properly to the login page but fails with a HTTPS certificate error), if there is a recent HSTS[*] security configuration cache for the default domain page (e.g. google.com) [1] is not really an issue: I wouldn't like myself that connecting to a WiFi captive network starts a browser. Also, open captive networks are messing up, dangerous, a WPA/RADIUS auth would be much better. However, open captive networks are quite commons in hotels, airports, parks, etc. So it cannot be dismissed. [2] the only fix is to type an URL you know is HTTP, not HTTPS and does not configure HSTS, and does not support DNSSEC. In my case I used ptiturl.ch Maybe this could be in the Debian User manual somehow? Feel free to contact me if you want help in writing the documentation. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Re: enabling remote X Window sessions
On Fri, Aug 22, 2014 at 08:10:45AM -0500, Buchs, Kevin J. wrote: Thanks for the comment, Nuno. I only want to run a single X client, so XDMCP is not the way to go. My problem is solely getting Xorg to start on Debian without the -nolisten tcp argument. On CentOS, this is the default and I can run remote X clients without any issues. Since switching to Debian, I have been thwarted. A secure way would be to SSH from the X11 server to the client, example: x11-server-this-is-the-screen% ssh -X client-where-app-is-started xclock then xclock displays on the screen, completely safely and security through SSH. However, if you really want to open the TCP port 6000 so as to make your X11 setup insecure, you simply need to modify /etc/X11/xinit/xserverrc and remove the `-nolisten tcp' -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140822131901.ga26...@alphanet.ch
Re: Simple system-wide autoconfiguration for GNOME 3
Replying to myself, this is the working solution. It is not that pretty, but has the advantage to be easily compatible each time GNOME will change the way it handles configuration files. ---/usr/local/etc/gnome3-user-settings--- #! /bin/bash gsettings set org.gnome.nautilus.desktop volumes-visible true gsettings set org.gnome.desktop.background show-desktop-icons true gsettings set org.gnome.desktop.background picture-uri '' gsettings set org.gnome.desktop.background primary-color '#00' gsettings set org.gnome.desktop.background secondary-color '#00' gsettings set org.gnome.desktop.wm.preferences focus-mode 'sloppy' gsettings set org.gnome.desktop.wm.preferences raise-on-click false gsettings set org.gnome.shell.overrides button-layout :minimize,maximize,close ---/etc/skel/.xsession--- #! /bin/bash /usr/local/etc/gnome3-user-settings rm -f $0 exec x-session-manager -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140620193018.ga22...@alphanet.ch
Simple system-wide autoconfiguration for GNOME 3
Hi, I can somewhat influence GNOME 3 (wheezy) to my taste, with the following commands, to be run under X11/GNOME and valid for the logged user only: gsettings set org.gnome.nautilus.desktop volumes-visible true gsettings set org.gnome.desktop.background show-desktop-icons true gsettings set org.gnome.desktop.background picture-uri '' gsettings set org.gnome.desktop.background primary-color '#00' gsettings set org.gnome.desktop.background secondary-color '#00' gsettings set org.gnome.desktop.wm.preferences focus-mode 'sloppy' gsettings set org.gnome.desktop.wm.preferences raise-on-click false gsettings set org.gnome.shell.overrides button-layout :minimize,maximize,close Unfortunately, gsettings seems to be interactively communicating with some daemon (dbus), and this daemon doesn't exist when I am installing. Moreover, the user doesn't exist yet, and I want a system-wide default. I am automatically installing with FAI. Below, I will remove the FAI details (such as $target) so to make it more understandable. I tried a list of different ideas, and the last one is the following, for example for the first gsettings above. gconftool --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults --type boolean --set /org/gnome/nautilus/desktop/volumes-visible true This creates, correctly, a file /etc/gconf/gconf.xml.defaults/%gconf-tree.xml which seems to contain correct settings. However they are not activated. What is the best way to automatically and system-wide set GNOME configurations, through bash, at automatic installation time ? Thank you for any wheezy/GNOME3 compatible pointers. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140619143813.ga14...@alphanet.ch
ext4 issue
Hi, on a quite new machine, with ECC memory, stress-tested before installing, installed about a month ago, everything was fine, running squeeze (linux-image-2.6.32-5-openvz-amd64) I upgraded the kernel to the latest release (2.6.32-41) and apart from the load average being wrong in some VEs, seemed to work quite well. But this week-end I had twice something like: Feb 5 14:05:40 virtual kernel: [408480.738756] EXT4-fs error (device dm-5): ext4_lookup: deleted inode referenced: 11152211 Feb 5 14:05:40 virtual kernel: [408480.738793] Aborting journal on device dm-5-8. Feb 5 14:05:40 virtual kernel: [408480.779450] EXT4-fs (dm-5): Remounting filesystem read-only Feb 5 14:05:40 virtual kernel: [408480.850473] EXT4-fs error (device dm-5): ext4_lookup: deleted inode referenced: 11152219 Feb 5 14:05:40 virtual kernel: [408480.852522] EXT4-fs error (device dm-5): ext4_lookup: deleted inode referenced: 11152212 Feb 5 14:06:19 virtual kernel: [408519.740348] EXT4-fs error (device dm-5): ext4_lookup: deleted inode referenced: 11152220 Unmounting, then running fsck.ext4 -f on the raw device only gave a few deleted inodes warnings. Running a second time did not show any problem. The 104 VZ is on a specific LV, filesystem ext4, in a VG which is on a RAID10 (4 disks) md array. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206085348.ga26...@alphanet.ch
[schaefer: Re: Disabling some services indivually and easily (nut)]
First, some software already uses kernel-passed command line to disable or enable user-space services, namely knoppix. And of course debian-installer. Second, I will probably file a bug against nut, however it is really difficult to discriminate between UPS not installed *intentionnally* and not, that's why there is a problem there. PS: I have tried to subscribe to debian-user, but failed, I will try again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Disabling some services indivually and easily (nut)
Summary: I wanted an administratively easy way to disable a service from running, something that could be specified at the LILO or GRUB boot prompt. I proposed to disable this service in run level 3, while still leaving it running at level 2. This would mean disabling the service would be as easy as adding a `3' at the end of the command line I was however concerned that this method would not really be maintainable, nor very practical if there are many services to disable independantly (I would quickly run out of usable run levels). (my practical question was about nut doing an immediate shutdown of the machine when the UPS cable was not connected; which would mean that in case of failure of the UPS, starting the system would be impossible without an in-field manipulation of the system rc2.d directory. I didn't find any easy way to configure nut to act specially on the system boot, thus this idea of service disabling). Suggestions given: - remove the /etc/rc2.d/S*nut okay, but this is regarded as complex, you don't want non savvy system-administrators to remove random files in the system - use the level 3 modification works, is quite easy, but is not reallys scalable, and you need to know in advance what services are going to break for some reason. So, another idea I had: - add a disable-service=serv1,serv2,... kernel command line that would be parsed by some Debian service at boot and would temporarily disable the rc.d runner script from starting those services Would that be a good idea ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Disabling some services indivually and easily (nut)
Hi, I have the following issue: if the cable to the UPS is removed, nut will shutdown the server. This is perfectly correct, when the UPS is supposed to be there. But when it has failed and is not in house ? First, I thought that nut could consider the system boot as a special case, and if the cable/UPS is not present, just quit gracefully, possibly with a warning mail. However, this could be dangerous in some environments. Thus the comportment of nut always shutting down when configurer is correct. So, another idea came to me, which was to use run-levels (e.g. normal with nut as init 2, and without nut as init 3. Selection done easily through a LILO menu). However this adds a lot of complexity, and this is not wanted. So, what about a kernel option `disable-services=nut,apache,whatever' which would be processed by Debian init script and disable the named services ? What do you think ? thank you for any idea! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gpg-idea missing in potato
Hi, apparently gpg-idea was removed from the archives at some point (stable). Can someone confirm/explain this ? thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: probleme /var/lib/dpkg/status
On Wed, 6 Feb 2002, Geoffroy Baud wrote: merci a tous j ai pu regler mon probleme en deplacent le dpkg.status.o du rep /var/backup et en le renomant bien. La question maintenant est: qu'est-ce qui a effacé ce fichier ? En 4 ans d'utilisation de Debian je n'ai jamais eu ce problème (du moins en stable). Ce qui me fait penser à un problème plus grave, genre crash, etc.
Re: AA with potato (strictly)
On Wed, 9 May 2001, Jens Benecke wrote: Windows kernel API to Linux. That means just about every performance boost But that also means that the Linux drivers need a proprietary Kernel module, which is so riddled with patents, NDAs and sub-contracts (which the [ and also that now a video driver can crash/corrupt the system much better than previously with the X I/O process model, like in Windows. ] So NVidia don't do it out of greed or stupidity, they do it because their lawyers tell them so, and because it cannot be changed that easily, and because 80% of NVidia doesn't NEED it to be changed. if the short term net result is to enhance the availability of drivers to Linux, good. But I am afraid this is going to be the path of many drivers, and thus we will loose in stability, cleanness and freedom.
(fwd) Re: Creating a bootable CD from online files!!
seg [EMAIL PROTECTED] wrote: Now, I have read all the possible instruction files from the debian Use the pseudo-image-kit (see http://cdimage.debian.org). I did use it successfully once. I have however heard that you need a very recent version of the utilities.
Re: Tape support under Linux 2.2.x
Robert Waldner [EMAIL PROTECTED] wrote: any SCSI-tapedrive should do AFAICT. never had any problems (with scsi, those things which reside on the floppy controller or come with their own cards are another matter altogether). Except the ones which do not behave like a SCSI Tape (Sequential Streaming) device, but have a proprietary or otherwise non standard protocol, such as, I think, the OnStream (which now has a Linux driver ... but it would have been SOOO easier if that device had been using the standard SCSI command set).
Installation manual: How to get the latest release ?
Hi, I intend to print a few (say 100) of the i386 French, German and English installation manuals. However, before sending this out, I would like to be sure it's the latest released version. For example, on the 2.2r2 CD1 you can find a file called install.pdf.fr, which is version 2.2.20 (30th of November 2000). But now, by using Google, I found a version 2.2.21. I read the manual and they suggest to use the CVS. Now, isn't it a simpler way, which would be something like apt-get install installation-manuals-2.2.21 and which would give me the PDFs for that release ? Or should I check out version 2.2.21 of the CVS, and then create the PDFs myself ? thanks for any tip.
Create potato CD from slink
Hi, I have an uptodate slink installation and a potato + slink mirror (as files). I read that you can automatically create images with the debian-cd*.deb package (that I have in my mirror). However, I cannot install it since it seems it requires a few other potato packages. I don't want to upgrade the machine where the CD build will be do to potato, I just want to create ISO images. Is it possible, and if yes, how can I do this ? Thank you for your time.
Re: Create potato CD from slink
Marc SCHAEFER [EMAIL PROTECTED] wrote: Is it possible, and if yes, how can I do this ? Yes, it seems possible (it is running at this time). All the needed information seems to be at: http://cdimage.debian.org/potato_pre.html
