Two or three times recently--as recent as this afternoon--a whole batch
of apps, the icons
of which live in the panel, or systray, have piled up at the left-hand
side. They don't overlap,
but they are all to directly the right of the normal (what I consider
normal) icons, which are the
smiling ball, desktop1, system settings, YaST, Konsole terminal, and
Kate. All the other
icons --15, plus the time/date, have moved to the left. What is causing
this, and how can
I make it stop? (I have moved them back a couple of times, but they no
longer stay put.)
System is OS-TW, up to date as per 1114. (I think it also occurred
before this update.)
Thanx for any insight--doug
Is there anyone here who has successfully compiled regard2d? As stated
on the project site, ",It converts photos of an object, taken from
different angles, into a 3D model of this object."
The main site is at https://www.regard3d.org/index.php. There is no
Linux binary available, let alone an rpm-package for OpenSuse.
There is a link to instructions for compiling it on Linux, and,
following that, I tried to compile the first part (OpenMVG), but it
MainWindow.cc:(.text+0x30d1): undefined reference to
From there I'm to less a programmer as to know how to proceed.
Anyone who has compiled this, or wants to guide me in how to make this a
Any help appreciated!
when running YaST Online Update warns today (not two days ago) that
support has finished, with a popup.
This is not true, end of life has been signalled for "January 31st 2021"
Cheers / Saludos,
Carlos E. R.
(from 15.1 x86_64 at Telcontar)
No sound at all from smplayer, system, Firefox, SeaMonkey. This is on my primary
system. Volume control acts as though I'm getting unmuted sound. Switching speaker
cable and speakers didn't help.
# inxi -SyI
Host: 00srv Kernel: 4.12.14-lp151.28.79-default x86_64 bits: 64
Desktop: KDE 3 Distro: openSUSE Leap 15.1
Info:...Shell: Bash inxi: 3.1.09
# inxi -Aay
Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio
vendor: Micro-Star MSI driver: snd_hda_intel v: kernel bus ID: 00:03.0
chip ID: 8086:0c0c
Device-2: Intel 8 Series/C220 Series High Definition Audio
vendor: Micro-Star MSI driver: snd_hda_intel v: kernel bus ID: 00:1b.0
chip ID: 8086:8c20
Sound Server: ALSA v: k4.12.14-lp151.28.79-default
http://fm.no-ip.com/Tmp/SUSE/Leap/alsa-info-msi85-s151a.txt July 2019 (working)
http://fm.no-ip.com/Tmp/SUSE/Leap/alsa-info-msi85-s151b.txt current :(
Where to start to fix?
Evolution as taught in public schools, like religion,
is based on faith, not on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
OK I know there were changes to opensuse passwords so when I
tries to log into opensuse main my email address wasn't recognized, so
when I tried to login to the mailing lists I was able to change my password,
however I got this: Login to profile is not availble for employees yet.
Well I am not an employee, at least I don't think so. So how do I log
onto mailing lists. I want to cancel the opensuse-factory list. Thanks....
X-Operating-System: Linux 4.4.104-18.44-default x86_64 openSUSE 42.2
User-Agent: mutt 1.10.1
Organization: Ptilopteri in Pandemonium
now displaying 12pt and the profile settings changed from 10pt to 12pt.
changed the profile settings and all is again normal. had to do the same
or something else changed the display and I didn't catch it but the change
I made brought the display back to what I expect to see.
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
within this e-mail I would like to inquire, if the following package for
openSUSE Leap 15.2 ff can be made available:
I could not find an official package available for openSUSE Leap 15.2.
Only the version libQt5Core5_ 5.12.7 is available under:
Mit freundlichen Grüßen / Kind regards
Be Free, Be Linux
I have a 2 GB disc mounted as /var/lib/libvirt/images.
I have images of installation on it. In order to have higher redundancy in
case of HDD failure (had one recently on root but on root there is not so much
So I took a second one, same size to set up a RAID1
Normally you would need three discs (set up the raid and then transfer from a
However I did this one in the past with success (only I forgot how and the
opensuse 15.2 killed all my maildata so I cannot find it in the archives (BTW
opensuse archives seem to be down too).
So I want to create a RAID called md/1 and use it as RAID setting it up with
one "missing". dev/sdd is the one with the data. /dev/sdf is the virgin new.
I began with:
dd if=/dev/sdd of=/dev/sdf count=1
Command (m for help): t
Partition number (1-3): 1
Hex code (type L to list codes): fd
Changed system type of partition 1 to fd (Linux raid autodetect)
so far so good. And it works up to here.
And I initialize the RAID:
mdadm -C /dev/md/1 -l 1 -n 2 missing /dev/sdf1
And so far so good, all is smooth.
Now I wish to give it a file system (in my case ext4) and there...the trouble
begin. I do not remember obviously how to do this right. I tried:
Which he does but complains:
mke2fs 1.45.6 (20-Mar-2020)
/dev/md/1 alignment is offset by 3584 bytes.
this may result in very poor performance, (re)-partitioning suggested.
Filesystem UUID: 9d21cc50-7c0c-49a2-....etc
Superblock bacups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654200,
496000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000,
Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done
So what do I wrong when creating the ext4? I suppose the command is wrong and
needs some more parameter or I have to change the tool all along.
Any suggestion why I am up for this "alignment offset by 3584 bytes"?
Thanks in advance.
Once created the files system, you unmount the old disk, mount the new raid in
a temp name as well as the data disc, copy from there to the Raid. Unmount
both and mount the Raid at the old location and restart the system. Once
restarted you can then manage the old data disc (after checking that the
transferred data is complete). All this I have done it before, but I really do
not recall how I did overcome the "alligment offset".
So I've got myself a bunch of NVME adapters and drives and plopped them
into my Haswell systems to make some good use of the empty PEG slot.
All of them don't have NVMe support in the BIOS and also do not offer
PCIe bifurcation so it'll probably be a single NVMe running in PCIe-x4
mode forever. If it's somehow possible to enable bifurcation without
proper BIOS support I'd like to know. I believe the PCIe bus goes
directly to the slot without any switches that might need to be
controlled on the one computer that I might want to put another NVMe in
(a Dell T20). The drives were recognized immediately as /dev/nvme0n1
and I've already installed nvme-cli and ran mkinitrd so the boot system
will have it also (even though it'll probably not need it).
The first system was plain partitions and I've wanted to convert to LVM,
so I created a new VG on the naked device (see my question about that
further down) and set up new volumes for swap, sysroot and home. Then I
moved home with xfscopy, re-created and switched the swap and lastly ran
btrfs replace to move it from the partition to the LVM, then edited
fstab and ran mkinitrd. It was only then that I realized that /boot was
not in fact on the EFI system partition, but a subvolume of the sysroot
btrfs. OK, the grub entries looked halfway sensible so I decided to see
what would happen, rebooted and of course it didn't find the boot
partition because Grub doesn't see anything the BIOS doesn't see. So I
booted into a rescue system, moved the btrfs back to where it was before
mount /dev/sda3 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /var /mnt/var
I don't really want or need to do that again, but it was less painful
than I remember it from years before… but the question remains if
there's an easy way to get the part that is needed to get NVMe and the
LVM on it recognized spliced out onto the SATA (which I would like to
replace with some older / smaller one later) but keep the rest of
sysroot on NVMe. As far as I understand Clover mod it can only boot
NVMe disks with a GPT and maybe only Windows, but I've yet to dig
deeper. But I gather that there might be a way to provide EFI with some
sort of driver or chain loader that sets up the NVMe recognition and
Grub could take over from there?
The other system (the T20) is already LVM based, which I want to
leverage for the move from the SATA to the NVMe drive. I've looked
around a bit and there are multiple ways of doing that and I'd like to
know if one is clearly preferrable over the other(s).
The first part concerns the creation of the new physical volume. All
the howtos I've read so far talk about partitioning the disk and then
using one of the partitions to create the volume. I think that isn't
necessary and I could use the whole device (unpartitioned) when I can't
boot from the disk and the partition would use the full space available
anyway. My experience with the second system indicate that this should
work OK, but maybe there is a disadvantage of doing that I don't know
The second part concerns the actual move of the logical volumes to the
new drive once it's been added to the volume group, I want at least the
swap and the home LV to reside there, but leave the root VG on the SATA
SSD (as long as I haven't figured out on the other system how to get the
boot system separated out). The emptied space will get used for backups
and less frequently used data, in a new LV. The LV move could be
effected by pvmove, but I've found several howtos for doing it via
setting up a mirror spanning the two devices and then breaking the
mirror and leaving only the new device in the LV. One was alluding to
that being somehow "better" or even "safer" than using pvmove. What are
the actual downsides of using pvmove? The NVME is larger than the SATA,
so I can make backup copies in the extra space (and on externalö disk)
before the "hot" move.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1: