Please guide me again
sorry, no x-mas present to offer
I'm also only able to search the inet for a solution...
Please guide me again
sorry, no x-mas present to offer
I'm also only able to search the inet for a solution...
I'm not sure what BD-ROM needs
=> "Filesystem"
Universal Disk Format - Wikipedia
=> "Compatibility" => "Linux kernel 2.6.26 and newer"
so it should read that disk ...
2021-12-22 20:44:40.188 T:2992628544 INFO: CD-ROM with unknown filesystem
according to this:
one {s,c}ould identify the Type with command "blkid"
P.S. LE machine is an Intel NUC NUC8i3BEK, 16GB RAM, Samsung SSD NvME 512GB
OT, but out of interest (thinking about to screw a Samsung EVO Plus in that NUC)
how hot does the NVMe get in that NUC ?
on a comand line "sensors" should tell and should be something like this (this is from an 980 Pro with heat cooler in an Desktop):
...
nvme-pci-0100
Adapter: PCI adapter
Composite: +30.9°C (low = -273.1°C, high = +81.8°C)
(crit = +84.8°C)
Sensor 1: +30.9°C (low = -273.1°C, high = +65261.8°C)
Sensor 2: +34.9°C (low = -273.1°C, high = +65261.8°C)
...
maybe the install of "System Tools" is needed to get "sensors" (lm_sensors)
I am thinking that this means what Joe Average was talking about above?? That the HD has some bad areas??
Bad areas or Bad Blocks are damaged area's on a disk.
Superblock are ~sorta~ additional copies of partition table/filesystem info's
a partition table is created when you create a partition on the disk
Superblocks are created when you create the ext4 filesystem
e2fsck or fsck.ext4 checks Superblocks too
if e2fsck cries regarding Superblocks something is up with your filesystem
in general:
a disk should always be unmounted when you
- create a partition [1]
- create a filesystem
- fsck the filesystem (though, a readonly switch for mounted FS is available)
[1]
afterwards the linux kernel isn't aware of the new created partition
either a reboot or partprobe (thanks @frakkin64) should do the re-reading
you could always feed google with the commands you aren't clear about e.g.
man parted
I always thought it meant Keep It Simple, Stupid...
Klojum you're talking scrap !
Then the fsck.ext4 gave me this..
fsck.ext4 or e2fsck shouldn't run on an mounted partition
fsck.ext4(8): check ext2/ext3/ext4 file system - Linux man page
Chap. "Description",
2cd Paragraph:
cit.: "Note that in general it is not safe to run e2fsck on mounted filesystems. ..."
yup, in an initial draft comment I had SysRescueCD (~800 MB) with GParted, Graphical File manager to format, FS-check, copy, ... in my mind...
I scratched that, cause live cd use some RAM and how could it influence long time copy/move of big data...
My intention was to provide a working solution without unthought surprises
I'm not sure if a graphical IF for smartmontools is available; couldn't find something on the GParted page
fsck != smartctl
coping data on bad disk causes bad data !
and a MC is available too,
all on board just some minor "command line gobbledeegook"
redhat (RHCE) taught me "do the simplest thing first" and KISS (keep it small and simple)
could you check if wsdd2 is running:
systemctl status wsdd2.service
it should read:
Active: active (running) since ...
else
systemctl enable wsdd2.service
and
systemctl restart wsdd2.service
the test didn't finished:
rebooted or suspended ?
at the end:
# 1 Short offline Interrupted (host reset)
AFAIK, some disks survive a reboot and the test continues, but ...
anyway, to me the disk seems good.
check the others too
hint:
you could run the tests at any time, even when the disk is filled with data.
this test was only to make sure to not copy/move data to a bad disk
nothings to thanks for.
just help another user the next time...
=> b-o-o-s-t community
wait, wait ,my fault
you need to install the addon "System Tools" first !
you should check the disks with smartctl:
- adjust X with the correct drive letter -
smartctl -t short /dev/sdX
then
smartctl -a /dev/sdX
to see if the HD is fit, see:https://en.wikipedia.org/wiki/S.M.A.R.T.
watch out for the "critical" disk attributes
"bad sector" is a indicator to better throw away the disk ...
===
regarding "clean disk":
be aware:
secure erase "irons" all data on the disk !!!
could you tell what your "kodi box" is ?
e.g. is it a ~PC~ where you could connect at least 2 HD ?
is there more to read about what is exactly broken ?
a pointer to the info ?
in another thread I'm trying to help another user regarding smb shares, maybe your info might shorten my work ...
to be honest: the last log files your provided (to me) have less worth to nail the bug, cause incomplete
from the 1. : "daemon 'smbd' finished starting up and ready to serve connections" => all seems okay [1]
from the 2.: something regarding Mesa => nothing to do with interrupted connections
from the 2.: ... r8169 0000:03:00.0: invalid short VPD tag 00 at offset 1
for the last one regarding r8169 (your LAN driver) I could find bug reports, but all aged, some years back and without solution.
search string was "invalid short VPD tag"
problems with LAN driver would support my theory it's network and not samba...
therefore complete log files are needed !
regarding incomplete logs
=======================
to me it seems you didn't configured journald keeping the logs files (against @mglae's advise)
didn't you ?
maybe I'm wrong, but => "- Journal begins at Tue 2021-12-14 14:17:02 CET. --"
when the logging begins after the error occured (you said: "I had the problem again a few days ago... versus "Journal begins at Tue 2021-12-14") then you can't find something about the error in that log's !
is clear ?
in general:
- either you configure the box to keep the log's over reboots/shutdowns
Addon => LibreElec Configuration => System => Logging => "Use Persistent Logs"
OR
- you keep the box (the samba server) running until the error occurs
for the first case you should notice the date/time on a piece of paper when you mention the error on/with your second box for easier searching afterwards.
are you able to ssh into the samba server then (right now after you mentioned the error) ?
===
anyway, I compared the output of your testparm with a default (unchanged) from my nightly.
I further need to mention:
my samba isn't active.
means it could be that some default entries changes during activation and I guess that is case for "username map"
the diffs. are (first: my, second: yours):
1.
map to guest = Bad User versus
map to guest = Never
2.
min domain uid = 1000 versus
no entry in yours
3.
server min protocol = SMB2_02 versus
server min protocol = SMB2
4.
username map = versus
username map = /run/samba/samba.map
hint: "username map =" is in my testparm empty
other diffs.: I have in all shares [Update], [Video], ... additional this: guest ok = Yes
hint: samba set some defaults, seeable via testparm, even if they're not explicit configured in smb.conf.
"guest ok" could be one of them [2]
I have no idea why all above diffs. exists, but for a test case your could put my entry (exclusive: "username map" !) in your smb.conf esp.
"server min protocol".
backup your current smb.conf before !!!
your need to restart samba afterwards, usually with "systemctl restart smb" or a reboot of the box will do too
(easily forgetable): your need restart samba everytime after you changed the smb.conf
[1]
in ~20 years I've never seen that a samba server shares sometimes and sometimes not. [3]
either it didn't start or it starts without to be able to make connections to it
in short: to me it seems your problem is not samba
[2]
I guess one could configure a complete empty [global]- section in smb.conf and all defaults are sharp.
[3]
but I've seen this with file sharing between two M$ boxes (~ win XP <=> Win 9x)
a by M$ known bug with attribut: Won't fix !
digging the inet with "drivers/gpu/drm/i915/display/intel_dp.c:1918 intel_dp_max_link_rate+0x79/0x90"
cause mostly one is not the only one on earth with a bug...
and found some similar bug reports with black screens and such
but all from 2014 or 2017, so they should be fixed and/or maybe they are not for all cases ...
some thoughts:
to me (I'm no developer) it seems the GPU driver crashes during negotiation about data rate and such and maybe reveals a up to now hidden bug which should be fixed (for ever)
1. question:
while we can't adjust TV output on the Brix via bios is there maybe a setting in the TV to (temporary) ~lower/limit~ the input ?
2. Q.:
you said you could install LE only with another monitor
why not setup a LE release with that (good) monitor, update to nightly and connect the Brix to the problematic TV and see what happens ?
maybe with a look into dmesg before and after OR the upload of both
and surely with the parameter mglae suggested in comment #9
advantage: a newer kernel (5.15.y) and therefore a newer GPU driver (where the bug is maybe already fixed ?!)
I guess the i915 driver developer is interessed in "why the driver i915 crashes (only ?) on the problematic TV ..."
maybe we get some useful input together ...
3. Q.:
the Samsung TV seems to be really new
if correct:
- does a samsung forum regarding that TV exists and is there some useful info's available (=> maybe another user and same bug) ?
- maybe a newer TV firmware in the pipe ?
@ALL
comments/thoughts/rotten fruits ?
you know to how to get a nightly installed while no usb creator is available ?
- will tell if not -
I think that's it.
to me the above translates to "das war's im Sinne "es ist fertig/erledigt" so I guess you meant "I think that it is" (...ist es doch)
und das grin-smiley wirkt abstossend (war das so gemeint ?)
Urrrgghhh, my fault: mixed date from bios flash util and bios itself
sorry !
NO !
...
Dec 09 22:00:41.168661 LibreELEC kernel: Hardware name: GIGABYTE GB-BRi5(H)-8250/MFLP5IP-00, BIOS F5 02/25/2019
...