Re: [gentoo-user] Is anyone using Scaleway VM hosting?
> On 11 Sep 2017, at 00:08, Alexey Eschenko wrote: > > I'm using Scaleway with Gentoo VM for two months. You can try to ask here but > I don't know if I can answer to you properly. Thanks. I signed up for an account there a day or two ago, and set up a VM running Gentoo. Scaleway provide a Gentoo VM image x86_64-gentoo-latest-2016-04-06_16:15, so I added a user account and a handful of essential tools and started updating it to latest. Having updated the VM to the current tree, I want to make an image of the system so that I have my Gentoo minimal 9-2017 VM that I can copy and deploy any time. The VM admin interface has sections for "volumes", "snapshots" and "images" - I assume they're all kinds of disc images, but I don't think I fully understand the difference. I think: • Volumes are active disc images, currently deployed in a VM. • Snapshots are VM disc images, which are saved once the VM has been shutdown. • Images are VM disk images which can be used as the basis for new VMs? If my understanding is correct, I don't really see the difference between a "snapshot" and an "image" - is it merely that "images" are copied when they're deployed, whereas "snapshots" are resumed and any changes overwrite the old filesystem? Are there any other differences? I'm used to running Linux on physical hardware, so I tend to think of disc images as being created if I boot from SystemRescueCD and `dd if=/dev/sda of=/mnt/usb-drive/old-pc.dd.img`. I can understand that, running a VM farm, one would probably want to have a bunch of disk images available to use - some of these I might label "my-gentoo-basic-master-2017" and "my-gentoo-webserver-master-2017", which I would mark as read-only, whilst others would be "my-webserver-www.something.com", and which would be current, active and read-write. I *think* this is the diasctintion being made between volumes, snapshots and images, but I lack confidence because this doesn't seem to be explained anywhere. When I try to make a snapshot of a volume I get a message "Volume not snapshot - server must be stopped to snapshot". That sounds reasonable, but when I go to shutdown the VM and see this scary message - https://i.imgur.com/1E02DrP.png I assume that "Archive" is the same as shutting down my PC - the contents of the VM are saved, and I can start it up again later. I don't understand the warning about the DSSD being "totally erased without any possible recovery" - surely the whole point is to make the VM inactive, but save it's current state, ready to start up again next time it's needed (like switching a regular PC on again). > Also I'd rather recommend to write to Scaleway support. They usually answers > in one business day. I don't feel confident in what I'm asking at the moment - I feel like these kind of questions ought to be covered in the first pages of a beginners' FAQ, but I don't immediately find them on Scaleway's site. I.E. I'm asking dumb questions, or I don't know the right questions to ask. The Scaleway community support pages show some customer discontent (e.g. the "Your SMTP ports are blocked. Contact our support to unblock them" and "Abuse reports ignored?") and I can't help but wondering if I should have spent the extra €2 a month and gone for Linode. Final question: Scaleway advertise their servers as €2.99 a month / €0.006 per hour - are customers always billed on an hourly basis? I.E. if I have a have VM that I only spin up when I need it, an hour or two at a time, for a few hours a month, am I right in thinking I pay only pennies for that? It seems very convenient. Is this charging model common amongst VM hosting providers? Thanks in advance for any pointers, Stroller.
Re: [gentoo-user] What do you think about Firefox 57?
On Sun, Sep 10, 2017 at 06:19:55PM -0700, Daniel Campbell wrote > > Based on what I've read so far, Moonchild is up front about any > breakage, and warns about unsupported compilers or settings. One of our > regulars (Walter Dnes) helps maintain PM for us, too, so that's even > better. :) A bit of clarification; I'm not a programmer/developer. I volunteer to do a couple of niche builds. * the SSE-only linux build for Pentium-3-class machines * the 32-bit linux "unstable" build I have a few desktops and laptops at home. I wanted maximum optimized manual builds for my machines. I set up separate working directories for each machine, with symlinks to the same source directory. The build script was the same, so it was also a symlink. The only differences were the mozconfig files, and a small "customize" include file. From there, it's a minor incremental effort to add another directory or two. The major part of the effort was setting up a CentOS 6.5 chroot to match the build environment for the mainstream linux build. -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-user] Unlocking Plasma desktop in Gentoo without systemd
I started a plasma session and after some period of input inactivity I noticed the screen blanked out. Later on I moved the mouse and to my surprise I obtained this message: * "The screen locker is broken and unlocking is not possible anymore. In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in and execute the command: loginctl unlock-sessions Afterwards switch back to the running session (Ctrl+Alt+F7)." * Given this is a non-systemd Gentoo installation and I intend to keep it this way as long as reasonably practicable, what should I instruct the user to do to recover their current plasma session? If this is a default Gentoo installation with openrc, why does a default plasma desktop screenlocker comes up with this nonsense? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd
> On 11 Sep 2017, at 18:49, Mick wrote: > > … > "The screen locker is broken and unlocking is not possible anymore. > In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2), > log in and execute the command: > > loginctl unlock-sessions > > ... > > If this is a default Gentoo installation with openrc, why does a default > plasma desktop screenlocker comes up with this nonsense? Is it possible some of your KDE components were emerged with USE="systemd"? Try something like `emerge -pN world`? Stroller.
Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd
I had a similar (if not identical problem). This solution is a "difficult" solution, the reason I experienced this (if I understand) was that I was running KDE at the same time I was updating KDE. I can't remember if I simply rebooted, or if all it took was logging out, and logging back in. Even if I had rebooted, the *most* that should be required is restarting X, which if you are running XDM may require restarting XDM, or as stated, simply logging out and logging back in (but that might not be possible from KDE running in this broken mode). It should happen relatively infrequently. If you are doing unattended updates, you are likely to run into this kind of problem from time to time. I do not recommend it except for "security" updates, which I don't believe there is an automated process in Gentoo to do. Ie. I don't believe Portage flags updates as "security" updates in any way, so a single command of "emerge --update --security-only @word" (to my knowledge) isn't really a possibility. Though, also, I haven't been following recent discussions that closely, and I only recently returned to Gentoo after about 10 years away. On 09/11/2017 10:49 AM, Mick wrote: > I started a plasma session and after some period of input inactivity I > noticed > the screen blanked out. Later on I moved the mouse and to my surprise I > obtained this message: > * > "The screen locker is broken and unlocking is not possible anymore. > In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2), > log in and execute the command: > > loginctl unlock-sessions > > Afterwards switch back to the running session (Ctrl+Alt+F7)." > * > > Given this is a non-systemd Gentoo installation and I intend to keep it this > way as long as reasonably practicable, what should I instruct the user to do > to recover their current plasma session? > > If this is a default Gentoo installation with openrc, why does a default > plasma desktop screenlocker comes up with this nonsense? > signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd
On Monday, 11 September 2017 19:18:30 BST Stroller wrote: > > On 11 Sep 2017, at 18:49, Mick wrote: > > > > … > > "The screen locker is broken and unlocking is not possible anymore. > > In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2), > > log in and execute the command: > > > > loginctl unlock-sessions > > > > ... > > > > If this is a default Gentoo installation with openrc, why does a default > > plasma desktop screenlocker comes up with this nonsense? > > Is it possible some of your KDE components were emerged with USE="systemd"? > > Try something like `emerge -pN world`? > > Stroller. Thanks Stroller, but no, this PC never had any systemd component, on purpose: # emerge -pN world These are the packages that would be merged, in order: Calculating dependencies... done! I had disabled USE flag 'systemd' in make.conf as soon as this flag was established: $ euse -I systemd global use flags (searching: systemd) local use flags (searching: systemd) [- c] systemd (dev-qt/qtcore): Enable native journald logging support [- c] systemd (media-sound/pulseaudio): Build with sys-apps/systemd support to replace standalone ConsoleKit. [- c] systemd (sys-apps/accountsservice): Use sys-apps/systemd instead of sys-auth/consolekit for session tracking [- c] systemd (sys-apps/busybox): Support systemd [- c] systemd (sys-apps/dbus): Build with sys-apps/systemd at_console support [- c] systemd (sys-auth/pambase): Use pam_systemd module to register user sessions in the systemd control group hierarchy. [- c] systemd (sys-auth/polkit): Use sys-apps/systemd instead of sys-auth/consolekit for session tracking [- c] systemd (sys-fs/udisks): Support sys-apps/systemd's logind The interesting thing is I never enabled screen locking, so plasma ought to be running with default settings. If such a setting causes the session to become inaccessible it should have been disabled by default. There may have been a warning about it in the past, but I can't recall it. The funny thing was the user thought her machine was being hacked! o_O I tried to pacify her by explaining that without systemd stack the attack surface should be smaller. ;-p -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd
On 09/11/2017 10:49 AM, Mick wrote: I started a plasma session and after some period of input inactivity I noticed the screen blanked out. Later on I moved the mouse and to my surprise I obtained this message: * "The screen locker is broken and unlocking is not possible anymore. In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in and execute the command: loginctl unlock-sessions Afterwards switch back to the running session (Ctrl+Alt+F7)." * Given this is a non-systemd Gentoo installation and I intend to keep it this way as long as reasonably practicable, what should I instruct the user to do to recover their current plasma session? Are you updating KDE? I always run into this issue when updating KDE, so I now turn off the screen lock before I commence updating. If this is a default Gentoo installation with openrc, why does a default plasma desktop screenlocker comes up with this nonsense? Because KDE expects people to use systemd, a bug was raised regarding this issue, and the developers basically said you're on your own (RESOLVED: WONTFIX): https://bugs.kde.org/show_bug.cgi?id=360489 According to a comment in the bug, you can try to figure out which session it is (ck-list-sessions) and look for the X11 display property set. This will not work (or could be difficult) if you have several users using KDE at the same time and can't tell the sessions apart. Once you figure that out, remember the session name and: # su -c 'dbus-send --system --print-reply \ --dest="org.freedesktop.ConsoleKit" \ /org/freedesktop/ConsoleKit/ \ org.freedesktop.ConsoleKit.Session.Unlock' This worked on my laptop running openrc. I now just disable the locker before doing updates. Dan
Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd
On Monday, 11 September 2017 19:27:02 BST Jigme Datse Yli-RAsku wrote: > I had a similar (if not identical problem). This solution is a > "difficult" solution, the reason I experienced this (if I understand) > was that I was running KDE at the same time I was updating KDE. No the user started a Plasma session after booting up the PC and while no updates were being performed. > I can't > remember if I simply rebooted, or if all it took was logging out, and > logging back in. Even if I had rebooted, the *most* that should be > required is restarting X, which if you are running XDM may require > restarting XDM, or as stated, simply logging out and logging back in > (but that might not be possible from KDE running in this broken mode). > It should happen relatively infrequently. I can login and restart xdm, but I fear the user may lose some the work being performed at the time. I may end up doing this, but not if there is a way to recover the session. Strangely, I can't see any relevant screenlock process I could stop from the console. :-( -- Regards, Mick
Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd
On 11.09.2017 21:04, Mick wrote:
> On Monday, 11 September 2017 19:27:02 BST Jigme Datse Yli-RAsku wrote:
>> I had a similar (if not identical problem). This solution is a
>> "difficult" solution, the reason I experienced this (if I understand)
>> was that I was running KDE at the same time I was updating KDE.
>
> No the user started a Plasma session after booting up the PC and while no
> updates were being performed.
>
>
>> I can't
>> remember if I simply rebooted, or if all it took was logging out, and
>> logging back in. Even if I had rebooted, the *most* that should be
>> required is restarting X, which if you are running XDM may require
>> restarting XDM, or as stated, simply logging out and logging back in
>> (but that might not be possible from KDE running in this broken mode).
>> It should happen relatively infrequently.
>
> I can login and restart xdm, but I fear the user may lose some the work being
> performed at the time. I may end up doing this, but not if there is a way to
> recover the session. Strangely, I can't see any relevant screenlock process
> I
> could stop from the console. :-(
>
Try this:
# Get Session-ID
sesid=$(ck-list-sessions | egrep "(Session[0-9]:|x11-display = ':0')" |
grep -B 2 "x11-display = ':0'" | grep "Session" | cut -d":" -f1)
# Unlock
sudo dbus-send --system --print-reply
--dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/${sesid}
org.freedesktop.ConsoleKit.Session.Unlock
--
Dan Johansson
***
This message is printed on 100% recycled electrons!
***
Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd
On Monday, 11 September 2017 20:27:02 BST Dan Johansson wrote:
> On 11.09.2017 21:04, Mick wrote:
> > On Monday, 11 September 2017 19:27:02 BST Jigme Datse Yli-RAsku wrote:
> >> I had a similar (if not identical problem). This solution is a
> >> "difficult" solution, the reason I experienced this (if I understand)
> >> was that I was running KDE at the same time I was updating KDE.
> >
> > No the user started a Plasma session after booting up the PC and while no
> > updates were being performed.
> >
> >> I can't
> >> remember if I simply rebooted, or if all it took was logging out, and
> >> logging back in. Even if I had rebooted, the *most* that should be
> >> required is restarting X, which if you are running XDM may require
> >> restarting XDM, or as stated, simply logging out and logging back in
> >> (but that might not be possible from KDE running in this broken mode).
> >> It should happen relatively infrequently.
> >
> > I can login and restart xdm, but I fear the user may lose some the work
> > being performed at the time. I may end up doing this, but not if there
> > is a way to recover the session. Strangely, I can't see any relevant
> > screenlock process I could stop from the console. :-(
>
> Try this:
>
> # Get Session-ID
> sesid=$(ck-list-sessions | egrep "(Session[0-9]:|x11-display = ':0')" |
> grep -B 2 "x11-display = ':0'" | grep "Session" | cut -d":" -f1)
>
> # Unlock
> sudo dbus-send --system --print-reply
> --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/${sesid}
> org.freedesktop.ConsoleKit.Session.Unlock
Thank you All, the suggestion to unlock the sessionID worked!
So, KDE is now becoming good as Gnome in becoming entwined with systemd. I
can see myself ending up in working on VTs only soon! ;-p
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
[gentoo-user] Downgrading glibc prevented by emerge/portage...but why initiated?
Hi, got a problem this morning: >>> Verifying ebuild manifests >>> Running pre-merge checks for sys-libs/glibc-2.24-r4 * Sanity check to keep you from breaking your system: * Downgrading glibc is not supported and a sure way to destruction * ERROR: sys-libs/glibc-2.24-r4::gentoo failed (pretend phase): * aborting to save your system * * Call stack: *ebuild.sh, line 115: Called pkg_pretend *ebuild.sh, line 348: Called toolchain-glibc_pkg_pretend * toolchain-glibc.eclass, line 507: Called die * The specific snippet of code: * die "aborting to save your system" * * If you need support, post the output of `emerge --info '=sys-libs/glibc-2.24-r4::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/glibc-2.24-r4::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.24-r4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/glibc-2.24-r4/temp/die.env'. * Working directory: '/var/tmp/portage/sys-libs/glibc-2.24-r4/homedir' * S: '/var/tmp/portage/sys-libs/glibc-2.24-r4/work/glibc-2.24' >>> Running pre-merge checks for media-sound/pulseaudio-11.0 * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 4.13.1-RT * Checking for suitable kernel configuration options... [ ok ] * A preallocated buffer-size of 2048 (kB) or higher is recommended for the HD-audio driver! * CONFIG_SND_HDA_PREALLOC_SIZE=64 I would interpret this as: In the past emerge had updated glibc to a higher version as it want it to install now and prevented the latter becayse it would be downgrade, which in turn would render my box useless. But why updateing to higher version in the first stepor attempting to downgrade now? And finally...ANy update is blocked for now it seems...how can I get out of this? Thanks a lot in advance for any help! Cheers Meino
Re: [gentoo-user] Downgrading glibc prevented by emerge/portage...but why initiated?
tu...@posteo.de wrote: > Hi, > > got a problem this morning: > Verifying ebuild manifests Running pre-merge checks for sys-libs/glibc-2.24-r4 > * Sanity check to keep you from breaking your system: > * Downgrading glibc is not supported and a sure way to destruction > * ERROR: sys-libs/glibc-2.24-r4::gentoo failed (pretend phase): > * aborting to save your system > * > * Call stack: > *ebuild.sh, line 115: Called pkg_pretend > *ebuild.sh, line 348: Called toolchain-glibc_pkg_pretend > * toolchain-glibc.eclass, line 507: Called die > * The specific snippet of code: > *die "aborting to save your system" > * > * If you need support, post the output of `emerge --info > '=sys-libs/glibc-2.24-r4::gentoo'`, > * the complete build log and the output of `emerge -pqv > '=sys-libs/glibc-2.24-r4::gentoo'`. > * The complete build log is located at > '/var/tmp/portage/sys-libs/glibc-2.24-r4/temp/build.log'. > * The ebuild environment file is located at > '/var/tmp/portage/sys-libs/glibc-2.24-r4/temp/die.env'. > * Working directory: '/var/tmp/portage/sys-libs/glibc-2.24-r4/homedir' > * S: '/var/tmp/portage/sys-libs/glibc-2.24-r4/work/glibc-2.24' Running pre-merge checks for media-sound/pulseaudio-11.0 > * Determining the location of the kernel source code > * Found kernel source directory: > * /usr/src/linux > * Found sources for kernel version: > * 4.13.1-RT > * Checking for suitable kernel configuration options... > [ ok ] > * A preallocated buffer-size of 2048 (kB) or higher is recommended for the > HD-audio driver! > * CONFIG_SND_HDA_PREALLOC_SIZE=64 > > I would interpret this as: > > In the past emerge had updated glibc to a higher version as it want it > to install now and prevented the latter becayse it would be downgrade, > which in turn would render my box useless. > > But why updateing to higher version in the first stepor attempting > to downgrade now? > > And finally...ANy update is blocked for now it seems...how can I get > out of this? > > Thanks a lot in advance for any help! > Cheers > Meino > I would start by adding -t to the emerge command. That should show what is pulling in the older glibc. Hopefully, that will shine a light on the why it wants to downgrade. May be a good idea to post that info here as well. May help others with a answer since it should provide more info. Dale :-) :-)
