Hi,
for the reference, the issue is solved by this config below.
Ales
---
cat /etc/network/interfaces
auto lo
iface lo inet loopback
#auto ens3f0
#iface ens3f0 inet manual
#auto ens3f1
#iface ens3f1 inet manual
allow-hotplug ens3f0
iface ens3f0 inet manual
Thanks for your replay, Reco.
Yes, in Stretch networking works well both - with and/or without directive
"auto".
In contrast Buster with:
auto bond0.20
iface bond0.20 inet manual
auto bond0.21
iface bond0.21 inet manual
gateway is unreachable by ping.
So I don't know why yet.
Ales
Hi.
On Thu, Jun 03, 2021 at 03:28:47PM +0200, deb...@centrum.cz wrote:
It's just a guess, but you have "auto" for "bond0":
> auto bond0
> iface bond0 inet manual
But what you do not have is "auto" for VLAN interfaces you build on top
of bond0:
> iface bond0.20 inet manual
> iface
Hello,
in Stretch I have done this by Debian way with /etc/network/interfaces an it
goes well.
The same configuration in Buster is interpreted differently and doesn't work.
Config from interfaces:
auto lo
iface lo inet loopback
allow-hotplug ens3f0
iface
I upgraded on 25th May office computer Debian Stretch to Buster. Home
directory comes from NFS server. Chromium browser now longer has the stored
passwords available.
Other browsers, Firefox and Google Chrome, do have the passwords still.
Where did chromium browser on Stretch store the passwords
On Fri Sep 4 12:07:23 2020 Greg Wooledge wrote:
> On Fri, Sep 04, 2020 at 11:09:45AM -0700, cgi...@surfnaked.ca
wrote:
>
>> OpenSSL version mismatch. Built against 1010104f, you have
1010006f
>
>> # find . -print | grep -i ssh [output abridged]
>>
On Fri, Sep 04, 2020 at 11:09:45AM -0700, cgi...@surfnaked.ca wrote:
> OpenSSL version mismatch. Built against 1010104f, you have 1010006f
> # find . -print | grep -i ssh [output abridged]
> /etc/X11/Xsession.d/90x11-comon_ssh-agent
> /etc/xdg/autostart/gnome-keyring-ssh.desktop
>
On Fri Sep 4 08:56:44 2020 Mike Kupfer
wrote:
> cgi...@surfnaked.ca wrote:
>
>> I'll continue puttering for a few more days - maybe others will
have
>> some ideas.
>
> So were there any errors or warnings in /var/log/Xorg.0.log?
Nothing there.
> I'd also check for error messages in
cgi...@surfnaked.ca wrote:
> I'll continue puttering for a few more days - maybe others will have
> some ideas.
So were there any errors or warnings in /var/log/Xorg.0.log?
I'd also check for error messages in $HOME/.xsession-errors.
regards,
mike
On Mi, 02 sep 20, 11:13:30, cgi...@surfnaked.ca wrote:
>
> I found instructions on the web for upgrading Stretch to Buster,
Do you mean these?
https://www.debian.org/releases/buster/releasenotes
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc
Descriptio
On Wed Sep 2 21:32:55 2020 Andy Smith wrote:
> On Wed, Sep 02, 2020 at 11:13:30AM -0700, cgi...@surfnaked.ca
wrote:
>
>> The Buster upgrade seemed to work OK. I re-booted and got to my
>> xfce login screen. But when I entered my user ID and password,
>> the screen blanked for a second or
Hello,
On Wed, Sep 02, 2020 at 11:13:30AM -0700, cgi...@surfnaked.ca wrote:
> The Buster upgrade seemed to work OK. I re-booted and got to my
> xfce login screen. But when I entered my user ID and password,
> the screen blanked for a second or so, then came back to a blank
> login screen.
Use
The scariest part of any system upgrade is that first re-boot.
Up until then, you're still running - but after that re-boot,
maybe the machine will come up, and maybe it won't.
Mine won't, and now I have to figure out how to fix it.
I found instructions on the web for upgrading Stretch
This is an Acer netbook, a year or two old, no legacy BIOS, bought with
Win10 installed. It has a hardwired SSD designated mmcblk0 and I
installed another SSD which is /dev/sda. Stretch installed with no
problem, and gives me a Windows entry in its menu. It's been OK for
about 18 months, so I
i have a device that runs stretch armel
if i change my repos to buster
i do apt clean all, apt update, apt install systemd
when systemd installs it fails to start and i get a series of timeouts
when i reboot i get
Begin: Running /scripts/init-bottom ... Begin: Stopping dropbear ... done.
[
Isaac N composed on 2020-04-05 22:29 (UTC+0300):
> After upgrading to debian buster i cannot access gui. I boot up and it
> stops services like UiD1000 then stops at "started update utmp about system
> runlevel changes".
> I can log on using tty to terminal; startX terminates with
>
After upgrading to debian buster i cannot access gui. I boot up and it
stops services like UiD1000 then stops at "started update utmp about system
runlevel changes".
I can log on using tty to terminal; startX terminates with
"xinit:connection to X server lost"
Starting a GUI application like
On Wed 15 Jan 2020 at 08:08:30 -0800, Alan Savage wrote:
> I am trying to upgrade from stretch to buster using the nonfree
> installation DVD ISO "firmware-10.2.0-amd64-DVD-1.iso" that I downloaded
> using the torrent here:
> https://cdimage.debian.org/cdimage/unofficial
I am trying to upgrade from stretch to buster using the nonfree
installation DVD ISO "firmware-10.2.0-amd64-DVD-1.iso" that I downloaded
using the torrent here:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.2.0+nonfree/amd64/bt-dvd/
I copied the ISO to
Bonjour,
Le lundi 18 novembre 2019, 13:26:15 CET ajh-valmer a écrit :
> On Monday 18 November 2019 Maxime wrote:
> > Il vous indique un paquet legacy car vous avez du vieux matériel
> > graphique.
> > Ce paquet nvidia-legacy provient tout de même de non-free car il n'est pas
> > libre, il inclut
On Monday 18 November 2019 Maxime wrote:
> Il vous indique un paquet legacy car vous avez du vieux matériel graphique.
> Ce paquet nvidia-legacy provient tout de même de non-free car il n'est pas
> libre, il inclut le module noyau DRM exploité par DKMS + le pilote graphique
> exploité par xorg.
Bonjour.
Il vous indique un paquet legacy car vous avez du vieux matériel graphique.
Ce paquet nvidia-legacy provient tout de même de non-free car il n'est pas
libre, il inclut le module noyau DRM exploité par DKMS + le pilote graphique
exploité par xorg.
Dans Buster le pilote xorg "nouveau"
Le vendredi 15 novembre 2019 12:10:03 UTC+1, Jérémy Prego a écrit :
> Le 15/11/2019 à 12:00, ajh-valmer a écrit :
[...]
> > Je ne vois pas de pilote nvidia "nouveau",
> > mais "xserver-xorg-video-nouveau".
>
> > tout simplement parce que le pilote nouveau est intégré au noyau. il n'y a
> > rien
Le 15/11/2019 à 12:00, ajh-valmer a écrit :
> On Friday 15 November 2019 10:37:11 didier.gau...@gmail.com wrote:
>> Le jeudi 14 novembre 2019 18:10:03 UTC+1, ajh-valmer a écrit :
>>> J'ai choisi le driver nvidia free (nvidia-legacy-340xx-driver).
>> Le pilote libre c'est Nouveau, le pilote que
On Friday 15 November 2019 10:37:11 didier.gau...@gmail.com wrote:
> Le jeudi 14 novembre 2019 18:10:03 UTC+1, ajh-valmer a écrit :
> > J'ai choisi le driver nvidia free (nvidia-legacy-340xx-driver).
> Le pilote libre c'est Nouveau, le pilote que tu indiques est la
> version ancienne (legacy) du
Bonjour
Le jeu. 14 nov. 2019 à 18:04, ajh-valmer a écrit :
> On Thursday 14 November 2019 12:08:51 Daniel Caillibaud wrote:
> > Regarde si ta carte est listée...
> > Peut-être que nvidia-legacy-340xx-driver ou nvidia-legacy-390xx-driver
> > suffirait, je laisse d'autres le confirmer.
>
> Merci à
Le jeudi 14 novembre 2019 18:10:03 UTC+1, ajh-valmer a écrit :
[...]
> J'ai choisi le driver nvidia free (nvidia-legacy-340xx-driver).
[...]
Le pilote libre c'est Nouveau, le pilote que tu indiques est la version
ancienne (legacy) du pilote propriétaire Nvidia
On Thursday 14 November 2019 12:08:51 Daniel Caillibaud wrote:
> Regarde si ta carte est listée...
> Peut-être que nvidia-legacy-340xx-driver ou nvidia-legacy-390xx-driver
> suffirait, je laisse d'autres le confirmer.
Merci à tous ceux qui m'ont aidé.
J'ai purgé complètement (reset)
Le 14/11/19 à 11h38, "ajh-valmer" a écrit :
> mais c'est un paquet 64 bits,
> et ma buster est en 32 bits.
> Elle n'apparait pas via "apt-cache search nvidia-detect"
> malgré que mon sources.list est bien configuré avec "non free".
> À moins qu'elle fonctionnera quand même ?
Non,
On Tuesday 12 November 2019 19:45:49 lann wrote:
> > Je lis : apt -y install nvidia-detect
> > mais "nvidia-detect" ne semble pas ou plus exister sous Buster.
>
> apt-cache policy nvidia-detect
> nvidia-detect:
> Installé : 418.74-1
> Candidat : 418.74-1
> Table de version :
> *** 418.74-1 990
>
: mardi 12 novembre 2019 23:05
À : debian-user-french@lists.debian.org
Objet : Re: Migration Stretch vers Buster : plus de mode graphique
On Tuesday 12 November 2019 19:45:49 lann wrote:
> "ajh-valmer" a écrit :
> > On Monday 11 November 2019 ajh-valmer wrote:
> > > &g
On Tuesday 12 November 2019 19:45:49 lann wrote:
> "ajh-valmer" a écrit :
> > On Monday 11 November 2019 ajh-valmer wrote:
> > > > > J'ai migré de Stretch vers Buster.
> > > > > Carte graphique Nvidia geforce proprio,
> > > > > qui
Le Tue, 12 Nov 2019 18:14:08 +0100,
"ajh-valmer" a écrit :
> On Monday 11 November 2019 19:58:14 ajh-valmer wrote:
> > > > J'ai migré de Stretch vers Buster.
> > > > Carte graphique Nvidia geforce proprio,
> > > > qui marchait parfaitement so
Bonjour.
Peut-être qu'un petit ménage s'impose avec:
apt update
apt purge nvidia*
rm /etc/X11/xorg.conf **(ou un move ailleurs pour sauvegarde car xorg se
débrouille sans conf aujourd'hui)
reboot
apt install nvidia-detect
nvidia-detect
apt install nvidia-driver **(ou autre paquet annoncé par
On Monday 11 November 2019 19:58:14 ajh-valmer wrote:
> > > J'ai migré de Stretch vers Buster.
> > > Carte graphique Nvidia geforce proprio,
> > > qui marchait parfaitement sous Stretch.
> > > En rebootant, j'ai ce message d'erreur au début :
> > >
Le 11/11/2019 à 19:58, ajh-valmer a écrit :
[...]
Connexion ssh possible ? Peux tu te connecter sur une console
(Ctrl+Alt+F1 à F6)
Comme je l'avais écrit :
Si je lance X, l'écran devient noir, rien,
plus de clavier, bloqué, seule solution : hard reboot.
Cela n'empêche pas ssh d'être
> > J'ai migré de Stretch vers Buster.
> > Carte graphique Nvidia geforce proprio,
> > qui marchait parfaitement sous Stretch.
> > En rebootant, j'ai ce message d'erreur au début :
> > "Failed to start openIPMI driver init script".
> > (openIPMI est bi
Le 11/11/2019 à 19:24, ajh-valmer a écrit :
Bonsoir à tous,
Bonsoir
J'ai migré de Stretch vers Buster.
Carte graphique Nvidia geforce proprio,
qui marchait parfaitement sous Stretch.
En rebootant, j'ai ce message d'erreur au début :
"Failed to start openIPMI driver init script".
Bonsoir à tous,
J'ai migré de Stretch vers Buster.
Carte graphique Nvidia geforce proprio,
qui marchait parfaitement sous Stretch.
En rebootant, j'ai ce message d'erreur au début :
"Failed to start openIPMI driver init script".
(openIPMI est bien installé),
ainsi que linux-headers-
On Ma, 24 sep 19, 22:28:59, Mark Fletcher wrote:
>
> In the end I think my problems were caused by previously having the
> deb-multimedia repositories in use and trying to move away from them
> at the same time as upgrading.
Most likely, which is why the Release Notes specifically advise to
Well, I really appreciate the deb-multimedia, but as I ran into similar
troubles times ago, I usually remove all non-official packages before
upgrade and reinstall them afterwards.
Greetings
Bernd
On Wed, 25 Sep 2019 20:09:40 +0200
Mattia wrote:
> So if anyone has a stretch server with owncloud-files installed and
> are planning to upgrade to buster: just don't! Wait for owncloud 10.3
> to come out.
Or consider moving to NextCloud. I have an instance running quite well
on Debian 10
Il 24/09/19 23:28, Mark Fletcher ha scritto:
I perform 5-days-a-week backups using Amanda. The machine in question
here happens to be the Amanda server as well as a client. The amanda
virtual tapes and holding disk are in a USB3 disk cage. The cage also
contains a RAID1 disk pair which contains
Hi list
This long email is just a report on my recent stretch to buster upgrade
experience. I had a bit of an adventure, didn't handle some steps well,
and thought the experience would be useful to put out there for others
to learn from / avoid some mistakes I made.
THERE IS NO QUESTION
Escaped from gnome. While working in gnome the visibility of my mouse
pointer became very erratic, often visible only at the margins of a
window. I would then have to move the mouse and guess where it pointed
in the window. The computer was all but unusable so I rebooted. Having
been schooled
No sound after upgrade to Buster
Switched from lxde to gnome to use gnome/sound speaker test - Still no sound
Rebooted to old stretch on another hard drive - had sound, output
changed to line out.
Rebooted to Buster. No sound and trapped in gnome. selection of desktops
shows at sign in but
On Wed 18 Sep 2019 at 12:06:00 (-), Curt wrote:
> On 2019-09-17, Sven Joachim wrote:
> > On 2019-09-17 11:10 -0500, David Wright wrote:
> >>
> >> Well, the only link *needed* is init, hence its dependency on package
> >> init, whose sole function is to keep the number of init configurations
>
On 2019-09-17, Sven Joachim wrote:
> On 2019-09-17 11:10 -0500, David Wright wrote:
>
>>
>> Well, the only link *needed* is init, hence its dependency on package
>> init, whose sole function is to keep the number of init configurations
>> more than zero and less than two.
>>
>> The rest of those
On Tue, Sep 17, 2019 at 05:06:52PM -0400, Greg Wooledge wrote:
[...]
> I can't believe people are still adding cruft to sysv-rc helpers in 2019.
Luckily, "real world" is much more colourful and diverse than your
(or my -- or anyone's!) beliefs ;-)
Cheers
-- tomás
signature.asc
Description:
On Tue, Sep 17, 2019 at 10:59:53PM +0200, Sven Joachim wrote:
> On 2019-09-17 09:13 -0400, Greg Wooledge wrote:
> > wooledg:~$ aptitude why systemd-sysv
> > i udev Depends dpkg (>= 1.19.3) | systemd-sysv
> >
> > OK... I'll admit, I do not quite understand that dependency.
>
> The udev init
On 2019-09-17 09:13 -0400, Greg Wooledge wrote:
> On Mon, Sep 16, 2019 at 11:11:33PM +0100, Brian wrote:
>> What causes systemd-sysv to be installed?
>
> wooledg:~$ aptitude why systemd-sysv
> i udev Depends dpkg (>= 1.19.3) | systemd-sysv
>
> OK... I'll admit, I do not quite understand that
On 2019-09-17 11:10 -0500, David Wright wrote:
>
> Well, the only link *needed* is init, hence its dependency on package
> init, whose sole function is to keep the number of init configurations
> more than zero and less than two.
>
> The rest of those links just mean that I can read, say, a 60
On Tue 17 Sep 2019 at 13:29:16 -0400, Greg Wooledge wrote:
> On Tue, Sep 17, 2019 at 06:25:05PM +0100, Brian wrote:
> > Upgrades from wheezy to jessie did not change the init system because
> > libpame-systemd had the dependency
> >
> > systemd-shim (>= 8-2) | systemd-sysv
>
>
On Tue, Sep 17, 2019 at 06:25:05PM +0100, Brian wrote:
> Upgrades from wheezy to jessie did not change the init system because
> libpame-systemd had the dependency
>
> systemd-shim (>= 8-2) | systemd-sysv
On Tue 17 Sep 2019 at 09:13:30 -0400, Greg Wooledge wrote:
> On Mon, Sep 16, 2019 at 11:11:33PM +0100, Brian wrote:
> > What causes systemd-sysv to be installed?
>
> wooledg:~$ aptitude why systemd-sysv
> i udev Depends dpkg (>= 1.19.3) | systemd-sysv
>
> OK... I'll admit, I do not quite
On Tue 17 Sep 2019 at 10:37:15 +0100, Brian wrote:
> On Sun 15 Sep 2019 at 23:31:23 +0100, Roger Lynn wrote:
>
> > I have three Stretch AMD64 systems with sysvinit - a desktop and laptop
> > running KDE and a headless server. Is there any information available
> > anywhere to tell me what will
On Tue 17 Sep 2019 at 09:45:21 (-0400), Greg Wooledge wrote:
> On Tue, Sep 17, 2019 at 09:40:50AM -0400, The Wanderer wrote:
> > I believe its name was chosen with
> > insufficient consideration, and is not in fact derived from its
> > function.
>
> You're not looking closely enough.
>
> > $
On 2019-09-17, The Wanderer wrote:
>>> Yes, but unless I'm greatly misunderstanding matters, /sbin/init is
>>> not specific to sysvinit.
>> That's okay, as I never came close to claiming it was. But you focus
>> uniquely upon this "point," while ignoring the part about the "links
>> needed for
On 2019-09-17 at 09:45, Greg Wooledge wrote:
> On Tue, Sep 17, 2019 at 09:40:50AM -0400, The Wanderer wrote:
>
>> I believe its name was chosen with
>> insufficient consideration, and is not in fact derived from its
>> function.
>
> You're not looking closely enough.
>
>> $ apt-file show
On Tue, Sep 17, 2019 at 09:40:50AM -0400, The Wanderer wrote:
> I believe its name was chosen with
> insufficient consideration, and is not in fact derived from its
> function.
You're not looking closely enough.
> $ apt-file show systemd-sysv
> systemd-sysv: /sbin/halt
> systemd-sysv: /sbin/init
On 2019-09-17 at 09:28, Curt wrote:
> On 2019-09-17, The Wanderer wrote:
>
>>> Why he would say "despite its name" eludes this correspondent,
>>> because the package has *everything* to do with sysvinit,
>>> providing as it does the "links needed for systemd to replace
>>> sysvinit. Installing
On 2019-09-17, The Wanderer wrote:
>> Why he would say "despite its name" eludes this correspondent,
>> because the package has *everything* to do with sysvinit, providing
>> as it does the "links needed for systemd to replace sysvinit.
>> Installing systemd-sysv will overwrite /sbin/init with a
On 2019-09-17 at 09:13, Greg Wooledge wrote:
> On Mon, Sep 16, 2019 at 11:11:33PM +0100, Brian wrote:
>
>> What causes systemd-sysv to be installed?
>
> wooledg:~$ aptitude why systemd-sysv
> i udev Depends dpkg (>= 1.19.3) | systemd-sysv
>
> OK... I'll admit, I do not quite understand that
On Mon, Sep 16, 2019 at 11:11:33PM +0100, Brian wrote:
> What causes systemd-sysv to be installed?
wooledg:~$ aptitude why systemd-sysv
i udev Depends dpkg (>= 1.19.3) | systemd-sysv
OK... I'll admit, I do not quite understand that dependency. But
what I really need to do is check this on a
On 2019-09-17 at 04:09, Curt wrote:
> On 2019-09-16, Brian wrote:
[that on some earlier date which has been clipped out, someone else -
who happens to be The Wanderer - wrote:]
>>> The dist-upgrade will have resulted in installing the
>>> systemd-sysv package, which (despite its name) has
On Sun 15 Sep 2019 at 23:31:23 +0100, Roger Lynn wrote:
> I have three Stretch AMD64 systems with sysvinit - a desktop and laptop
> running KDE and a headless server. Is there any information available
> anywhere to tell me what will happen when I attempt to upgrade them to
> Buster? The release
On 2019-09-16, Brian wrote:
>>
>> The dist-upgrade will have resulted in installing the systemd-sysv
>> package, which (despite its name) has nothing to do with sysvinit; it is
>> the package which sets systemd as the primary / active / default init
>> system.
>>
>> Installing sysvinit-core
On Mon, Sep 16, 2019 at 3:17 PM The Wanderer wrote:
> >> If you want to keep sysvinit, here's the order of events:
> >>
> >> change sources from stretch to buster
> >
> > Fine.
> >
> >> apt update
> >
> > Splendid.
> >
l happen when I
> > >>> attempt to upgrade them to Buster? The release notes don't
> > >>> mention it and other sources I can find just talk about switching
> > >>> from systemd to sysvinit, which doesn't look easy with a desktop
> >
On 2019-09-16 at 18:11, Brian wrote:
> On Mon 16 Sep 2019 at 15:16:34 -0400, The Wanderer wrote:
>
>> On 2019-09-16 at 15:07, Brian wrote:
>>
>>> On Sun 15 Sep 2019 at 21:52:50 -0400, Dan Ritter wrote:
apt install sysvinit-core
>>>
>>> What happens if this is not done?
>>
>> Next time
>> mention it and other sources I can find just talk about switching
> >>> from systemd to sysvinit, which doesn't look easy with a desktop
> >>> environment.
> >>
> >> If you want to keep sysvinit, here's the order of events:
> >>
>
sn't look easy with a desktop
>>> environment.
>>
>> If you want to keep sysvinit, here's the order of events:
>>
>> change sources from stretch to buster
>
> Fine.
>
>> apt update
>
> Splendid.
>
>> apt dist-upgrade
>
>
nit, here's the order of events:
>
> change sources from stretch to buster
Fine.
> apt update
Splendid.
> apt dist-upgrade
Great.
> apt install sysvinit-core
What happens if this is not done?
--
Brian.
Quoting Dan Ritter (2019-09-16 03:52:50)
> Roger Lynn wrote:
> > The KDE systems have systemd-shim installed, which is not present in
> > Buster. Is this going to cause problems? Will the server be okay?
> > Should I just stay with Stretch until Bullseye is released or
> > consider moving to
otes don't mention it and other sources I can find just
> talk about switching from systemd to sysvinit, which doesn't look easy with
> a desktop environment.
If you want to keep sysvinit, here's the order of events:
change sources from stretch to buster
apt update
apt dist-upgrade
apt install sysv
Hi,
I have three Stretch AMD64 systems with sysvinit - a desktop and laptop
running KDE and a headless server. Is there any information available
anywhere to tell me what will happen when I attempt to upgrade them to
Buster? The release notes don't mention it and other sources I can find just
Thanks to everybody, for all the hints.
I think the way to search in, is to create an edid file and load it at boot.
I searched in this direction before, I just abandoned that way because it did
not work.
Now the question I have is: How to create that edid file.
The tool I found creates a file
On Thu 12 Sep 2019 at 06:23:04 (+), Jan Michael Greiner wrote:
> On Monday, September 9, 2019, 1:55:06 PM GMT+2, Charles Curley wrote:
> >> On Mon, 9 Sep 2019 10:20:37+ (UTC) Jan Michael Greiner wrote:
> >> With Debian Stretch (9.8) I had the display running with 3840x2160
> >> resolution
Jan Michael Greiner wrote:
> Dear all,
>
> My laptop: Lenovo E520
> Graphics: Intel HD Graphics 3000 (kernel module i915)
>
> External display AOC U2879VF, 28 inch, connected by HDMI cable
>
> With Debian Stretch (9.8) I had the display running with 3840x2160 resolution
> at 24Hz reduced
Hi
I have a kind of same problem.
A monitor able of displaying at 1920x1080.
Intel HD Graphics 620 with driver i915/modesetting.
With old Stable (kernel 4.9.0-9) it was working fine.
With new Stable (kernel 4.19.0-6) it set max display 1024x768.
See
Dear Charles,
On Monday, September 9, 2019, 1:55:06 PM GMT+2, Charles Curley wrote:
>> On Mon, 9 Sep 2019 10:20:37+ (UTC) Jan Michael Greiner wrote:
>> With Debian Stretch (9.8) I had the display running with 3840x2160
>> resolution at 24Hz reduced blank.
>> [What worked with Debian
Thomas George wrote:
> Checked archives, installed pavucontrol but this did not help. Any
> suggestions?
check alsamixer -c0 and look for muted channels
You could run the script alsa-info (from alsa-utils) and choose to
upload/share, and send the link to this list.
Hope this helps.
On Mon, 9 Sep 2019 14:11:25 -0400
Thomas George wrote:
> Checked archives, installed pavucontrol but this did not help. Any
> suggestions?
>
Checked archives, installed pavucontrol but this did not help. Any
suggestions?
On Mon, 9 Sep 2019 10:20:37 + (UTC)
Jan Michael Greiner wrote:
> With Debian Stretch (9.8) I had the display running with 3840x2160
> resolution at 24Hz reduced blank.
And I take it you want to reproduce that on Debian 10 (buster). I
suggest you:
* Install arandr.
* Use arandr to set
Apparently internal snapshots of a qcow2-based vm are problematic when
the vm boots from UEFI. I found that out when my nightly snapshots
stopped working after I upgraded a server from stretch to buster.
Testing the effective line of the script with actual values, I got this
result
Hello,
I have just successfully upgraded 12 physical machines to the new Debian
release (Debian Buster) and can tell that the upgrade runs very smoothly.
Very nice job by all contributors, thank you very much!
I have noticed, that files previously existing under /usr/share/vim/vimfiles
have
James Allsopp writes:
Hi,
I was going to upgrade to Buster, but I've got docker installed and am
running a container as an ldap server. Consequently I don't want to get rid
of it, but the install guide I read suggested removing all 3rd-party
repositories before starting.
This is the
I upgraded just fine with 3rd party repositories enabled. What you might
want to do is ensure the repositories match the Debian version you're
upgrading to.
Typically repositories that do different builds for different Debian
versions put the version in the repository URL. So check whether any
Hi,
I was going to upgrade to Buster, but I've got docker installed and am
running a container as an ldap server. Consequently I don't want to get rid
of it, but the install guide I read suggested removing all 3rd-party
repositories before starting.
This is the current situatioin with my sources
x and then
changed sources.list to reference buster..." because that is a definite
negative. There is no reason (at this point) to install stretch and then
upgrade to buster. So go back and don't do that.
If you are saying you have been running a mixed (stretch/buster)system and
want to
Hi
When updating from Stretch to Buster I know that I need to change
references in the sources.list file
Mine is below
# deb cdrom:[Debian GNU/Linux 9.5.0 _Stretch_ - Official amd64 DVD
Binary-1 20180714-10:25]/ stretch contrib main non-free
# deb cdrom:[Debian GNU/Linux 9.5.0 _Stretch_
to install Buster.
In Stretch perl is 5.24.1-3+deb9u5 but is 5.28.1-6 in Buster.
Is it feasible to run under Stretch? How?
mmdebstrap has no tight dependencies so you should be able to simply
install the Buster package in Stretch and try use it.
Today == *rain* Tomorrow = holiday Should have lots
Quoting Richard Owlett (2019-05-26 16:34:17)
> I was investigating using multistrap, but it has been orphaned.
> mmdebstrap apparently has the desired features of multistrap but is
> available only in Buster.
>
> I do not have the available bandwidth to install Buster.
&g
I was investigating using multistrap, but it has been orphaned.
mmdebstrap apparently has the desired features of multistrap but is
available only in Buster.
I do not have the available bandwidth to install Buster.
In Stretch perl is 5.24.1-3+deb9u5 but is 5.28.1-6 in Buster.
Is it feasible
On Wed 10 Apr 2019 at 13:26:39 (+0200), Vincent Lefevre wrote:
> On 2019-04-09 13:28:40 -0500, David Wright wrote:
> > On Tue 09 Apr 2019 at 15:38:43 (+0200), Vincent Lefevre wrote:
> > > On 2019-04-08 18:26:23 +0300, Reco wrote:
> > > > stretch$ TZ=UTC date
> > > > Mon Apr 8 15:22:02 UTC 2019
>
On 2019-04-09 13:28:40 -0500, David Wright wrote:
> On Tue 09 Apr 2019 at 15:38:43 (+0200), Vincent Lefevre wrote:
> > On 2019-04-08 18:26:23 +0300, Reco wrote:
> > > stretch$ TZ=UTC date
> > > Mon Apr 8 15:22:02 UTC 2019
> > > buster$ TZ=UTC date
> > > Mon 08 Apr 2019 03:22:04 PM UTC
> >
> >
On Tue 09 Apr 2019 at 20:07:37 (-), Curt wrote:
> On 2019-04-09, Étienne Mollier wrote:
> >
> > The output may differ depending on you operating system level,
> > given Reco's observations. Feel free to have à look at
> > /usr/share/zoneinfo/, to have an idea of the available
> > locations.
On 2019-04-09, Étienne Mollier wrote:
>
> The output may differ depending on you operating system level,
> given Reco's observations. Feel free to have à look at
> /usr/share/zoneinfo/, to have an idea of the available
> locations.
I took a look.
I was confused to note the presence of the UCT
On Tue 09 Apr 2019 at 14:55:37 (-0400), Greg Wooledge wrote:
> On Tue, Apr 09, 2019 at 01:28:40PM -0500, David Wright wrote:
> > My question about the OP's issue is whether I'm going to have to
> > change something to keep what I get in jessie and stretch, or is
> > this just a temporary bug in
1 - 100 of 166 matches
Mail list logo
