Re: An Odd File Name
On Mon, Feb 13, 2017 at 12:49:35PM -0600, David Wright wrote: > You could try partial wildcarding, like: > > $ ls *tall*build* This is often very useful, even to make typing awkward characters easier. I often use ? rather than * to reduce the risk of accidentally matching other files. -- Jonathan Dowland Please do not CC me, I am subscribed to the list. signature.asc Description: Digital signature
Re: [FOLLOW-UP] Re: Having scanned set of installation DVDs...
On 02/13/2017 05:40 PM, songbird wrote: Richard Owlett wrote: On 02/12/2017 09:26 AM, songbird wrote: Richard Owlett wrote: songbird wrote: ... years ago i copied from dvds to a subdirectory on an external USB drive. it worked ok, but i did have to tell in the apt sources list that i was using a file and not a dvd. i am pretty sure i used a "cp -r" to do it too... fwiw, :) I have that on my TO-DO list. There's an additional step - creating packages.gz so apt related tools look at it as a large DVD. the package list is in there, should be no need to regenerate it. if your apt sources list points to the right directory (use file not cd or dvd in the list) it should find it and use it. We have different goals/assumptions. You are creating a directory for each CD/DVD. I have a situation in mind that mounting more than one directory would be a problem. Thus my solution for Jessie would take 13 DVDs and create one humongous pseudo-DVD. P.S. I've never been described as "normal", much less "typical" ;/ but you do understand that i only had them copied to one device, one mount point, one directory which contained them all, but apt doesn't care, it scans them all the one time when you update and then they are available just like any other repository. really, i think you are doing more work than is needed here for no real gain in anything that i can determine. mounting the device as i did caused absolutely no problems that i recall. each disk was an entry in the apt sources list, but if i didn't need that device (it was an external USB device so not always turned on for use) i just commented out those lines in the apt sources list. Light begins to dawn. I just carefully read manpage for sources.list . Seems that I "knew" things that just weren't so ;/ I have the morning free and will do some experimenting. Thank you for your patience.
Re: Kernel Update on Stretch
Daniel Bareiro wrote: > Some time ago I read that Linux 4.x incorporates the feature to be > updated without requiring a restart of the operating system. Some Linux Distributions have such a feature. Debian is not one of them. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Kernel Update on Stretch
On Tue, Feb 14, 2017 at 01:46:08PM +0100, Sven Hartge wrote: Daniel Bareiro wrote: Some time ago I read that Linux 4.x incorporates the feature to be updated without requiring a restart of the operating system. Some Linux Distributions have such a feature. Debian is not one of them. Actually, yes it is, you just need to install the user space tools.[1] The facility is called "kexec" (named after the system call to 'EXECute a new Kernel', I suspect). Install the "kexec-tools" package and, if I'm reading that page correctly, the "reboot" command will be replaced by a kexec call (see the linked page, though, for precautions about your first reboot). [1] wiki.debian.org/BootProcessSpeedup#Using_kexec_for_warm_reboots Grüße, Sven. -- Sigmentation fault. Core dumped. -- For more information, please reread.
Re: Kernel Update on Stretch
Darac Marjal wrote: > On Tue, Feb 14, 2017 at 01:46:08PM +0100, Sven Hartge wrote: >> Daniel Bareiro wrote: >>> Some time ago I read that Linux 4.x incorporates the feature to be >>> updated without requiring a restart of the operating system. >> Some Linux Distributions have such a feature. Debian is not one of >> them. > Actually, yes it is, you just need to install the user space tools.[1] You misunderstood Daniel. He thinks of mechanisms like ksplice or kpatch where you can alter/patch the running kernel without rebooting the system. > The facility is called "kexec" (named after the system call to > 'EXECute a new Kernel', I suspect). Install the "kexec-tools" package > and, if I'm reading that page correctly, the "reboot" command will be > replaced by a kexec call (see the linked page, though, for precautions > about your first reboot). kexec still "reboots" the system, meaning the complete userland has to be stopped before the new kernel can be started. You only gain time because you don't have to wait for the UEFI/BIOS, RAID cards, network cards, etc. to initialize. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Kernel Update on Stretch
Hi, Darac. On 14/02/17 10:01, Darac Marjal wrote: >>> Some time ago I read that Linux 4.x incorporates the feature to be >>> updated without requiring a restart of the operating system. >> Some Linux Distributions have such a feature. Debian is not one of them. > Actually, yes it is, you just need to install the user space tools.[1] > > The facility is called "kexec" (named after the system call to 'EXECute > a new Kernel', I suspect). Install the "kexec-tools" package and, if I'm > reading that page correctly, the "reboot" command will be replaced by a > kexec call (see the linked page, though, for precautions about your > first reboot). > > [1] wiki.debian.org/BootProcessSpeedup#Using_kexec_for_warm_reboots Reading about the documentation you mentioned and researching a little more about kexec, I see that kexec skips the BIOS init part, but it requires a boot anyway. In fact, I see that kexec is present in Jessie and I've also seen some examples of use with 2.6 series kernels. I understand that what I mentioned was introduced with Linux 4.x. Thanks for your reply. Kind regards, Daniel signature.asc Description: OpenPGP digital signature
Re: Kernel Update on Stretch
Hi, Sven. On 14/02/17 10:19, Sven Hartge wrote: > He thinks of mechanisms like ksplice or kpatch where you can > alter/patch the running kernel without rebooting the system. Yes, I had read some about this and that, for example, Ubuntu has it available but as a paid service that one can hire. What is not clear to me is if these systems are complemented with the package system or it is something independent. I think it's some kind of hot patching, which would not require installing a new version of the kernel package. Thanks for your reply. Kind regards, Daniel signature.asc Description: OpenPGP digital signature
Re: Kernel Update on Stretch
Hi, On 02/14/2017 12:58 AM, Daniel Bareiro wrote: > Some time ago I read that Linux 4.x incorporates the feature to be > updated without requiring a restart of the operating system. They incorporated parts of that. There are still some unsolved issues. See for example this article from last November about the topic: https://lwn.net/Articles/706327/ So there's no complete upstream support for this yet, there are several distributions that roll their own variants. > Since stretch incorporates a kernel of the 4.x series, this would imply > that we can update the kernel package and avoid reboots? No. There are two components to this: 1. The kernel must support loading live patches This is partially true for the kernel that will come with Stretch (CONFIG_LIVEPATCH=y), but (see the LWN article I linked) it doesn't actually work safely yet. 2. Someone needs to prepare the live patches. Currently nobody in Debian is doing that. You could do it yourself with the right tooling (look at kpatch and kgraft), but preparing these kinds of patches is very complicated. (And that still doesn't solve the problem that the current patch loading support is unsafe, see 1.) Further reading: https://lists.debian.org/1460472961.25201.200.ca...@decadent.org.uk Depending on whether there is movement in the upstream kernel there is a chance this might be a thing in Buster, but it definitely won't work out of the box in Stretch. You'll still need to reboot. Regards, Christian
Re: sysvinit - call for testers of 2.88dsf-59.9
On 02/13/2017 06:23 PM, Ian Jackson wrote:
Ian Jackson writes ("sysvinit - call for testers of 2.88dsf-59.9"):
If you are running testing (stretch) and using sysvinit, I'd
appreciate it if you could install the new sysvinit packages from
unstable (sid).
Thanks to those who replies already. I have had favourable test
reports for usrmerge[1] and a normal install with / and /usr on the
same filesystem, including some new stretch installs.
[1] usrmerge means binaries and libraries have been moved to /usr and
/{bin,lib,sbin} are symlinks to /usr/{bin,lib,sbin} respectively.
I'm still lacking a test report for a system where /usr is a separate
filesystem, if anyone has one running stretch that they are willing to
test this package on. (See my previous email for the list of binary
packages and versions etc.)
Thanks,
Ian.
Hi Ian, I ran your test, just so you know I have /user on root.
# uname -a
Linux jimmy-1 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64
GNU/Linux
Before your patch: # cat /proc/1/comm
systemd
After your patch: # cat /proc/1/comm
init
So I am now running an init system with no ill effects and my system is
not trying to change the way it's running when I run "upgrade-system"
and that is a good thing.
regards,
--
Jimmy Johnson
Debian Sid/Testing - Plasma 5.8.4 - Kernel 4.9.0-1 - EXT4 at sda24
Registered Linux User #380263
Re: sysvinit - call for testers of 2.88dsf-59.9
Hi, on a laptop with testing, updated init packages, and freshly rebooted, the priority of the packages is still "required": # cat /proc/1/comm init $ mount -t ext4 /dev/sda1 on / type ext4 (rw,relatime,lazytime) /dev/sda2 on /home type ext4 (rw,relatime,lazytime) $ dpkg -s sysvinit-utils | grep -E '(Version|Priority|Multi-Arch)' Priority: required Multi-Arch: foreign Version: 2.88dsf-59.9 $ dpkg -s sysv-rc | grep -E '(Version|Priority|Multi-Arch)' Priority: required Multi-Arch: foreign Version: 2.88dsf-59.9 $ dpkg -s initscripts | grep -E '(Version|Priority|Multi-Arch)' Priority: required Multi-Arch: foreign Version: 2.88dsf-59.9 Regards, jvp.
Re: sysvinit - call for testers of 2.88dsf-59.9
On 02/12/2017 02:54 PM, Ian Jackson wrote: Big-Snip < [ Ben Hutchings ] How can I test this? * Keep /usr mounted read-only on shutdown (Closes: #757083) Thanks, -- Jimmy Johnson Debian Sid/Testing - Plasma 5.8.4 - EXT4 at sda15 Registered Linux User #380263
Re: sysvinit - call for testers of 2.88dsf-59.9
On 02/14/2017 11:29 AM, Jimmy Johnson wrote: /usr mounted read-only on shutdown (Closes: #757083) Only effects systems with separate partition for /usr ? -- Jimmy Johnson Debian Sid/Testing - Plasma 5.8.4 - EXT4 at sda15 Registered Linux User #380263
Re: [FOLLOW-UP] Re: Having scanned set of installation DVDs...
Richard Owlett wrote: ... > Light begins to dawn. I just carefully read manpage for sources.list . > Seems that I "knew" things that just weren't so ;/ > I have the morning free and will do some experimenting. > Thank you for your patience. i'm glad for that, especially if it does save you tons of needless bit moving. :) songbird
Re: sysvinit - call for testers of 2.88dsf-59.9
Jimmy Johnson writes ("Re: sysvinit - call for testers of 2.88dsf-59.9"):
> Hi Ian, I ran your test, just so you know I have /user on root.
> # uname -a
> Linux jimmy-1 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64
> GNU/Linux
>
> Before your patch: # cat /proc/1/comm
> systemd
>
> After your patch: # cat /proc/1/comm
> init
>
> So I am now running an init system with no ill effects and my system is
> not trying to change the way it's running when I run "upgrade-system"
> and that is a good thing.
Thanks for the report. I'm not sure exactly what you did, but I think
that your computer no longer wants to switch from systemd to sysvinit
is not due to anything in my recent upload. (Unless, just possibly,
this is due to the new multiarch changes and your system is
mixed-arch?)
But I'm glad to hear that things are more like you want them to be.
Regards,
Ian.
Fwd: How set screen( not x 11 !) color in Debian to ANSI black or #000000 via command line ?
Gentlemen How set screen( not x 11 !) color in Debian to ANSI black or #00via command line ? Relevant comment would appreciated -- http://www.fastmail.com - Same, same, but different...
Re: How set screen( not x 11 !) color in Debian to ANSI black or #000000 via command line ?
swjatoslaw gerus composed on 2017-02-15 00:45 (UTC+0100):
How set screen( not x 11 !) color in Debian to ANSI black or
#00via command line ?
Relevant comment would appreciated
I have
tty=$(tty); [ "$tty" != "${tty#/dev/tty[0-9]}" ] && setterm --background blue
--foreground white --bold on --blank 59 --store
in ~/.bashrc (all on one line). Maybe something similar would do what you wish.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
