Re: lilo removal in squeeze (or, "please test grub2")
On Sun, 23 May 2010 16:11:30 -0400 (EDT), William Pitcock wrote: > "Stephen Powell" <zlinux...@wowway.com> wrote: >> (blah blah blah blah) > > Nobody cares if you are opposed to it. Unless you are offering to become > lilo upstream, it's going away. > > William I do understand why a Debian package maintainer does not wish to become "upstream". And I hope that someone who is both willing and able to do so steps up to the plate. But withdrawing it from the distribution seems like overkill to me, especially since you want to withdraw it from Squeeze and not Squeeze+1. Lilo, as it exists today, works just fine for my purposes. And apparently it works just fine for a lot of other people too. The Lord bless you, William. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1170680188.363342.1274662130640.javamail.r...@md01.wow.synacor.com
Re: how to compute predictable network interface names?
On Thu, Feb 23, 2017, at 10:16, Harald Dunkel wrote:
> On 02/16/2017 12:47 PM, Christian Seiler wrote:
> >
> > On a system with predictable names running? Or on a system
> > pre-upgrade?
> >
>
> Its more "pre-installation". I boot a USB stick and run
> my own installer (using debootstrap or creating a clone).
> The NIC name is needed to setup /etc/network/interfaces.
> I know how the interfaces are named using the old scheme,
> but the predictable names are hard to guess.
>
Debian used to assign network devices based on MAC address.
If you want to continue doing something like that, use the
kernel boot parameter
net.ifnames=0
and create your own udev rule. For example:
/etc/udev/rules.d/76-netnames.rules:
# Create custom network interface names based on MAC address.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:11:25:86:61:87",
NAME="net0"
This rule will assign the Ethernet adapter with MAC address 00:11:25:86:61:87
the interface name net0. Reference the interface by this name in
/etc/network/interfaces.
I hope this helps.
--
.''`. Stephen Powell<zlinux...@fastmail.com>
: :' :
`. `'`
`-
Re: Don't taint kernel when using the forcepae kernel boot parameter
On Sat, Feb 18, 2017, at 13:36, Nicholas Geovanis wrote: > > Wow. This is some of the best Debian doc I've seen. Really thanks. > And z/VM stuff. What's not to like? > > Nick-former-VM/SP-current-Debian-system-administrator-:-)-G Thanks for the compliment. I hope you find at least some of it useful. I have received much benefit over the years as a user of open source software. The docs are my attempt at giving something back. Regards, -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Don't taint kernel when using the forcepae kernel boot parameter
For those of you who have an old laptop/notebook with a Banias-class Pentium M or Celeron M 32-bit Intel processor, use the forcepae option, and run a custom kernel (admitedly a limited audience), I have just developed a patch which you may find useful. By default, the kernel will taint itself (for the reason "CPU out of spec") when the forcepae kernel boot parameter is used. I disagree with this course of action. First of all, the CPU is not really out of spec. The CPU has all the capabilities that the kernel requires of it. It just fails to report one of them. Second, there is no binary-only blob mixed in with the source code. It makes sense to disable lock debugging when all the source code is not available, but there is no missing source code in this case. My patch leaves the kernel untainted: wget http://www.stevesdebianstuff.org/dont_taint_forcepae.patch For more information about building a custom kernel, see http://www.stevesdebianstuff.org/Kernel.htm -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Last spam: Let me know Munich Mayor's email address, please..
On Fri, Feb 17, 2017, at 04:30, Andre Müller wrote: > > The day comes closer, that we remove all politicians and do our own > constitution. > This is the only way to change the whole system. I'm sick of it and many > people in whole > Europe also. And as for the United States, do we not have the best Congress money can buy? -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
A new HOWTO page for the Adobe Flash Player plugin under chromium under Linux
It seems to me that there is much confusion out there for how to install the Adobe Flash Player plugin for chromium for Linux. Since fools rush in where angels fear to tread, I have created a new web page on my web site for how to do this. I'd appreciate any comments, positive and negative. I'd like to make the page as good as I can. Here's the link: http://www.stevesdebianstuff.org/flash.htm Let me know what you think. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#854840: sl-modem-dkms FTBFS at kernel version 4.9
I just tried building a custom kernel using "make deb-pkg" instead of kernel-package (make-kpkg), but results are the same. So this is not a bug in kernel-package. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#854840: sl-modem-dkms FTBFS at kernel version 4.9
Here is more information about the nature of the build failure. root@smp1:~# apt-get --reinstall install sl-modem-dkms Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 3 not upgraded. Need to get 0 B/205 kB of archives. After this operation, 0 B of additional disk space will be used. (Reading database ... 176139 files and directories currently installed.) Preparing to unpack .../sl-modem-dkms_2.9.11~20110321-12_i386.deb ... -- Deleting module version: 2.9.11~20110321 completely from the DKMS tree. -- Done. Unpacking sl-modem-dkms (2.9.11~20110321-12) over (2.9.11~20110321-12) ... Setting up sl-modem-dkms (2.9.11~20110321-12) ... Loading new sl-modem-2.9.11~20110321 DKMS files... Building for 4.9.2-1custom01-686-pae Building initial module for 4.9.2-1custom01-686-pae Error! Build of slusb.ko failed for: 4.9.2-1custom01-686-pae (i686) Consult the make.log in the build directory /var/lib/dkms/sl-modem/2.9.11~20110321/build/ for more information. DKMS make.log for sl-modem-2.9.11~20110321 for kernel 4.9.2-1custom01-686-pae (i686) Fri Feb 10 19:07:40 EST 2017 make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers' doing %.o: %.c cc -Wall -pipe -O3 -fomit-frame-pointer -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB `test -f /lib/modules/4.9.2-1custom01-686-pae/build/include/linux/modversions.h && echo -DMODVERSIONS --include /lib/modules/4.9.2-1custom01-686-pae/build/include/linux/modversions.h -I/lib/modules/4.9.2-1custom01-686-pae/build/include` -I. -I./../modem -o amrmo_init.o -c amrmo_init.c amrmo_init.c:57:26: fatal error: linux/module.h: No such file or directory #include ^ compilation terminated. Makefile:128: recipe for target 'amrmo_init.o' failed make: *** [amrmo_init.o] Error 1 make: Leaving directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers' make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem' make modules -C /lib/modules/4.9.2-1custom01-686-pae/build SUBDIRS=/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem make[1]: Entering directory '/usr/src/linux-source-4.9' -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#854840: sl-modem-dkms FTBFS at kernel version 4.9
Package: sl-modem-dkms Version: 2.9.11~20110321-12 Severity: normal sl-modem-dkms fails to build from source with a custom kernel at version 4.9. The build procedure followed is documented at http://www.stevesdebianstuff.org/Kernel.htm#Example2, except that the kernel source package used is linux-source-4.9 instead of linux-source-3.16. Also, linux-kbuild-4.9 is manually installed instead of linux-kbuild-3.16. Other changes to the procedure are made based on package versions, of course. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Recreating a second boot kernel in LILO
On Wed, Jan 18, 2017, at 20:49, Stephen Powell wrote: > > ... > The first two "image" entries define the standard "most recent" and > "next-most recent" kernels and don't need to be messed with, provided > that the standard symbolic link names are being maintained by > "do_symlinks = yes" in /etc/kernel-img.conf or by installation of the > xy-symlinks kernel hook scripts. > ... :1,$s/xy-symlinks/zy-symlinks/ -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Recreating a second boot kernel in LILO
On Wed, Jan 18, 2017, at 20:49, Stephen Powell wrote: > ... > One such program, memtest86+, provides a stand-alone memory testing > program built to resemble a Linux kernel, so that Linuxboot loaders > think it is a Linux kernel and will load it like one (the entire boot image is > loaded, not just a single sector, as with "other"). > ... :1,$s/Linuxboot/Linux boot/ -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Recreating a second boot kernel in LILO
On Sat, Jan 14, 2017, at 11:38, Stephen Powell wrote: > > If there are special kernels that you want to be able to boot which are > outside > the normal "last two", then you must manually edit /etc/lilo.conf to provide > the capability to boot this kernel, then run lilo. > As an example, here is a copy of my /etc/lilo.conf for one of my machines which uses non-parity memory. Non-parity memory is cheaper, but memory errors cannot be directly detected. However, there are programs one can run if one suspects that he/she has a bad memory stick. One such program, memtest86+, provides a stand-alone memory testing program built to resemble a Linux kernel, so that Linuxboot loaders think it is a Linux kernel and will load it like one (the entire boot image is loaded, not just a single sector, as with "other"). # /etc/lilo.conf # # global options # #boot=/dev/sda1 boot=/dev/disk/by-uuid/e15c-a23a-4f1e-bb6b-8ca0b512cff2 compact default=Linux delay=40 # # This allows lilo to correctly handle the USB-attached floppy drive. # It is used in conjunction with a user-created udev rule which # creates a symbolic link between /dev/fd0 and the actual device name # for the USB-attached floppy drive in the current boot. # #disk=/dev/sdb disk=/dev/fd0 bios=0x00 # # This is the disk geometry reported by BIOS Int 13h Function 08h # for the hard disk. Specifying it here allows the "geometric" # option to work. However, we are not using the "geometric" option. # The disk geometry reported by BIOS Int 13h Function 08h is # reported here for reference purposes only. # #disk=/dev/sda disk=/dev/disk/by-id/ata-Samsung_SSD_840_EVO_120GB_S1D5NSBDB61675Y sectors=63 heads=240 cylinders=1024 # install=text large-memory # # The BIOS supports EDD, but linear is used instead of lba32 in order # to get maximum benefit out of the compact option: 128 sectors # per BIOS call. # linear map=/boot/map # # per-image options # image=/boot/vmlinuz label=Linux initrd=/boot/initrd.img append="net.ifnames=0" read-only #root=/dev/sda6 root="UUID=1af2bc58-83f7-44f8-af32-94d1dd54701e" vga=normal # image=/boot/vmlinuz.old label=LinuxOLD initrd=/boot/initrd.img.old append="net.ifnames=0" read-only #root=/dev/sda6 root="UUID=1af2bc58-83f7-44f8-af32-94d1dd54701e" vga=normal optional # image=/boot/memtest86+.bin label=memtest86+ The first two "image" entries define the standard "most recent" and "next-most recent" kernels and don't need to be messed with, provided that the standard symbolic link names are being maintained by "do_symlinks = yes" in /etc/kernel-img.conf or by installation of the xy-symlinks kernel hook scripts. The third "image" entry defines the stand-alone memtest86+ program. To run it, the user types "memtest86+" (without the quotes) at a LILO "boot:" prompt. This boot entry may be thought of as a special Linux kernel which is outside the normal cycle of "most recent" and "next-most recent". -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Recreating a second boot kernel in LILO
On Sat, Jan 14, 2017, at 10:05, Richard Owlett wrote: > On 1/14/2017 8:45 AM, Miroslav Skoric wrote: > > Hello all, > > > > Intro: I have been using LILO for ages. Now running Wheezy 7.11 > > LTS. As usual and for test purposes on older machines I have two > > kernel flavours: 486 and 686-rt. In LILO boot menu they appear as > > Linux486 and Linux686 (before renaming they were Linux and > > LinuxOLD). Both work nice on two desktops of different age. > > > > Anyway, few years ago I had a repetitive problem with the 686-rt > > kernel slowing down the touch pad on a laptop, so I decided to > > remove it completely. So in the LILO menu was left just one boot > > option. Recently I decided to install 686-rt again, and during > > the installation it added new config*, init.rd*, and vmlinuz* > > into /boot, but it did not add any new init.rd* and vmlinuz* > > links into /. And without that LILO still keeps one entry. Any > > idea how to produce new links in / in order to recreate the > > second boot entry? (In lilo.conf everything is the same as in > > desktops, however /sbin/lilo complains about missing links in /) > > > > M.S. > > You may find Steve Powell's LILO Page useful - > http://www.stevesdebianstuff.org/lilo.htm > Also http://www.stevesdebianstuff.org/index.htm may be of interest. > HTH > > The default installation of lilo assumes that the user is only interested in booting the two most recently-installed kernels. By Debian convention, symbolic links are assigned to these kernels in / if "do_symlinks = yes" is specified in /etc/kernel-img.conf. The most recent kernel is assigned the symbolic link name "vmlinuz", and the next-most-recent kernel is assigned the symbolic link name "vmlinuz.old". The same pattern is followed with the initial RAM file system images that correspond to these kernel images. The most recent initial RAM file system image is given the symbolic link name "initrd.img", and the next-most-recent initial RAM file system image is given the symbolic link name "initrd.img.old". If "link_in_boot = yes" is present in /etc/kernel-img.conf, then these symbolic links are maintained in /boot instead of in /. However, these symbolic links are maintained only for stock Debian kernels. For custom kernels created with make-kpkg or "make deb-pkg", "do_symlinks = yes" in /etc/kernel-img.conf has no effect. In my web page, referred to above by Richard Owlett, I provide a reference to my kernel building web page where there are execs called zy-symlinks which will provide equivalent function for custom kernels. If there are special kernels that you want to be able to boot which are outside the normal "last two", then you must manually edit /etc/lilo.conf to provide the capability to boot this kernel, then run lilo. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
[Pkg-xfce-devel] Bug#837895: [SOLVED] lightdm-gtk-greeter: GUI does not run, black screen, on startup
As of the last update of stretch, which I did just a few minutes ago, this problem has been solved. I suspect that the problem was gtk-related, as the problems I was having with web (i.e. epiphany-browser) have been fixed too. However, since I am only subscribed to this bug report, and did not open it myself, I will leave closure to the OP or to the package maintainer. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `- ___ Pkg-xfce-devel mailing list Pkg-xfce-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xfce-devel
Bug#837895: [SOLVED] lightdm-gtk-greeter: GUI does not run, black screen, on startup
As of the last update of stretch, which I did just a few minutes ago, this problem has been solved. I suspect that the problem was gtk-related, as the problems I was having with web (i.e. epiphany-browser) have been fixed too. However, since I am only subscribed to this bug report, and did not open it myself, I will leave closure to the OP or to the package maintainer. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#837895: lightdm-gtk-greeter: GUI does not run, black screen, on startup
ile you wish to see? -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
[Pkg-xfce-devel] Bug#837895: lightdm-gtk-greeter: GUI does not run, black screen, on startup
ile you wish to see? -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `- ___ Pkg-xfce-devel mailing list Pkg-xfce-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xfce-devel
Re: cant get to desktop anymore
On Wed, Sep 21, 2016, at 16:32, Stephen Powell wrote: > > I did notice one thing peculiar. startx output is written to the terminal > of vt1, of course, even though it's running as a background task. And I got > the error message > > modprobe: FATAL: Module mach64 not found in directory /lib/modules/xxx > > where xxx is the identity of the running kernel. Strange. The kernel has > never had a mach64 module in it, as far as I know. mach64 is the name > of the X driver, but there is no kernel module by that name. One other thing I noticed. It may or may not be related. "web" (i.e. epiphany-browser) is broken. When I click on the icon for changing settings (including listing bookmarks), nothing happens. I switched back to chromium, which seems to be working fine. Lovely "upgrade", Debian! -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: cant get to desktop anymore
On Sun, Sep 18, 2016, at 19:57, Ric Moore wrote: > On 09/18/2016 06:00 PM, Kent West wrote: > > On Sun, Sep 18, 2016 at 3:28 PM, bell canada <bellcanada...@gmail.com > > <mailto:bellcanada...@gmail.com>> wrote: > > > > hello i installed debian 8 and i cant get into my desktop..why plz help > > > > roberto > > 438 881 9269 <tel:438%20881%209269> > > all i get is ablack scren > > even recory mode doesnt help > > > > > > Do you get to a login prompt at all (graphical or text-based)? > > > > What happens if you press Ctrl-Alt-F2? > If the OP would do that, login as his user and enter "startx", I bet a > donut that he gets to his desktop. Mine is STILL boroken that way > ...POS. synaptic isn't fixed yet. Someone just shoot me. Ric > After a recent stretch upgrade, I experienced a similar problem. I use the XFCE4 desktop environment, the lightdm login daemon, and systemd as my init system. After "upgrading" and rebooting, I got a black screen with a mouse pointer. And that was it. I used the following procedure as a work-around: I used Ctrl+Alt+F1 to switch to a text console. I logged in as root. I issued systemctl stop lightdm.service systemctl disable lightdm.service then I exited the root login session, logged in on the text console as my normal non-superuser self, and issued startx -- vt7 & This brought up my normal XFCE4 desktop on vt7, bypassing the lightdm login daemon. Of course after a reboot, the two systemctl commands won't be needed. The lightdm service will no longer start. I did notice one thing peculiar. startx output is written to the terminal of vt1, of course, even though it's running as a background task. And I got the error message modprobe: FATAL: Module mach64 not found in directory /lib/modules/xxx where xxx is the identity of the running kernel. Strange. The kernel has never had a mach64 module in it, as far as I know. mach64 is the name of the X driver, but there is no kernel module by that name. I obviously don't like using this work-around, but I can at least limp along until somebody somewhere fixes this problem. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Debian Jessie : regular console instead of a hi-res one!
On Mon, Sep 5, 2016, at 12:46, Stephen Powell wrote: > > To determine which module to blacklist, issue > >dmesg|less > > and see if you can figure out which module is loading. You can also issue > >lsmod|less > > to see which modules are loaded. Perhaps you can identify which module is > the frame buffer driver this way. Knowing your video chipset helps give you > a clue also. Issue > >lspci|less > > and look for VGA. This may give you a clue as to the identity of the frame > buffer driver. > I found a better way to identify the frame buffer driver. Issue lspci -k|less then search for the character string VGA. You should see something like this: 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000] Subsystem: Gigabyte Technology Co., Ltd RS780L [Radeon 3000] Kernel driver in use: radeon Kernel modules: radeon This clearly identifies the frame buffer driver. I realize that the OP has chosen a different solution. But for the sake of others who may find this thread in a future search who wish to go the hardware text mode route, I have added this information. The "vga" option of LILO (also usable with GRUB2 if you use linux16 and initrd16 instead of linux and initrd in the menuentry bloc) provides more choices than the hardware default of 80x25. For more information about this, see my LILO web page at http://www.stevesdebianstuff.org/lilo.htm#VGA -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Debian Jessie : regular console instead of a hi-res one!
On Mon, Sep 5, 2016, at 12:01, Mayuresh Kathe wrote: > > Is there any way to get a regular console under Debian Jessie? > I don't use a GUI, just plain old CLI, and working on hi-res with "tiny" > little fonts is extremely painful. > I have tried playing with "console-setup". No results. > Yes. What you are seeing is a "frame buffer" console. In most cases, the X driver requires this. But if you are not using an X server, you can disable it. The trick is to blacklist the right driver. For example, if you have a radeon chipset, blacklisting the radeon driver might accomplish this. Create a file such as /etc/modprobe.d/local.conf. Put a line in it which says blacklist radeon Save the file and exit the editor. Whenever you blacklist a module, it is a good idea to rebuild your initial RAM file system, although if the module is not loaded until after the permanent root file system is mounted read-only, this is not strictly required. To do this, issue update-initramfs -u -k $(uname -r) Then shutdown and reboot. To determine which module to blacklist, issue dmesg|less and see if you can figure out which module is loading. You can also issue lsmod|less to see which modules are loaded. Perhaps you can identify which module is the frame buffer driver this way. Knowing your video chipset helps give you a clue also. Issue lspci|less and look for VGA. This may give you a clue as to the identity of the frame buffer driver. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
i2o drivers not needed after all!
On Wed, 01 Jul 2015 19:05:57 +0100, Ben Hutchings wrote: > > Please note that i2o will be going away entirely (disabled in 4.0, > removed upstream in 4.2). (The above quote is from Debian bug report 790722, now archived.) And so it did. I was able to build custom kernels which included these drivers by enabling them in staging for 4.0 and 4.1. For 4.2 and later, I created a patch file that added these drivers back. But recently, while researching something else, I happened to stumble upon something on the internet which suggested that the dpt_i2o driver, which is still in the kernel, might work in my situation, since I have an Adaptec i2o raid controller. I reviewed the boot logs and discovered that this driver tried to load, but it failed to initialize because it was unable to reserve some memory. I wondered if it was trying to obtain resources already reserved by i2o_core. So I blacklisted i2o_core. dpt_i2o came right up! It creates the device as /dev/sda instead of /dev/i2o/hda, but that's fine. As another happy coincidence, I no longer need local mods to udev to get the symbolic links to the disk created in /dev/disk. (udev has dropped support for the /dev/i2o/hd* devices). Of course, with unmodified newer kernels, I won't need to blacklist i2o_core, since it no longer exists. The problem was that i2o_core always loaded first, and therefore the load of dpt_i2o always failed. Therefore, I thought I needed i2o_core. But as it turns out, I don't. dpt_i2o is working just fine for me. All's well that ends well! Regards, -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Downloading and naming
On Tue, Aug 2, 2016, at 18:33, Pascal Hambourg wrote: > Le 02/08/2016 à 02:28, Stephen Powell a écrit : >> My original point remains. If one's computer has less than 4 GiB of >> memory installed, and the processor does not support the XD/NX bit, then >> running a 32-bit PAE-enabled kernel does not benefit one at all. > > Your original point did not mention the NX/XD bit. True. I *assumed* that the processor did not support the NX/XD bit. That assumption should have been explicitly stated. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Downloading and naming
On Mon, Aug 1, 2016, at 19:30, Pascal Hambourg wrote: > Le 01/08/2016 à 04:02, Stephen Powell a écrit : >> >> To the best of my knowledge, there are no 32-bit-only processors which >> support the NX bit. A 32-bit PAE-enabled kernel can only use NX if it >> is running on a 64-bit-capable processor. > > You should check your information. A number of late 32-bit Pentium 4 and > Pentium M models support the NX bit. > Perhaps there are some 32-bit-only processors which support XD/NX. But none of mine do. >> >> To give a specific example, my IBM ThinkPad X31 has >> a Pentium M processor, which is PAE capable and 32 bit only (...) >> And the PAE kernel >> can't exploit the NX bit, because the processor doesn't support it. > > This is really surprising because, according to > <https://en.wikipedia.org/wiki/Pentium_M>, Pentium M models which > support PAE also support the NX bit. Actually, PAE support was added > just to support the NX bit, the physical address size is still 32 bits. > You should check your information. :-) That same Wikipedia article that you quoted above also says this: "The Banias family processors internally support PAE but do not show the PAE support flag in their CPUID information ..." All Pentium M processors support PAE, they just don't all advertise such support in the output of the CPUID instruction. My IBM ThinkPad X31 has a Banias-class Pentium M processor. I can get a PAE-enabled kernel to run on it, but I must use the "forcepae" kernel boot parameter in order to get it to work. My original point remains. If one's computer has less than 4 GiB of memory installed, and the processor does not support the XD/NX bit, then running a 32-bit PAE-enabled kernel does not benefit one at all. In fact, it actually hurts one, because a PAE-enabled kernel uses more memory. Debian is one of the few distributions to still provide non-PAE kernels. And I applaud them for doing so for just such situations as I described above. Just because one's processor supports PAE doesn't necessarily mean that one benefits from using a PAE kernel. In addition to my IBM ThinkPad X31, I have two other 32-bit-only machines. One uses a Pentium 4 processor, the other uses a Xeon. None of them support the NX bit. And none of them have more than 4 GiB of memory installed. (Only the ThinkPad requires the "forcepae" kernel boot parameter to get a PAE-enabled kernel to run.) -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Downloading and naming
On Sun, Jul 31, 2016, at 19:07, Pascal Hambourg wrote: > Le 01/08/2016 à 00:00, Stephen Powell a écrit : >> one's processor supports PAE, but the motherboard only supports a maximum of >> 2 GiB of RAM, what does a PAE kernel buy one? Nothing, as far as I can see. > > PAE allows to use the NX/XD bit on CPU which support it to prevent > execution of data memory areas. To the best of my knowledge, there are no 32-bit-only processors which support the NX bit. A 32-bit PAE-enabled kernel can only use NX if it is running on a 64-bit-capable processor. I should have explicitly stated what was an implicit assumption, namely, that the processor is not 64-bit capable. To give a specific example, my IBM ThinkPad X31 has a Pentium M processor, which is PAE capable and 32 bit only, and the motherboard only supports a maximum of 2 GiB of RAM. I *can* run a PAE-enabled kernel on it, but a PAE-enabled kernel uses more memory. PAE allows more than 4 GiB of memory to be accessed, but I don't have that much. And the PAE kernel can't exploit the NX bit, because the processor doesn't support it. A PAE-enabled kernel actually *hurts* me in this case. I'm better off running a non-PAE kernel, even though the processor supports PAE. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Downloading and naming
On Sun, Jul 31, 2016, at 03:46, Brian Wengel wrote: > > Dear Debian community > > Maybe it’s just me, but as a rather new-comer to the Debian world a few > things puzzles me. > > 1: Going to the download section is like being taken 15 years back. Isn’t > it time to take the step to move away from the CD/DVD media and move into > the USB Flash drive arena? > ... I'll stop quoting there, because the rest of your post has the same general tone. Debian is not a bleeding-edge distribution. Many of us use old hardware, hardware that has been abandoned by Windows long ago, hardware that in many cases has even been abandoned by other Linux Distributions. For example, Debian is one of the few Linux distributions, maybe the only Linux distribution, to still provide non-PAE kernels. Ubuntu has been providing only PAE stock kernels for some time now. Even if the hardware supports PAE, some of us prefer to run a non-PAE kernel because it uses less memory. If one's processor supports PAE, but the motherboard only supports a maximum of 2 GiB of RAM, what does a PAE kernel buy one? Nothing, as far as I can see. But some distributions have a one-size-fits-all slam it, jam it, cram it, attitude, an attitude based solely on minimizing their support costs, rather than on trying to provide what's best for as many users as possible. We like to think of ourselves as "The Universal Operating System". It's not truly universal, but it's close. A quick check of the ports page shows that we support about 10 official ports and about 20 unofficial ports. How many hardware platforms does Ubuntu support? If you like Ubuntu better than Debian, fine. Use Ubuntu. Nobody's stopping you. But don't come over here and try to tell us that we should be doing things the way Ubuntu does. We're different for a reason. I'm not saying there isn't room for improvement: I'm sure there is. But asking questions is one thing. Telling us we should be like Ubuntu is another. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Terminal
On Fri, Jul 29, 2016, at 19:25, Doug wrote: > > I have found Linux in a Nutshell, 6th edition, extremely useful. > ... I'd also like to recommend "The Linux Cookbook: Tips and Techniques for Everyday Use", 2nd Edition, by Michael Stutz. This is a hard-copy book, and to the best of my knowledge is not available online. The first edition of the book is available online here: http://www.dsl.org/cookbook/cookbook_toc.html The first edition is getting dated, but there is still a lot of useful information in it. Rather than being organized as a list of commands and parameters, it is organized in a task-oriented fashion. (Oh, you want to do *that*! Here, type this ...) -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: What Linux distribution to use?
On Wed, Jul 27, 2016, at 14:29, Brian wrote: > > ... > for one machine, probably ancient but still doing a useful > job, I have > > model name : Geode(TM) Integrated Processor by AMD PCS > > That's not enough, is it? What has to done to determine its processor > class? > > I'm happy enough keeping it on Jessie but, for obvious reasons, don't > want to attempt a disastrous Stretch upgrade. Sven has already replied to the general case; but I thought I'd mention your specific example, since it is a particularly interesting case. As I understand it, the AMD Geode processor is one instruction short of the full Pentium Pro instruction set: NOPL. But it appears that the GCC compiler has been modified to not generate NOPL instructions when "-march i686" is used. Therefore, the AMD Geode should qualify. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: What Linux distribution to use?
On Tue, Jul 26, 2016, at 19:05, David Wright wrote: > > One issue though: I have a useful laptop that has a nifty 686 (AIUI) > Pentium M processor, but I have to run linux-image-3.16.0-4-586 on it > because it lacks the PAE. (It has SSE/SSE2.) Do you know whether > stretch will cater for non-PAE processors? Or is this no more than > a kernel issue which doesn't involve package builds, as appears to > be the case in jessie? You have a Banias-class Pentium M. All Pentium Ms support PAE. But due to a microcode bug, the Banias-class Pentium Ms do not report their PAE capability in the output of the CPUID instruction. A *-686-pae kernel will run just fine on a Banias-class Pentium M, but you must supply the "forcepae" kernel boot parameter to get it to work. I have such a machine myself, so I know from experience. Note that stretch supports both *-686 and *-686-pae kernels. You don't necessarily *need* to run a PAE kernel. Some prefer to run a non-PAE kernel because it's easier on the memory requirements. But the processor must support the Pentium Pro instruction set, which all Pentium Ms do. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: does anybody remember which debian release was it that asked for the MAC ID details at the end ?
On Mon, Jul 18, 2016, at 18:08, shirish शिरीष wrote: > Hi all, > > Does anybody remember which release of Debian was it that had the bug > where d-i used to ask for MAC ID details during the end phase > (networking phase) to the user and if s/he didn't know the MAC ID > details the installation couldn't move further (unless one knew some > tricks). > > I know for a fact that it was fixed in squeeze but it was in one of > the releases before. From the Wikipedia page it becomes clear that d-i > was introduced in Sarge in June 2005 so it has to be between 2005 and > 2011. > > https://en.wikipedia.org/wiki/List_of_Debian_releases#Debian_3.1_.28Sarge.29 > > Does anybody know which release had that bug ? > > I am in midst of making a presentation hence need that historical > information for accuracy. > > Look forward to know. I think I have used all Debian releases between Sarge and Stretch, and I don't remember any such bug. Then again, I didn't necessarily *install* all those releases. There may have been some releases where I only did an upgrade. Furthermore, I usually only use a stable installer. A bug in the testing release of the installer that was fixed before it became the stable installer is not likely one that I would have encountered. Sorry I can't be more helpful. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
LXDE - how to set default image viewer?
On Sat, 16 Jul 2016 13:41:01 +, "Markos" wrote: > Hi, > > I'm using Lxde with Debian Jessie. > > I installed Wine and now whenever I try to open an image (png, gif etc.) > the system use Internet Explorer with Wine to open the image. > > How to reconfigure LXDE to use eog or gpicview as default image viewer? > > Thanks, > Markos Have you tried searching the Internet? I typed file extension associations lxde in my browser's search engine and got results that look promising. I don't use lxde myself, so I can't verify if it works. P.S. I apologize for the broken thread. My e-mail client does not appear to provide a way to set the "In-reply-to" header, and I've already deleted your original e-mail. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: reasons to ditch LILO before upgrading to jessie?
On Sun, Jul 10, 2016, at 03:31, Pascal Hambourg wrote: > > AFAICS, elilo is not available any more in stretch and sid. > I'm sorry to hear that. I don't have any UEFI-based systems right now, so it's not an issue for me -- yet. But it may be someday. On the other hand, CSM-less UEFI systems may fail in the marketplace. There have been attempts in the past to eliminate 16-bit support which failed. We'll just have to wait and see. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: reasons to ditch LILO before upgrading to jessie?
On Sat, Jul 9, 2016, at 18:25, Brian wrote: > On Sat 09 Jul 2016 at 16:41:24 -0400, Stephen Powell wrote: >> >> Long live choice! > > For choice to exist it does not have to be presented as such in the > installer. > Your point is well taken. The installer does not offer choice in everything, just the big things. A choice of desktop, for example. However, even desktop choice is not presented in the installation steps. It's hidden in installer options. For example, I generally install with expert desktop=xfce and then, if I select "Desktop Environment" in tasksel, I get an xfce desktop instead of a gnome3 desktop. Perhaps the boot loader choice could be handled in a similar fashion. Something like expert desktop=xfce bootloader=lilo with the defaults being gnome3 and grub2, respectively. (Dare I suggest adding initsystem=sysvinit as an option too? No, I better not. I don't want to get that flame war going again.) Peace. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: reasons to ditch LILO before upgrading to jessie?
On Sat, Jul 9, 2016, at 16:33, Felix Miata wrote: > > All that's well and good, but I see nothing there that equates to my > understanding of the meaning of "editing", which includes removal as well as > appending. Oh, I see what you're saying. Well, the Linux kernel generally does it's own overriding. For example, if the kernel command line contains conflicting options, such as "ro" and "rw", the last one supplied takes precedence. There are some exceptions. For example, if the "console" parameter is specified twice, both consoles are used. But, strictly speaking, you're right. LILO appends options supplied on the command line to options specified in the "append" configuration file statement, it does not replace them. > > What I'd like to find which I've had no luck with so far, is finding a Debian > installer cmdline option to skip the waste of time that is installation of > any bootloader. My disks get generic MBR code and Grub installed by me before > any OS gets installed. Thus, I have no need to see warnings about blocklists > and unreliability from installers trying to do what I don't want or need done If you do the installation in expert mode, you can skip the step to install a boot loader. But that's in interactive mode. I've never done an automated installation, so I don't know what can and cannot be done in that environment. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: reasons to ditch LILO before upgrading to jessie?
On Sat, Jul 9, 2016, at 16:00, Brian wrote: > > All well and good but the installer inexplicably offers a choice between > GRUB and LILO. The installer manual is unhelpful on which to choose. A > newcomer wouldn't have a clue. We do them no service with this retrograde > offering. Get rid of it. > > What is the point of a choice? Just offer GRUB; it is the bootloader for > Debian and has many advantages over LILO in todayss Linux ecosystem. > People who have a great desire to use LILO can search it out. > > Unmaintained in Debian, The bit-rot starts here. > I am not a member of the Debian installer team, and I am not authorized to speak for them. However, I will make the observation that LILO used to be the default boot loader, indeed the only boot loader at one point, in the Debian installer for i386/amd64. I suspect that LILO has been retained as an option in the Debian installer for that reason. The lilo package is maintained in Debian. It's maintainer is Joachim Wiedorn. He is also the upstream maintainer. He has ceased active development of lilo, but I believe he still accepts bug reports. And if he wants rid of it, I know a couple of people who are interested in taking it over, myself included. So I'm not concerned about it's maintenance status. As long as there are PCs with a BIOS, or a CSM, lilo will remain usable. If the BIOS/CSM goes, lilo goes with it. lilo can't function without a BIOS/CSM. But for UEFI-only systems, there's elilo as a grub alternative. Long live choice! -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: reasons to ditch LILO before upgrading to jessie?
On Sat, Jul 9, 2016, at 10:53, Felix Miata wrote:
> Stephen Powell composed on 2016-07-09 08:58 (UTC-0400):
>
>> As for features, LILO has all the features that I need.
>
> One feature it never acquired AFAIK, which Grub shares with Syslinux, is the
> ability to edit the kernel cmdline at boot time, before kernel load. With
> problematic hardware, problematic BIOS, and pre-release kernel and distro
> versions, that ability is a big troubleshooting convenience. It's one of the
> features that facilitated my decision to migrate from OS/2 to Linux as
> primary OS.
Not true. I use the traditional text-mode interface of LILO (install=text).
To supply kernel options during boot, press the Shift key (by itself) before
the "delay" timer expires to get a boot prompt ("boot:"). Then type the
label of the kernel you want followed by the desired boot parameters.
For example,
Linux single
to boot the kernel in single-user mode. Or
Linux forcepae
to get a PAE-requiring kernel to boot on a Banias-class Pentium M or
Celeron M processor, if you forgot to specify
append="forcepae"
in /etc/lilo.conf before running lilo. If you can't remember the names of
your kernel labels, press the Tab key at a "boot:" prompt. LILO will
display the names of your kernel labels followed by another "boot:" prompt.
I've never used the menu-based interface of LILO, but I'm sure that there
is a way to supply kernel options at boot time with the menu-based interface
as well.
See my LILO web page at
http://www.stevesdebianstuff.org/lilo.htm
for more information.
P.S. I used to use OS/2 as well. But I switched because OS/2, after Warp 4,
was more or less abandoned by IBM. Besides, Linux is free. If I had known
about Linux back then, I would probably have gone straight from DOS to Linux.
--
.''`. Stephen Powell<zlinux...@fastmail.com>
: :' :
`. `'`
`-
Re: reasons to ditch LILO before upgrading to jessie?
On Thu, Jul 7, 2016, at 20:53, Felix Miata wrote: > Stephen Powell composed on 2016-07-07 20:30 (UTC-0400): > > > If your system has a BIOS and a traditional DOS-style partition table, > > there's no reason not to use LILO, unless you just don't want to. > > Or, if you like to be able to boot without hunting down rescue media even > though you forgot to "rerun" some configuration utility after a kernel > upgrade. Once you understand how Grub's shell works, which includes command > history and tab completion much the same as *ash, it is simple (maybe not so > much in Grub2, which I don't use, as in Grub, which accounts for about 97% of > my bootloader installations). Grub's shell has built-in help. With Grub, > there's no reason to be scared when an expected boot menu doesn't show up. > ... I've been using LILO for about 16 years, and I've never had to use rescue media because I forgot to run lilo. Modern Debian systems make sure that lilo gets run when it needs to be run. As for features, LILO has all the features that I need. Chiefly, it has the feature of being able to load the Linux kernel into storage (and it's initial RAM file system image) and transfer control to it. It does one thing, and it does that one thing very well: it loads the Linux kernel. I believe in the KISS philosophy (Keep It Simple, Stupid). If you're happy with grub-legacy, great. I'm happy for you. Keep using it. I'm happy with LILO, and I intend to keep using it. And apparently, the OP is happy with LILO too; and there's no reason, at least at this point, why *he* shouldn't keep using it. Inside every large program is a small program struggling to get out -- Hoare's law of large programs. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: reasons to ditch LILO before upgrading to jessie?
On Thu, Jul 7, 2016, at 10:57, Giovanni Gigante wrote: > > At the end, I decided to try the upgrade to jessie with LiLo (24.1) in > place. I thought that the probability of hitting some bug caused by the > interaction between LiLo and the upgraded distribution was less than the > probabily of causing some damage by switching the bootloader (for > example, by messing up the RAID configuration) since I've never > configured Grub before. Also, the golden heuristic of "if it ain't > broke, don't fix it", and the fact that this particular Debian upgrade > is also switching from the init scripts to systemd, so I did not want to > introduce even more changes in the boot process for the moment. > > Apparently, it worked. > I never doubted that it would. I still use LILO with the latest jessie kernels. I maintain a web page for Debian users who use LILO, or who are thinking of switching from GRUB to LILO: http://www.stevesdebianstuff.org/lilo.htm I don't address the issue of software RAID though. I've never tried it. I have used LILO with hardware RAID. It works just fine. I'm using it right now as I write this. As far as LILO being unmaintained is concerned, I wouldn't be too concerned about that. I've been thinking about offering to maintain it myself. I haven't heard from Joachim lately. Maybe I'll drop him another line. The three main things I like about LILO are (1) I understand how it works, (2) it is easy to configure, and (3) it doesn't use any unallocated sectors. The main limitations to LILO's future viability, as I see it, are UEFI and GPT. LILO is heavily dependent on the traditional BIOS. Most UEFI systems have a CSM to provide a BIOS for forward compatibility, though it is often disabled by default. But some of the newest systems are starting to ship with no CSM. I won't buy one of those as long as I have a choice. And GPT is needed to break the 2 TiB disk size limit. But none of my disks are anywhere near that big. If your system has a BIOS and a traditional DOS-style partition table, there's no reason not to use LILO, unless you just don't want to. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Upgrading the minimum required s390x CPU to z10?
On Wed, Jun 1, 2016, at 11:39, R P Herrold wrote: > > IBM upstream has moved the 'enterprise' distributions to the > even later z196 level about three years ago, via the -march > option. They made no secret of their intention to 'end the > life' of earlier hardware main-line support, even if it was > not well communicated outside of 'enterprise' circles > > One could speculate why, but ... why bother. Chopping off the > legacy tail gets rid of easy conversions and substitution > replacement by Hercules rather than zPDT, and so drives more > of the remaining 'paying customer' pot either off of Z (to > Power, or distributed) Less than a year ago, I reported a problem to IBM regarding a kernel crash on pre-z10 processors, and they produced a fix for it. (See https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/patch/?id=0b991f5cdcd6201e5401f83ca3a672343c3bfc49.) So, for Linux they are still supporting the entire z/Architecture line. Of course, it's no secret that they want their customers to keep buying their newer models every few years. For their own proprietary 64-bit operating systems, such as z/VM, they start cutting off older hardware. We still run z/VM 5.4.0 because it is the last release of z/VM that still supports our z/890. Starting with z/VM 6.1.0, a z10 or newer is required. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: ssh-ing in inside private network
On Tue, May 31, 2016, at 19:25, Lisi Reisz wrote: > ... > Assuming that sshd is actually running at that stage, which it looks as > though > it isn't > ... Looks as though I've given you mostly information that you don't need. Sorry about that. At the risk of doing so again, here's how you can tell if the ssh daemon is running. Issue ps aux|grep ssh You should see something like the following in the output: root 709 0.0 0.0 10200 3632 ?Ss May24 0:00 /usr/sbin/sshd The thing to look for is "/usr/sbin/sshd". If you don't see it, it's not running. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: ssh-ing in inside private network
On Tue, May 31, 2016, at 15:31, Lisi Reisz wrote: > ... > So I need static IPs fast! > ... (The above was actually quoted from an earlier post). If you want to convert your computers to use static IP addresses, you might want to take a look at the following web page: http://www.stevesdebianstuff.org/hercules.htm The main subject of the web page is running Debian under Hercules under Debian, which of course you are not interested in. But in the process of documenting that there is a discussion about converting the host system for Hercules to use a static IP address. Using static IP addresses has some little known "gotchas", which are covered above. See the section titled "Networking changes". It also covers switching from network-manager to ifupdown, but if I recall correctly, you've already made that conversion. You might also want to take a look at the section titled "Router reconfiguration". In your case, you probably don't need or want to reconfigure the router, but you might want to get into the reconfiguration screens so that you can find out for sure which addresses are in the router's DHCP pool, so that you can chose a static IP address which is *inside* the router's network but *outside* the DHCP pool. That way, you can be sure that your static IP address will never interfere with what DHCP wants to do. > > Help!! This was the point of the whole exercise. I want CLI only (no X > running) access to the Ubuntu installation on Hermes. > Ubuntu systems usually do not have a password assigned to root. Therefore, you have to use sudo for all administrative work. If you want to *be* root, so that all commands issued run with root privileges, you have to assign a password to root with sudo passwd root I recommend that you ssh into the machine as a non-root user first, then elevate privileges by running a nested root shell via su After you supply the root password, which you just set earlier, your privileges will be escalated to root privileges until you enter the exit command, which will return you to your former non-root self. It is possible to login remotely as root, if the configuration of the host system's ssh server allows it, but "best practices" recommends against it for security reasons. It makes your home network easier to hack. But if you really want to do it, edit the file /etc/ssh/sshd_config. In the # Authentication section, look for Permitrootlogin no and change it to Permitrootlogin yes then bounce the ssh daemon with /etc/init.d/ssh restart As I said, it's not recommended; but it's your gun, your bullet, and your foot! -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#825141: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel
On Mon, May 23, 2016, at 22:16, Ben Hutchings wrote: > On Mon, 2016-05-23 at 21:06 -0400, Stephen Powell wrote: >> >> The following message is received at boot time when booting the stock Debian >> kernel >> version 4.5.3-2 on the s390x architecture: >> >> dasd_mod: module verification failed: signature and/or required key missing >> - tainting kernel > > This is expected until we sort out support for loading signed modules > in unstable. > I've done a little research on this. I haven't checked other architectures, but the stock s390x kernel for 4.5.3-2 (and today I also tried 4.5.4-1) has CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_ALL is not set This seems to be the problem. From what I've read, If CONFIG_MODULE_SIG=y, but CONFIG_MODULE_SIG_ALL is not set, then the modules need to be manually signed via scripts/sign-file between the "make modules" and "make modules_install" phases of the build process. But automated tools for building debian kernel packages, such as make-kpkg from kernel-package, "make deb-pkg", and I presume the tools you use for building stock kernels as well, do not allow this manual signing step to take place. I have been able to build a successful kernel using make-kpkg with both of the above options not set, as well as with both of them set to y. But the combination of options currently used in the stock kernel is problematic for these tools. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#825141: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel
On Mon, May 23, 2016, at 22:16, Ben Hutchings wrote: > On Mon, 2016-05-23 at 21:06 -0400, Stephen Powell wrote: >> >> The following message is received at boot time when booting the stock Debian >> kernel >> version 4.5.3-2 on the s390x architecture: >> >> dasd_mod: module verification failed: signature and/or required key missing >> - tainting kernel > > This is expected until we sort out support for loading signed modules > in unstable. > I've done a little research on this. I haven't checked other architectures, but the stock s390x kernel for 4.5.3-2 (and today I also tried 4.5.4-1) has CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_ALL is not set This seems to be the problem. From what I've read, If CONFIG_MODULE_SIG=y, but CONFIG_MODULE_SIG_ALL is not set, then the modules need to be manually signed via scripts/sign-file between the "make modules" and "make modules_install" phases of the build process. But automated tools for building debian kernel packages, such as make-kpkg from kernel-package, "make deb-pkg", and I presume the tools you use for building stock kernels as well, do not allow this manual signing step to take place. I have been able to build a successful kernel using make-kpkg with both of the above options not set, as well as with both of them set to y. But the combination of options currently used in the stock kernel is problematic for these tools. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#825141: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel
Package: linux Version: 4.5.3-2 Severity: minor X-Debbugs-CC: debian-s...@lists.debian.org The following message is received at boot time when booting the stock Debian kernel version 4.5.3-2 on the s390x architecture: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel The kernel does boot; but the kernel gets tainted, which disables lock debugging. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#825141: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel
Package: linux Version: 4.5.3-2 Severity: minor X-Debbugs-CC: debian-s390@lists.debian.org The following message is received at boot time when booting the stock Debian kernel version 4.5.3-2 on the s390x architecture: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel The kernel does boot; but the kernel gets tainted, which disables lock debugging. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#825141: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel
Package: linux Version: 4.5.3-2 Severity: minor X-Debbugs-CC: debian-s...@lists.debian.org The following message is received at boot time when booting the stock Debian kernel version 4.5.3-2 on the s390x architecture: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel The kernel does boot; but the kernel gets tainted, which disables lock debugging. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Grub won't install
On Wed, May 18, 2016, at 14:57, Marc Shapiro wrote: > > Lilo definitely still works with current kernels. I started out using > lilo 17 or 18 years ago and I am still using it now under Jessie and > kernel vmlinuz-3.16.0-4-amd64. > I maintain a LILO web page for the benefit of Debian users here: http://www.stevesdebianstuff.org/lilo.htm I use it myself on the latest kernels without difficulty. Many people believe that modern UEFI boards don't have a BIOS for forward compatibility anymore. That may be true in some cases. But in other cases, the use of the "connected standby" feature in UEFI, which is a default setting in many cases, has disabled the Compatibility Support Module (CSM) which provides the BIOS. LILO is not for everyone, but it is still usable in a surprising number of situations. I have a 64-bit machine that is only a couple of years old that uses it. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: What happened to the info tutorial?
On Sat, Apr 16, 2016, at 17:31, Stephen Powell wrote: > The "info" command in jessie has a tutorial which can be accessed by pressing > the "H" key. Oops!, I meant to say the "h" key, not the "H" key. Otherwise, the question remains as written. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
What happened to the info tutorial?
The "info" command in jessie has a tutorial which can be accessed by pressing the "H" key. You must have the texinfo-doc-nonfree package installed for this to work; but if this package is installed, it works. But under stretch, it does not work, even if the texinfo-doc-nonfree package is installed. From the changelogs, it appears that info.info has been removed from the texinfo-doc-nonfree package. Is the tutorial still available in another package? Has upstream deleted the tutorial entirely? Are there any options for those who want to keep the tutorial? What's the scoop on this? -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits
On Tue, Apr 5, 2016, at 20:37, Ben Hutchings wrote:
>
> I'm not applying this until the kernel actually supports device numbers
> that large. Currently it defines (in include/linux/kdev_t.h):
>
> static inline u32 new_encode_dev(dev_t dev) { ... }
> static inline dev_t new_decode_dev(u32 dev) { ... }
>
> static inline u64 huge_encode_dev(dev_t dev)
> {
> return new_encode_dev(dev);
> }
>
> static inline dev_t huge_decode_dev(u64 dev)
> {
> return new_decode_dev(dev);
> }
>
> i.e. anything above bit 31 is zeroed.
>
> Ben.
>
Interesting. I wasn't aware of that. Thank you for calling my attention
to it. Under the circumstances, wishlist is fine.
Regards,
--
.''`. Stephen Powell<zlinux...@fastmail.com>
: :' :
`. `'`
`-
Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits
On Tue, Apr 5, 2016, at 20:37, Ben Hutchings wrote:
>
> I'm not applying this until the kernel actually supports device numbers
> that large. Currently it defines (in include/linux/kdev_t.h):
>
> static inline u32 new_encode_dev(dev_t dev) { ... }
> static inline dev_t new_decode_dev(u32 dev) { ... }
>
> static inline u64 huge_encode_dev(dev_t dev)
> {
> return new_encode_dev(dev);
> }
>
> static inline dev_t huge_decode_dev(u64 dev)
> {
> return new_decode_dev(dev);
> }
>
> i.e. anything above bit 31 is zeroed.
>
> Ben.
>
Interesting. I wasn't aware of that. Thank you for calling my attention
to it. Under the circumstances, wishlist is fine.
Regards,
--
.''`. Stephen Powell<zlinux...@fastmail.com>
: :' :
`. `'`
`-
Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits
Package: initramfs-tools-core
Version: 0.123
Severity: minor
Tags: patch
Congratulations on initramfs-tools version 0.123! Many bugs in version 0.120
have been fixed in this version. However, it appears that the parse_numeric
function, while improved over the 0.120 version, still doesn't handle the
general case of a composite device number. It seems it will only handle 8 hex
digits or less correctly.
I have submitted a patch for your consideration. The patch will accommodate the
general case of a composite device number of up to 16 hex digits (the limit).
It also tightens up some other error checking corner cases.
Respectfully submitted,
--
.''`. Stephen Powell<zlinux...@fastmail.com>
: :' :
`. `'`
`-
--- a/functions 2016-01-21 18:33:59.0 -0500
+++ b/functions 2016-03-24 08:09:11.0 -0400
@@ -128,14 +128,28 @@
# lilo compatibility
parse_numeric() {
- case $1 in
+ case "$1" in
*:*)
# Does it match /[0-9]*:[0-9]*/?
- minor=${1#*:}
- major=${1%:*}
- case $major$minor in
+ minor="${1#*:}" # Everything after the first colon.
+ major="${1%%:*}" # Everything before the first colon.
+ [ X"$major" = X ] && return # major is null.
+ [ X"$minor" = X ] && return # minor is null.
+ case "$major$minor" in
*[!0-9]*)
- # No.
+ # major or minor contains a non-numeric character.
+ return
+ ;;
+ esac
+ case "$major" in
+ 0?*)
+ # major has a leading zero.
+ return
+ ;;
+ esac
+ case "$minor" in
+ 0?*)
+ # minor has a leading zero.
return
;;
esac
@@ -146,9 +160,56 @@
;;
*)
# [A-Fa-f0-9]*
- value=$(( 0x${1} ))
- minor=$(( (${value} & 0xff) | (${value} >> 12) & 0xfff00 ))
- major=$(( (${value} >> 8) & 0xfff ))
+ case "$1" in
+ 0?*)
+ # Composite device number has a leading zero.
+ return
+ ;;
+ esac
+ [ ${#1} -gt 16 ] && return # More than 16 hex digits.
+ #
+ # 16 hex digits, with leading zeros suppressed.
+ # Format is MmmMMMmm, where the "M"s are the hex
+ # digits of the major device number and the "m"s are the
+ # hex digits of the minor device number.
+ #
+ # Note: the shell uses 64-bit two's complement signed binary
+ # integer arithmetic internally when evaluating arithmetic
+ # expressions, even on 32-bit platforms such as i386. Bitwise
+ # shift operations are arithmetic shifts, not logical shifts.
+ # Only the right-most 63 bits participate in a shift operation.
+ # The left-most bit, the sign bit, does not participate in
+ # the shift operation and remains unchanged. For a shift
+ # left operation, bits shifted out of the left-most bit
+ # position which participates in the shift are lost; and zeros
+ # are shifted in on the right. Arithmetic overflow occurs
+ # if any bits unlike the sign bit are shifted out of the
+ # left-most bit position which participates in the shift.
+ # (However, arithmetic overflow is ignored.) For a shift
+ # right operation, bits shifted out of the right-most bit
+ # position are lost; and copies of the sign bit are shifted
+ # in on the left. All 64 bit positions, including the sign
+ # bit, participate in bitwise "and" and bitwise "or"
+ # operations.
+ #
+ # Hexadecimal constants are treated as padded on the left
+ # with zeros, if needed, or truncated on the left, if needed,
+ # to make 16 digits. If the left-most digit, after padding
+ # or truncating if needed, is in the range 8-f, inclusive,
+ # then the number is treated as negative, in two's complement
+ # form. Otherwise, the number is treated as positive (or zero
+ # if all digits are zero).
+ #
+ # For the three operators used in the expressions below,
+ # the bitwise shift right operator (>>) has the highest
+ # priority, followed by the bitwise "and" operator (&),
+ # followed by the bitwise "or" operator (|). Therefore, the
+ # default order of operations is correct; and no parentheses
+ # are needed in the expressions themselves.
+ #
+ devno=$(( 0x$1 ))
+ major=$(( devno >> 8 & 0xfff | devno >> 32 & 0xf000 ))
+ minor=$(( devno & 0xff | devno >> 12 & 0xff00 ))
;;
esac
Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits
Package: initramfs-tools-core
Version: 0.123
Severity: minor
Tags: patch
Congratulations on initramfs-tools version 0.123! Many bugs in version 0.120
have been fixed in this version. However, it appears that the parse_numeric
function, while improved over the 0.120 version, still doesn't handle the
general case of a composite device number. It seems it will only handle 8 hex
digits or less correctly.
I have submitted a patch for your consideration. The patch will accommodate the
general case of a composite device number of up to 16 hex digits (the limit).
It also tightens up some other error checking corner cases.
Respectfully submitted,
--
.''`. Stephen Powell<zlinux...@fastmail.com>
: :' :
`. `'`
`-
--- a/functions 2016-01-21 18:33:59.0 -0500
+++ b/functions 2016-03-24 08:09:11.0 -0400
@@ -128,14 +128,28 @@
# lilo compatibility
parse_numeric() {
- case $1 in
+ case "$1" in
*:*)
# Does it match /[0-9]*:[0-9]*/?
- minor=${1#*:}
- major=${1%:*}
- case $major$minor in
+ minor="${1#*:}" # Everything after the first colon.
+ major="${1%%:*}" # Everything before the first colon.
+ [ X"$major" = X ] && return # major is null.
+ [ X"$minor" = X ] && return # minor is null.
+ case "$major$minor" in
*[!0-9]*)
- # No.
+ # major or minor contains a non-numeric character.
+ return
+ ;;
+ esac
+ case "$major" in
+ 0?*)
+ # major has a leading zero.
+ return
+ ;;
+ esac
+ case "$minor" in
+ 0?*)
+ # minor has a leading zero.
return
;;
esac
@@ -146,9 +160,56 @@
;;
*)
# [A-Fa-f0-9]*
- value=$(( 0x${1} ))
- minor=$(( (${value} & 0xff) | (${value} >> 12) & 0xfff00 ))
- major=$(( (${value} >> 8) & 0xfff ))
+ case "$1" in
+ 0?*)
+ # Composite device number has a leading zero.
+ return
+ ;;
+ esac
+ [ ${#1} -gt 16 ] && return # More than 16 hex digits.
+ #
+ # 16 hex digits, with leading zeros suppressed.
+ # Format is MmmMMMmm, where the "M"s are the hex
+ # digits of the major device number and the "m"s are the
+ # hex digits of the minor device number.
+ #
+ # Note: the shell uses 64-bit two's complement signed binary
+ # integer arithmetic internally when evaluating arithmetic
+ # expressions, even on 32-bit platforms such as i386. Bitwise
+ # shift operations are arithmetic shifts, not logical shifts.
+ # Only the right-most 63 bits participate in a shift operation.
+ # The left-most bit, the sign bit, does not participate in
+ # the shift operation and remains unchanged. For a shift
+ # left operation, bits shifted out of the left-most bit
+ # position which participates in the shift are lost; and zeros
+ # are shifted in on the right. Arithmetic overflow occurs
+ # if any bits unlike the sign bit are shifted out of the
+ # left-most bit position which participates in the shift.
+ # (However, arithmetic overflow is ignored.) For a shift
+ # right operation, bits shifted out of the right-most bit
+ # position are lost; and copies of the sign bit are shifted
+ # in on the left. All 64 bit positions, including the sign
+ # bit, participate in bitwise "and" and bitwise "or"
+ # operations.
+ #
+ # Hexadecimal constants are treated as padded on the left
+ # with zeros, if needed, or truncated on the left, if needed,
+ # to make 16 digits. If the left-most digit, after padding
+ # or truncating if needed, is in the range 8-f, inclusive,
+ # then the number is treated as negative, in two's complement
+ # form. Otherwise, the number is treated as positive (or zero
+ # if all digits are zero).
+ #
+ # For the three operators used in the expressions below,
+ # the bitwise shift right operator (>>) has the highest
+ # priority, followed by the bitwise "and" operator (&),
+ # followed by the bitwise "or" operator (|). Therefore, the
+ # default order of operations is correct; and no parentheses
+ # are needed in the expressions themselves.
+ #
+ devno=$(( 0x$1 ))
+ major=$(( devno >> 8 & 0xfff | devno >> 32 & 0xf000 ))
+ minor=$(( devno & 0xff | devno >> 12 & 0xff00 ))
;;
esac
Bug#815288: FTBFS error with source package texinfo-doc-nonfree: unknown command sortas (and other errors)
Package: texinfo-doc-nonfree
Version: 6.1.0-1
The source package texinfo-doc-nonfree, version 6.1.0-1, fails to build from
source.
An excert from the console log follows inline:
makeinfo texinfo.texi
texinfo.texi:8674: unknown command `sortas'
texinfo.texi:8674: misplaced {
texinfo.texi:8674: misplaced }
texinfo.texi:9555: unknown command `sortas'
texinfo.texi:9555: misplaced {
texinfo.texi:9555: misplaced }
texinfo.texi:10462: unknown command `sortas'
texinfo.texi:10462: misplaced {
texinfo.texi:10462: misplaced }
texinfo.texi:11260: unknown command `sortas'
texinfo.texi:11260: misplaced {
texinfo.texi:11260: misplaced }
texinfo.texi:11299: unknown command `sortas'
texinfo.texi:11299: misplaced {
texinfo.texi:11299: misplaced }
texinfo.texi:11678: unknown command `sortas'
texinfo.texi:11678: misplaced {
texinfo.texi:11678: misplaced }
texinfo.texi:15502: unknown command `sortas'
texinfo.texi:15502: misplaced {
texinfo.texi:15502: misplaced }
texinfo.texi:15503: unknown command `sortas'
texinfo.texi:15503: misplaced {
texinfo.texi:15503: misplaced }
texinfo.texi:19498: warning: unreferenced node `Command Syntax'
texinfo.texi:19498: warning: node `Command List' is next for `Command Syntax'
in sectioning but not in menu
texinfo.texi:19498: warning: node `@@-Command Details' is up for `Command
Syntax' in sectioning but not in menu
texinfo.texi:19492: node `@@-Command Details' lacks menu item for `Command
Syntax' despite being its Up target
texinfo.texi:19573: warning: unreferenced node `Command List'
texinfo.texi:19573: warning: node `Command Contexts' is next for `Command List'
in sectioning but not in menu
texinfo.texi:19573: warning: node `Command Syntax' is prev for `Command List'
in sectioning but not in menu
texinfo.texi:19573: warning: node `@@-Command Details' is up for `Command List'
in sectioning but not in menu
texinfo.texi:19492: node `@@-Command Details' lacks menu item for `Command
List' despite being its Up target
texinfo.texi:20886: warning: unreferenced node `Command Contexts'
texinfo.texi:20886: warning: node `Command List' is prev for `Command Contexts'
in sectioning but not in menu
texinfo.texi:20886: warning: node `@@-Command Details' is up for `Command
Contexts' in sectioning but not in menu
texinfo.texi:19492: node `@@-Command Details' lacks menu item for `Command
Contexts' despite being its Up target
debian/rules:13: recipe for target 'build-stamp' failed
make: *** [build-stamp] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
.''`. Stephen Powell<zlinux...@fastmail.com>
: :' :
`. `'`
`-
Re: turning off Google Chrome's warning
On Thu, Jan 21, 2016, at 21:59, Frank McCormick wrote: > > On 21/01/16 09:41 PM, Stephen Powell wrote: >> >> What does chrome give you that chromium does not? > > Nothing that I know of...but I thought that staying with the Google > product is just simpler. I've had chromium on this machine for a little > while and it **seems** to be Chrome in plainer clothes. So I just > might remove google-chrome and live with chromium for now. An install of > 64-bit Debian is not in the cards for now. One thing that chrome gives you that chromium does not is the built-in PPAPI Adobe flash plugin, which you may or may not need or want. But if you do want it or need it, you can install chromium plus pepperflashplugin-nonfree. Unfortunatley, there are no automatic updates. You have to run "update-pepperflashplugin-nonfree --status" periodically to check for updates, followed by "update-pepperflashplugin-nonfree --install" if an update is needed. That does bring up an interesting question though. I believe that "update-pepperflashplugin-nonfree --install" works by downloading the chrome package from google, extracting the built-in pepper flash plugin, then installing the pepper flash plugin into chromium. Will Google stop updating the 32-bit version of the flash plugin contained within the 32-bit version of chrome? I don't know the answer to that one. Note that chromium does support html5, so the need for the flash plugin is not as great as it once was. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: turning off Google Chrome's warning
On Thu, Jan 21, 2016, at 18:55, Frank McCormick wrote: > > Does anyone know how to urn off the warning from Google-Chrome > that comes up every time you go into the browser. The warning is > about Google no longer supporting 32 bit versions as of March. > It's really annoying. > > Thanks > Oops! My original reply went to Frank personally instead of to the list, as I intended. I'm still getting used to this new e-mail client. Anyway, No, I don't. But chromium is still supported, including the 32-bit version, and chromium is open source. Do you really need chrome? What does chrome give you that chromium does not? -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Re: Attempt to Move Root
On Fri, 25 Dec 2015 10:33:56 -0500 (EST), Stephen Powell wrote:
> On Tue, 22 Dec 2015 10:57:41 -0500 (EST), Nicolas George wrote:
>> ...
>> I noticed that LILO seems to be actually capable
>> of finding the sectors for files on LVM.
>
> In the general case, the sectors of a file on an LVM2 logical volume may
> reside on multiple physical partitions on multiple physical disks. But if
> all of those disks are addressable via the BIOS, and all of the sectors
> are accessible via the BIOS, then it may be theoretically possible for LILO
> to read the map file, the kernel image file, and the initial RAM file system
> image file from an LVM2 logical volume at boot time. I guess I was making
> an implicit assumption that they would all have to be on the same physical
> device. But maybe that's not true. I'll have to look into that.
Looking at the source package for lilo, in src/geometry.c, I find the following:
if (lbm.lv_dev != geo->base_dev)
die("LVM boot LV cannot be on multiple PVs\n");
Therefore, it appears from a cursory examination that an LVM2 logical volume
may be used for /boot if the logical volume maps to a single
physical volume. It is not clear to me from this cursory examination whether
this "physical volume" actually means a partition; or if it means a physical
disk,
which may consist of multiple partitions. In any case, I would not recommend
putting /boot on an LVM2 logical volume. It's just one more layer of
complexity, and one more potential thing to go wrong.
--
.''`. Stephen Powell<zlinux...@wowway.com>
: :' :
`. `'`
`-
Re: Attempt to Move Root
On Tue, 22 Dec 2015 14:44:31 -0500 (EST), Sven Hartge wrote: > > In ye olde days (pre-Windowsm 98) some programs (I think Photoshop did > it.) wrote licence data into that space, because it was unused. The copy > protection scheme of some games also tried to hide information there. > I can think of some other cases. Back in the day when most BIOSes had a head limit of 16, thus limiting the size of a hard disk addressable via BIOS Int 13h functions 02h and 03h to 504MiB, programs such as Ontrack Disk Manager could be installed to circumvent this restriction. They would hook the BIOS to increase the head limit to 255. I believe this was accomplished by putting the BIOS hook program in the boot sector and moving the original boot sector to the second sector (CHS value 0:0:2). Also, in the days of IBM 386 microchannel machines, such as the IBM PS/2 model 70, IBM sold a memory board that initialized after POST by using a similar boot hook. Around that same time period, Novell Netware was known to also use an unallocated sector, perhaps for licensing, copy protection, etc. These schemes all conflicted with each other of course. As I say in my lilo web page, there are no rules for the use of unallocated sectors. And grub-legacy and grub-pc (by default at least) now do a similar thing. They store information in unallocated sectors. That's one of the reasons (but not the only reason) that I switched back to LILO. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: Attempt to Move Root
On Tue, 22 Dec 2015 10:57:41 -0500 (EST), Nicolas George wrote: > > What you write is slightly inaccurate. The core of your inaccuracy is this: > LILO does not use the BIOS to read FILES, but SECTORS. How to map files to > sectors is entirely LILO's problem. That depends on your point of view. To lilo's map installer (the lilo command that runs at a Linux shell prompt) they are files. The LILO boot loader itself reads an ordered list of sectors created for it by the map installer. But it is still a file. If what you mean is that the LILO boot loader, at boot time, cannot determine which sectors to read based on examining the file system structures, then yes, that is true. > > IIRC, the mapping is computed when (re)installing LILO on the boot-sector > and hard-coded in the boot-sector itself, with one level of indirection (the > map file). After a quick glance at the sources, it uses the FIBMAP ioctl and > various others to ask the kernel the blocks used by a file and converts to > sectors. At the same time, I noticed that LILO seems to be actually capable > of finding the sectors for files on LVM. In the general case, the sectors of a file on an LVM2 logical volume may reside on multiple physical partitions on multiple physical disks. But if all of those disks are addressable via the BIOS, and all of the sectors are accessible via the BIOS, then it may be theoretically possible for LILO to read the map file, the kernel image file, and the initial RAM file system image file from an LVM2 logical volume at boot time. I guess I was making an implicit assumption that they would all have to be on the same physical device. But maybe that's not true. I'll have to look into that. > > I have not read this thread carefully, so maybe it has already been > addressed, but all this suggest that the OP should install GRUB instead of > LILO and be done with that kind of trouble. As subsequent posts have indicated, the trouble was with an incorrect UUID. It had nothing to do with the OP's choice of boot loader. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: Attempt to Move Root
On Mon, 21 Dec 2015 10:36:48 -0500 (EST), David Baron wrote: > > On Monday 21 December 2015 10:25:15 Stephen Powell wrote: >> >> Obviously, the LILO map file is on the IDE drive. Is your /boot partition >> on the IDE drive? If so, you cannot remove it. The /boot partition must >> be a partition on a physical drive, but obviously it cannot be on the drive >> that you want to remove. > > The boot is not a separate partition but is a directory on the root so > travels with it. Copy on both old and new directories. No, that won't work. If the root filesystem is an LVM2 logical volume, then /boot *cannot* be part of the root filesystem. To be more rigorous, there will be a /boot directory in the / filesystem, but it must be an *empty* directory, so that another filesystem can be mounted on that directory. Another filesystem must get mounted on the /boot directory in the root filesystem, and that filesystem must be made on a partition of a *real* disk which is accessible via the BIOS. It cannot be an LVM2 logical volume. The boot partition contains the LILO map file (by default, /boot/map) as well as the kernel image file and the initial RAM filesystem image file. LILO reads these files at boot time via BIOS calls, and the BIOS does not support LVM2 logical volumes. You can have a physical disk with two partitions on it, one partition of which is an LVM2 physical volume which is part of an LVM2 logical volume, and the other one of which is a stand-alone partition which is mounted on /boot. But the filesystem which gets mounted on /boot must *not* be an LVM2 logical volume. I thought I made that clear before. Also, the LILO boot sector must be either on the MBR of a *real* disk, or the first sector of a partition on a *real* disk. > > The loop that I get is something more problematic. Agreed. As I said before, there is probably something missing from the initial RAM file system that needs to be there for the kernel to mount an LVM2 logical volume.
Re: Attempt to Move Root
On Mon, 21 Dec 2015 10:31:54 -0500 (EST), Lisi Reisz wrote: > > Could he not dd them onto another drive? > ... He can copy the /boot data to another drive, not necessarily with dd. In fact, if he wants to be able to remove the existing IDE drive, he must. But he cannot copy it to an LVM2 logical volume. The data in /boot (after copying) must be on a partition on a physical disk which is accessible via the BIOS and not on the old IDE drive which he wishes to remove. The / filesystem can be an LVM2 logical volume, provided the initial RAM filesystem contains sufficient files to mount an LVM2 logical volume, but the filesystem which gets mounted on /boot must be made on a partition of a *real* disk which is not scheduled to be removed from the system.
Re: Attempt to Move Root
On Mon, 21 Dec 2015 15:43:54 -0500 (EST), David Baron wrote: > > Repeat: NO LV's Oh. Sorry. Looking back over the thread, I guess I got the idea from Anders Andersson that you were using LVM2 logical volumes. My mistake. Yes, if / is a partition on a real disk, then /boot can be part of the same filesystem. I've been on the wrong track for several posts now. Please excuse the noise. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: Attempt to Move Root
On Mon, 21 Dec 2015 04:50:00 -0500 (EST), David Baron wrote: > > Went through all the motions, both ways: On native and chroot. Results were > the same. Get in that loop of lv not ready messages. Difference: Native > attempt still needs the IDE plugged in or I get 99 99 99 ... , chroot does > not. > > So, what do I do next? Obviously, the LILO map file is on the IDE drive. Is your /boot partition on the IDE drive? If so, you cannot remove it. The /boot partition must be a partition on a physical drive, but obviously it cannot be on the drive that you want to remove. The "volume not ready" messages would indicate that LVM2, or some file(s) needed by it, are not included in the initial RAM file system.
Re: Attempt to Move Root
On Sun, 20 Dec 2015 15:51:22 -0500 (EST), David Baron wrote: > > So ... do I need the chroot and the binds and all this at all? That's the recommended way. Make sure that the edited copies of /etc/lilo.conf, /etc/fstab, and /etc/initramfs-tools/conf.d/resume, in the chrooted environment, all make sense for the new setup, especially the "boot" and "root" configuration file records in /etc/lilo.conf. /etc/initramfs-tools/conf.d/resume must specify the UUID of the swap partition. I have another web page that may be helpful to you. It shows an example of copying a root file system for a virtual machine running under z/VM in the s390x environment. That is not your situation, of course; but portions of it are applicable to your environment. You may be able to separate the wheat from the chaff and figure out what applies to your situation and what doesn't. Then again, it may only confuse you. So I give you the link with some hesitation. The parts that apply are the copying of the file system(s), and setting up the chroot environment. I hope it does more good than harm. Here it is: http://www.stevesdebianstuff.org/diag250.htm The s390x environment uses a boot loader called zIPL, not LILO; but zIPL's design is similar to LILO in that it does not understand the structure of a Linux file system. It simply reads a predetermined list of blocks from the file system at boot time. Also note that /boot must not use the btrfs filesystem. This is an undocumented restriction for both zIPL and LILO. I recommend ext2 for /boot. (If the partition size is small enough, you pretty much have to use ext2. ext3 and ext4 require a journal, and that in turn requires a certain minimum partition size.) Good luck.
Re: Attempt to Move Root
On Sun, 20 Dec 2015 05:58:47 -0500 (EST), David Baron wrote: > > OK, mounted newrootpartition newroot > Did a cp -x / newroot > Successful so far, elementary > > Edited newroot/etc/fstab and newroot/etc/lilo.conf to point root to > newrootpartition (by uuid) > > mount --bind /dev newroot/dev > mount --bind /proc newroot/proc > as instructed in various posts, to enable lilo to run. > > chroot newroot > lilo ... > > Looked successful. Umounted everything and reboot. > > Get boot menu (congratulations !?). > Chose the kernel. > > Now got that lvm not ready business.. I usually get this once and then > normally boot up. Now getting it over and again. BTW, if I control/C a few > times, I end up inside initramfs>. > > Put up the live DVD, regenerated the initramfs, but ... no change. > Put up the live DVD, mounted the old root partition, went through the lilo > process and back up. > > So ... how do I do this?? I have several thoughts. First of all, the right way to copy the root filesystem under these conditions is cp -a -x /. newroot That period after the forward slash is important! Second, make sure that the initial RAM filesystem contains everything needed to initialize a logical volume. If you make a logical volume the root filesystem in the Debian installer, the Debian installer *should* do whatever is necessary to make sure that everything needed to mount a logical volume gets included in the initial RAM filesystem. I've never tried to do this, so I can't give you a list of what files will be needed. You can examine an existing inital RAM filesystem to see what files are included by using lsinitramfs. Third, although it is possible to make a logical volume the root filesystem, /boot must not be part of this filesystem. It must be a separate partition on a physical volume. (Furthermore, it must be a separate partition that is accessible via the BIOS.) The same goes for the boot sector. (The "boot" configuration record in /etc/lilo.conf.) Usually, this is the first sector on the /boot partition or else the master boot record. And if it is not the master boot record, then a generic MBR boot loader program must be installed in the MBR and the /boot partition must be on that physical disk, and it must be marked active in the partition table (and all other partitions marked inactive). Finally, make sure that the BIOS is actually booting from this physical disk. Although the specific subject of using an LVM2 logical volume as the root filesystem is not specifically covered, you may find some useful lilo tidbits on my lilo web page: http://www.stevesdebianstuff.org/lilo.htm Finally, make sure that there are no duplicate UUIDs in the system that might confuse the kernel during boot.
Re: My web site is back
On Tue, 08 Dec 2015 18:55:43 -0500 (EST), Gener Badenas wrote: > > How much is the hosting now and with whom? $48 for hosting, $9.00 for domain registration, total $57. Good for one year. I'll have to pay again next year. I decided to go with debian-hosting.info. So far, I haven't yet figured out how to upload files via their control panel, but the account comes with FTP service, so I was able to upload my files via FTP. By the way, I have no business interest in debian-hosting.info, other than being one of their newest customers.
My web site is back
Old site: h t t p : / / u s e r s . w o w w a y . c o m / ~ z l i n u x m a n / New site: http://www.stevesdebianstuff.org/ If you have bookmarks set for the old site you should update your bookmarks. Some pages from the old site are not on the new site because I judged them to be obsolete.
Re: My web site is back
On Tue, 08 Dec 2015 12:36:44 -0500 (EST), Martin Read wrote: > On 08/12/15 16:58, Darac Marjal wrote: >> >> To which, the venerable W3C replied "Cool URIs don't change": >> http://www.w3.org/Provider/Style/URI.html > > Your criticism is invalid, given that the action that has clearly been > taken here is "change my URIs so that in future they're under a domain I > control instead of a domain someone *else* controls". > > (Also, given the behaviour of search engines, "Pretty much the only good > reason for a document to disappear from the Web is that the company > which owned the domain name went out of business or can no longer afford > to keep the server running." is a beautiful theoretical principle with > no grounding in practicality.) Actually, I didn't change my web site name for either reason. I changed it because my ISP decided to discontinue their web hosting service. (Or maybe they just decided to discontinue their *free* web hosting service provided to *home* users of their cable modem internet connectivity. They may still provide a *for charge* web hosting service to their *business* customers. I wouldn't know.) In any case, they "pulled the plug" on me. I now pay for a web hosting service that I used to get free. But I will admit that the new URL is more "cool" than the old one. :-)
Re: [OT] Soliciting Advice on e-mail and web-hosting providers
On Sat, 28 Nov 2015 10:15:08 -0500 (EST), mister s jones wrote: > On Saturday, November 28, 2015 09:49:47 Stephen Powell wrote: >> So, does anyone wish to share their experiences, good or bad? Is there >> anyone you wish to recommend? Is there anyone you want to warn me to stay >> away from? All opinions are welcome. > > I personally have been here for years and I like them > > http://debian-hosting.info/ > > Prices are reasonable and service has been great. I checked out their web site, and they seem like a good outfit. But I must admit, I'm totally lost. Allow me to explain. My old web site was pure HTML. No ASP, no PHP, no SQL. It's just pure information, with some links for downloading files. I'm not a business trying to set up a web site so that customers can order stuff from me. I just want to publish free information for the public. It's mostly tech stuff about Debian. When I created my old web site, All I did to manage it was use FTP to upload and download files. By convention, the home page was "index.htm". Any other pages could be linked to from that page. The only thing that I would like to change is to use SSL-encrypted FTP, so that my password won't be sent over the network in clear text. I must admit that I don't understand this brave new world of web hosting. Looking at debian-hosting's web site, I'm totally lost as to how I would mangage my account. What I'm looking for is something similar to what I had before. Is there anything like that out there? Or can I manage a debian-hosting account that way?
Re: [OT] Soliciting Advice on e-mail and web-hosting providers
On Sat, 05 Dec 2015 18:43:13 -0500 (EST), Lisi Reisz wrote: > > I ma assuming (or subconsciously remembering) that you are in the USA. Is > that correct? Hi, Lisi. Yes, that's correct. I hope you won't hold that against me. :-) Wow used to offer free web hosting to subscribers to their cable modem internet service. They decided to withdraw that service, so I'm looking for a new web-hosting service for my web site. If I can get it free, that's great; but I'm not willing for anyone to run ads on my site.
Re: OT: reply styles, family matters
On Mon, 30 Nov 2015 20:31:29 -0500 (EST), Bob Bernstein wrote: > ... > With that as background, here is my question/request: is anyone > aware of a spirited defence of our ideal method of "selective > quoting," (for lack of a better label) one, say, that perhaps > has achieved the status of a "net classic?" Surely some 'net > genius has dealt these nay-sayers, who seem to LIKE top-posting, > a solid uppercut? How about this one: https://en.wikipedia.org/wiki/Posting_style ?
[OT] Soliciting Advice on e-mail and web-hosting providers
I currently get my internet connectivity, e-mail service, and web-hosting service from the same provider. I recently complained to my ISP about backscatter SPAM I was getting from other people's infected machines that were sending out SPAM to invalid e-mail addresses and spoofing me as the sender. (See https://en.wikipedia.org/wiki/Email_spoofing and https://en.wikipedia.org/wiki/Backscatter_(email) for good articles about these subjects.) Their response was to suspend my e-mail access and delete my web site! I finally got my e-mail access back, but my web site is still down. This experience has convinced me that tying my e-mail and web-hosting to my ISP is a bad idea. The two extra services are free to subscribers to their internet access service, but I don't want problems in one area to adversely affect the other areas. Clearly that is not the case now. So I am looking for a good e-mail provider and a good web-hosting provider. For the e-mail service I want a provider that has good protection against backscatter SPAM, provides a web-based e-mail client, and does not force me to view tons of ads in order to get to their web-mail client. I want all transmission of credentials, particularly passwords, passed between the client and the server, to be encrypted, not sent across the network in clear text, where a sniffer operating in promiscuous mode could intercept them. I also want the e-mail provider to work well with Debian mailing lists. (I have heard, for example, that when gmail users post to a list to which they are subscribed they do not receive copies of their own posts.) For web-hosting, I am looking for one which allows me to upload and download web pages and other files to my site via SSL-encrypted FTP, whether implicit or explicit SSL I don't care, so that passwords sent across the internet cannot be intercepted by a sniffer. Obviously, low cost is important too. I'm not a business. My web site is providing a public service for free. There are no ads on my web site, and there is no money coming in to pay for the web hosting. Another important consideration is that I don't want the service provider, e-mail or web-hosting, selling information about me to anyone. So, does anyone wish to share their experiences, good or bad? Is there anyone you wish to recommend? Is there anyone you want to warn me to stay away from? All opinions are welcome.
Re: How to identify obsolete packages
On Sat, 31 Oct 2015 13:27:19 -0400 (EDT), Jude DaShiell wrote: > > I get aptitude to resolve recommended upgrades just by using the -r > switch on the command line. There's probably a way to do that using > g.u.i. but don't know that one yet. It's been a while now, but IIRC, this works for install but not for safe-upgrade or full-upgrade. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: How to identify obsolete packages (was: Anybody know why aptitude is not installed by default in Sid?)
On Sat, 31 Oct 2015 10:38:48 -0400 (EDT), "Reco" wrote: > On Sat, 31 Oct 2015 10:29:48 -0400 (EDT), Stephen Powell wrote: >> Does anyone know an easy way to identify obsolete packages without >> using aptitide? > > deborphan --guess-all According to the documentation for deborphan, "deborphan finds packages that have no packages depending on them ...". That's not what I want. What I want is a list of installed packages that are not listed in any repository found in /etc/apt/sources.list. This is what aptitude refers to as "Obsolete or Locally Created Packages". As an example, lilo has no packages depending on it; but it is included in Debian stretch, which is listed in /etc/apt/sources.list. Therefore, by aptitude's definition of obsolete, lilo is not obsolete. On the other hand, libapt-pkg4.12, which still exists in jessie, was recently removed from stretch. Therefore, for stretch systems, libapt-pkg4.12, though it may be installed by reason of a migration from jessie, is classified as obsolete. It is installed, but it is no longer installable from the Debian archive. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
[SOLVED] How to identify obsolete packages
On Sat, 31 Oct 2015 11:28:26 -0400 (EDT), Kamaraju Kusumanchi wrote: > > Here is one way. > > To identify packages that are no longer present in the archive > > % apt-show-versions -r . | grep "No available version in archive" That's what I'm talking about! Thanks! (Although it does require the installation of another package: apt-show-versions.) I'm curious, though. Do you use the C shell? Or did you just customize your prompt? -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
How to identify obsolete packages (was: Anybody know why aptitude is not installed by default in Sid?)
On Sat, 31 Oct 2015 07:38:25 -0400 (EDT), Chris Bannister wrote: > > Oh great! They've fixed it. I hated having to "dpkg --purge aptitude" > after a new installation. If you want extra packages, it's just an > apt-get install step away. I used to use aptitude; but I've switched back to using apt, mainly because apt-get resolves "Recommends" dependencies during an upgrade while aptitude does not. But there is one thing that I like about aptitude that, if I could get equivalent functionality out of apt, I might not bother to install aptitude. aptitude, when run with no parameters, provides a full-screen interface. This full-screen interface lists package categories which can be expanded. One category in particular is of interest to me: "Obsolete and Locally Created Packages". By expanding this category, I can identify obsolete packages. (An obsolete package, by definition, is an installed package which no longer exists in the Debian archive.) 99% of the time, an obsolete package is one that I wish to purge. I've seen cases where packages are held back during "apt-get --purge dist-upgrade" processing until these obsolete packages are purged. But I have not found a way to easily identify obsolete packages using apt. There is an "autoremove" option on apt-get to remove packages which were automatically installed but which are no longer required by any installed package. But that is different. That's not the same thing as an obsolete package. An obsolete package may have been manually installed, but it's still obsolete, and I need to be able to identify it as such. Does anyone know an easy way to identify obsolete packages without using aptitide? -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: RealTek RTL8192EU drivers
On Thu, 29 Oct 2015 15:43:51 -0400 (EDT), Jose Martinez wrote: > > I sure appreciate the info. The internal B43 wireless on my laptop does > not play nicely with the b43legacy driver and locks up fairly > frequently, and has limited data rates. (the b43 driver doesn't work at > all). This seems to be a pretty common problem, as I've run across it > mentioned on several sites. So, I thought I'd get something that was > less problematic.alas and alack the solution seems to have its own > issues!! In Debian, the driver and the firmware are separate. Make sure you have the firmware installed also. Usually, you can detect missing firmware with dmesg|less and search for the string "firmware" (without the quotes). See if there are any error messages regarding the attempt to load firmware. You will need Debian package firmware-b43legacy-installer or firmware-b43-installer, depending on which chipset is built in. firmware-b43legacy-installer is needed for chipsets BCM4301, BCM4306/2, or BCM4306. firmware-b43-installer is used for chipets BCM4306/3, BCM4311, BCM4318, BCM4321, BCM4322 (only 14e4:432b), or BCM4312 (with Low-Power a.k.a. LP-PHY). Make sure that you have the contrib and the non-free sections of the archive enabled in /etc/apt/sources.list, as this involves non-free stuff. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: RealTek RTL8192EU drivers
On Tue, 27 Oct 2015 20:24:07 -0400 (EDT), Jose Martinez wrote: > > I recently purchased a USB wifi adapter which has a RealTek RTL8192EU > chip (ID 0bda:818b) in it. A CD came with the wifi adapter which had > drivers for Windows (which worked properly) and purports to have linux > drivers as well. Of course the linux driver has to be compiled. > Following their instructions, and using their install.sh shell script, I > attempted to compile and install the driver. Unfortunately, the > compilation failed (attached is a copy of the output from the > compilation run). I am running Debian 8.2 with kernel 3.16 (sometimes > 4.2, though 4.2 seems to have some issues that 3.16 doesn't, but that is > another conversation). I have all the headers installed and can compile > the kernel successfully on the system, so I'm sure it's not a matter of > missing headers/source information. Any assistance, either to get the > distributed driver to compile, or to obtain a driver that does compile > would be greatly appreciated. I found this: http://askubuntu.com/questions/619840/rtl8192eu-driver-does-not-work This is for Ubuntu, not Debian; but perhaps it can be adapted for Debian. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Bug#801913: init-premount boot script is now superfluous
Package: sysconfig-hardware Version: 0.0.10+nmu3 Severity: wishlist X-Debbugs-CC: debian-s390@lists.debian.org Now that sysconfig-hardware brings DASD devices online before the permanent root file system is mounted, the script usr/share/initramfs-tools/scripts/init-premount/sysconfig_hardware is superfluous. It is no longer needed. It should be dropped from the package. That's one less piece of code to maintain, and one less item that needs to be included in the initial RAM file system image file. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
[SOLVED] [OT] Has my e-mail account been hacked?
On Tue, 13 Oct 2015 04:15:21 -0400 (EDT), Jochen Spieker wrote: > > It looks like the mail was delivered directly through > smtp02.wow.cmh.synacor.com by a user who successfully authenticated > using the username thecoughingcanary. On Wed, 14 Oct 2015 05:04:55 -0400 (EDT), Brian <a...@cityscape.co.uk> wrote: > > Your mails all have > > X-Authed-Username: emxpbnV4bWFuQHdvd3dheS5jb20= > > The one to aol.com has > > X-Authed-Username: dGhlY291Z2hpbmdjYW5hcnlAd293d2F5LmNvbQ== > > so did not come from your account. > > Someone has access (legitimately or not) to the second account and is > sending mails with a forged envelope From. Your only recourse is to > present the evidence to the ISP and let them deal with it. Thank you, Jochen and Brian, that is exactly the kind of information I was looking for. I now know that my e-mail account has not been hacked, just spoofed. I will report this to my ISP. Thanks to all who participated in this thread. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Bug#801912: DASD options are ignored because device is already online
Package: sysconfig-hardware Version: 0.0.10+nmu3 Severity: normal X-Debbugs-CC: debian-s...@lists.debian.org Tags: patch The DASD options are being ignored. The problem is in etc/sysconfig/scripts/hardware/hwup-ccw-dasd. The DASD options can only be set *before* the device is brought online. The script is attempting to set the DASD options *after* bringing the device online. Thus, the DASD options are ignored. A patch which fixes the problem is attached. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-diff -ura a/etc/sysconfig/scripts/hardware/hwup-ccw-dasd b/etc/sysconfig/scripts/hardware/hwup-ccw-dasd --- a/etc/sysconfig/scripts/hardware/hwup-ccw-dasd 2015-09-06 03:38:33.0 -0400 +++ b/etc/sysconfig/scripts/hardware/hwup-ccw-dasd 2015-10-15 14:26:51.819975570 -0400 @@ -15,18 +15,17 @@ message_n "Configuring device $ID: " read _online < $SYSFS$DEVPATH/online if [ "$_online" -ne "1" ]; then + if [ -n "$DASD_USE_DIAG" ]; then +echo "$DASD_USE_DIAG" > $SYSFS$DEVPATH/use_diag + fi + if [ -n "$DASD_READONLY" ]; then +echo "$DASD_READONLY" > $SYSFS$DEVPATH/readonly + fi echo 1 > $SYSFS$DEVPATH/online message_n "online. " else message_n "already online. " fi -if [ -n "$DASD_USE_DIAG" ]; then - echo "$DASD_USE_DIAG" > $SYSFS$DEVPATH/use_diag -fi -if [ -n "$DASD_READONLY" ]; then - echo "$DASD_READONLY" > $SYSFS$DEVPATH/readonly -fi - message "ok. "
Bug#801913: init-premount boot script is now superfluous
Package: sysconfig-hardware Version: 0.0.10+nmu3 Severity: wishlist X-Debbugs-CC: debian-s...@lists.debian.org Now that sysconfig-hardware brings DASD devices online before the permanent root file system is mounted, the script usr/share/initramfs-tools/scripts/init-premount/sysconfig_hardware is superfluous. It is no longer needed. It should be dropped from the package. That's one less piece of code to maintain, and one less item that needs to be included in the initial RAM file system image file. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: [OT] Has my e-mail account been hacked?
On Tue, 13 Oct 2015 11:22:34 -0400 (EDT), Andrew McGlashan wrote: > > On 13/10/2015 7:15 PM, Jochen Spieker wrote: >> Stuart Longland: I had a similar case on my self-administered mail >> host. A friend of mine has an account there and random hosts from >> all over the world used his credentials to send legitimately >> looking spam. We never found out how this happened but changing the >> password was enough to make it stop. > > Odds on it was open WiFi somewhere, people trust public WiFi ... I > cannot understand why. It is patently stupid [or ignorant at best] to > use public [or otherwise open] WiFi -- if you don't run it yourself or > you totally trust the person whom is running it, then leave it alone. That may have been the case for Stuart's friend, but it is not the case with me. I use only wired ethernet. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: [OT] Has my e-mail account been hacked?
On Tue, 13 Oct 2015 22:09:53 -0400 (EDT), Stuart Longland wrote: > > This isn't level 1 helpdesk material, you'll actually need a technical > contact there. Their level 1 help desk isn't much help anyway, if you're a Linux user. The last time I called their level 1 help desk for technical support, the conversation went something like this: Me: I'm having an internet connectivity problem. I can't Them: What release of Windows are you running? Me: I don't run Windows; I run Linux. Them: I'm sorry, sir, we don't support Linux. Me: This is not a Linux problem. This is an internet connectivity problem. I can't ... Them: I'm sorry, sir, we don't support Linux. Is there anything else we can help you with today, sir? Me: No, I don't think so. And that was that. They'll gladly take the money of a Linux user. But if you have problems, you're on your own. That was a few years ago. Maybe it's better now. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: [OT] Has my e-mail account been hacked?
On Tue, 13 Oct 2015 18:57:58 -0400 (EDT), Brian <a...@cityscape.co.uk> wrote: > > The comment was a general one and directed at all our readers. However, > earlier you said "Someone discovered my password somehow". You have > just demolished that guess as having no basis as a likely cause. Likely, no, but still possible. For example, when I update my web pages, I use my ISP's FTP server. Suppose someone else on my ISP's subnet has a network sniffer in promiscuous mode. The FTP server uses ordinary unencrypted FTP. The userid and password are sent in clear text. I wish they had an FTPS server, but the last time I checked, they didn't. I use e-mail solely through a web-based e-mail client. When I login, I don't know if the password is sent in clear text over the network or not. That being said, if my password was obtained in this manner, I don't have much of a defense against it. If I change my password, they can get the new one the same way as they got the old one. Another possibility is a malicious web site that I may have unknowingly visited that managed to find a password in memory, a cookie, etc. So despite all the precautions that I have taken, it is still possible for a password to be "discovered". Having said that, it looks like someone else's credentials may have been used, based on some other posts to this thread. But I am not an expert in these matters. That's why I asked for help. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: [OT] Has my e-mail account been hacked?
On Mon, 12 Oct 2015 12:36:27 -0400 (EDT), Brian <a...@cityscape.co.uk> wrote: > > I tend to think passwords (except the very simplest or guessable ones) > are not "discovered" but handed over. 1. My password is known only to me. Even my wife doesn't know it. 2. My password is a random sequence of uppercase and lowercase letters. It is not a pronounceable word, and it is fairly long. 3. I use e-mail only from my home computer. 4. I use wired ethernet only 5. I never respond to the (almost daily) phishing attacks designed to coax my password out of me. 6. My wife and I are empty nesters. There is no-one else at home. In short, I have not "handed it over". -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Re: [OT] Has my e-mail account been hacked?
On Tue, 13 Oct 2015 02:36:46 -0400 (EDT), Jimmy Johnson wrote: > > Looks like it was mailed from MS Windows. Maybe mailed from a Windows > OS with a virus. Do you run Windows too? No, I don't. There is no computer connected to my home network that even has Windows installed. -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
