Re: Wine in bullseye, which way to go?

[Miroslav Skoric]

On 2/2/24 9:10 PM, Greg Wooledge wrote:



I am not sure what do you mean by "install that architecture". I have
been using i386 versions of Debian, and I do not plan to reinstall it
now just because the CPU may allow that.


At some point, you will have to make a decision.  i386 is going to stop
being supported sooner or later.




Yeah, I know that. Until then I will try to get the most out of this 
i386 installation as-is.


In any case, I managed to get rid of some 250+ amd64 packages that came 
with pretty useless wine (5.0.3-3) installation from the bullseye repo. 
After deinstalling wine & related software (in Synaptic), I ran apt-get 
update, apt-get upgrade, and apt autoremove. It freed cca 1GB.


After reboot, all was clean, so I decided to go with wine via WineHQ. I 
followed their published procedure for bullseye installation, and after 
a while it ended up with wine version 9, which for now seems functional.


Will update the list in days to come ...

Misko

Wine in bullseye, which way to go?

[Miroslav Skoric]

Hi!

As I have some Windows software (for ham radio) that does not have 
adequate Linux versions, I wanted to install Wine and some related 
packages from the bullseye repository (wine, q4wine, winetricks, 
playonlinux, etc). By the way, I had Wine with buster earlier, and most 
Windows software worked more or less flawlessly, but I deinstalled all 
that software and Wine before I upgraded buster to bullseye.


This time I was puzzled when noticed that Synaptic installed lots of 
amd64 packages even though my system is i386. Also, it removed some 
packages, and also reported few errors or like. Finally, no Windows 
software wanted to run, instead q4wine returned "Exit -1" or like.


See bellow some details for particular packages installation:

(Wine)

Removing portaudio19-dev:i386 (19.6.0-1.1) ...
Removing libjack-dev (1:0.125.0-3+b1) ...
dpkg: libjack0:i386: dependency problems, but removing anyway as you 
requested:
 mpv depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; 
however:

  Package libjack-jackd2-0 is not installed.
  Package libjack-0.125 is not installed.
  Package libjack0:i386 which provides libjack-0.125 is to be removed.
 mplayer depends on libjack-jackd2-0 (>= 1.9.10+20150825) | 
libjack-0.125; however:

  Package libjack-jackd2-0 is not installed.
  Package libjack-0.125 is not installed.
  Package libjack0:i386 which provides libjack-0.125 is to be removed.
 libportaudio2:i386 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | 
libjack-0.125; however:

  Package libjack-jackd2-0 is not installed.
  Package libjack-0.125 is not installed.
  Package libjack0:i386 which provides libjack-0.125 is to be removed.
 libfluidsynth2:i386 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | 
libjack-0.125; however:

  Package libjack-jackd2-0 is not installed.
  Package libjack-0.125 is not installed.
  Package libjack0:i386 which provides libjack-0.125 is to be removed.
 libavdevice58:i386 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | 
libjack-0.125; however:

  Package libjack-jackd2-0 is not installed.
  Package libjack-0.125 is not installed.
  Package libjack0:i386 which provides libjack-0.125 is to be removed.
 libasound2-plugins:i386 depends on libjack-jackd2-0 (>= 
1.9.10+20150825) | libjack-0.125; however:

  Package libjack-jackd2-0 is not installed.
  Package libjack-0.125 is not installed.
  Package libjack0:i386 which provides libjack-0.125 is to be removed.
 gstreamer1.0-plugins-good:i386 depends on libjack-jackd2-0 (>= 
1.9.10+20150825) | libjack-0.125; however:

  Package libjack-jackd2-0 is not installed.
  Package libjack-0.125 is not installed.
  Package libjack0:i386 which provides libjack-0.125 is to be removed.
Removing libjack0:i386 (1:0.125.0-3+b1) ...
Setting up gcc-10-base:amd64 (10.2.1-6) ...
Setting up libgcc-s1:amd64 (10.2.1-6) ...
Setting up libcrypt1:amd64 (1:4.4.18-4) ...
Setting up libc6:amd64 (2.31-13+deb11u7) ...
Setting up libgpg-error0:amd64 (1.38-2) ...
Setting up libgcrypt20:amd64 (1.8.7-6) ...
Setting up liblz4-1:amd64 (1.9.3-2) ...
Setting up liblzma5:amd64 (5.2.5-2.1~deb11u1) ...
Setting up libzstd1:amd64 (1.4.8+dfsg-2.1) ...
Setting up libexpat1:amd64 (2.2.10-2+deb11u5) ...
Setting up libgraphite2-3:amd64 (1.3.14-1) ...
Setting up liblcms2-2:amd64 (2.12~rc1-2) ...
Setting up libpixman-1-0:amd64 (0.40.0-1.1~deb11u1) ...
Setting up libcdparanoia0:amd64 (3.10.2+debian-13.1) ...
Setting up ipp-usb (0.9.17-3+b4) ...
ipp-usb.service is a disabled or a static unit, not starting it.
Setting up libvo-amrwbenc0:amd64 (0.1.3-2) ...
Setting up libxau6:amd64 (1:1.0.9-1) ...
Setting up libraw1394-11:amd64 (2.1.2-2) ...
Setting up libkeyutils1:amd64 (1.6.1-2) ...
Setting up libgpm2:amd64 (1.20.7-8) ...
Setting up libmpg123-0:amd64 (1.26.4-1) ...
Setting up libogg0:amd64 (1.3.4-0.1) ...
Setting up libspeex1:amd64 (1.2~rc1.2-1.1) ...
Setting up libshine3:amd64 (3.1.1-2) ...
Setting up libtwolame0:amd64 (0.4.0-2) ...
Setting up libdatrie1:amd64 (0.2.13-1) ...
Setting up libgsm1:amd64 (1.0.18-2) ...
Setting up libvisual-0.4-0:amd64 (0.4.0-17) ...
Setting up libcapi20-3:amd64 (1:3.27-3+b1) ...
Setting up libglvnd0:amd64 (1.3.2-1) ...
Setting up libssl1.1:amd64 (1.1.1w-0+deb11u1) ...
Setting up libaom0:amd64 (1.0.0.errata1-3+deb11u1) ...
Setting up libbrotli1:amd64 (1.0.9-2+b2) ...
Setting up libsqlite3-0:amd64 (3.34.1-3) ...
Setting up libsasl2-modules:amd64 (2.1.27+dfsg-2.1+deb11u1) ...
Setting up libffi7:amd64 (3.3-6) ...
Setting up libvkd3d1:i386 (1.1-5) ...
Setting up libnghttp2-14:amd64 (1.43.0-1+deb11u1) ...
Setting up libunistring2:amd64 (0.9.10-4) ...
Setting up libdeflate0:amd64 (1.7-1) ...
Setting up zlib1g:amd64 (1:1.2.11.dfsg-2+deb11u2) ...
Setting up libidn2-0:amd64 (2.3.0-5) ...
Setting up libcom-err2:amd64 (1.46.2-2) ...
Setting up libgomp1:amd64 (10.2.1-6) ...
Setting up libxvidcore4:amd64 (2:1.3.7-1) ...
Setting up libunwind8:amd64 (1.3.2-2) ...
Setting up libx264-160:amd64 (2:0.160.3011+gitcde9a93-2.1) ...
Setting up libjbig0:amd64 

Re: apt full-upgrade failed at marco-common package

[Miroslav Skoric]

On 1/30/24 1:43 PM, Michael Kjörling wrote:


https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#file-conflicts
should help.



Sure. Thanks!

Re: apt full-upgrade failed at marco-common package

[Miroslav Skoric]

On 1/30/24 1:40 PM, The Wanderer wrote:

/tmp/apt-dpkg-install-S65GMD/8-marco-common_1.24.1-3_all.deb (--unpack):

   trying to overwrite
'/usr/share/themes/Gorilla/metacity-1/metacity-theme-1.xml', which is
also in package gnome-themes-more 0.9.0.deb0.8


Where do you get 'gnome-themes-more' from? At least as far as I can tell
without more digging, it isn't in current stable or testing.

It *is* available on archive.debian.org and snapshot.debian.org, with
that version number, but based on the timestamps it doesn't seem to have
been updated since 2010.



Dunno ... probably it became orphaned after upgrading from some previous 
releases. I used apt-forktracer to get rid of some packages before 
upgrading to bullseye, but many packages were still listed there. I was 
cautious and did not want to remove all of those just like that ...




My first default would be to remove gnome-themes-more (possibly with
apt, possibly directly with dpkg), then try the '--fix-broken' step
again.

Assuming that works, I'd then follow it up by repeating the full-upgrade
step just to make sure, and then after that - if I really wanted
gnome-themes-more - try to reinstall it (preferably using an updated
package, if you can get your hands on one).



Thanks for advice. I tried to remove that package with apt at first, to 
no avail, but dpkg was successful. Then the '--fix-broken' step and the 
full-upgrade step performed without errors.


Misko

Re: apt full-upgrade failed at marco-common package

[Miroslav Skoric]

On 1/30/24 1:41 PM, Greg Wooledge wrote:

On Tue, Jan 30, 2024 at 01:19:09PM +0100, Miroslav Skoric wrote:

Unpacking marco-common (1.24.1-3) over (1.20.3-1) ...
.[1mdpkg:.[0m error processing archive
/tmp/apt-dpkg-install-S65GMD/8-marco-common_1.24.1-3_all.deb (--unpack):
  trying to overwrite
'/usr/share/themes/Gorilla/metacity-1/metacity-theme-1.xml', which is also
in package gnome-themes-more 0.9.0.deb0.8


These two packages can't coexist, so you're going to have to pick
one to get rid of.

I did an "apt-cache show marco", and it's a window manager intended
to be used by MATE.

I did "apt-cache show gnome-themes-more" and it doesn't exist in
Debian 12 at all.  It must have been removed at some point, or else
it came from a third party source.  (That "*deb0.8" version string
looks a little odd to me, too.)

So... figure out which of these two packages you can live without,
get rid of it, and then retry the upgrade.

Two packages both trying to supply the same file, without a Conflicts:
line or something equivalent, should be considered a bug, if they're
both Debian packages.  If one of them's third-party, then of course
all bets are off.




Thank you. I removed gnome-themes-more as I mostly use MATE. (Did not 
check whether Gnome would suffer by any means :-)

apt full-upgrade failed at marco-common package

[Miroslav Skoric]

Hi,

I [partially] upgraded buster to bullseye according to official "Release 
Notes for Debian 11 (bullseye), 32-bit PC" (October 4, 2023). I did it 
in two sessions as suggested:


"4.4.4 Minimal system upgrade" (# apt upgrade --without-new-pkgs). That 
part performed without any issue, and cat /etc/debian_version reported 
11.8 (previously it was 10.x).


"4.4.5 Upgrading the system" (# apt full-upgrade) ran also fine until 
some 20% or so, and then failed when handled marco-common package. Here 
are the few last lines of that session:


...
Preparing to unpack .../6-mate-settings-daemon-common_1.24.1-1_all.deb ...
Unpacking mate-settings-daemon-common (1.24.1-1) over (1.20.4-1) ...
Preparing to unpack .../7-marco_1.24.1-3_i386.deb ...
Unpacking marco (1.24.1-3) over (1.20.3-1) ...
Preparing to unpack .../8-marco-common_1.24.1-3_all.deb ...
Unpacking marco-common (1.24.1-3) over (1.20.3-1) ...
.[1mdpkg:.[0m error processing archive 
/tmp/apt-dpkg-install-S65GMD/8-marco-common_1.24.1-3_all.deb (--unpack):
 trying to overwrite 
'/usr/share/themes/Gorilla/metacity-1/metacity-theme-1.xml', which is 
also in package gnome-themes-more 0.9.0.deb0.8

Errors were encountered while processing:
 /tmp/apt-dpkg-install-S65GMD/8-marco-common_1.24.1-3_all.deb


A repeated # apt full-upgrade returned a list of unmet dependencies, 
including this one:


marco : Depends: marco-common (= 1.24.1-3) but 1.20.3-1 is installed

At the end of the list it suggested: Try 'apt --fix-broken install' with 
no packages (or specify a solution). I tried it and it seemed as if it 
tried to process again the above lines (unpacking, preparing), to no avail.


What can I try to resolve that? After system reboot, I am able to reach 
the rescue mode as root and type commands. (Green 'OK' follow all parts 
of boot. GUI, startx fail. Shutdown, poweroff run properly.)


Thank you.

Misko

Re: Resizing LVM partitions

[Miroslav Skoric]

On 1/24/24 11:27 PM, Greg Wooledge wrote:

On Wed, Jan 24, 2024 at 10:43:51PM +0100, Miroslav Skoric wrote:

I do not have root account.


Sure you do.  You might not have a root *password* set.


(I use sudo from my user account.) I think I
already tried rescue mode in the past but was not prompted for root
password.


You can set a root password:

 sudo passwd root

That should allow you to enter single-user mode, or to login directly
as root on a text console, both of which are things that you may need
to do as a system administrator.  Especially if you're trying to
unmount /home.




Of course, sorry for my mixing terms. In fact I have never logged in 
directly as root so I thought the account was disabled or unusable.


In any case, after setting a root password I did this:

1. Log-out as user (in GUI)
2. Ctrl-Alt-F2
3. Log-in as root (in CLI)
4. # lvreduce --size -50G --resizefs /dev/mapper/localhost-home
Do you want to unmount "/home" ? [Y|n] y
...
...
Size of logical volume localhost/home changed from 261.00 GiB (66816 
extents) to 211.00 GiB (54016 extents).

Logical volume localhost/home successfully resized.

... after reboot ...

# df -h
Filesystem  Size  Used Avail Use% Mounted on
udev1.5G 0  1.5G   0% /dev
tmpfs   297M  8.9M  288M   3% /run
/dev/mapper/localhost-root  6.2G  4.7G  1.2G  81% /
/dev/mapper/localhost-usr15G   11G  2.7G  80% /usr
tmpfs   1.5G 0  1.5G   0% /dev/shm
tmpfs   5.0M  4.0K  5.0M   1% /run/lock
tmpfs   1.5G 0  1.5G   0% /sys/fs/cgroup
/dev/sda1   228M  142M   74M  66% /boot
/dev/mapper/localhost-home  208G   60G  138G  31% /home
/dev/mapper/localhost-var   3.7G  2.0G  1.6G  57% /var
/dev/mapper/localhost-tmp   2.3G   57K  2.2G   1% /tmp
tmpfs   297M   32K  297M   1% /run/user/1000

# vgdisplay
  --- Volume group ---
  VG Name   localhost
  System ID
  Formatlvm2
  Metadata Areas1
  Metadata Sequence No  21
  VG Access read/write
  VG Status resizable
  MAX LV0
  Cur LV6
  Open LV   6
  Max PV0
  Cur PV1
  Act PV1
  VG Size   <297.85 GiB
  PE Size   4.00 MiB
  Total PE  76249
  Alloc PE / Size   62346 / <243.54 GiB
  Free  PE / Size   13903 / <54.31 GiB
  VG UUID   fbCaw1-u3SN-2HCy-w6y8-v0nK-QsFE-FETNZM

... and then I extended /, /usr, and /var for 1GB each. Seems all ok.

Thank you!

Re: Resizing LVM partitions

[Miroslav Skoric]

On 1/24/24 3:20 AM, Max Nikulin wrote:

On 24/01/2024 06:29, Miroslav Skoric wrote:
 # df -h 



/dev/mapper/localhost-root  6.2G  4.7G  1.2G  81% /


Taking into account size of kernel packages, I would allocate a few G 
more for the root partition.


dpkg -s linux-image-6.1.0-17-amd64 | grep -i size
Installed-Size: 398452

Notice that separate /usr is not supported by latest systemd that should 
be a part of the next Debian release.





Thank you. Will consider that.

Re: Resizing LVM partitions

[Miroslav Skoric]

On 1/24/24 12:42 AM, Greg Wooledge wrote:


You'll have to unmount it, which generally means you will have to reboot
in single-user mode, or from rescue media, whichever is easier.

If you aren't opposed to setting a root password (some people have *weird*
self-imposed restrictions, seriously), single-user mode (aka "rescue mode"
from the GRUB menu) is the standard way to do this.  Boot to the GRUB menu,
select rescue mode, give the root password when prompted, then you should
end up with a root shell prompt.  I don't recall whether /home will be
mounted at that point; if it is, unmount it.  Then you should be able
to do whatever resizing is needed.  When done, exit from the shell, and
the system should boot normally.




I do not have root account. (I use sudo from my user account.) I think I 
already tried rescue mode in the past but was not prompted for root 
password.

Re: Resizing LVM partitions

[Miroslav Skoric]

On 1/23/24 7:36 AM, Andy Smith wrote:


ext filesystems do need to be unmounted when shrinking them (they can
grow online, though). When you use the --resizefs (-r) option, LVM asks
you if you wish to unmount. Obviously you cannot do that on a
fiulesystme which is in use, which means you'll need a live or rescue
environment to do it for the root filesystem.

I'd shrink what else I could and then see where I am at. It's okay to do
them one at a time. LVM will just not do it if there's a problem.
Another thing I sometimes do in these situations is make a new LV and
move some of the things in / out into it where possible, to free up some
more space on /.



Dunno ... in any case, for some reason the rescue mode I went to by 
booting from an old installation CD (dated back to Debian 6.0.1A 
Squeeze!) did not see partitions in form of e.g. 
/dev/mapper/localhost-home, but rather /dev/localhost/home, so lvreduce 
rejected to proceed.


So I tried vgdisplay. It returned ... among the others ...

...
Total PE  76249
Alloc PE / Size   74378 / 290.54 GiB
Free  PE / Size   1871 / 7.31 GiB

... so I considered that 7.31 GB could be used for extending /, /usr, 
and /var file systems. I rebooted machine into normal operation and did 
the following:


 # vgdisplay

  --- Volume group ---
  VG Name   localhost
  System ID
  Formatlvm2
  Metadata Areas1
  Metadata Sequence No  17
  VG Access read/write
  VG Status resizable
  MAX LV0
  Cur LV6
  Open LV   6
  Max PV0
  Cur PV1
  Act PV1
  VG Size   <297.85 GiB
  PE Size   4.00 MiB
  Total PE  76249
  Alloc PE / Size   74378 / <290.54 GiB
  Free  PE / Size   1871 / <7.31 GiB
  VG UUID   fbCaw1-u3SN-2HCy-w6y8-v0nK-QsFE-FETNZM

 # df -h

Filesystem  Size  Used Avail Use% Mounted on
udev1.5G 0  1.5G   0% /dev
tmpfs   297M  8.8M  288M   3% /run
/dev/mapper/localhost-root  5.2G  4.7G  211M  96% /
/dev/mapper/localhost-usr14G   12G  948M  93% /usr
tmpfs   1.5G 0  1.5G   0% /dev/shm
tmpfs   5.0M  4.0K  5.0M   1% /run/lock
tmpfs   1.5G 0  1.5G   0% /sys/fs/cgroup
/dev/sda1   228M  133M   84M  62% /boot
/dev/mapper/localhost-tmp   2.3G   55K  2.2G   1% /tmp
/dev/mapper/localhost-var   2.7G  1.9G  659M  75% /var
/dev/mapper/localhost-home  257G   63G  182G  26% /home
tmpfs   297M   32K  297M   1% /run/user/1000

 # lvextend --size +1G --resizefs /dev/mapper/localhost-root
  Size of logical volume localhost/root changed from 5.32 GiB (1363 
extents) to 6.32 GiB (1619 extents).

  Logical volume localhost/root successfully resized.
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mapper/localhost-root is mounted on /; on-line 
resizing required

old_desc_blocks = 22, new_desc_blocks = 26
The filesystem on /dev/mapper/localhost-root is now 6631424 (1k) blocks 
long.


 # df -h (to check the new status)

Filesystem  Size  Used Avail Use% Mounted on
udev1.5G 0  1.5G   0% /dev
tmpfs   297M  8.8M  288M   3% /run
/dev/mapper/localhost-root  6.2G  4.7G  1.2G  81% /
/dev/mapper/localhost-usr14G   12G  948M  93% /usr
tmpfs   1.5G 0  1.5G   0% /dev/shm
tmpfs   5.0M  4.0K  5.0M   1% /run/lock
tmpfs   1.5G 0  1.5G   0% /sys/fs/cgroup
/dev/sda1   228M  133M   84M  62% /boot
/dev/mapper/localhost-tmp   2.3G   55K  2.2G   1% /tmp
/dev/mapper/localhost-var   2.7G  1.9G  659M  75% /var
/dev/mapper/localhost-home  257G   63G  182G  26% /home
tmpfs   297M   32K  297M   1% /run/user/1000

 # lvextend --size +1G --resizefs /dev/mapper/localhost-usr
  Size of logical volume localhost/usr changed from <13.38 GiB (3425 
extents) to <14.38 GiB (3681 extents).

  Logical volume localhost/usr successfully resized.
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mapper/localhost-usr is mounted on /usr; on-line 
resizing required

old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mapper/localhost-usr is now 3769344 (4k) blocks long.

 # df -h
Filesystem  Size  Used Avail Use% Mounted on
udev1.5G 0  1.5G   0% /dev
tmpfs   297M  8.8M  288M   3% /run
/dev/mapper/localhost-root  6.2G  4.7G  1.2G  81% /
/dev/mapper/localhost-usr15G   12G  1.9G  86% /usr
tmpfs   1.5G 0  1.5G   0% /dev/shm
tmpfs   5.0M  4.0K  5.0M   1% /run/lock
tmpfs   1.5G 0  1.5G   0% /sys/fs/cgroup
/dev/sda1   228M  133M   84M  62% /boot
/dev/mapper/localhost-tmp   2.3G   55K  2.2G   1% /tmp
/dev/mapper/localhost-var   

Re: Resizing LVM partitions

[Miroslav Skoric]

On 1/22/24 11:21 PM, Greg Wooledge wrote:

On Mon, Jan 22, 2024 at 10:41:57PM +0100, Miroslav Skoric wrote:

As I need to extend & resize more than one LV in the file system (/, /usr,
and /var), should they all need to be unmounted before the operation? As I
remember, it is ext3 system on that comp.


What??  I don't think these words mean what you think they mean.

An LV is a logical volume, which is like a virtual partition.  It's a
block device, like /dev/sda2.  You can use an LV the same way you would
use a partition -- you can use it for swap space, or a file system, or
other purposes.

A file system is a mountable directory structure that you can put inside
a partition, or an LV.  File system types include ext4, ext3, xfs, vfat,
and so on.



Sorry for my ignorance regarding terminology, I mix terms sometimes :-)


If your system has separately mounted file systems for /, /usr and
/var and you want to shrink ALL of them, then yes, you would need to
unmount all three of them, shrink them, then (re)boot.  You can't
unmount / during normal operations, so the only ways to shrink / would
involved booting in a special way, either with some external medium,
or with specific kernel parameters.  Thus, you'd typically reboot to
get back to normal operations afterward.



Let me clarify: I did not plan to shrink all of those, but rather just 
one (/home). The other three (/, /usr, and /var) shall be extended from 
the released space.


I managed to locate the first CD of my very old initial installation set 
(squeeze). However, booting from that one did not help me to get /home 
available for shrinking. See later what I did instead.



However, if you're in a position where you think you need to make
dramatic changes to FOUR of your mounted file systems, perhaps you
might want to consider restarting from scratch.  Ponder why you have
separate file systems at all.  Are they really giving you a benefit?
Have you ever filled up one of them and thought "Oh wow, I am *so*
glad I separated these file systems so I didn't fill up ___ as well!"
Or are they just giving you grief with no benefits?




Well I belong to those who are going to exercise any possible way to 
prolong the life of an existing installation, no matter how old it is. 
In my case it started from squeeze a decade or more ago and gradually 
upgraded during the years. And I knew that some years ago I resized the 
file system because of similar reasons, and that worked at the time. But 
the procedure disappeared from memory :-)


Reinstalling from scratch is always possible, of course.

Re: Resizing LVM partitions

[Miroslav Skoric]

On 1/22/24 7:01 PM, to...@tuxteam.de wrote:


Ah, forgot to say: "pvdisplay -m" will give you a "physical" map of
your physical volume. So you get an idea what is where and where
you find gaps.




"pvdisplay -m" provided some idea that there was some free space but (if 
I am not wrong) not how much in MB, GB, or else.


I found gvdisplay more precise in that direction.

Re: Resizing LVM partitions

[Miroslav Skoric]

On 1/22/24 5:02 PM, Greg Wooledge wrote:

On Mon, Jan 22, 2024 at 03:17:36PM +, Alain D D Williams wrote:

The shrinking of /home is the hard part. You MUST first unmount /home, then
resize the file system, then resize the logical volume.


Before doing any of that, one should check the volume group and see
if there are unallocated hunks of free space that can simply be assigned
to the root LV.



vgdisplay

?

It helped me for now, see my other responses to the topic ...

Re: Resizing LVM partitions

[Miroslav Skoric]

On 1/22/24 6:59 PM, to...@tuxteam.de wrote:

On Mon, Jan 22, 2024 at 03:40:06PM +, Alain D D Williams wrote:

On Mon, Jan 22, 2024 at 10:29:55AM -0500, Stefan Monnier wrote:

lvextend --size +1G --resizefs /dev/mapper/localhost-home

Ie get lvextend to do the maths & work it out for me.

Those who are cleverer than me might be able to tell you how to get it right
first time!


lvreduce --size -50G --resizefs /dev/mapper/localhost-home


Oh, even better. It is a long time since I looked at than man page.

Does this still need to be done with the file system unmounted or can it be
done with an active file system these days ?


You have first to shrink the file system (if it's ext4, you can use
resize2fs: note that you can only *grow* an ext4 which is mounted
(called "online resizing) -- to *shrink* it, it has to be unmounted.



I will check it again but I think that file systems in that LVM are 
ext3. So it requires all of them to be unmounted prior to resizing ?



Since I wasn't quite sure whether ext2's Gs are the same as LVM's
and didn't want to bother with whatever clippings each process
takes, what I did in this situation was:

  - shrink (resize2fs) the file system to a size clearly below target
  - resize the LVM to my target size
  - resize2fs again without params, which lets it take whatever the
partition offers



That last resize2fs (without params) would not work here, or at least it 
would not work for my three file systems that need to be extended: / , 
/usr , and /var . Maybe to extend each of them separately like this:


lvextend --size +1G --resizefs /dev/mapper/localhost-root
lvextend --size +1G --resizefs /dev/mapper/localhost-usr
lvextend --size +1G --resizefs /dev/mapper/localhost-var

?

Re: Resizing LVM partitions

[Miroslav Skoric]

On 1/22/24 4:40 PM, Alain D D Williams wrote:

On Mon, Jan 22, 2024 at 10:29:55AM -0500, Stefan Monnier wrote:

lvextend --size +1G --resizefs /dev/mapper/localhost-home

Ie get lvextend to do the maths & work it out for me.

Those who are cleverer than me might be able to tell you how to get it right
first time!


lvreduce --size -50G --resizefs /dev/mapper/localhost-home


Oh, even better. It is a long time since I looked at than man page.

Does this still need to be done with the file system unmounted or can it be
done with an active file system these days ?



As I need to extend & resize more than one LV in the file system (/, 
/usr, and /var), should they all need to be unmounted before the 
operation? As I remember, it is ext3 system on that comp.

Re: Resizing LVM partitions

[Miroslav Skoric]

On 1/22/24 4:17 PM, Alain D D Williams wrote:

On Mon, Jan 22, 2024 at 03:32:30PM +0100, sko...@uns.ac.rs wrote:

I am getting the following message at any boot:

"The volume "Filesystem root" has only 221.1 MB disk space remaining."

  df -h says:

Filesystem  Size  Used Avail Use% Mounted on
udev1.5G 0  1.5G   0% /dev
tmpfs   297M  9.0M  288M   4% /run
/dev/mapper/localhost-root  5.2G  4.7G  211M  96% /
/dev/mapper/localhost-usr14G   12G  948M  93% /usr
tmpfs   1.5G 0  1.5G   0% /dev/shm
tmpfs   5.0M  4.0K  5.0M   1% /run/lock
tmpfs   1.5G 0  1.5G   0% /sys/fs/cgroup
/dev/sda1   228M  133M   84M  62% /boot
/dev/mapper/localhost-tmp   2.3G   57K  2.2G   1% /tmp
/dev/mapper/localhost-var   2.7G  2.5G   55M  98% /var
/dev/mapper/localhost-home  257G   73G  172G  30% /home
tmpfs   297M   40K  297M   1% /run/user/1000

As my system has encrypted LVM, I suppose that I shall reduce some space
used for /home, and then use it to extend /, /usr, and /var logical
partitions. I think I did (or tried to do) something similar several years
ago, but forgot the proper procedure. Any link for a good tutorial is
welcomed. Thanks.


The shrinking of /home is the hard part. You MUST first unmount /home, then
resize the file system, then resize the logical volume.

umount /home

Find out how big it is:
resize2fs /dev/mapper/localhost-home

Change the filesystem size:
resize2fs /dev/mapper/localhost-home NEW-SIZE

Change the partition size:
lvextend --size 200G /dev/mapper/localhost-home

The hard bit is working out what NEW-SIZE should be and having it such
that you use all of the partition but without making the file system size
greater than the partition size - ie getting the last few megabytes right.

What I do is make NEW-SIZE 2GB smaller than I want (assuming that it still 
fits),
the size I give to lvextend 1GB smaller - so it all works, but there is wasted
space & it is not quite big enough. I then do:

lvextend --size +1G --resizefs /dev/mapper/localhost-home

Ie get lvextend to do the maths & work it out for me.

Those who are cleverer than me might be able to tell you how to get it right
first time!

mount /home

Extending the others is easy and can be done when the system is running &
active, something like:

lvextend --size +1G --resizefs /dev/mapper/localhost-var

Finally: ensure that you have a good backup of /home before you start.



Sounds interesting. Thank you. Will see other opinions too.

Re: Cannot read newsgroups with new Thunderbird

[Miroslav Skoric]

On 10/6/22 1:05 AM, Ralph Katz wrote:

On 10/5/22 07:08, Miroslav Skoric wrote:
After a recent Thunderbird upgrade in Buster (from version 
91-something to 101-something, or like), it stopped handling 
newsgroups properly (where the source is News Server (NNTP) on the 
same machine, and there nothing was changed/upgraded).


To be precise, Thunderbird now seems downloading new messages from the 
NNTP server, then shows the new number of messages in the folder pane, 
but displays an empty content in the message pane, i.e. Subject and 
From columns are empty, while Date column is filled with 1/1/70 - for 
all news messages that arrived since the Thunderbird upgrade.


Btw, handling personal emails (from the local POP Mail Server) is ok.

Any idea?

Misko


I'm reading your post on Thunderbird 102.3.0 in bullseye (debian stable) 
from newsgroup gmane.linux.debian.user at
news://news.gmane.io/gmane.linux.debian.user   and replying directly to 
debian-user.


The upgrade to Thunderbird 102.3.0 was seamless.  So thunderbird does 
the job for newsgroups, at least in bullseye.


Good luck!

Ralph




I am using buster, not bullseye.

Cannot read newsgroups with new Thunderbird

[Miroslav Skoric]

After a recent Thunderbird upgrade in Buster (from version 91-something 
to 101-something, or like), it stopped handling newsgroups properly 
(where the source is News Server (NNTP) on the same machine, and there 
nothing was changed/upgraded).


To be precise, Thunderbird now seems downloading new messages from the 
NNTP server, then shows the new number of messages in the folder pane, 
but displays an empty content in the message pane, i.e. Subject and From 
columns are empty, while Date column is filled with 1/1/70 - for all 
news messages that arrived since the Thunderbird upgrade.


Btw, handling personal emails (from the local POP Mail Server) is ok.

Any idea?

Misko

Re: Upgrade issue with Debian 9 -> 10

[Miroslav Skoric]

On 7/5/22 9:37 AM, Tom Dial wrote:


Post the output from

# fdisk -l (or $ sudo fdisk -l)
# vgdisplay -v (or $ sudo vgdisplay -v)



Here it is:

# fdisk -l
Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Disk model: Hitachi HTS54323
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0005de22

Device Boot  Start   End   Sectors   Size Id Type
/dev/sda1  *  2048499711497664   243M 83 Linux
/dev/sda2   501758 625141759 624640002 297.9G  5 Extended
/dev/sda5   501760 625141759 62464 297.9G 83 Linux




Disk /dev/mapper/sda5_crypt: 297.9 GiB, 319814627328 bytes, 624637944 
sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/localhost-root: 5.3 GiB, 5716836352 bytes, 11165696 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/localhost-usr: 13.4 GiB, 14365491200 bytes, 28057600 
sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/localhost-var: 2.8 GiB, 2998927360 bytes, 5857280 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/localhost-swap_1: 5.7 GiB, 6090129408 bytes, 11894784 
sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/localhost-tmp: 2.4 GiB, 2545942528 bytes, 4972544 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/localhost-home: 261 GiB, 280246616064 bytes, 547356672 
sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes




# vgdisplay -v
  --- Volume group ---
  VG Name   localhost
  System ID
  Formatlvm2
  Metadata Areas1
  Metadata Sequence No  17
  VG Access read/write
  VG Status resizable
  MAX LV0
  Cur LV6
  Open LV   6
  Max PV0
  Cur PV1
  Act PV1
  VG Size   <297.85 GiB
  PE Size   4.00 MiB
  Total PE  76249
  Alloc PE / Size   74378 / <290.54 GiB
  Free  PE / Size   1871 / <7.31 GiB
  VG UUID   fbCaw1-u3SN-2HCy-w6y8-v0nK-QsFE-FETNZM

  --- Logical volume ---
  LV Path/dev/localhost/root
  LV Nameroot
  VG Namelocalhost
  LV UUIDz3MLJc-UsXY-hxOE-xSk2-ipAl-NUny-PDpXv6
  LV Write Accessread/write
  LV Creation host, time ,
  LV Status  available
  # open 1
  LV Size5.32 GiB
  Current LE 1363
  Segments   2
  Allocation inherit
  Read ahead sectors auto
  - currently set to 256
  Block device   254:1

  --- Logical volume ---
  LV Path/dev/localhost/usr
  LV Nameusr
  VG Namelocalhost
  LV UUIDUbFZNN-Y0oA-tEAb-5a8g-z65r-Ekqv-agbmrc
  LV Write Accessread/write
  LV Creation host, time ,
  LV Status  available
  # open 1
  LV Size<13.38 GiB
  Current LE 3425
  Segments   2
  Allocation inherit
  Read ahead sectors auto
  - currently set to 256
  Block device   254:2

  --- Logical volume ---
  LV Path/dev/localhost/var
  LV Namevar
  VG Namelocalhost
  LV UUIDyljPiS-bfh3-w0vA-fAg9-anAE-OaiF-XgvyoY
  LV Write Accessread/write
  LV Creation host, time ,
  LV Status  available
  # open 1
  LV Size2.79 GiB
  Current LE 715
  Segments   1
  Allocation inherit
  Read ahead sectors auto
  - currently set to 256
  Block device   254:3

  --- Logical volume ---
  LV Path/dev/localhost/swap_1
  LV Nameswap_1
  VG Namelocalhost
  LV UUIDpJlSwq-fmd6-sDck-XYOq-QkUs-Zwju-4Y3uSH
  LV Write Accessread/write
  LV Creation host, time ,
  LV Status  available
  # open 2
  LV Size5.67 GiB
  Current LE 1452
  Segments   1
  Allocation inherit
  Read ahead sectors auto
  - currently set 

Re: Upgrade issue with Debian 9 -> 10

[Miroslav Skoric]

On 7/3/22 7:51 PM, David Christensen wrote:

On 7/3/22 02:31, Miroslav Skoric wrote:

Hi all,

Yesterday I attempted to upgrade Compaq Presario CQ56 laptop to 
buster. I followed instructions in 'Chapter 4. Upgrades from Debian 9 
(stretch)', so all went well with a minimal upgrade (apt-get upgrade). 
When it finished, I went to the main part of the upgrade (apt 
full-upgrade). It ran well until some 40-45% and then started 
complaining about lack of disk space.


(apt -o APT::Get::Trivial-Only=true full-upgrade did not say I shall 
get into any trouble.)


So, at one point the full upgrade just exited. I tried to uninstall 
some old stuff but it was not possible. df -h showed that / and /usr 
were almost 100% used.


Shutdown & reboot seemed going normally, although including few 
[FAILED] warnings mostly with firewall failed to start and like. 
Majority went [OK] until the point where it was about to perform fsck 
on mounted volumes where it looks as an endless process occasionally 
repeating this line:


[nnn.nn] perf: interrupt took too long ( > ), lowering 
kernel.perf_event_max_sample_rate to n


where 'n' are numbers.

Ctrl-Alt-F2 brings tty2 from where I can log in, then sudo etc. df -h 
shows that filesystem /dev/mapper/localhost-root (mounted on /) is 99% 
used, and /dev/mapper/localhost-usr (mounted on /usr) is 100% used.


As it is (an encrypted) LVM, where /dev/mapper/localhost-home (mounted 
on /home) is only 21% used, I suppose that it shall be possible to 
resize partitions i.e. logical volumes so that some space of /home to 
be assigned to / and /usr


It seems that resize2fs, lvextend, and some related commands are 
available in tty2, but I am unsure about the proper order & syntax of 
those commands. Also, what about the ongoing fsck process in tty1? Any 
suggestion?



The KISS approach is to check in your system configuration files to a 
version control system, back up your data, take an image of the OS 
drive, remove the OS drive, insert a blank OS drive, do a fresh install, 
check out the old system configuration files to a side directory, 
configure the new OS instance, restore your data, and validate everything.



David




Seems as a drastic solution :-)
Will try to cure this one, and if things go wrong I can always do a 
fresh install.


Misko

Re: Upgrade issue with Debian 9 -> 10

[Miroslav Skoric]

On 7/3/22 4:28 PM, Miroslav Skoric wrote:


Haven't tried that, but something else already helped: While it was 
idling with fsck in tty1, I went to tty2 and entered: apt --fix-broken 
install   ... and it did/resumed full upgrade. (Interestingly, this time 
it did not complain about no space in / and /usr.) When it finished, I 
tested startx and it brought GUI. Not sure now but I think that I then 
rebooted and it went it into GUI as expected. So far - so good. Few red 
[FAILED] warnings during CLI phase related to not starting UFV, 
Shorewall, and minissdpd services, so I need to check for that.




As a temporary cure for [FAILED] warnings, I removed ufw and gufw as I 
sparsely used them anyway. Then I also removed completely all shorewall 
things, purged its old folders, and reinstalled again. Now the shorewall 
service starts properly. The only remaining [FAILED] warning comes from 
minissdpd:


# systemctl status minissdpd.service
● minissdpd.service - keep memory of all UPnP devices that announced 
themselves
   Loaded: loaded (/lib/systemd/system/minissdpd.service; enabled; 
vendor preset
   Active: failed (Result: exit-code) since Tue 2022-07-05 13:00:48 
CEST; 3min 1

 Docs: man:minissdpd(1)
  Process: 1225 ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper 
${MiniSSD


Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: can't parse 
"wlo1" as
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: Usage: 
/usr/sbin/mini
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]:
is eith
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: 
192.168.1.42/255.25
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]:   By default, 
socket
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]:   and pid 
written to
Jul 05 13:00:48 localhost minissdpd[1225]: ioctl(s, SIOCGIFADDR, ...): 
Cannot as
Jul 05 13:00:48 localhost systemd[1]: minissdpd.service: Control process 
exited,
Jul 05 13:00:48 localhost systemd[1]: minissdpd.service: Failed with 
result 'exi
Jul 05 13:00:48 localhost systemd[1]: Failed to start keep memory of all 
UPnP de

lines 1-16/16 (END)...skipping...
● minissdpd.service - keep memory of all UPnP devices that announced 
themselves
   Loaded: loaded (/lib/systemd/system/minissdpd.service; enabled; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2022-07-05 13:00:48 
CEST; 3min 16s ago

 Docs: man:minissdpd(1)
  Process: 1225 ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper 
${MiniSSDPd_INTERFACE_ADDRESS} $MiniSSDPd_OTHER_OPTIONS (code=exited, 
status=1


Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: can't parse 
"wlo1" as a valid address or interface name
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: Usage: 
/usr/sbin/minissdpd [-d] [-6] [-s socket] [-p pidfile] [-t TTL] [-f 
device] -i Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]:
is either an IPv4 address with mask such as
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: 
192.168.1.42/255.255.255.0, or an interface name such as eth0.
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]:   By default, 
socket will be open as /var/run/minissdpd.sock
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]:   and pid 
written to file /var/run/minissdpd.pid
Jul 05 13:00:48 localhost minissdpd[1225]: ioctl(s, SIOCGIFADDR, ...): 
Cannot assign requested address
Jul 05 13:00:48 localhost systemd[1]: minissdpd.service: Control process 
exited, code=exited, status=1/FAILURE
Jul 05 13:00:48 localhost systemd[1]: minissdpd.service: Failed with 
result 'exit-code'.
Jul 05 13:00:48 localhost systemd[1]: Failed to start keep memory of all 
UPnP devices that announced themselves.

~
~
~
~


... Seems it does not like network device change (wlan0 --> wlo1). It 
makes me wonder if I shall try to remove/reinstall minissdpd. Any idea?




Well, for sure I missed to uninstall some software that I rarely used in 
stretch, and if I did so I might have not got into trouble. Now will 
take more care with buster.




I freed some 1.5 GB by removing LaTeX and TeX Live packages that I 
installed few years ago just for test but never really used. Probably 
need to get rid of more unneeded stuff.


So far - so good. Seems that buster runs a bit faster (than stretch) on 
this old laptop.


Misko

Re: Upgrade issue with Debian 9 -> 10

[Miroslav Skoric]

On 7/3/22 1:17 PM, Andrew M.A. Cater wrote:


Ctrl-Alt-F2 brings tty2 from where I can log in, then sudo etc. df -h shows
that filesystem /dev/mapper/localhost-root (mounted on /) is 99% used, and
/dev/mapper/localhost-usr (mounted on /usr) is 100% used.



Apt tends to store files in /var - it's possible that /var is also full.



Possibly. /var was always around 49-50% used here, but I knew from some 
earlier upgrade that it might be too small to store new packages for 
upgrading to buster. And because of that I added a thumb drive as a 
temporary /var/archives, and it served the purpose.



If you repeat an apt-get update - do you have errors about needing
to rerun a configure step?



Haven't tried that, but something else already helped: While it was 
idling with fsck in tty1, I went to tty2 and entered: apt --fix-broken 
install   ... and it did/resumed full upgrade. (Interestingly, this time 
it did not complain about no space in / and /usr.) When it finished, I 
tested startx and it brought GUI. Not sure now but I think that I then 
rebooted and it went it into GUI as expected. So far - so good. Few red 
[FAILED] warnings during CLI phase related to not starting UFV, 
Shorewall, and minissdpd services, so I need to check for that.


A subsequent apt --fix-broken install (or some other command) only 
complained about some initrd issue with kernel image 4.19.0-20-686 so I 
removed that image and stayed with 4.9.0-19-686.


After that, apt autoremove freed some 500MB of old stretch packages so 
now / is about 97% used, while /usr is still 100% used.



In thi situation, I might be tempted to save off any data in /home and any
options in /etc/ to configure mail and things like that and
do a reinstall with Debian 11 as a quick fix but that's a destructive
option.



Will see whether it will work without such a destructive option :-)
In fact, that laptop started running Linux as squeeze some ten years 
ago, and I gradually upgraded it to wheezy, jessie, ... It makes me 
wonder if I gave it few more years of life with buster, after stretch 
went EOL yesterday.




When you installed, did you manually specify sizes for filesystems or
did you say "install in one encrypted LVM"?



I cannot remember because I made it with squeeze somewhere in 2013 or 
so. What I do recall is that at some upgrade point I had similar space 
issues, when resize2fs and/or lvextend solved the problem within the 
existing LVM. (I had 'borrowed' some space where I had a surplus, and 
added where needed. Probably I will need to learn it again.)



If you did that then, effectively, /home and so on are auto-sized and LVM
is keeping track of free space. Deleting unwanted files is the only way
to reclaim space and then, perhaps resize.



Well, for sure I missed to uninstall some software that I rarely used in 
stretch, and if I did so I might have not got into trouble. Now will 
take more care with buster.




Good luck with it all - with every good wish, as ever,

Andy Cater


Thanks.

Misko

Upgrade issue with Debian 9 -> 10

[Miroslav Skoric]

Hi all,

Yesterday I attempted to upgrade Compaq Presario CQ56 laptop to buster. 
I followed instructions in 'Chapter 4. Upgrades from Debian 9 
(stretch)', so all went well with a minimal upgrade (apt-get upgrade). 
When it finished, I went to the main part of the upgrade (apt 
full-upgrade). It ran well until some 40-45% and then started 
complaining about lack of disk space.


(apt -o APT::Get::Trivial-Only=true full-upgrade did not say I shall get 
into any trouble.)


So, at one point the full upgrade just exited. I tried to uninstall some 
old stuff but it was not possible. df -h showed that / and /usr were 
almost 100% used.


Shutdown & reboot seemed going normally, although including few [FAILED] 
warnings mostly with firewall failed to start and like. Majority went 
[OK] until the point where it was about to perform fsck on mounted 
volumes where it looks as an endless process occasionally repeating this 
line:


[nnn.nn] perf: interrupt took too long ( > ), lowering 
kernel.perf_event_max_sample_rate to n


where 'n' are numbers.

Ctrl-Alt-F2 brings tty2 from where I can log in, then sudo etc. df -h 
shows that filesystem /dev/mapper/localhost-root (mounted on /) is 99% 
used, and /dev/mapper/localhost-usr (mounted on /usr) is 100% used.


As it is (an encrypted) LVM, where /dev/mapper/localhost-home (mounted 
on /home) is only 21% used, I suppose that it shall be possible to 
resize partitions i.e. logical volumes so that some space of /home to be 
assigned to / and /usr


It seems that resize2fs, lvextend, and some related commands are 
available in tty2, but I am unsure about the proper order & syntax of 
those commands. Also, what about the ongoing fsck process in tty1? Any 
suggestion?


Misko

Firefox insists to be default browser ...

[Miroslav Skoric]

Hi all,

After the recent upgrade of Firefox and Thunderbird in oldoldstable 
(Mate desktop), about a month ago or so, when the versions changed from 
60-something to 90-something, Firefox annoyingly keeps asking me to be 
the default browser, even though I always respond to that asking by 
click on 'dont ask me again', and have set it as default browser in 
Mate's Control Center default applications.


Furthermore, Thunderbird is also set there as default email client. 
However, if I click on a weblink in Thunderbird mail, another 
Thunderbird session opens (instead opening Firefox). And when I close 
both software, and return to Mate Control Center to check again for 
default applications ... voila ... Thunderbird seems as magically 
selected itself for web browser too (both with mail client)!


How to prevent that misbehaviour? All worked well for me with older 
versions of Firefox and Thunderbird (before that version jump to 90 
something). What went wrong with the new versions?


Misko

Firefox insists to be default !?

[Miroslav Skoric]

Hi all,

After the recent upgrade of Firefox (and Thunderbird) in oldoldstable 
(Mate desktop), Firefox always asks me to be default browser, even 
though I have set it as default in Mate's default applications, and 
respond to that asking by click on 'dont ask me again'.


Furthermore, Thunderbird is also set as a default email client. However, 
if I click on a weblink in Thunderbird mail, another Thunderbird session 
opens (instead opening Firefox). And when I close both software, and 
return to Mate control panel to check again for default applications ... 
voila ... Thunderbird seems as magically selected for both mail client 
and web browser there!


How to prevent that misbehaviour? All worked well with previous versions 
of Firefox and Thunderbird. What went wrong with new versions?


Misko

Re: ALSA plugins

[Miroslav Skoric]

On 11/22/21 1:04 AM, Dan Ritter wrote:



The dmix plugin is installed by default.

$ aplay -L|grep dmix
dmix:CARD=HDMI,DEV=3
dmix:CARD=Generic,DEV=0

The dsnoop plugin is installed by default:
$ arecord -L|grep dsnoop
dsnoop:CARD=Generic,DEV=0
dsnoop:CARD=Generic,DEV=2

You configure them either in your systemwide /etc/asoundrc, or
your personal ~/.asoundrc



Thanks. Here is what I got before adding a secondary sound-card device:

ham@localhost:~$ aplay -L|grep dmix
dmix:CARD=Intel,DEV=0
ham@localhost:~$ arecord -L|grep dsnoop
dsnoop:CARD=Intel,DEV=0
ham@localhost:~$


... and here is what I got after adding the secondary sound-card device:

ham@localhost:~$ aplay -L|grep dmix
dmix:CARD=Intel,DEV=0
dmix:CARD=Audio,DEV=0
ham@localhost:~$ arecord -L|grep dsnoop
dsnoop:CARD=Intel,DEV=0
dsnoop:CARD=Audio,DEV=0
ham@localhost:~$


Btw, there was no ~/.asoundrc in personal directory, and also no 
/etc/asoundrc (either before or after attaching the second card). Each 
sound card works well on its own, running different amateur radio 
protocols. The plan is to make the second card 'sharing' its function in 
between the protocol (application) it uses now *and* another one 
protocol that shall be also sent to the same card. However, up to now 
that added protocol/application returns an error msg telling that either 
record or playback device is already busy or not accessible in that card.


And then someone suggested me to check for dmix and dsnoop, as those 
plugins shall overcome that 'application sharing' issue.


Any idea?

Misko

Re: ALSA plugins

[Miroslav Skoric]

On 11/21/21 9:33 PM, Georgi Naplatanov wrote:

On 11/21/21 20:57, Miroslav Skoric wrote:

Hi all,

I was recently told that ALSA doesn't normally allow sharing a soundcard
with two applications, but there are two ALSA plugins, dsnoop and dmix
to share capture and playback respectively. I spent some time in
searching the web for possible info on how to install or how to check if
those plugins are installed, but did not find instructions. Any pointer
in that direction? Thanks in advance.



Why don't you use PulseAudio or maybe PipeWire?

Kind regards
Georgi




My issue is related to some amateur radio applications, and the 
application maintainer suggested me to check with ALSA plugins first. It 
should be possible to try PulseAudio as an alternative method but I wait 
for instructions from hams who made it working.


Thanks anyway,

Misko

ALSA plugins

[Miroslav Skoric]

Hi all,

I was recently told that ALSA doesn't normally allow sharing a soundcard 
with two applications, but there are two ALSA plugins, dsnoop and dmix 
to share capture and playback respectively. I spent some time in 
searching the web for possible info on how to install or how to check if 
those plugins are installed, but did not find instructions. Any pointer 
in that direction? Thanks in advance.


Misko

Re: An old box running Debian 8

[Miroslav Skoric]

On 11/13/20 3:52 PM, Andrei POPESCU wrote:



Beware that LTS support for jessie ended in June 2020.

https://www.debian.org/releases/jessie/

That system should be upgraded to some release with security support as
soon as possible, especially since it's dealing with e-mail as far as I
understand from your other messages.



Well, ending LTS support for jessie was one of the reasons for 
considering upgrade 8 to 9. However, in any case it is a single-purpose 
machine where most of activity is 'unconnected'. Furthermore, the comp 
is behind the firewall where almost all in & out activities are banned.


Related to e-mail security: That box stores & forwards amateur radio 
traffic only, where the local users access their mailboxes by ham radio 
stations, not by the Internet. The Internet is used just for 
server-to-server batch exchange, where partnering servers are licensed 
and proven.


(And all of that is plain text only. No html, no scripts ... An 
advantage of ham radio vs. Internet  :-)


Misko

Re: An old box running Debian 8

[Miroslav Skoric]

On 11/13/20 9:29 PM, David Wright wrote:



I would have thought that Debian has made kernel testing just about as
easy as they can since:
jessie  installs with 3.16 but 4.9  is also available,
stretch installs with 4.9  but 4.19 is also available,
buster  installs with 4.19
so there's full overlap. (I've not looked at backports.)



That's actually what I also thought about.

Btw, when you say 'installs', do you mean a fresh installation only, or 
it includes a 'forced' kernel update during a distribution upgrade? My 
old box was installed for the first time in squeeze, then upgraded to 
wheezy, then to jessie.

Re: An old box running Debian 8

[Miroslav Skoric]

On 11/12/20 9:53 AM, Michael Lange wrote:



A really good option in this field is IceWM. It has everything a typical
user needs out-of-the-box and is extremely lightweight (and themeable).




From my own experience I agree about that.

Still, the tricky part will be to choose other gui programs that are
still usable with the OP's hardware. For example, if they need a gui text
editor, nedit may be light enough for such a machine (that is, if one can
live without proper unicode support) and maybe xfe may still be a usable
gui file manager for them. The display command provides probably a usable
image viewer.
Web browsers will be especially tricky.
If dillo is good enough it will probably behave more or less smoothly.
Using firefox would very likely be not much fun.



In fact, some basic GUI on that old box would be of use for only me as a 
system admin, especially when some newbies knock the office door asking 
to see if there is any nice graphics in Linux. (Remote users who access 
their mailboxes by radio stations do not need me having any GUI at all.)


In any case, I understood from this thread that after distro upgrade 
from 8 to 9 shall work in CLI, and then look for a simple window manager 
& light mail processor.


Thanks to all.

Misko

Re: Celeron vis a vis Pentium

[Miroslav Skoric]

On 11/11/20 10:24 PM, Felix Miata wrote:




...PS: Pentium II and Celeron are two processors.


Celeron is a budget family of Intel processors, based upon Pentium II, III, 4 
and
newer Pentium processors. Pentium II Celeron means a Celeron based upon the
Pentium II family, the oldest family of Celerons.



Yep. I purchased that machine (as then new) in early 1998  :-)

That's why I want to see its lifetime after full 'maturity' :-)

Misko

Re: An old box running Debian 8

[Miroslav Skoric]

On 11/13/20 12:12 AM, Linux-Fan wrote:


Miroslav Skoric writes:


On 11/11/20 7:09 PM, Linux-Fan wrote:

Pentium II is old indeed. Whenever using old processors, it is 
important to

test if the new kernel will still support them.


So maybe I shall try some newer kernel only?


If you have an easy means to do that: Yes, I would highly recommend doing
that.



I'll consider that kind of test (if possible at all). Need to check what 
(newer) kernels are available in Debian 8 repository. Cannot remember 
now what (if any) kernel change occurred when I upgraded 7 to 8.


Misko

Re: An old box running Debian 8

[Miroslav Skoric]

On 11/13/20 2:36 AM, Doug McGarrett wrote:

I have been only cursorily following here, since I don't use debian, but 
I wonder if you might
consider upgrading your mother board to a new one the same size and 
shape, with
a faster processor and probably more ram. Then the latest version of deb 
would surely work
and well. It's a full afternoon's worth of work, more than likely, but 
you would have to see
if you think it's worth it. A lot cheaper than replacing the whole 
machine, surely.

--doug




I see. But I think that any such hardware changes (CPU, RAM) are not 
worth. The idea is using that box until its EOL when something major 
dies. (And upgrade the OS & software until it becomes impossible.)


By the way ...

When it happens, I'll probably play the same 'upgrade game' with the 
next 'elderly' candidate (CPU Athlon XP 2500+ 1.84 GHz, 512 MB RAM). I 
purchased it some ten years ago as then second-hand, for some 70 US$, 
incl. CRT display, keyboard, mouse ... I have recently upgraded it from 
Deb 8 to 9, and the only issue was that after upgrade it did not want to 
boot in GUI at all (just stayed at blank screen). I resolved that by 
booting in CLI, and then startx to Mate (when needed).


Misko

Re: An old box running Debian 8

[Miroslav Skoric]

On 11/11/20 7:42 PM, Felix Miata wrote:




I have an old comp (CPU Pentium II Celeron 400 MHz, 224 MB RAM) running
ham radio server in Debian 8. It works well in CLI, but very slow after
starting GUI. I wonder whether it would be worth to try (if possible at
all) to upgrade it to Debian 9. Any experience with such old boxes?


Which WM or DE is your GUI running? Some use/need a lot more RAM than others. If
you want a full DE you might wish to try TDE, a fork of KDE3 initially created
when KDE went to version 4, 10 years ago. Its latest release is available for
Squeeze, Wheezy, Jesse, Stretch and Buster.




It is MATE (cannot remember the version). At first I removed all 
graphics, so it remained CLI-only Jesse. Then I installed Mate from the 
repository. Just for occasional use, not 24/7.


Btw, I did not even think of KDE or Gnome because they both were 
terribly slow even in Wheezy.


Did not much test MATE vs. Xfce or LXDE, regarding the speed.


Misko

Re: An old box running Debian 8

[Miroslav Skoric]

On 11/11/20 9:43 PM, Charles Curley wrote:




I have an old comp (CPU Pentium II Celeron 400 MHz, 224 MB RAM)
running ham radio server in Debian 8. It works well in CLI, but very
slow after starting GUI. I wonder whether it would be worth to try
(if possible at all) to upgrade it to Debian 9. Any experience with
such old boxes?


It is not clear whether you are merely observing that it is slow with a
GUI running, or whether you would like to have a GUI, and are asking
for advice specifically there.

Assuming the latter, what do you want out of a GUI? An absolute minimal
GUI such as FVWM might serve you well enough, but I would not expect
miracles. Also consider a lightweight desktop such as XFCE. But I would
be surprised if that solution helped.



At first, I wondered whether Pentium II Celeron 400 MHz, 224 MB RAM, 
would make it even bootable after upgrading 8 to 9. (Without any GUI, if 
needed to be removed before the upgrade).


And when bootable, what GUI might be workable at best (Mate, Xfce, ...)?
As I said, for nothing much more than occasional Thunderbird, or any 
other compatible mail client that can use the CLI-based ham email server 
(FBB), to process pop3/smtp mails by using copy/paste by mouse click etc.


At this stage (Debian 8) I do that in MATE + Thunderbird. It's slow but 
works. What is not known is whether that would work in Debian 9.

Re: An old box running Debian 8

[Miroslav Skoric]

On 11/11/20 7:09 PM, Greg Wooledge wrote:



Upgrading to a newer release is not likely to make it faster.  If anything,
it'll be slower (due to increased memory demands of newer software).



That's something I have already experienced with previous upgrades. But 
it was always in full GUI (either Gnome, KDE, LXDE, Mate, etc). While I 
examined that machine for a 'refurbished' CLI-based system, I removed 
all GUI. And it was not so bad. Then I re-installed Mate desktop again, 
just to run it for some specific tasks such as Thunderbird client. Of 
course the GUI + TB is terribly slow, but it is used only once in a while.



It's also worth noting that Debian 8->9 has a huge change to X and video
drivers.  Lots of chipsets are supported *differently* in Debian 9 than
they were in previous versions.  Whether that's good or bad will depend
on the chipset.  Some chipsets may have lost support altogether.



On another machine, a little bit better than the first one, I did have a 
big issue: After upgrading 8->9 and restart it did not want to open GUI 
at all, so the only solution was to boot in CLI, then 'startx' GUI. So I 
suppose than on this (older) box, GUI might be even more problematic. 
(It is Matrox MGA 400.)


On the other side, it makes me wonder if just CLI-only packages in 
Debian 9 would make it too slow after upgrade (if workable at all).



At this point, your system is quite old, and you should not expect it to
last forever.  Even if the software works perfectly, the hardware is
eventually going to fail.  You might want to get ahead of that by buying
something less ancient.  You might even save on electricity by doing this.




Yeah, I know. The point was to use it until the hardware dies :-)
Electricity? It is in the ham union's office, so nobody cares :-)

Re: An old box running Debian 8

[Miroslav Skoric]

On 11/11/20 7:09 PM, Linux-Fan wrote:



Pentium II is old indeed. Whenever using old processors, it is important 
to test if the new kernel will still support them.




So maybe I shall try some newer kernel only?

An old box running Debian 8

[Miroslav Skoric]

I have an old comp (CPU Pentium II Celeron 400 MHz, 224 MB RAM) running 
ham radio server in Debian 8. It works well in CLI, but very slow after 
starting GUI. I wonder whether it would be worth to try (if possible at 
all) to upgrade it to Debian 9. Any experience with such old boxes?


Misko YT7MPB

Re: Screensaver issues after distro upgrade

[Miroslav Skoric]

On 9/11/19 12:12 AM, Ben Caradoc-Davies wrote:



I saw the same problem when I tried lightlocker after upgrading to XFCE 
4.14, so I went back to good old xscreensaver. Ugly bitmaps fonts and no 
theming, but secure and reliable. There is a new locker in XFCE, but 
there have been reports of segfaults causing uncommanded unlock, so I 
consider it too vulnerable for use. There is a bug report.


Kind regards,



Ben, I just removed light-locker, and the problem disappeared. I did not 
reinstall xscreensaver (yet). Looks as if it is not required in my 
environment (MATE).


Regards,

Misko

Re: Screensaver issues after distro upgrade (SOLVED)

[Miroslav Skoric]

On 9/10/19 8:11 PM, Christopher David Howie wrote:


On 9/10/19 4:30 AM, Miroslav Skoric wrote:

After upgrading the old laptop from Jessie to Stretch, I noticed that
the screensaver in Mate environment does not work for me as before. For
example, when the screen goes black after some time of inactivity, for
returning back it is not enough just to touch the touchpad or press any
key. Instead, pressing any key or touching the touchpad makes the screen
just some 1% lighter than the full black (or better to say, it remains
99% black). However, the last working GUI does not return.


I have this same issue with the default configuration of XFCE on Buster,
where the problem was not present on Stretch.



Hi Chris,

Well, I noticed that issue after I recently upgraded to Stretch, but not 
had it in Jessie. Whatever. Having in mind that Stretch is oldstable for 
a while, and you had the issue in Buster, it seems that the issue goes 
through the versions intact :-)



Is light-locker installed, and do you use lightdm?  light-locker appears
to be the source of this issue.  Googling "light-locker black screen"
returns dozens of posts across many sites complaining about the same
problem.



Yes, light-locker was installed, and as soon as I removed it the problem 
disappeared. By the way, lightdm is still there, however I am unsure 
about the display manager in current use because it is the system that 
started initially from Squeeze several years ago, and included Gnome, 
KDE, LXDE, and XFCE (and I added MATE in Wheezy I think). Before the 
last dist-upgrade I removed KDE because I used it at least.



I resolved this issue by removing light-locker and installing
xscreensaver instead.  Note that this required removing a few
metapackages, and then marking the dependent packages that I wanted to
keep as manually installed to prevent apt from removing most of my
desktop tools.



Well, in trying solution for this issue, I removed xscreensaver 
yesterday. So it disappeared from MATE's menu System > Preferences > ... 
but that did not solve the problem.


Nevertheless now I only have one instance of screensaver preferences in 
MATE's System > Preferences > Look and Feel > Screensaver. It works well 
for now. I'll observe its behaviour, and report again if it is not good.


Thank you for help!

Misko

Screensaver issues after distro upgrade

[Miroslav Skoric]

Hello,

After upgrading the old laptop from Jessie to Stretch, I noticed that 
the screensaver in Mate environment does not work for me as before. For 
example, when the screen goes black after some time of inactivity, for 
returning back it is not enough just to touch the touchpad or press any 
key. Instead, pressing any key or touching the touchpad makes the screen 
just some 1% lighter than the full black (or better to say, it remains 
99% black). However, the last working GUI does not return.


The only solution I found is to press Ctrl-Alt-F1 and there is another 
GUI login screen, and after login I am returned back to the last state 
of GUI I was working in.


Furthermore, if I do not perform Ctrl-Alt-F1 in a relatively short time 
after the screen went black (but after some 15-20 mins or so), 
Ctrl-Alt-F1 gives the GUI login prompt again but the touchpad is not 
responding to touching and no key from keyboard reacts (and the mouse 
pointer looks as 'frozen'). However, it is still possible to press the 
left key bellow the touchpad to continue with login.


Ctrl-Alt-F2 remains 99% black as described above, while Ctrl-Alt-F3 to 
Ctrl-Alt-F6 bring text CGI login prompt. I wonder whether all of that 
are normal conditions for Stretch.


Finally, if the laptop is continually active (means without any kind of 
idling where the screensaver activates), it works perfectly for hours or 
more.


Any comment?

Misko

Re: Cannot boot after distro upgrade (SOLVED)

[Miroslav Skoric]

On 9/3/19 7:55 AM, Reco wrote:





However, I wonder whether the other partitions (/, /usr, /var) shall
remain ext3 in fstab, or they shall be changed to ext4 too.


blkid has an answer for that. If it says that your /, /usr and /var are
ext3 - leave them as that.

Reco




Exactly, blkid said just that. Thank you for help!

I'll look for potential system misbehaviour that might be linked with 
the previous issue, and will report here.


Misko

Re: Cannot boot after distro upgrade

[Miroslav Skoric]

On 9/2/19 1:19 AM, Pascal Hambourg wrote:



Sure. I upgraded Jessie to Stretch last week. And it worked well for 
me until Friday eve. (And before that I upgraded Wheezy to Jessie cca 
year ago. It worked well for me too.)


Until is doesn't work any more. You cannot run a new system with an old 
kernel forever. Some parts of the new system require new features 
provided by a newer kernel. You should have upgraded the kernel as soon 
as you upgraded from Wheezy to Jessie. Same when upgrading from Jessie 
to Stretch.




Probably you are right. But it makes me wonder why the previous upgrade 
(from Wheezy to Jessie), as well as this one (from Jessie to Stretch) 
did not upgrade the kernel automatically, as it did with other packages.


Whatever, at the end of the day, it works again so I appreciate your 
comments on kernel issues.

Re: Cannot boot after distro upgrade (SOLVED)

[Miroslav Skoric]

On 9/2/19 5:39 PM, Reco wrote:

Hi.

On Mon, Sep 02, 2019 at 04:44:18PM +0200, Miroslav Skoric wrote:

On 9/2/19 10:28 AM, Reco wrote:



Judging from the pictures, it's the ext4 filesystem.
So, let's proceed to the destructive steps:

fsck.ext4 -f /dev/localhost/tmp
mount -t ext4 /dev/localhost/tmp /tmp
umount /tmp
fsck.ext4 -f /dev/localhost/tmp

If the mounting succeeds, change filesystem type to ext4 for /tmp in
/etc/fstab, and do the same for /home.


New pictures ... looked to me as the second command (mount) failed.

Btw, somewhere it suggested 'dmesg | tail' so I inserted it too.


Ok, plan B.

Comment out both /home and /tmp from fstab.
Reboot. It should give you both the console and the network.
Install fresh stretch kernel (version 4.9.0-9), reboot.
Try mounting /tmp afterwards.

Reco




Reco,

Thanks, success! Btw, since I don't not have broadband on my place where 
I read your plan B, I went to another place and did it slightly 
differently: I installed the new kernel (without prior commenting out 
/home and /tmp from fstab), then rebooted. The machine still reported 
the same errors as before - but after I changed fstab params for /home 
and /tmp to be ext4, it mounted them in a second. Subsequent rebooting 
was OK too. Will observe the behaviour in days to come.


Now I suppose that the above commands (plan A) are not needed. However, 
I wonder whether the other partitions (/, /usr, /var) shall remain ext3 
in fstab, or they shall be changed to ext4 too.


Misko

Re: Cannot boot after distro upgrade

[Miroslav Skoric]

On 9/1/19 7:52 PM, Étienne Mollier wrote:



The output of the above command (version dumpe2fs 1.43.4
31-Jan-2017) is the same as yours, with *one addition*:
inline_data


Good news, this is consistent with Reco's observation in the
other thread.  Follows his recommendations and see what happens.



Sure. I sent few photos on the commands' output. Don't know if the list 
accepts attachments.



root@(none):/# nano /etc/fstab
#
...
proc/procprocdefaults00
/dev/mapper/localhost-root/   ext3errors=remount-ro 0
1
# /boot was on /dev/sda1 during installation
UUID=../bootext2defaults02
/dev/mapper/localhost-home/homeext3defaults 02
/dev/mapper/localhost-tmp/tmpext3defaults 02
/dev/mapper/localhost-usr/usrext3defaults 02
/dev/mapper/localhost-var/varext3defaults 02
/dev/mapper/localhost-swap_1noneswapsw00
/dev/scd0/media/cdrom0udf,iso9660 user,noauto00


I don't suppose these /, /usr and /var have this "inline_data"
flag in "dumpe2fs" output, do they?



That's a completely new area for me, so I don't know :-)

Regards,

Misko

Re: Cannot boot after distro upgrade

[Miroslav Skoric]

On 9/2/19 12:26 AM, Pascal Hambourg wrote:


Le 01/09/2019 à 22:59, Miroslav Skoric a écrit :


root@(none):/# uname -a
Linux (none) 3.2.0-4-486 #1 Debian 3.2.96-2 i686 GNU/Linux


So you upgraded from Jessie to Stretch but still ran the old kernel from 
Wheezy all this time ? Wow.




Sure. I upgraded Jessie to Stretch last week. And it worked well for me 
until Friday eve. (And before that I upgraded Wheezy to Jessie cca year 
ago. It worked well for me too.) It's almost a ten year old laptop now.


If the dist upgrade was not complete (and if the system not functional 
anymore), how to change/upgrade the kernel now?


apt-get install linux-image-586



Hmmm, without network? Ok, I will see if I could enable networking ...

Re: Cannot boot after distro upgrade

[Miroslav Skoric]

On 9/1/19 8:40 PM, Pascal Hambourg wrote:


Le 01/09/2019 à 17:01, Miroslav Skoric a écrit :


EXT3-fs (dm-6): error: couldn't mount because of unsupported optional 
features (8000)


This is not the same as the previous error message you showed while 
using the Debian Jessie 8.11 installer in rescue mode :



EXT4-fs (dm-6): couldn't mount as ext3 due to feature incompatibilities


See the differences ?

EXT3-fs vs EXT4-fs : "recent" versions of the kernel use the ext4 driver 
for all ext* versions. Seeing "EXT3-fs" indicates that you run a very 
old kernel, older that the 3.16 one included in Jessie.


"unsupported feature" vs "feature incompatibilities" : the former means 
that the kernel does not support the feature (too old, again) whereas 
the latter means that the feature is incompatible with mounting as ext3.


man ext4 states that "inline_data" feature is supported since version 
3.8, so the 3.16 kernel from Jessie would support it.


what kind of outdated kernel version are you running ? Is it still the 
3.2 version from Wheezy ? Looks like the dist upgrade was not complete. 
If so, install a 3.16 kernel, replace ext3 with ext4 or auto for the two 
filesystems, reboot and see if they mount fine.





Hi Pascal,

root@(none):/# uname -a
Linux (none) 3.2.0-4-486 #1 Debian 3.2.96-2 i686 GNU/Linux
root@(none):/#


If the dist upgrade was not complete (and if the system not functional 
anymore), how to change/upgrade the kernel now?


Tnx.

Misko

Re: Cannot boot after distro upgrade

[Miroslav Skoric]

On 9/1/19 5:33 PM, Reco wrote:



So, let's do something easy and non-destructive first (I assume that
/tmp does not contain anything useful):

tune2fs -l /dev/localhost/tmp

fsck.ext3 -f -n /dev/localhost/tmp

fsck.ext4 -f -n /dev/localhost/tmp

fsck.ext3 -b 8193 -f -n /dev/localhost/tmp

fsck.ext4 -b 8193 -f -n /dev/localhost/tmp

And, for the good measure,

uname -a

Reco




Reco,

There is a lot in the output of those commands. I can put the outputs 
into txt files, but cannot mount the usb stick to transfer the content 
to the other comp to send it. Syntax ..?


Or to wait that I copy/paste the output by hand :-)

Misko

Re: Cannot boot after distro upgrade

[Miroslav Skoric]

On 9/1/19 1:20 PM, Étienne Mollier wrote:



Hi Miroslav,

Pascal is probably right.  If you manage to have access to the
command "dumpe2fs" in your rescue environment, what is the
output of:

# dumpe2fs /dev/mapper/localhost-home | grep '^Filesystem features:'

Actual Ext3 should probably not have more features than:

has_journal ext_attrresize_inode
dir_index   filetypesparse_super
large_file

If you have more, you most likely want to edit your /etc/fstab
entries to use ext4.  Out of curiosity, how are defined your /,
/usr and /var in fstab ?  It could be interesting for us to see
the differences, since you mention those are mounting properly.



Hi Étienne,

The output of the above command (version dumpe2fs 1.43.4 31-Jan-2017) is 
the same as yours, with *one addition*: inline_data


root@(none):/# nano /etc/fstab
#
...
proc/procprocdefaults00
/dev/mapper/localhost-root  /   ext3errors=remount-ro 01
# /boot was on /dev/sda1 during installation
UUID=../bootext2defaults02
/dev/mapper/localhost-home/homeext3defaults 02
/dev/mapper/localhost-tmp/tmpext3defaults 02
/dev/mapper/localhost-usr/usrext3defaults 02
/dev/mapper/localhost-var/varext3defaults 02
/dev/mapper/localhost-swap_1noneswapsw00
/dev/scd0/media/cdrom0udf,iso9660 user,noauto00


Regards,

Misko

Re: Cannot boot after distro upgrade

[Miroslav Skoric]

On 8/31/19 3:48 PM, Reco wrote:


On Sat, Aug 31, 2019 at 03:41:12PM +0200, Miroslav Skoric wrote:

On 8/31/19 3:26 PM, Reco wrote:



Boot with init=/bin/bash kernel commandline parameter, remount root
filesystem read-write, fix your /etc/fstab (systemd is picky about
filesystems it's not able to mount, and no, "noauto" won't fix it),
reboot once more.


Sorry for my ignorance, but where to put that "init=/bin/bash"? Here I have 
LILO and it starts booting properly.


http://tldp.org/HOWTO/LILO-2.html , chapter 2.3.

Reco




Ok Reco, I managed to crawl through this a little bit (I am an old 
person), so when I reached prompt, did that:


root@(none):/# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=1514900k,nr_inodes=215931,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=304560k,mode=755)
/dev/mapper/localhost-root on / type ext3 
(rw,relatime,errors=continue,barrier=1,data=ordered)
/dev/mapper/localhost-usr on /usr type ext3 
(rw,relatime,errors=continue,barrier=1,data=ordered)

root@(none):/#

root@(none):/# mount -a
[ 1024.810706] EXT3-fs (dm-6): error: couldn't mount because of 
unsupported optional features (8000)
mount: wrong fs type, bad option, bad superblock on 
/dev/mapper/localhost-home, missing codepage or helper program, or other 
error


In some cases useful info is found in syslog - try dmesg | tail or so.
[ 1024.839252] EXT3-fs (dm-5): error: couldn't mount because of 
unsupported optional features (8000)
mount: wrong fs type, bad option, bad superblock on 
/dev/mapper/localhost-tmp, missing codepage or helper program, or other 
error


In some cases useful info is found in syslog - try dmesg | tail or so.
[ 1024.874388] kjournald starting. Commit interval 5 seconds
[ 1024.874702] EXT3-fs (dm-3): using internal journal
[ 1024.874761] EXT3-fs (dm-3): mounted filesystem with ordered data mode
root@(none):/#

root@(none):/# dmesg | tail
[ 19.828971] kjournald starting. Commit interval 5 seconds
[ 19.836188] EXT3-fs (dm-2): using internal journal
[ 19.836246] EXT3-fs (dm-2): mounted filesystem with ordered data mode
[ 19.838924] aufs: module is from the staging directory, the quality is 
unknown, you have been warned.

[ 19.840477] aufs 3.2.x+setfl-debian
[ 1024.810706] EXT3-fs (dm-6): error: couldn't mount because of 
unsupported optional features (8000)
[ 1024.839252] EXT3-fs (dm-5): error: couldn't mount because of 
unsupported optional features (8000)

[ 1024.874388] kjournald starting. Commit interval 5 seconds
[ 1024.874702] EXT3-fs (dm-3): using internal journal
[ 1024.874761] EXT3-fs (dm-3): mounted filesystem with ordered data mode

root@(none):/# nano /etc/fstab
#
...
proc/proc   procdefaults0   0
/dev/mapper/localhost-root  ext3errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=.. /boot   ext2defaults0   2
/dev/mapper/localhost-home  /home   ext3defaults 0  2
/dev/mapper/localhost-tmp   /tmpext3defaults 0  2
/dev/mapper/localhost-usr   /usrext3defaults 0  2
/dev/mapper/localhost-var   /varext3defaults 0  2
/dev/mapper/localhost-swap_1noneswapsw  0   0
/dev/scd0   /media/cdrom0   udf,iso9660 user,noauto 0   0


Whatever I tried to fix in fstab, did not bring improvement. As Pascal 
Hambourg suggested, tried also to mount /home and /tmp as ext4  but no 
avail. At next reboot:


...
...
[FAILED] Failed to mount /home.
See 'systemctl status home.mount' for details.
...
...
...

and similar for /tmp


By the way, there appeared some other errors (I hope not in connection 
with the main issue):


...
...
[FAILED] Failed to start Console System Startup Logging.
See 'systemctl status console-kit-log-system-start.service' for details.
[FAILED] Failed to start Enable support for additional executable binary 
formats.

See 'systemctl status binfmt-support.service' for details.
...
...

Any idea?

Misko

Re: Cannot boot after distro upgrade

[Miroslav Skoric]

On 8/31/19 3:26 PM, Étienne Mollier wrote:



Maybe a check
of the memory and SMART data, if those options are available
from your BIOS, could be welcome, especially SMART since some
messages were mentioning checking the disk.



I checked the system memory and hard disk self test (quick test and 
SMART check), and the tests passed OK.



If operations here over do not make any difference, then you
really should consider creating a Rescue drive on an USB thumb.
I have had a good experience with SystemRescueCD over the years:

http://www.system-rescue-cd.org/

But if you have a Debian installation media, you can also
achieve a thing or two by booting on the "Rescue Mode".



Ok, I borrowed from a friend the first installation CD for Debian 8.11.1 
i386 and tried to use it for rescue. (I still have the CDs for Debian 
6.0.1a i386 but supposed that the newer version is better.)


So, when entered rescue mode, I tried fsck at first. It refused because 
/dev/mapper/localhost-root was mounted as root file system. So I 
unmounted it and tried fsck again. It reported several issues in 
/dev/mapper/localhost-home and /dev/mapper/localhost-tmp, and offered to 
truncate and/or to fix them. When finished, the subsequent fsck reported 
all clean (/dev/mapper/localhost-home, /dev/mapper/localhost-tmp, 
/dev/mapper/localhost-usr, /dev/mapper/localhost-var).


# mount -a  reported (among the others):

 "wrong fs type, bad option, bad superblock on 
/dev/mapper/localhost-home, missing codepage or helper program, or other 
error"


and

 "wrong fs type, bad option, bad superblock on 
/dev/mapper/localhost-tmp, missing codepage or helper program, or other 
error"



# dmesg | tail reported (among the other):

EXT4-fs (dm-6): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (dm-5): couldn't mount as ext3 due to feature incompatibilities


# mount reported that /, /usr, and /var were there, but not /home and /tmp.


My /etc/fstab includes:

/dev/mapper/localhost-home /home ext3 defaults 0 2
/dev/mapper/localhost-tmp /tmp ext3 defaults 0 2


When I reboot, those two fail.

Any idea?


PS: I can also try with that SystemRescueCD but just wanted to try this 
quickest way ...


Misko

Re: Cannot boot after distro upgrade

[Miroslav Skoric]

On 8/31/19 3:26 PM, Étienne Mollier wrote:



Perhaps you can attempt a boot in "Recovery Mode", see the
"Advanced Boot Options" at the Grub menu stage of the boot.
It could have a positive effect if a faulty kernel module is
loaded and causes this loop in the boot sequence.  Maybe a check
of the memory and SMART data, if those options are available
from your BIOS, could be welcome, especially SMART since some
messages were mentioning checking the disk.



Thanks for idea. However, there is no Grub here, only Lilo. I will check 
BIOS for options.



If operations here over do not make any difference, then you
really should consider creating a Rescue drive on an USB thumb.
I have had a good experience with SystemRescueCD over the years:

http://www.system-rescue-cd.org/

But if you have a Debian installation media, you can also
achieve a thing or two by booting on the "Rescue Mode".



Will try some of those. I have Debian installation media for 6.0.1 only 
and unsure whether it would work with strech.



If you absolutely positively do not want to build a rescue
media, last chance option would be to edit the Grub menu entry,
and in the linux line, edit (or append if non-existent) the
following "init=" option (hit 'e' to edit the menu entry and F10
to boot):

linux root=UUID=[...] ro init=/bin/bash

This is a last chance option, do not expect your system to
operate properly without a regular init process.  Boot in this
mode only to proceed to your investigations as of why the
machine fails to spawn the login process.  Quitting this shell
hangs the machine; you have to hard reset.



As said, no Grub here. Is there similar option for Lilo?

Thanks!

Misko

Re: Cannot boot after distro upgrade

[Miroslav Skoric]

On 8/31/19 3:26 PM, Reco wrote:



Boot with init=/bin/bash kernel commandline parameter, remount root
filesystem read-write, fix your /etc/fstab (systemd is picky about
filesystems it's not able to mount, and no, "noauto" won't fix it),
reboot once more.

Reco




Hi,

Sorry for my ignorance, but where to put that "init=/bin/bash"? Here I 
have LILO and it starts booting properly. However, after a page or two, 
everything stops at the point I mentioned in my previous mail. And as I 
said, I never get root console prompt or anything like that. So how to 
remount filesystem, etc ... (Btw, it is encrypted LVM, if it can help. 
Seems that decryption part passes well, but somewhere later booting fails.)


Misko

Cannot boot after distro upgrade

[Miroslav Skoric]

Hello,

After upgrading the old laptop from jessie to strech, it worked well for 
few days (although more slowly than it was with jessie). But after last 
proper shutdown, it does not boot anymore. In fact, it starts to boot 
until it comes to a point where it says:


"You are in emergency mode. After logging in, type "journalctl -xb" to 
view system logs, "systemctl reboot" to reboot, "systemctl default" or 
^D to try again to boot into default mode.


Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue."


Ok, when I press Enter it says:

"Checking in progress on 2 disks (0.0% complete)"

... it takes 1-2 seconds .. while it changes to:

"Checking in progress on 1 disk (11.0% complete)"

... and returns back to the first message:

"You are in emergency mode. After logging in, type "journalctl -xb" to 
view system logs, "systemctl reboot" to reboot, "systemctl default" or 
^D to try again to boot into default mode.


Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue."

... and further pressing Enter seems to go nowhere and repeat endlessly. 
Ctrl-Alt-F* does not open any new console. This one with error doesn't 
accept anything but Enter.


I do not have any rescue/emergency media because it was an old 
installation, started several years ago with squeeze, and upgraded over 
time to wheezy, jessie, ..


Any idea what to do? Thanks.

Misko

Re: Not power off after shutdown in Jessie

[Miroslav Skoric]

On 06/10/2018 06:33 PM, The Wanderer wrote:


On 2018-05-31 at 02:01, Miroslav Skoric wrote:


After upgrading from Wheezy LTS to Jessie, one of my machines having 512
MB RAM, does not power off when it reached target shutdown. It seems
some old issue/bug with systemd or else. In fact, everything closes down
properly except it does not unmount the following:

/run/user/1000
/run/user/106
/var
/home
/tmp


How can you tell that these are still mounted?



Because the machine kept reporting 'failed unmount' for these above, 
something like this:


umounting /run/user/1000
failed to umount /run/user/1000
umounting /run/user/106
failed to umount /run/user/106
...
...

(Sorry I forgot the exact syntax of how the machine reported that, 
because it was last week. But it finally started to poweroff properly 
after I removed all clamav -related stuff from that machine. In fact, I 
noticed that all those clam* things still belonged to Wheezy, being in 
versions ...deb7u1 or so, after I upgraded Wheezy LTS to Jessie.)




Could it be a kernel/BIOS incompatibility? (I.e., probably something to
do with ACPI tables.)



I don't know ... I got that machine some 6-7 years ago, as a second-hand 
then. So it is probably some 10+ year old at least.




The only fix I've found for that problem, aside from reverting to the
older kernel, is to upgrade the BIOS on the affected computers. Some of
them had BIOS versions dating back to at least 2012, if not 2009;
bringing them up to the manufacturer's latest BIOS release for that
model got the new environments to shut down and reboot normally.



I see. But as I said, removing some packages returned the box to normal 
shutdown.


Furthermore, what wondered me even more is that another *older* box I 
have here (dated back to the beginning of the previous decade!), that 
runs with only 224MB RAM on Celeron 400MHz, did not experience failure 
in poweroff at all.

Re: Not power off after shutdown in Jessie

[Miroslav Skoric]

On 06/04/2018 03:12 PM, Curt wrote:



I'm really too ignorant to be answering questions and should be asking some.

However I can't think of any.

Except: any clues in the logs?

Look here:

  /usr/share/doc/systemd/README.Debian.gz

under

  Debugging boot/shutdown problems
  

which explains how to create a root debug shell on VT 9 available quite
late in the shutdown process; or, failing or in lieu of that, generating a
shutdown-log.txt file instead.

Good luck.




Thank you for ideas. Well I am not an expert into debugging shutdown 
processes at all. However, systemctl in VT9 returned some "failed" units 
for boot (as well as many still "active" ones for shutdown), among which 
I saw "failed" clamd or some else service related to clamav. And since I 
really did not need any clam* things on that particular machine any 
more, I went to Synaptic manager and purged them all.


(Btw, I noticed that all those clam* things still belonged to Wheezy ... 
like deb7u1 or so, dunno whether they should had been automatically 
upgraded to some deb8u* during the distro upgrade Wheezy LTS >> Jessie.)


Whatever, the first next shutdown was successful, as well as the 
subsequent dozen ones, as well as the reboot sessions. Will keep an eye 
on that ... tnx for now.

Re: Not power off after shutdown in Jessie

[Miroslav Skoric]

On 05/31/2018 08:01 AM, Miroslav Skoric wrote:

After upgrading from Wheezy LTS to Jessie, one of my machines having 512 
MB RAM, does not power off when it reached target shutdown. It seems 
some old issue/bug with systemd or else. In fact, everything closes down 
properly except it does not unmount the following:


/run/user/1000
/run/user/106
/var
/home
/tmp

... and hangs there forever. That did not happen in Wheezy. Any idea?



Btw, after waiting for at least 3-4 hours for poweroff, I went to tty1 
console to try ctrl-alt-del there (because that did not work in tty7 
where the system left hanging). It did not help much there too, however 
I noticed two new lines there:


[74199.357014] systemd[1]: var.mount failed to run 'umount' task: Cannot 
allocate memory
[74199.380035] systemd[1]: home.mount failed to run 'umount' task: 
Cannot allocate memory



Any idea?

Re: Not power off after shutdown in Jessie

[Miroslav Skoric]

On 05/31/2018 04:18 PM, Curt wrote:


On 2018-05-31, Miroslav Skoric  wrote:

After upgrading from Wheezy LTS to Jessie, one of my machines having 512
MB RAM, does not power off when it reached target shutdown. It seems
some old issue/bug with systemd or else. In fact, everything closes down
properly except it does not unmount the following:

/run/user/1000
/run/user/106
/var
/home
/tmp

... and hangs there forever. That did not happen in Wheezy. Any idea?




You could try logging out, I've read somewhere, switching to a console,
logging in as root (or another user entirely) and executing
'systemd-cgls' to determine what processes are still running for the
user in question (assuming for the moment your problem is related to
some program in your session being "stuck.")




I did so, and noticed just some few Gnome -related things to be active 
for the user 106 - myself? (although I logged out from the Mate desktop 
and not from Gnome), as well as a few items active for user 1000 i.e. 
root (such as 'sudo su' and 'systemd-cgls').


Anyway, to be sure whether any of those processes were needed to run or 
not, I did in parallel the same test with another slower machine running 
Jessie at only 224MB RAM (also the recent upgrade from Wheezy), but 
which one performs proper shutdown/poweroff.


You bet, at both machines exactly the same processes were listed as 
still running for user 106 and user 1000. However, only the better one 
box having 512 MB RAM, does not power off when reached target shutdown.


Any other thing to try?

Not power off after shutdown in Jessie

[Miroslav Skoric]

After upgrading from Wheezy LTS to Jessie, one of my machines having 512 
MB RAM, does not power off when it reached target shutdown. It seems 
some old issue/bug with systemd or else. In fact, everything closes down 
properly except it does not unmount the following:


/run/user/1000
/run/user/106
/var
/home
/tmp

... and hangs there forever. That did not happen in Wheezy. Any idea?

Re: making more room in root partition for distribution upgrade

[Miroslav Skoric]

On 05/21/2018 03:55 PM, David Wright wrote:


As for appendix C in the Installation Manual, well that looks like
a bit of a joke: who's running linux in 256MB memory, let alone 16MB?



One of my older machines still runs Wheezy LTS in 224 MB RAM. And soon I 
am going to try an upgrade to Jessie.

Re: [semi-OT] temperature/humidity/flood sensor recommendations

[Miroslav Skoric]

On 01/08/2018 04:57 PM, Roberto C. Sánchez wrote:


Hi all,

This is semi-OT but I am curious to know what temperature/humidity/flood
sensors everyone out there has experience with.

I am looking for something to use at home, but I would like to stay away
from WiFi and smart home devices.  Basically, I am looking for something
simple, which plugs into Ethernet, and makes its data available via HTTP
and/or telnet (or any other simple text-based protocol).  If it includes
some other fancy features (e.g., sending email alerts, SNMP traps, etc.)
then that is OK too.  I don't care whether it does onboard data storage.

I intend to integrate this with my own existing monitoring solution that
already includes Icinga, some custom scripts, logcheck alerts, and a few
other odds and ends (e.g., email alerts from apcupsd for power outages).

Any suggestions?

Regards,

-Roberto



Maybe you could think about some of those sensors:

https://www.modmypi.com/electronics/sensors-347/temperhum-usb-temperature-and-humidity-sensor/
https://www.modmypi.com/electronics/sensors-347/temper-gold-original-usb-temperature-sensor
https://www.modmypi.com/electronics/sensors-347/temper2-usb-dual-temperature-sensor/

For example, I managed to get some incomplete results with TEMPerHUM 
temperature & humidity sensor and temper-python 
(https://github.com/padelt/temper-python) in Wheezy. I sent my reports 
to ModMyPi, www.modmypi.com, to post them on their website. You may 
check there. I wish I had an option to get the monitored data written 
into a file that, in turn, my amateur radio software could recognize as 
a source of APRS 'weather data'. (When I experimented with that sensor, 
a command executed in CLI only returned a single line of data at a time, 
so that did not satisfy my needs. So I would appreciate whether 
temper-python or some other software could be upgraded in that direction.)


Misko

Re: Recreating a second boot kernel in LILO

[Miroslav Skoric]

On 01/14/2017 05:38 PM, Stephen Powell wrote:

On Sat, Jan 14, 2017, at 10:05, Richard Owlett wrote:

On 1/14/2017 8:45 AM, Miroslav Skoric wrote:

Hello all,

Intro: I have been using LILO for ages. Now running Wheezy 7.11
LTS. As usual and for test purposes on older machines I have two
kernel flavours: 486 and 686-rt. In LILO boot menu they appear as
Linux486 and Linux686 (before renaming they were Linux and
LinuxOLD). Both work nice on two desktops of different age.

Anyway, few years ago I had a repetitive problem with the 686-rt
kernel slowing down the touch pad on a laptop, so I decided to
remove it completely. So in the LILO menu was left just one boot
option. Recently I decided to install 686-rt again, and during
the installation it added new config*, init.rd*, and vmlinuz*
into /boot, but it did not add any new init.rd* and vmlinuz*
links into /. And without that LILO still keeps one entry. Any
idea how to produce new links in / in order to recreate the
second boot entry? (In lilo.conf everything is the same as in
desktops, however /sbin/lilo complains about missing links in /)

M.S.


You may find Steve Powell's LILO Page useful -
http://www.stevesdebianstuff.org/lilo.htm
Also http://www.stevesdebianstuff.org/index.htm may be of interest.
HTH




The default installation of lilo assumes that the user is only interested
in booting the two most recently-installed kernels.  By Debian convention,
symbolic links are assigned to these kernels in / if "do_symlinks = yes"
is specified in /etc/kernel-img.conf.  The most recent kernel
is assigned the symbolic link name "vmlinuz", and the next-most-recent kernel
is assigned the symbolic link name "vmlinuz.old".  The same pattern is
followed with the initial RAM file system images that correspond to these
kernel images.  The most recent initial RAM file system image is given the
symbolic link name "initrd.img", and the next-most-recent initial RAM file
system image is given the symbolic link name "initrd.img.old".  If
"link_in_boot = yes" is present in /etc/kernel-img.conf, then these symbolic
links are maintained in /boot instead of in /.  However, these symbolic links
are maintained only for stock Debian kernels.  For custom kernels created
with make-kpkg or "make deb-pkg", "do_symlinks = yes" in /etc/kernel-img.conf
has no effect.  In my web page, referred to above by Richard Owlett, I provide
a reference to my kernel building web page where there are execs called
zy-symlinks which will provide equivalent function for custom kernels.

If there are special kernels that you want to be able to boot which are outside
the normal "last two", then you must manually edit /etc/lilo.conf to provide
the capability to boot this kernel, then run lilo.



Thank you all for your comments. Anyway, I think when I made the initial 
install several years ago (it was Squeeze 6.0.1a) it offered more than 
one kernel option for installation, so I probably chose two flavours to 
be installed, or something like that. So whenever a new kernel update 
appeared after that, it flawlessly updated both flavours (486 version & 
686-rt version). So I always ended with two new kernels, and I could 
test/use them interchangeably. Yes I know that was not in accord with 
best LILO practices, but it worked for me. And I also realized the risk 
of neither update to be of 100% quality, but what is a chance that both 
kernel flavours might fail in the same update cycle?


Anyway, I have managed to recreate a second boot kernel in LILO, so 
things work nice for now.


M.S.

Recreating a second boot kernel in LILO

[Miroslav Skoric]

Hello all,

Intro: I have been using LILO for ages. Now running Wheezy 7.11 LTS. As 
usual and for test purposes on older machines I have two kernel 
flavours: 486 and 686-rt. In LILO boot menu they appear as Linux486 and 
Linux686 (before renaming they were Linux and LinuxOLD). Both work nice 
on two desktops of different age.


Anyway, few years ago I had a repetitive problem with the 686-rt kernel 
slowing down the touch pad on a laptop, so I decided to remove it 
completely. So in the LILO menu was left just one boot option. Recently 
I decided to install 686-rt again, and during the installation it added 
new config*, init.rd*, and vmlinuz* into /boot, but it did not add any 
new init.rd* and vmlinuz* links into /. And without that LILO still 
keeps one entry. Any idea how to produce new links in / in order to 
recreate the second boot entry? (In lilo.conf everything is the same as 
in desktops, however /sbin/lilo complains about missing links in /)


M.S.

Gnome GUI: status line issue

[Miroslav Skoric]

Hi,

I am not sure now how that has happened, but probably somewhere during 
the system upgrade from squeeze to wheezy (the upgrade done from within 
GUI), one of my machines somehow lost the ability of the status line in 
Gnome GUI to show icons of active program windows, either normal or 
[minimized]. What to do to recover that ability? (Now in the status 
line, there are only four boxes on the right for Workspaces 1-4. All the 
remaining of the line is empty black.)

Gnome: status line issue

[Miroslav Skoric]

Hi,

I am not sure now, but probably somewhere during the system upgrade from 
squeeze to wheezy, one of my machines somehow 'lost' the ability of the 
status line in Gnome GUI to show active programs, normal or [minimized]. 
What to do to recover that ability?


Regards,

M.

Re: Machine freezes after kernel update

[Miroslav Skoric]

On 10/10/2015 09:33 PM, Piyavkin wrote:



Yeah, but if the issue becomes permanent in all the future versions
starting from 3.2.71-2? It's kind of scary.



Good news: After some time waiting, there came version 3.2.73-2 and I 
tested it both with 686-rt and 486 flavors. Both work good. No problem 
with booting into GUI.


M.S.

Re: Machine freezes after kernel update

[Miroslav Skoric]

On 10/10/2015 09:33 PM, Piyavkin wrote:



Miroslav, by the way, what version of BIOS your laptop has?




Insyde F15

Re: Machine freezes after kernel update

[Miroslav Skoric]

On 10/09/2015 06:09 PM, Brad Rogers wrote:



If that's true, that's a *serious* bug.  LILO (or Grub, come to that)
should never delete kernels.  I know Grub doesn't but, as I said before,
I've not used LILO for some years.  Even so, I'd be surprised if it could
actually _delete_ kernels like that.  Keeping an old, known to work
kernel is the sensible thing to do.



Well, what I gonna do is to test LILO behaviour with some other two 
machines, a newer one having 3.2.0-4-rt-686-pae kernel only, and the 
other one running 3.2.0-4-486 only. (But before that, I'll wait for a 
while to skip the last problematic update.)

Re: Machine freezes after kernel update

[Miroslav Skoric]

On 10/09/2015 05:19 PM, Chris Bannister wrote:



In fact, (and in my case) LILO does delete old kernels during the upgrade,


Wow! I really think that is a bug *if* it does. What makes you think
that is the case?



Ok, let me say it this way: That laptop has 2 different flavours of 
kernel, the first one is rt-686-pae while the other is 486, and the 
first one has a 'regular' "Linux" entry within LILO boot menu, while the 
second one was designated as "LinuxOLD" entry. (Btw, that machine was 
gradually upgraded to wheezy 7.9, and started as squeeze 6.0.1a some 2.5 
years ago, so I forgot the initial kernel setup.) Anyway, for a long 
time now there have been only such two kernel options, so I could choose 
in between them. As long as I remember, during every kernel update both 
kernels were updated in the same time so I could test each one 
instantly. I never had any system freezing since the very beginning of 
squeeze. And by looking into the /boot/ directory, I always saw the 
single newest instance of each flavour. I have never seen any older 
version kept there after the update. (Have I missed to look into some 
other folder?)


One more thing that might be interesting: For some traditional reasons 
(say, rather conservative personality), I haven't tried GRUB on that 
machine. In opposite to that, I have a desktop comp running Ubuntu 
(started with 10.04.x LTS and gradually upgraded to 14.04.x LTS) where I 
initially had GRUB for a while. I remember that very soon GRUB menu 
became filled in with a lot of kernel options, and that it kept a dozen 
or more kernels there, so later I decided to install LILO and remove 
GRUB. Interestingly, that Ubuntu still keeps some 7-8 older kernels 
backwards (until I de-install them - I do it maybe once per year because 
I do have a plenty of disk space there). Btw, /boot/grub/ sub-folder is 
still there for unknown reasons, so it might be that some GRUB 'ghost' 
forces it to keep older stuff :-)

Re: Machine freezes after kernel update

[Miroslav Skoric]

On 10/09/2015 08:45 PM, Piyavkin wrote:



I have exactly the same issue with the same kernel-packages. See here:
https://lists.debian.org/debian-user/2015/10/msg00231.html



Yes, my symptom was identical to what you have described there. 
Interestingly you use GRUB and not LILO, but even your GRUB was also not 
keeping the previous kernel(s) too. Very strange.




And what should we do with future upgrades from now?



Probably, to wait for a while in order to avoid that 'faulty' 3.2.71-2 
iteration of 3.2.0-4 kernels.

Re: Machine freezes after kernel update

[Miroslav Skoric]

On 10/08/2015 10:58 AM, Riley Baird wrote:


rescue CLI?


If dpkg is available during the rescue CLI, you can install the .deb file
using the command

$ dpkg -i /path/to/packagename.deb



Riley, that was the solution I looked for and dpkg did the job. I 
reinstalled the previous kernel and removed the failed one. So the 
system does not freeze any more. Thanks!


Furthermore, as mentioned in my other mail, I used to have 486 and 
686-pae kernels, and was used to switch from one to another from time to 
time, to see the difference. In the past I noticed that 686-pae tend to 
make mouse cursor moving slowly for a while, then to recover as usual, 
then maybe run slowly again and again, etc. Is that a known issue with 
686-pae versions?



Then, to make sure that apt doesn't want to upgrade to the latest kernel
version, you can use the command

$ apt-mark hold packagename



Btw, does it give a temporary or permanent block for further kernel 
upgrades? Thanks.

Re: Machine freezes after kernel update

[Miroslav Skoric]

On 10/08/2015 12:37 AM, Brad Rogers wrote:


Thanks. Well I do not have GRUB here but LILO, and there are no saved
old kernels as long as I know.


There should be;  Debian doesn't delete old kernels as part of the
upgrade process.  Even LILO should have an option to boot older
kernels.  Older kernels are deliberately kept such that, if the new
kernel *does* fail, you can still, hopefully, use a previous one.  It's
been a long time since I used LILO, so can't advise how to access those
old kernels.



In fact, (and in my case) LILO does delete old kernels during the 
upgrade, however I always had two opportunities for booting the system 
(one kernel of 486 category a.k.a. "older machines", the other of 
686-pae type for "modern machines"). During all kernel upgrades up to 
now (since squeeze 6.0.1a to wheezy 7.9) both kernels had been replaced 
by newer versions at the same time, and I was always able to restart the 
system without issues. This was the first time that both kernel variants 
failed to boot.



archived in /var/cache/apt/archives as .deb packages. For example,


Those are an artefact of the install process;  You appear not to be
deleting packages once installed successfully.  Nothing wrong with
that, but you can end up short on disk space that way.  This lack of
space can lead to booting issues.



Well, there were just few .deb packages of the last known kernels there 
- so not much space was occupied. And I had luck with them because I 
used them to reinstall the previous (good) kernel images without 
downloading them again :-)  So it seems that keeping those packages in 
cache for a while was actually useful. Thanks anyway.

Re: Machine freezes after kernel update

[Miroslav Skoric]

On 10/07/2015 08:56 AM, Riley Baird wrote:


After the last kernel update and restart, a wheezy-based machine (laptop
running 7.9) boots to some point, however it freezes just before opening
GUI. Access to CLI (Ctrl-Alt-F1 etc) is also not possible. What to do to
recover?


Debian saves your old kernels upon an upgrade. In the GRUB bootloader
menu, select "Advanced options for Debian GNU/Linux". Then, select
the kernel version that you want. If this works, the problem is with
the new kernel. If it doesn't, it is probably something to do with the
GUI. Try doing this and let us know what happens.



Thanks. Well I do not have GRUB here but LILO, and there are no saved 
old kernels as long as I know. However, I managed to access the file 
system by using rescue CD, and noticed that the older kernel images were 
archived in /var/cache/apt/archives as .deb packages. For example, there 
are few 3.2.68-1+deb7u4 images & headers (that worked perfectly), 
however apt-get install still wants to use "newest" version 3.2.71-2 
(that produced the problem). Is it possible to force it to install the 
older version from the .deb files? Or, how to install from .deb files in 
rescue CLI?

Machine freezes after kernel update

[Miroslav Skoric]

Hi,

After the last kernel update and restart, a wheezy-based machine (laptop 
running 7.9) boots to some point, however it freezes just before opening 
GUI. Access to CLI (Ctrl-Alt-F1 etc) is also not possible. What to do to 
recover?


Regards,

M.

Re: Image cloning software

[Miroslav Skoric]

On 12/09/2014 11:11 PM, Andrei POPESCU wrote:



You should probably provide more details about the installation to be
cloned and hardware where the clone will be used.

Kind regards,
Andrei



Here it is:

'Source 1' hardware: Desktop CPU Celeron 400 MHz, RAM 224 MB, HDD 21 GB 
(a half of a 41 GB ATA Maxtor)
'Source 1' OS: Debian 6.0.10 (Gnome, KDE, LXDE, Xfce), LILO dual-boot 
with Windows XP


'Source 2' hardware: Compaq Presario CQ56 CPU Pentium Dual-Core T4500 
2.30 GHz, RAM 1.37 GB, HDD 320 GB (encrypted LVM)

'Source 2' OS: only Debian 7.7 (Gnome, KDE, LXDE, Xfce), LILO

'Target' hardware: Desktop CPU AMD Athlon 1.1 GHz, RAM 512 MB, HDD 41 GB 
(a half of a 82 GB ATA Maxtor)

'Target' OS: LILO for dual-boot with Windows XP

Regards,

M.


--
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/548f6e1d.8050...@eunet.rs

Re: Image cloning software

[Miroslav Skoric]

Is there a good software for Debian 7.7 as well as for Debian 6.10
that is capable to produce a multi DVD/CD image of a working system,
in a way that such image can be used later as a DVD/CD installation
media for 'cloning' on the other comps (or on itself, in case of an
irreparable failure of a working machine)? Thanks.


You may want to look at the bootcd package - looks like it will do
what you ask... Or at least similar enough to get you most of the way
there.



Hi,

Thanks to all who provided suggestions.

Btw, when I mentioned 'cloning' an image on the other machines, I meant 
including those with different hardware (CPU, GPU, HDD  RAM size). 
Would it be possible?


M.


--
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/54874812.4030...@eunet.rs

Image cloning software

[Miroslav Skoric]

Is there a good software for Debian 7.7 as well as for Debian 6.10 that 
is capable to produce a multi DVD/CD image of a working system, in a way 
that such image can be used later as a DVD/CD installation media for 
'cloning' on the other comps (or on itself, in case of an irreparable 
failure of a working machine)? Thanks.


M.


--
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/547a04d4.2000...@eunet.rs

Re: Resizing LVM issue

[Miroslav Skoric]

On 06/22/2014 03:29 PM, Pascal Hambourg wrote:


Miroslav Skoric a écrit :


1. What would you do if you need more space in /tmp and you know you
have some spare space in /home or else, but do not want to reinstall?


If you are in such a situation, then you missed one of the goals of LVM.
You should not have allocated all the space in the VG but instead should
have left some free space for further growing or creating LVs when the
need arises.



Let's try once again: I have not allocated anything at the time of 
installation. The only thing I've done was to accept Debian installer's 
suggestion to make the OS installation by using the whole hard disk and 
make the LVM. (In the other words, I let the installer to calculate 
particular partitions.) I see now some of you telling it should not be 
done that way, but would not be better to blame the programmers who had 
made such a 'bad option' within the installer?


Secondly, either the installer and/or some online manuals had suggested 
that the main purpose of LVM was to allow additional reallocating space 
within the OS's partitions, later if and when needed, from within an 
already working system. If that's not the case, I'd suggest the 
programmer community to invent a better solution.


Anyway, as I said earlier, I managed to restore the space to the 
original status, then I reallocated things in the proper order. So, in a 
couple of days it will be a month since I fixed my wrong attempt to 
reallocate the space, and the machine is not complaining ever since :0




--
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/53b030f...@eunet.rs

Linux replacement for Sony PMB?

[Miroslav Skoric]

Is there a good replacement for Sony's PMB software? I mean, something 
that can import both photos and videos from a camera, and store  play 
them in the order of date/time of recording.


M.


--
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/53b076e4.5010...@eunet.rs

Installation disc creator (Was: Resizing LVM issue)

[Miroslav Skoric]

On 06/15/2014 10:52 PM, Reco wrote:



No, it seems to belong to main archive.

$ apt-cache search apt on cd | grep ^apt
apt - commandline package manager
aptdaemon - transaction based package management service
aptoncd - Installation disc creator for packages downloaded via APT



Yep, aptoncd was the one that asked for more space in /tmp. Not anymore 
after resizing. I use that app mostly for updating the other machine 
that does not have broadband access (dial-up is there but too slow for 
updating). Btw, what app is good for making an image of the system, sort 
of full backup, and is it possible to use such an image to clone more 
than one comp later, i.e. to avoid installations from scratch? (I have 
two Debian machines here and another one with Ubuntu, and maybe would go 
moving that Ubuntu to Debian but don't like reinstalling all over again...)


M.


--
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/53a6c0f6.3030...@eunet.rs

Re: Resizing LVM issue

[Miroslav Skoric]

On 06/05/2014 11:29 AM, Jochen Spieker wrote:


Miroslav Skoric:

On 06/01/2014 11:36 PM, Jochen Spieker wrote:



If you don't have a
backup you can try to resize the LV again to its original size and hope
for the best.


Thanks for suggestions. Yep, I managed to return back to the
original size at first. Then I resized it properly (incl. leaving
few gigs as unused space). e2fsck did spent a while to recheck each
partition but seems that everything is in order now. We'll see in
days to come ...


Nice! It is still possible that some of your data was overwritten but if
the fsck didn't find anything troubling you are probably safe now.

Next todo: implement a useful backup strategy. :)

J.



Just to let you know that after some ten days after 2nd resizing 
everything is still in order (no complaints from fsck or else). From the 
lesson learned: The proper order of commands should be carefully 
performed; In that case, resizing the LVM is a good option until the 
installation process improves itself in a way it automatically format 
new partitions to be better balanced. (I mean, if I remember properly, 
during the initial system installation some years ago ... it was 6.0.1a 
that I upgraded to 7.5 since ... it offered to setup the LVM partitions 
automatically. So I accepted its recommendation.) But recently I 
realized that I needed more space in /tmp and found that I had more than 
enough free space in /home ... that was the reason for resizing.


(Btw, the app apt-on-CD recently started to ask for more space in /tmp. 
After resizing, that app seems to be happy :-)


M.


--
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/539cc5ec.30...@eunet.rs

Re: Resizing LVM issue

[Miroslav Skoric]

On 06/05/2014 11:04 AM, Bob Proulx wrote:


Richard Hector wrote:

I prefer not to get in the situation where I have to shrink a filesystem
though - xfs doesn't support it anyway.


Agreed.  Even better is to avoid it.  Small ext{3,4} file systems
shrink acceptably well.  But larger ext{3,4} file systems can take a
very long time to shrink.  I once made the mistake of trying to shrink
a 600G filesystem.  The operation was eventually successful.  But it
took 10 days to complete!  And once I started it there was no other
option than to let it complete.



Two questions:

1. What would you do if you need more space in /tmp and you know you 
have some spare space in /home or else, but do not want to reinstall?


2. Wouldn't be nice if resizing routines/commands/programs/... show 
calculated time they would need for such an operation, so a user could 
decide whether to continue or cancel?


M.


--
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/539cc14a.3010...@eunet.rs

Re: Resizing LVM issue

[Miroslav Skoric]

On 06/05/2014 08:42 AM, Richard Hector wrote:




If I have to shrink a filesystem, I tend to shrink it to something
smaller than my eventual goal, then shrink the LV to the goal, then
resize2fs again without specifying the size, so it grows to fit.

I prefer not to get in the situation where I have to shrink a filesystem
though - xfs doesn't support it anyway.

Richard




Thanks for suggestions. Well I would not shrink the filesystem (actually 
a part of it) if I did not need more space on /tmp (as a part of the 
LVM). Anyway, after this experience, may I suggest to LVM programmers to 
think about some software routines that would enable users to recompose 
(resize, shrink, whatever ...) their LVM from within a mounted system, 
in a way that after the next reboot, the LVM and FS automatically 
recomposes itself - so to avoid common mistakes.


M.


--
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/539cbfa4.7060...@eunet.rs

Re: Resizing LVM issue

[Miroslav Skoric]

On 06/01/2014 11:03 PM, emmanuel segura wrote:



i think the correct steps are:

resize2fs /dev/mapper/localhost-home -2G
lvresize --size -2G /dev/mapper/localhost-home




Thank you. I tried with the first command but it did not work (it 
returned an error).


However later I managed to resize the system to its original state, and 
from there to make resizing properly.


M.


--
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/538f9af6.4070...@eunet.rs

Re: Resizing LVM issue

[Miroslav Skoric]

On 06/01/2014 11:36 PM, Jochen Spieker wrote:



If you don't have a
backup you can try to resize the LV again to its original size and hope
for the best.

BTW, I found it to be good practice to initially use less than 100% of
available space on my PVs for the LVs. That way I can grow filesystems
that are too small easily when I need that space.



Thanks for suggestions. Yep, I managed to return back to the original 
size at first. Then I resized it properly (incl. leaving few gigs as 
unused space). e2fsck did spent a while to recheck each partition but 
seems that everything is in order now. We'll see in days to come ...


M.


--
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/538f9b0f.4020...@eunet.rs

Resizing LVM issue

[Miroslav Skoric]

Hi,

I have encrypted LVM on one of my Wheezy machines, and recently noticed 
that /tmp space was too low for one application (In fact it was about 
350 MB and I wanted it to be around 2.5 GB). So I tried to make /tmp 
space bigger while I was mounted and online, but vgdisplay reported no 
free space for that action (something like that):


sys@localhost:~$ sudo vgdisplay
  --- Volume group ---
  VG Name   localhost
  System ID
  Formatlvm2
  Metadata Areas1
  Metadata Sequence No  9
  VG Access read/write
  VG Status resizable
  MAX LV0
  Cur LV6
  Open LV   6
  Max PV0
  Cur PV1
  Act PV1
  VG Size   297.85 GiB
  PE Size   4.00 MiB
  Total PE  76249
  Alloc PE / Size   76249 / 297.85 GiB
  Free  PE / Size   0 / 0
  VG UUID   fbCaw1-u3SN-2HCy-

Then I decided to shrink /home for some 2 gig and to add to /tmp :

sys@localhost:~$ sudo lvresize --size -2G /dev/mapper/localhost-home
sys@localhost:~$ sudo lvresize --size +2G /dev/mapper/localhost-tmp

According to df, it did so:

sys@localhost:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs329233   219069 93166  71% /
udev   102400 10240   0% /dev
tmpfs 304560  756303804   1% /run
/dev/mapper/localhost-root329233   219069 93166  71% /
tmpfs   51200  5120   0% /run/lock
tmpfs 609100   80609020   1% /run/shm
/dev/sda1 23319131650189100  15% /boot
/dev/mapper/localhost-home 289312040 11966292 262649508   5% /home
/dev/mapper/localhost-tmp240831511231   2273129   1% /tmp
/dev/mapper/localhost-usr8647944  5745732   2462916  70% /usr
/dev/mapper/localhost-var2882592   916600   1819560  34% /var
sys@localhost:~$

It seems that /dev/mapper/localhost-tmp was about 2.4 GB so I wanted to 
resize newly changed filesystems:


sys@localhost:~$ sudo resize2fs /dev/mapper/localhost-home
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mapper/localhost-home is mounted on /home; on-line 
resizing required

resize2fs: On-line shrinking not supported

Similar output was with e2fsck:

sys@localhost:~$ sudo e2fsck -p /dev/mapper/localhost-home
/dev/mapper/localhost-home is mounted.
e2fsck: Cannot continue, aborting.


sys@localhost:~$

Obviously I should not have done that while being mounted (or did not 
know the proper syntax), however it did not complain with resize2fs 
/dev/mapper/localhost-tmp


But after the next reboot, it stopped when tried to perform Checking 
file systems:


/dev/mapper/localhost-home: The filesystem size (according to the 
superblock) is 73481216 blocks

The physical size of the device is 72956928 blocks
Either the superblock or the partition table is likely to be corrupt!

/dev/mapper/localhost-home: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
 (i.e., without -a or -p options)

Anyway, the other segments of the filesystem were clean, so by CONTROL-D 
it was possible to terminate the shell, so to resume system boot.


My question is how to solve that inconsistency issue now? At first I 
tried with dumpe2fs in searching for backup superblocks, then with 
e2fsck -b one_of_those_backup_superblocks_from_the_list, but without 
resolution. I mean the inconsistency is not fixed. Probably I do not use 
e2fsck properly even when /home is not mounted. So the machine still 
keeps stopping during the boot at filesystem check, so I have to 
continue booting by pressing CONTROL-D.


Any suggestion?


--
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/538b8663.8050...@eunet.rs

Re: Long-term support for Squeeze

[Miroslav Skoric]

On 03/19/2014 01:42 AM, Scott Ferguson wrote:



After all, the clock keeps ticking and Debian squeeze is going to reach
its End of Life in less than two months otherwise.




Whatever happens, I'd keep 'Squeeze LTS' for at least a couple of years 
more, if for nothing else but for keeping the old hardware playing as a 
firewall/router for the rest of the home LAN. I checked the difference 
in between Squeeze and Wheezy HW requirements and it seems that Wheezy 
asks for some more RAM. And one of my old machines has only 224 MB of 
RAM with Celeron 400 MHz CPU. That old box runs 6.0.9 now and I am not 
sure if it would accept an upgrade to 7.0.4 - not to mention that its 
HDD also does not have too much free space ...


However, if Squeeze is going to be officially abandoned soon, I'd search 
for some alternatives ...



--
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/5341673b.3080...@eunet.rs

Upgrade from 6.0.7 to 7.0 issues

[Miroslav Skoric]

I upgraded the other day, and noticed some differences between my 
desktop appearance (Gnome) and what is described in the Help. According 
to Help, there should be some Activities menu or something like that in 
the upper left corner, but only I see is Applications and Places in that 
screen area. Any idea?



--
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/51ab89d8.3060...@eunet.rs

Re: How to configure two NIC's in Debian 6.0.4 box?

[Miroslav Skoric]

On 02/15/2012 07:25 PM, Christofer C. Bell wrote:

On Wed, Feb 15, 2012 at 11:57 AM, Miroslav Skoricsko...@eunet.rs  wrote:


I wonder what is the best way to reconfigure the NIC's so the old card (now
eth0) boots as eth1, and the new card (now eth1) boots as eth0?


This is done using the file /etc/udev/rules.d/70-persistent-net.rules

Just open that in your favorite editor and the format should be
self-explanatory.  Edit that file to taste and reboot.

Good luck!



Thanks, that worked!


--
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/4f3d8072.7060...@eunet.rs

How to configure two NIC's in Debian 6.0.4 box?

[Miroslav Skoric]

I have a dual-boot Win$/Debian box having two cards, an older one 3Com 
(3C905TX in Win$, 3c59x in Deb) and a newer one TP Link (TF-3200 in 
Win$, sundance in Deb). Both cards are wired to the other two machines 
in the LAN, the older card links to an older box, the newer card links 
to a newer box.


The issue is that the 'central' box sees the old NIC as eth0 and the new 
NIC as eth1, though I would like it to be the opposite. Besides that, it 
seems that the cards get renamed during the system boot, as follows:


renamed network interface eth1 to eth1-eth0
renamed network interface eth0 to eth1
renamed network interface eth1-eth0 to eth0

The only stuff within /etc/network/interfaces is:

auto lo
iface lo inet loopback

and the working parameters for both cards are set by Network Manager 
Applet 0.8.1


I wonder what is the best way to reconfigure the NIC's so the old card 
(now eth0) boots as eth1, and the new card (now eth1) boots as eth0?



--
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/4f3bf208.5030...@eunet.rs