Bug#986822: installation-reports: Debian 11 Breaks Analague sound on Thinkpad Helix 2nd Gen

[dekks herton]

Package: installation-reports
Severity: important
X-Debbugs-Cc: dekkz...@gmail.com

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: usb key
Image version: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-
including-firmware/weekly-builds/amd64/iso-dvd/firmware-testing-amd64-DVD-1.iso
Date: <31/03/2021>

Machine: Thinkpad Helix 2nd Gen
Partitions: 

Filesystem   Type 1K-blocks Used Available Use%
Mounted on
udev devtmpfs   39808240   3980824   0%
/dev
tmpfstmpfs   804352 2176802176   1%
/run
/dev/mapper/HELIX2NDGEN--vg-root ext4  28703652 11950108  15272432  44% /
tmpfstmpfs  4021748   132976   3888772   4%
/dev/shm
tmpfstmpfs 51204  5116   1%
/run/lock
/dev/sda2ext2483946   253033205928  56%
/boot
/dev/sda1vfat52324813344509904   3%
/boot/efi
/dev/mapper/HELIX2NDGEN--vg-home ext4 177483612  2645548 165752728   2%
/home
tmpfstmpfs   804348  164804184   1%
/run/user/1000

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[E]

Comments/Problems:

No analogue sound on Tablet from Broadwell-U from intel smart sound chipset -
hw works on Buster but breaks on Bullseye
Card0 on Buster no longer detected on Bullseye

Tried installing Intel SOF drivers/firmware to no effect, forcing snd_hda_intel
via modprobe conf doesn't work either
Broadwell-U works eith with HDA or SOF drivers theoretically.
There is record of a kernel compilation flag to enable SOF functionality
SND_SOC_SOF_BROADWELL_SUPPORT=Y breaking legacy and snd_hda_intel too.

inxi Audio output

Device-1: Intel Broadwell-U Audio vendor: Lenovo driver: snd_hda_intel
  v: kernel bus ID: 00:03.0
  Device-2: Realtek USB Audio type: USB driver: snd-usb-audio
  bus ID: 1-3.3:5
  Sound Server: ALSA v: k5.10.0-5-amd64

Buster aplay log

linux-image-4.19.0-14-amd644.19.171-2

 List of PLAYBACK Hardware Devices 
card 0: broadwellrt286 [broadwell-rt286], device 0: System Playback/Capture (*)
[]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: broadwellrt286 [broadwell-rt286], device 1: Offload0 Playback (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: broadwellrt286 [broadwell-rt286], device 2: Offload1 Playback (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: HDMI [HDA Intel HDMI], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: HDMI [HDA Intel HDMI], device 10: HDMI 4 [HDMI 4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Audio [USB Audio], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Bullseye aplay log

linux-image-5.10.0-4-amd64 5.10.19-1

 List of PLAYBACK Hardware Devices 
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 10: HDMI 4 [HDMI 4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Audio [USB Audio], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Re: [SOLVED] Re: Can't install Grub on SSD (bullseye)

[Steve McIntyre]

On Sat, Apr 10, 2021 at 07:52:29PM +0200, Xavier Brochard wrote:
>> > > On Tue, Apr 06, 2021 at 12:11:54AM +0200, Xavier Brochard wrote:
>> I'm currently testing the new installer for bullseye. I ran into a
>> strange problem with grub-install, using "bios" grub, not EFI. Basicaly
>> grub
>> files
>> are not copied in /boot/grub if my carget is a SSD.
>
>Problem SOLVED. It was unsufficient inodes on the SSD setup because I
>formated the /boot partition in Ext4 FS with largefile4 option.

Aha!! Thanks for continuing to dig and telling us the answer. :-)
Curious - was that a deliberate decision for the inode count??

>It would help to test inodes before installing grub.

Maybe. It's not such a common issue, as you might have guessed!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
We don't need no education.
We don't need no thought control.

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Samuel Thibault]

Petter Reinholdtsen, le lun. 12 avril 2021 07:34:38 +0200, a ecrit:
> Sad to hear the patch has been ignored for several years.

Please do not confuse "ignore" with "terribly understaffed".

Samuel

Re: Bug#986758: unblock: systemd/247.3-5

[Michael Biebl]

control: retitle -1 unblock: systemd/247.3-5

Am 11.04.21 um 18:48 schrieb Luca Boccassi:

Please unblock package systemd

As requested by Michael, opening unblock ticket. Debdiff attached. Two
high-impact patches are backported from upstream and should be included
in Bullseye.


Thanks Luca!


* Backport patch to fix assert with invalid LoadCredentials=
   Regression introduced in v247, fixed in v249, see:
   https://github.com/systemd/systemd/issues/19178
   (Closes: #986302)

* network: Delay addition of IPv6 Proxy NDP addresses.
   Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
   networkd adds them". (Closes: #985510)

The first patch fixes a crash when a malformed option is set in any
unit.

unblock systemd/247.3-4


I decided to make a 247.3-5 upload to fix #975018 as well:


udev-udeb: setup /dev/fd, /dev/std{in,out,err} symlinks

As systemd-udevd no longer sets them up itself, we create them manually

after mounting devtmpfs. This avoids breaking applications which expect



Somehow this issue did not show up on the systemd bug tracker, so I 
completely forgot about it. Apologies for that.


This fixes a regression which e.g. broke fetch-url and triggered a 
workaround in debian-installer-utils_1.134:



   [ Raphaël Hertzog ]
   * Use /proc/self/fd/4 instead of /dev/fd/4 to unbreak fetch-url with 

recent

 udev versions that no longer setup the /dev/fd symlink. Closes: #967546



I'd rather see this fixed for good. It's possible that other 
applications expect those symlinks as well.


This does affect udev-udeb, so kibi's ack would be appreciated.

Thanks for considering,
Michael


unblock systemd/247.3-5
diff --git a/debian/changelog b/debian/changelog
index 22a8ad2..0588fec 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,27 +1,3 @@
-systemd (247.3-5) unstable; urgency=medium
-
-  * udev-udeb: setup /dev/fd, /dev/std{in,out,err} symlinks.
-As systemd-udevd no longer sets them up itself, we create them manually
-after mounting devtmpfs. This avoids breaking applications which expect
-those symlinks. (Closes: #975018)
-
- -- Michael Biebl   Mon, 12 Apr 2021 20:21:24 +0200
-
-systemd (247.3-4) unstable; urgency=medium
-
-  [ Luca Boccassi ]
-  * Backport patch to fix assert with invalid LoadCredentials=
-Regression introduced in v247, fixed in v249, see:
-https://github.com/systemd/systemd/issues/19178
-(Closes: #986302)
-
-  [ Michael Biebl ]
-  * network: Delay addition of IPv6 Proxy NDP addresses.
-Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
-networkd adds them". (Closes: #985510)
-
- -- Michael Biebl   Sun, 11 Apr 2021 16:06:46 +0200
-
 systemd (247.3-3) unstable; urgency=medium
 
   * pkg-config: make prefix overridable again (Closes: #984763)
diff --git a/debian/extra/start-udev b/debian/extra/start-udev
index 0a8b284..6048925 100755
--- a/debian/extra/start-udev
+++ b/debian/extra/start-udev
@@ -6,11 +6,6 @@ fi
 
 if ! grep -E -q "^[^[:space:]]+ /dev devtmpfs" /proc/mounts; then
 mount -n -o mode=0755 -t devtmpfs devtmpfs /dev
-# Setup a few /dev symlinks, see #975018
-[ ! -h /dev/fd ] && ln -s /proc/self/fd /dev/fd
-[ ! -h /dev/stdin ] && ln -s /proc/self/fd/0 /dev/stdin
-[ ! -h /dev/stdout ] && ln -s /proc/self/fd/1 /dev/stdout
-[ ! -h /dev/stderr ] && ln -s /proc/self/fd/2 /dev/stderr
 fi
 
 SYSTEMD_LOG_LEVEL=notice /lib/systemd/systemd-udevd --daemon 
--resolve-names=never
diff --git 
a/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch 
b/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch
deleted file mode 100644
index c9e3500..000
--- a/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From: Luca Boccassi 
-Date: Thu, 1 Apr 2021 22:18:29 +0100
-Subject: LoadCredentials: do not assert on invalid syntax
-
-LoadCredentials=foo causes an assertion to be triggered, as we
-are not checking that the rvalue's right hand side part is non-empty
-before using it in unit_full_printf.
-
-Fixes #19178
-
-# printf [Service]nLoadCredential=passwd.hashed-password.rootn > hello.service
-# systemd-analyze verify ./hello.service
-...
-Assertion 'format' failed at src/core/unit-printf.c:232, function 
unit_full_printf(). Aborting.
-Aborted (core dumped)
-
-(cherry picked from commit f7a6f1226e800f7695c2073675523062ea697aa4)

- src/core/load-fragment.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
-index 4964249..5b66fb1 100644
 a/src/core/load-fragment.c
-+++ b/src/core/load-fragment.c
-@@ -4569,7 +4569,7 @@ int config_parse_load_credential(
- r = extract_first_word(&p, &word, ":", 
EXTRACT_DONT_COALESCE_SEPARATORS);
- if (r == -ENOMEM)
- return log_oom();
--if (r <= 0) {
-+if (r <= 0 || isempty(p)) {
- log_syntax(unit, LOG_WARNING, fil

Re: Finding a tentative bullseye release date

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sat, 10 Apr 2021 18:14:36 +0200):
> That's not just my opinion, but sort of consensus of the involved people.
> Going through the above mentioned thread shows that.
> There are also alternatives mentioned, but they all have their disadvantages,
> that's why the consensus.

May I submit a patch for this? (attached)


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/changelog b/debian/changelog
index c1598e53..257aaf1e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,36 +1,46 @@
 tasksel (3.66) UNRELEASED; urgency=medium
 
   [ Shengjing Zhu ]
   * Switch to fcitx5 for Simplified and Traditional Chinese desktop.
 Fcitx5 works for Wayland. (Closes: #983704)
 
+  [ Holger Wansing]
+  * GNOME now depends on ibus. For some languages, there are additional
+packages needed, to make ibus work. Adding them for Amharic, Simplified
+chinese, Traditional chinese, Japanese, Kannada, Malayalam and Telugu.
+This requites new task-*-gnome-desktop packages to be added for Amharic,
+Simplified chinese, Traditional chinese, and Kannada.
+Thanks to Shengjing Zhu for working out the circumstances.
+  * ibus does not have default configurations for all languages, so force
+to create one via gnome-initial-setup for all the languages using ibus.
+
  -- Holger Wansing   Sat, 20 Mar 2021 16:22:17 +0800
 
 tasksel (3.65) unstable; urgency=medium
 
   * Team upload.
 
   [ HIGUCHI Daisuke ]
   * tasksel-japanese-desktop: prefer uim-mozc over uim-anthy (Closes: #982175)
 
   [ Holger Wansing ]
   * Re-add manpages-it to task-italian task (package is again available in
 unstable/testing). Closes: #982043.
   * Add manpages translations from newly introduced manpages-l10n package
 (manpages-pt-br, manpages-nl, manpages-mk, manpages-ro, manpages-es)
 to the respective language tasks (see #982043).
   * Re-add synaptic to gnome desktop tasks. Closes: #983074
   * Remove scim-qt-immodule from task-chinese-t-kde-desktop, since it's no
 longer in the archive.
 
   [ YOSHINO Yoshihito ]
   * Let gnome-flashback-desktop task in Japanese pull
 task-japanese-gnome-desktop. Closes: #983688
 
  -- Holger Wansing   Sat, 13 Mar 2021 16:26:46 +0100
 
 tasksel (3.64) unstable; urgency=medium
 
   * Team upload.
 
   [ Holger Wansing ]
diff --git a/debian/control b/debian/control
index 30feb782..b4f39cd8 100644
--- a/debian/control
+++ b/debian/control
@@ -412,60 +412,70 @@ Architecture: all
 Description: Albanian desktop
  This task localises the desktop in Albanian.
 Depends: ${misc:Depends},
 Recommends:
 	firefox-esr-l10n-sq | firefox-l10n-sq,
 	myspell-sq,
 
 Package: task-amharic
 Architecture: all
 Description: Amharic environment
  This task installs programs, data files, fonts, and
  documentation that makes it easier for Amharic speakers
  to use Debian.
 Depends: ${misc:Depends},
 Recommends:
 	aspell-am
 
 Package: task-amharic-desktop
 Architecture: all
 Description: Amharic desktop
  This task localises the desktop in Amharic.
 Depends: ${misc:Depends}
 Recommends:
 	fonts-sil-abyssinica,
 	fcitx,
 	fcitx-table-amharic,
 	fcitx-frontend-gtk2,
 	fcitx-frontend-gtk3,
 	fcitx-config-gtk
 
+Package: task-amharic-gnome-desktop
+Architecture: all
+Description: Amharic GNOME desktop
+ This task localises the GNOME desktop in Amharic.
+Depends: ${misc:Depends}
+Recommends:
+	ibus-m17n,
+# ibus doesn't have a default config for all languages, so force creation
+	gnome-initial-setup
+
 Package: task-amharic-kde-desktop
 Architecture: all
 Description: Amharic KDE Plasma desktop
  This task localises the KDE Plasma desktop in Amharic.
 Depends: ${misc:Depends},
 Recommends:
 	fcitx-frontend-qt5,
 	kde-config-fcitx
 
 Package: task-arabic
 Architecture: all
 Description: Arabic environment
  This task installs programs, data files, fonts, and
  documentation that makes it easier for Arabic speakers
  to use Debian.
 Depends: ${misc:Depends},
 Recommends:
 	fonts-arabeyes,
 	aspell-ar,
 	aspell-ar-large,
 	itools
 
 Package: task-arabic-desktop
 Architecture: all
 Description: Arabic desktop
  This task localises the desktop in Arabic.
 Depends: ${misc:Depends},
 Recommends:
 	fonts-kacst,
 	fonts-farsiweb,
@@ -724,103 +734,123 @@ Recommends:
 	opencc,
 	zhcon,
 	manpages-zh,
 
 Package: task-chinese-s-desktop
 Architecture: all
 Description: Simplified Chinese desktop
  This task localises the desktop in Simplified Chinese.
 Depends: ${misc:Depends},
 Recommends:
 # Input method stuff
 	im-config,
 	fcitx5,
 	fcitx5-chinese-addons,
 # Fonts
 	fonts-noto,
 	fonts-noto-cjk,
 # Software help and localization
 	libreoffice-l10n-zh-cn,
 	libreoffice-help-zh-cn,
 	firefox-esr-l10n-zh-cn | firefox-l10n-zh-cn,
 # Dictionary
 	goldendict,
 # poppler-data is needed to display
 # Chinese on poppler applications.
 	poppler-data
 Suggests:
 	fonts-arphic-ukai,
 	fonts-arphic-uming
 
+Package: task-chinese-s-gnome

Re: serial console install issues, all the links of the chain

[Richard Hector]

On 12/04/21 6:18 pm, Geert Stappers wrote:


Do we know the "path" that original poster is using?

Possible format for answer to this

  - APU device
  - 9-pin serial connector
  - null-modem, cross connects everthing
  - 9-pin serial connector
  - USB-Serial-Adapter
  - Linux computer
  - XFCE desktop
  - "terminal window", sized at 80x26 character
  - application `screen`
  - User


More or less right. I'm not sure of the specs of the null-modem cable; I 
found it amongst my collection of junk. For all I know it's straight 
through and the USB adapter autodetects - is that a thing?


But I also don't see the significance - I've had no issues that look 
like communications problems, flow control problems or anything like that.


Cheers,
Richard

Re: serial console install issues

[Ben Hutchings]

On Mon, 2021-04-12 at 13:48 +1200, Richard Hector wrote:
> On 11/04/21 9:26 pm, Samuel Thibault wrote:
> > Richard Hector, le dim. 11 avril 2021 21:18:49 +1200, a ecrit:
> > > On 11/04/21 9:10 pm, Samuel Thibault wrote:
> > > > $ git grep -i "Boot console" .
> > > > en/boot-installer/parameters.xml:  Boot console
> > > > po/[...]
> > > > 
> > > > That's very most probably it.
> > > 
> > > I think so, yes. But my problems started earlier than booting linux, at 
> > > the
> > > SysLinux menu.
> > 
> > See the section, it talks about kernel arguments, which are passed from
> > the syslinux menu. See the section just before, "Boot Parameters".
> 
> Yes.
> 
> It's becoming clear that I asked/commented/complained about too many 
> things in one email :-)
> 
> I got the hang of the boot parameters, though that section doesn't 
> mention removing the 'vga=xxx' section from the linux command line. I'm 
> not sure if that's important; I'll have to retest to confirm.
> 
> But all that's irrelevant if I can't get to the linux commandline, 
> because Syslinux is misbehaving.
>
> Does anyone know if it's inherent in Syslinux that it won't work 
> correctly with a 24-line serial terminal?
[...]

I think that syslinux is working through a BIOS-emulated display and
keyboard controller, and is not aware that a serial terminal is beign
used.  The code for SeaBIOS's serial console support is here:
. 
It presents an 80x25 (or 40x25) text display as there is no VGA BIOS
mode number for 80x24.

Ben.


-- 
Ben Hutchings
The world is coming to an end.  Please log off.


signature.asc
Description: This is a digitally signed message part

Re: serial console install issues

[Richard Hector]

On 13/04/21 12:31 pm, Ben Hutchings wrote:

On Mon, 2021-04-12 at 13:48 +1200, Richard Hector wrote:

On 11/04/21 9:26 pm, Samuel Thibault wrote:
> Richard Hector, le dim. 11 avril 2021 21:18:49 +1200, a ecrit:
> > On 11/04/21 9:10 pm, Samuel Thibault wrote:
> > > $ git grep -i "Boot console" .
> > > en/boot-installer/parameters.xml:  Boot console
> > > po/[...]
> > > 
> > > That's very most probably it.
> > 
> > I think so, yes. But my problems started earlier than booting linux, at the

> > SysLinux menu.
> 
> See the section, it talks about kernel arguments, which are passed from

> the syslinux menu. See the section just before, "Boot Parameters".

Yes.

It's becoming clear that I asked/commented/complained about too many 
things in one email :-)


I got the hang of the boot parameters, though that section doesn't 
mention removing the 'vga=xxx' section from the linux command line. I'm 
not sure if that's important; I'll have to retest to confirm.


But all that's irrelevant if I can't get to the linux commandline, 
because Syslinux is misbehaving.


Does anyone know if it's inherent in Syslinux that it won't work 
correctly with a 24-line serial terminal?

[...]

I think that syslinux is working through a BIOS-emulated display and
keyboard controller, and is not aware that a serial terminal is beign
used.  The code for SeaBIOS's serial console support is here:
.
It presents an 80x25 (or 40x25) text display as there is no VGA BIOS
mode number for 80x24.


Ah - so while syslinux can talk to a serial console, it's not using that 
in this case? Interesting, thanks. That could explain why I haven't seen 
this on previous serial console installations (an old Soekris box).


That might make it more difficult to solve in software, leaving more 
documentation as the only answer.


Cheers,
Richard

Bug#985481: debootstrap: Detection of docker container is broken with cgroup v2

[Arnaud Rebillout]

Hello Nicholas! Thanks for your feedback here, see replies below.


On Sun, 11 Apr 2021 11:51:20 -0400 Nicholas D Steeves 
 wrote:


> I'm not sure that systemd-detect-virt and your patch are
> forward-compatible in light of
>
> Originally, ".dockerenv" was for transmitting the environment
> variables of the container across the container boundary -- I would
> not recommend relying on its existence either (IIRC, that code
> you've linked to is the only reason it still exists). There's
> likely something incriminatory inside /sys/fs/cgroup, but I haven't
> checked recently.
> https://github.com/moby/moby/issues/18355#issuecomment-220484748
>
> This makes it sounds like ".dockerenv" may be deprecated and later
> removed.

That's a good point, but it's also a 5 years old comment, and the 
.dockerenv file is still present these days.


I would think that if Docker plans to remove it, they will issue a more 
formal deprecation warning that will give us enough time to fix things 
on our side. Also the fact that systemd checks for this file gives me 
more confidence that it's not just me doing something fancy here: it 
seems that this is the "de facto" solution to detect docker containers.


FWIW, it's also the most common solution on Q&A sites like 
stackoverflow. Other people do that, because there is no better solution 
provided apparently. Unless I missed it.



> Cgroup v2 is also mounted at /sys/fs/cgroup, so I wonder if the original
> check should be rewritten to check for something under this path instead
> of mountinfo?  Also, using this /sys/fs/cgroup method, I'm not sure if
> it's better debootstrap style to express the OR logical operator in the
> regex or a shell "||" (ie: seems to be needed because the tree under
> /sys/fs/cgroup is different between v1 and v2).

I just had a quick look in /sys/fs/cgroup from within a container. 
Nothing obvious stands out, there's no file named docker, and nothing in 
the content of those files mentions docker. I'll attach the output below.


I will CC Tianon, as he was the author of the comment mentioned above, 
and he might know better, 5 years after :)


In short, Tianon, if you're reading those lines, our question is: what 
would be the right way to detect that we're running from within a docker 
container, apart from checking for the existence of the file 
`/.dockerenv` ???


Thanks !



 Logs -- checking /sys/fs/cgroup from within a docker container


# head -n 100 /sys/fs/cgroup/*
==> /sys/fs/cgroup/cgroup.controllers <==
cpuset cpu io memory hugetlb pids rdma

==> /sys/fs/cgroup/cgroup.events <==
populated 1
frozen 0

==> /sys/fs/cgroup/cgroup.freeze <==
0

==> /sys/fs/cgroup/cgroup.max.depth <==
max

==> /sys/fs/cgroup/cgroup.max.descendants <==
max

==> /sys/fs/cgroup/cgroup.procs <==
1
16

==> /sys/fs/cgroup/cgroup.stat <==
nr_descendants 0
nr_dying_descendants 0

==> /sys/fs/cgroup/cgroup.subtree_control <==

==> /sys/fs/cgroup/cgroup.threads <==
1
16

==> /sys/fs/cgroup/cgroup.type <==
domain

==> /sys/fs/cgroup/cpu.max <==
max 10

==> /sys/fs/cgroup/cpu.pressure <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=6857

==> /sys/fs/cgroup/cpu.stat <==
usage_usec 145464
user_usec 57509
system_usec 87955
nr_periods 0
nr_throttled 0
throttled_usec 0

==> /sys/fs/cgroup/cpu.weight <==
100

==> /sys/fs/cgroup/cpu.weight.nice <==
0

==> /sys/fs/cgroup/cpuset.cpus <==


==> /sys/fs/cgroup/cpuset.cpus.effective <==
0-7

==> /sys/fs/cgroup/cpuset.cpus.partition <==
member

==> /sys/fs/cgroup/cpuset.mems <==


==> /sys/fs/cgroup/cpuset.mems.effective <==
0

==> /sys/fs/cgroup/hugetlb.1GB.current <==
0

==> /sys/fs/cgroup/hugetlb.1GB.events <==
max 0

==> /sys/fs/cgroup/hugetlb.1GB.events.local <==
max 0

==> /sys/fs/cgroup/hugetlb.1GB.max <==
max

==> /sys/fs/cgroup/hugetlb.1GB.rsvd.current <==
0

==> /sys/fs/cgroup/hugetlb.1GB.rsvd.max <==
max

==> /sys/fs/cgroup/hugetlb.2MB.current <==
0

==> /sys/fs/cgroup/hugetlb.2MB.events <==
max 0

==> /sys/fs/cgroup/hugetlb.2MB.events.local <==
max 0

==> /sys/fs/cgroup/hugetlb.2MB.max <==
max

==> /sys/fs/cgroup/hugetlb.2MB.rsvd.current <==
0

==> /sys/fs/cgroup/hugetlb.2MB.rsvd.max <==
max

==> /sys/fs/cgroup/io.max <==

==> /sys/fs/cgroup/io.pressure <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=24710
full avg10=0.00 avg60=0.00 avg300=0.00 total=24710

==> /sys/fs/cgroup/io.stat <==
259:0 rbytes=5431296 wbytes=0 rios=196 wios=0 dbytes=0 dios=0
254:0 rbytes=5431296 wbytes=0 rios=196 wios=0 dbytes=0 dios=0
254:1 rbytes=5431296 wbytes=0 rios=196 wios=0 dbytes=0 dios=0

==> /sys/fs/cgroup/io.weight <==
default 100

==> /sys/fs/cgroup/memory.current <==
6696960

==> /sys/fs/cgroup/memory.events <==
low 0
high 0
max 0
oom 0
oom_kill 0

==> /sys/fs/cgroup/memory.events.local <==
low 0
high 0
max 0
oom 0
oom_kill 0

==> /sys/fs/cgroup/memory.high <==
max

==> /sys/fs/cgroup/memory.low <==
0

==> /sys/fs/cgroup/memory.max <==
max

==> /sys/fs/cgroup/memory.min <==
0

==> /sys/fs/cgroup/memory.numa_stat <==
anon N0=602

Re: serial console install issues, all the links of the chain

[Geert Stappers]

On Tue, Apr 13, 2021 at 10:40:07AM +1200, Richard Hector wrote:
> On 12/04/21 6:18 pm, Geert Stappers wrote:
> } On Sun, Apr 11, 2021 at 10:05:22PM -0600
> } } Maybe because of used putty or screen as the app for interaction.
> > 
> > Do we know the "path" that original poster is using?
> > 
> > Possible format for answer to this
> > 
> >   - APU device
> >   - 9-pin serial connector
> >   - null-modem, cross connects everthing
> >   - 9-pin serial connector
> >   - USB-Serial-Adapter
> >   - Linux computer
> >   - XFCE desktop
> >   - "terminal window", sized at 80x26 character
> >   - application `screen`
> >   - User
> 
> More or less right.

Acknowlegde


> I'm not sure of the specs of the null-modem cable; I found it amongst
> my collection of junk. For all I know it's straight through and the
> USB adapter autodetects - is that a thing?

Let's consider the cable stuff being fine.

 
> But I also don't see the significance - I've had no issues that look like
> communications problems, flow control problems or anything like that.

I agree on that. The
> } } Maybe because of used putty or screen as the app for interaction.
and especial putty got my attention. Because PuTTY is to me "SSH client
for Microsoft Windows". My question about "chain of links" was to find
out if we were dealing with

 - device
 - cable
 - Linux box or another computer with SSH server
 - PuTTY
 - MS Windows version 
 

Now we known for sure. Question
> > Do we know the "path" that original poster is using?
is being answered.   :-)


> Cheers,
> Richard
 

Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: serial console install issues BIOS related

[Geert Stappers]

On Tue, Apr 13, 2021 at 12:42:41PM +1200, Richard Hector wrote:
> On 13/04/21 12:31 pm, Ben Hutchings wrote:
> > On Mon, 2021-04-12 at 13:48 +1200, Richard Hector wrote:
> > >
> > >   
> > > 
> > > But all that's irrelevant if I can't get to the linux commandline,
> > > because Syslinux is misbehaving.
> > > 
> > > Does anyone know if it's inherent in Syslinux that it won't work
> > > correctly with a 24-line serial terminal?
> > [...]
> > 
> > I think that syslinux is working through a BIOS-emulated display and
> > keyboard controller, and is not aware that a serial terminal is beign
> > used.  The code for SeaBIOS's serial console support is here:
> > .
> > It presents an 80x25 (or 40x25) text display as there is no VGA BIOS
> > mode number for 80x24.
> 
> Ah - so while syslinux can talk to a serial console, it's not using that in
> this case? Interesting, thanks. That could explain why I haven't seen this
> on previous serial console installations (an old Soekris box).
> 
> That might make it more difficult to solve in software, leaving more
> documentation as the only answer.

Please express proposals.



Regards
Geert Stappers
Voluntering for transforming update proposals into git commits.
-- 
Silence is hard to parse