Re: 404 trying to use stretch/backports
Felix Miata wrote: > Didn't help. :-( can you open it in the browser
Re: Strange message during boot
Hey Richard, Perhaps it is just me but i am having trouble deciphering this sentence: "When booting one specific install I many repetitions to the effect that it is beginning a specific script." could you please elaborate upon it? On 01/10/2018 03:22 PM, Richard Owlett wrote: > I multi-boot several varieties of Debian. > When booting one specific install I many repetitions to the effect > that it is beginning a specific script. > > It then proceeds to bring up an apparently normal system. > > Would this be logged somewhere? > Where? > > TIA > signature.asc Description: OpenPGP digital signature
Re: 404 trying to use stretch/backports
On 1/11/2018 8:08 AM, Felix Miata wrote: Trying to get a non-broken recent version of mc, the instructions on https://backports.debian.org/Instructions/ fail[1]. How can I get a non-broken relatively recent mc package installed, e.g. patched 4.8.19, or 4.8.20? Breakage was fixed 15 months ago[2]. [1] # apt-get update ... err:9 http://ftp.debian.org/debian stretch-backports/main i386 Packages 404 Not Found... What lines do you have in 'sources.list'? The following URL is working for me: deb http://ftp.debian.org/debian stretch-backports main -- John Doe
Re: 404 trying to use stretch/backports
On Thu, Jan 11, 2018 at 09:52:00AM +0100, john doe wrote: > On 1/11/2018 8:08 AM, Felix Miata wrote: > > Trying to get a non-broken recent version of mc, the instructions on > > https://backports.debian.org/Instructions/ fail[1]. How can I get a > > non-broken > > relatively recent mc package installed, e.g. patched 4.8.19, or 4.8.20? > > Breakage > > was fixed 15 months ago[2]. > What lines do you have in 'sources.list'? > > The following URL is working for me: > > deb http://ftp.debian.org/debian stretch-backports main Hey guys, there is no backport of the mc package available, so someone has to backport it first. There is no automatic backport process running because that's technically not really possible and that's not how backports are intendet to work. $ rmadison mc mc | 3:4.8.3-10| oldoldstable | source, amd64, armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc mc | 3:4.8.13-3| oldstable | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x mc | 3:4.8.13-3| oldstable-kfreebsd | source, kfreebsd-amd64, kfreebsd-i386 mc | 3:4.8.18-1| stable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x mc | 3:4.8.19-1| testing| source, amd64, arm64, armel, armhf, i386, mips, mipsel, ppc64el, s390x mc | 3:4.8.19-1| unstable | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x mc | 3:4.8.19-1| unstable-debug | source mc | 3:4.8.19-1+b1 | testing| mips64el mc | 3:4.8.19-1+b1 | unstable | mips64el So 4.8.19 is available in unstable, that would be something someone could backport. Cheeers, Sven
Re: Strange message during boot
On 01/11/2018 02:32 AM, Jeroen Mathon wrote: Hey Richard, Perhaps it is just me but i am having trouble deciphering this sentence: "When booting one specific install I many repetitions to the effect that it is beginning a specific script." could you please elaborate upon it? OOPS, typos and awkward phrasing. It should have read: When booting one specific install, it displays many repetitions of the line to the effect that it is beginning a specific script. Specifics: sda1 - Always has the latest version of Debian, currently 9.1 . For housekeeping reasons it has the only copy of Grub on my machine. sda8 - The problem install is Debian 8. It had been my primary work install until I trashed some data files. It has been kept to reconstruct those files as I have time. sda9 - Current work install of Debian 9.1 On 01/10/2018 03:22 PM, Richard Owlett wrote: I multi-boot several varieties of Debian. When booting one specific install I many repetitions to the effect that it is beginning a specific script. It then proceeds to bring up an apparently normal system. Would this be logged somewhere? Where? TIA
Re: System won't boot anymore after upgrade to jessie
> > > > Thank you, it was "dep" indeed! > > Then remove those additional files, check that MODULES=most is set in > /etc/initramfs-tools/initramfs.conf, do a "update-initramfs -u -kall", > and you should be good to go. > The driver policy file? It is safe to just remove it? Btw, isn't a bit dangerous to use -kall? The documentation says the kall will make the change affect all the initramfs on the machine. If the one actually working gets modified and starts to have problems I could not be able to boot for good, couldn't? Just to explore the safest way, if i make a copy of the initramfs actually present in /boot (/boot/initrd.img-3.16.0-4-amd64 (bad one, not booting) and /boot/initrd.img-3.2.0-4-amd64 (good one, booting) ), then I do update-initramfs and it doesn't work, to restore the previous situation, rewriting the modified initramfs file with the old one is enough? Or alternatively I can create a new initramfs from scratch and boot that one? > > > Reading here, though I think they were talking about ubuntu, ( > > https://ubuntuforums.org/showthread.php?t=1365365) there is a module to > > manage raid called dmraid. Maybe including that could solve the problem? > > No, dmraid is for Controller-based SoftRAID, often used with Windows Great, thanks! betta
Re: System won't boot anymore after upgrade to jessie
Elisabetta Falivene wrote: >>> Thank you, it was "dep" indeed! >> Then remove those additional files, check that MODULES=most is set in >> /etc/initramfs-tools/initramfs.conf, do a "update-initramfs -u -kall", >> and you should be good to go. > The driver policy file? It is safe to just remove it? Yes. It is a left-over from something. It is old and it is certainly not needed, it is just annoying. I had it on my Wheezy systems and removed it during the upgrade to Jessie, because it was causing the same problems you had. > Btw, isn't a bit dangerous to use -kall? The documentation says the kall > will make the change affect all the initramfs on the machine. If the one > actually working gets modified and starts to have problems I could not be > able to boot for good, couldn't? In theory. But this change just makes your initramfs more universal and thus more likely to boot on different hardware than breaking anything. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: 404 trying to use stretch/backports
Sven Hoexter composed on 2018-01-11 10:08 (UTC+0100): > On Thu, Jan 11, 2018 at 09:52:00AM +0100, john doe wrote: >> Felix Miata wrote: >> > Trying to get a non-broken recent version of mc, the instructions on >> > https://backports.debian.org/Instructions/ fail[1]. How can I get a >> > non-broken >> > relatively recent mc package installed, e.g. patched 4.8.19, or 4.8.20? >> > Breakage >> > was fixed 15 months ago[2]. >> What lines do you have in 'sources.list'? I had looked at it repeatedly, probably close to 10 times. Only after looking again after some thread replies did I spot stretch/backports where stretch-backports belongs. :-p >> The following URL is working for me: >> deb http://ftp.debian.org/debian stretch-backports main > Hey guys, > there is no backport of the mc package available, so someone has to backport > it > first. There is no automatic backport process running because that's > technically > not really possible and that's not how backports are intendet to work. > So 4.8.19 is available in unstable, that would be something someone could > backport. I don't know what the intent is in the existence of: http://ftp.debian.org/debian/pool/main/m/mc/mc_4.8.19-1_i386.deb & http://ftp.debian.org/debian/pool/main/m/mc/mc-data_4.8.19-1_all.deb especially with 4.8.20 having been released in November, but I downloaded manually and installed 4.8.19 with dpkg, and it works just fine compared to the broken 4.8.18 that had been installed. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: 404 trying to use stretch/backports
On Thu, Jan 11, 2018 at 07:35:59AM -0500, Felix Miata wrote: Hi, >I don't know what the intent is in the existence of: > http://ftp.debian.org/debian/pool/main/m/mc/mc_4.8.19-1_i386.deb & > http://ftp.debian.org/debian/pool/main/m/mc/mc-data_4.8.19-1_all.deb Those are the packages available and build on unstable. This is a combined package pool. > especially with 4.8.20 having been released in November, but I downloaded > manually and installed 4.8.19 with dpkg, and it works just fine compared to > the > broken 4.8.18 that had been installed. Well someone has to update the package for unstable first. Then it can migrate at some point to testing and then someone could build a backport base on this work. This does not happen on its own. Using the package from unstable can work but it can also break at any time due changes in libraries. Cheers, Sven
Re: System won't boot anymore after upgrade to jessie
> > > > The driver policy file? It is safe to just remove it? > > Yes. It is a left-over from something. It is old and it is certainly not > needed, it is just annoying. > Ok > > I had it on my Wheezy systems and removed it during the upgrade to > Jessie, because it was causing the same problems you had. > > > Btw, isn't a bit dangerous to use -kall? The documentation says the kall > > will make the change affect all the initramfs on the machine. If the one > > actually working gets modified and starts to have problems I could not be > > able to boot for good, couldn't? > > In theory. But this change just makes your initramfs more universal and > thus more likely to boot on different hardware than breaking anything. > Got it! Thank you very much! b
Re: 404 trying to use stretch/backports
On Thu 11 Jan 2018 at 13:43:19 +0100, Sven Hoexter wrote: > On Thu, Jan 11, 2018 at 07:35:59AM -0500, Felix Miata wrote: > > Hi, > > >I don't know what the intent is in the existence of: > > http://ftp.debian.org/debian/pool/main/m/mc/mc_4.8.19-1_i386.deb & > > http://ftp.debian.org/debian/pool/main/m/mc/mc-data_4.8.19-1_all.deb > > Those are the packages available and build on unstable. This is a combined > package pool. > > > > especially with 4.8.20 having been released in November, but I downloaded > > manually and installed 4.8.19 with dpkg, and it works just fine compared to > > the > > broken 4.8.18 that had been installed. > > Well someone has to update the package for unstable first. Then it can > migrate at > some point to testing and then someone could build a backport base on this > work. > This does not happen on its own. > > Using the package from unstable can work but it can also break at any time due > changes in libraries. I can see what you are saying about mixing stable and unstable but don't completely follow it in this case. Only mc and mc-data from unstable are needed and the libraries on stable are sufficient to produce a working mc. Are you suggesting these libraries could be subject to future change? -- Brian.
Re: Strange message during boot
On Thursday, January 11, 2018 05:29:42 AM Richard Owlett wrote: > OOPS, typos and awkward phrasing. It should have read: > When booting one specific install, it displays many repetitions of the > line to the effect that it is beginning a specific script. > Did it give you the name of the specific script? Perhaps it would help if you shared that here (along with as much of the message as you can duplicate (presumably from memory or after doing a reboot). > Specifics: > sda1 - Always has the latest version of Debian, currently 9.1 . > For housekeeping reasons it has the only copy of Grub > on my machine. > sda8 - The problem install is Debian 8. It had been my primary work > install until I trashed some data files. It has been kept to > reconstruct those files as I have time. > sda9 - Current work install of Debian 9.1 >
Re: System won't boot anymore after upgrade to jessie
On Thu, Jan 11, 2018 at 01:05:01AM +0100, deloptes wrote:
> Greg Wooledge wrote:
>
> > Moreover, the simple zcat|cpio -i no longer works with stretch's initrd
> > images. They're in a different format, and you have to use
> > lsinitramfs or unmkinitramfs to see or extract their contents.
> >
> > On a jessie system, the zcat|cpio -i may still work (not sure about
> > backported kernels though).
>
> I just tested it on stretch
>
> file /boot/initrd.img-4.14.12eko4
> /boot/initrd.img-4.14.12eko4: gzip compressed data, last modified: Tue Jan
> 9 22:45:46 2018, from Unix
>
> $ zcat /boot/initrd.img-4.14.12eko4 | cpio -id
> 76825 blocks
>
> so if it is gzip format it works perfectly - what format do you mean?
Whatever "4.14.12eko4" is, it's not a stretch kernel image.
wooledg:~$ ls /boot
config-3.16.0-4-amd64 initrd.img-4.9.0-4-amd64 System.map-4.9.0-5-amd64
config-4.9.0-4-amd64 initrd.img-4.9.0-5-amd64 vmlinuz-3.16.0-4-amd64
config-4.9.0-5-amd64 lost+found vmlinuz-4.9.0-4-amd64
grub System.map-3.16.0-4-amd64 vmlinuz-4.9.0-5-amd64
initrd.img-3.16.0-4-amd64 System.map-4.9.0-4-amd64
wooledg:~$ zcat /boot/initrd.img-3.16.0-4-amd64 | cpio -itv | head -3
drwxr-xr-x 10 root root0 Apr 10 2017 .
drwxr-xr-x 5 root root0 Apr 10 2017 scripts
-rw-r--r-- 1 root root 9187 Apr 17 2016 scripts/functions
wooledg:~$ zcat /boot/initrd.img-4.9.0-5-amd64 | cpio -itv | head -3
gzip: /boot/initrd.img-4.9.0-5-amd64: not in gzip format
cpio: premature end of archive
wooledg:~$ lsinitramfs /boot/initrd.img-4.9.0-5-amd64 | head -3
kernel
kernel/x86
kernel/x86/microcode
wooledg:~$ file /boot/initrd.img-3.16.0-4-amd64
/boot/initrd.img-3.16.0-4-amd64: gzip compressed data, last modified: Mon Apr
10 14:03:50 2017, from Unix
wooledg:~$ file /boot/initrd.img-4.9.0-5-amd64
/boot/initrd.img-4.9.0-5-amd64: ASCII cpio archive (SVR4 with no CRC)
In fact, I believe the stretch initrd images are sequences of concatenated
cpio archives, some gzipped, some not, possibly with a NUL byte or
something between them.
wooledg:~$ cpio -itv < /boot/initrd.img-4.9.0-5-amd64
drwxr-xr-x 2 root root0 Apr 9 2017 kernel
drwxr-xr-x 2 root root0 Apr 9 2017 kernel/x86
drwxr-xr-x 2 root root0 Apr 9 2017 kernel/x86/microcode
drwxr-xr-x 2 root root0 Apr 9 2017
kernel/x86/microcode/.enuineIntel.align.0123456789abc
-rw-r--r-- 1 root root98304 Apr 9 2017
kernel/x86/microcode/GenuineIntel.bin
194 blocks
Whereas, if you use lsinitramfs, you'll see far more content, from
the subsequent cpio archives in the image. Or, if you manually
string together multiple cpio commands:
wooledg:~$ { cpio -itv; echo XXX; zcat | cpio -itv | head -3; } <
/boot/initrd.img-4.9.0-5-amd64
drwxr-xr-x 2 root root0 Apr 9 2017 kernel
drwxr-xr-x 2 root root0 Apr 9 2017 kernel/x86
drwxr-xr-x 2 root root0 Apr 9 2017 kernel/x86/microcode
drwxr-xr-x 2 root root0 Apr 9 2017
kernel/x86/microcode/.enuineIntel.align.0123456789abc
-rw-r--r-- 1 root root98304 Apr 9 2017
kernel/x86/microcode/GenuineIntel.bin
194 blocks
XXX
drwxr-xr-x 10 root root0 Jan 5 08:00 .
drwxr-xr-x 5 root root0 Jan 5 08:00 scripts
-rw-r--r-- 1 root root 9394 Mar 6 2017 scripts/functions
I don't actually know how many cpio archives are concatenated together
in that image. At least two, obviously, with the first uncompressed
and the second gzipped.
Re: Why was this package removed but apt?
> It was installed because CraftCMS depends on it :) Care to give some details? E.g. *how* was it installed, then? IIUC your system needs it, so the removal caused some breakage (which is why you noticed the issue). Normally APT only auto-removes packages which are marked as "automatically installed" (i.e. installed because they are required by some other package rather than because the user explicitly asked to installed this package), so how come that package was installed and marked as "automatically installed" even though there were apparently no other package that was marked as requiring it. Stefan
Re: Strange message during boot
On 01/11/2018 07:26 AM, rhkra...@gmail.com wrote: On Thursday, January 11, 2018 05:29:42 AM Richard Owlett wrote: OOPS, typos and awkward phrasing. It should have read: When booting one specific install, it displays many repetitions of the line to the effect that it is beginning a specific script. Did it give you the name of the specific script? Perhaps it would help if you shared that here (along with as much of the message as you can duplicate (presumably from memory or after doing a reboot). Did a reboot with pen and paper at hand. The line is: Begin: Running /scrips/local-block ... done. As to other suggestions: journactl -xb yields: root@stretch-2nd:~# journactl -xb > testlog.txt bash: journactl: command not found root@stretch-2nd:~# Installed bootlogd with Synaptic. /var/log/bootlog does not exist after multiple boots However, /var/log/boot contains: (Nothing has been logged yet. If you're still seeing this message your current init system might not write bootup messages to the system console at all.) /etc/apt/sources.list indicates the install had been done with: deb cdrom:[Debian GNU/Linux stretch-DI-rc3 _Stretch_ - Official Snapshot i386 NETINST Binary-1 20170409-00:50]/ stretch main
Re: Strange message during boot
On 2018-01-11 at 09:36, Richard Owlett wrote: > On 01/11/2018 07:26 AM, rhkra...@gmail.com wrote: > >> On Thursday, January 11, 2018 05:29:42 AM Richard Owlett wrote: >> >>> OOPS, typos and awkward phrasing. It should have read: >>> When booting one specific install, it displays many repetitions of the >>> line to the effect that it is beginning a specific script. >> >> Did it give you the name of the specific script? >> >> Perhaps it would help if you shared that here (along with as much of the >> message as you can duplicate (presumably from memory or after doing a >> reboot). > > > Did a reboot with pen and paper at hand. > The line is: >> Begin: Running /scrips/local-block ... done. Does it really say 'scrips' rather than 'scripts'? Googling on that error message (with the presumed typo corrected) leads me to http://forums.debian.net/viewtopic.php?f=5&t=133578 as a first hit. 'dlocate scripts/local-block' finds three packages on my system: cryptsetup, lvm2, and mdadm. Results on your system may differ. I would suggest running that command on your system and investigating the resulting list of packages. > As to other suggestions: > > journactl -xb yields: That should be 'journalctl'. >> root@stretch-2nd:~# journactl -xb > testlog.txt >> bash: journactl: command not found >> root@stretch-2nd:~# > > Installed bootlogd with Synaptic. /var/log/bootlog does not exist after > multiple boots > > However, /var/log/boot contains: >> (Nothing has been logged yet. If you're still seeing this message your >> current init system might not write bootup messages to the system console at >> all.) What init system are you running? Usually, this can be determined by 'dlocate /sbin/init', but I can't guarantee that that will hold for all systems. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Strange message during boot
On Thu 11 Jan 2018 at 09:45:35 -0500, The Wanderer wrote: > What init system are you running? > > Usually, this can be determined by 'dlocate /sbin/init', but I can't > guarantee that that will hold for all systems. Guaranteed: 'cat /proc/1/comm'. -- Brian.
Re: Why was this package removed but apt?
Well, it was removed by unattended-upgrades according to term.log and apt.log :) / Jonathan On 01/11/2018 03:35 PM, Stefan Monnier wrote: It was installed manually by me: apt install php7.1-mbstring So I "explicitly asked" apt to install that package actually. So now the question is why/how did this package end up marked "automatically installed" (or if it wasn't, why did unattended-upgrades remove it even tho it wasn't marked as automatically-installed; tho this would most likely be a bug in unattended-upgrades and I think such a bug is rather unlikely at this stage). Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: Strange message during boot
On 2018-01-11 at 10:23, Brian wrote: > On Thu 11 Jan 2018 at 09:45:35 -0500, The Wanderer wrote: > >> What init system are you running? >> >> Usually, this can be determined by 'dlocate /sbin/init', but I can't >> guarantee that that will hold for all systems. > > Guaranteed: 'cat /proc/1/comm'. On my system: $ dlocate /sbin/init sysvinit-core: /sbin/init $ cat /proc/1/comm init So the former command produces recognizably useful information, whereas the latter does not. I can't be sure what the latter command would output on a different system, not having tested it - but since AFAIK the standard practice is to launch the init system via /sbin/init (symlinked to something else if necessary) regardless, I would expect the command to be 'init' in all cases. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Strange message during boot
On Thu, Jan 11, 2018 at 10:27:33AM -0500, The Wanderer wrote: > On 2018-01-11 at 10:23, Brian wrote: > > > On Thu 11 Jan 2018 at 09:45:35 -0500, The Wanderer wrote: > > > >> What init system are you running? > >> > >> Usually, this can be determined by 'dlocate /sbin/init', but I can't > >> guarantee that that will hold for all systems. > > > > Guaranteed: 'cat /proc/1/comm'. > > On my system: > > $ dlocate /sbin/init > sysvinit-core: /sbin/init > $ cat /proc/1/comm > init > > So the former command produces recognizably useful information, whereas > the latter does not. > > I can't be sure what the latter command would output on a different > system, not having tested it - but since AFAIK the standard practice is > to launch the init system via /sbin/init (symlinked to something else if > necessary) regardless, I would expect the command to be 'init' in all > cases. wooledg:~$ ls -l /sbin/init lrwxrwxrwx 1 root root 20 Jul 5 2017 /sbin/init -> /lib/systemd/systemd wooledg:~$ cat /proc/1/comm systemd P.S. "ls -l /sbin/init" is the command we usually give to people in #debian when they ask similar questions.
Re: Strange message during boot
On 2018-01-11 at 10:35, Greg Wooledge wrote: > On Thu, Jan 11, 2018 at 10:27:33AM -0500, The Wanderer wrote: > >> On 2018-01-11 at 10:23, Brian wrote: >>> Guaranteed: 'cat /proc/1/comm'. >> >> On my system: >> >> $ dlocate /sbin/init >> sysvinit-core: /sbin/init >> $ cat /proc/1/comm >> init >> >> So the former command produces recognizably useful information, whereas >> the latter does not. >> >> I can't be sure what the latter command would output on a different >> system, not having tested it - but since AFAIK the standard practice is >> to launch the init system via /sbin/init (symlinked to something else if >> necessary) regardless, I would expect the command to be 'init' in all >> cases. > > wooledg:~$ ls -l /sbin/init > lrwxrwxrwx 1 root root 20 Jul 5 2017 /sbin/init -> /lib/systemd/systemd > wooledg:~$ cat /proc/1/comm > systemd So it's smart enough to bypass the name of the symlink when populating this node? I'm a little bit surprised, especially given the number of programs which intentionally behave differently depending on which name they were invoked with, but that could be useful in some circumstances. > P.S. "ls -l /sbin/init" is the command we usually give to people in > #debian when they ask similar questions. Right. I meant to bring that up at some point in the thread, but it slipped my mind during editing passes on what I'd already written. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
iwlwifi and symbols table
Hi I just upgraded to Stretch. At boot I get a warning: " No symbols table" (actually it is in French: "pas de table des symboles"). Nevertheless everything works, except my access point: "modprobe iwlwifi.ko" can't find this module in the kernel directory, but this module is there. I remember there was a problem with this module in Jessie, but I can't remember the solution. Please help.
[Diagnostic Summary] Re: Strange message during boot
I multi-boot several varieties of Debian. When booting one specific install, it displays many repetitions of: Begin: Running /scripts/local-block ... done. It then proceeds to bring up an apparently normal system. Would this be logged somewhere? Where? Specifics: sda1 - Always has the latest version of Debian, currently 9.1 . For housekeeping reasons it has the only copy of Grub on my machine. sda8 - The problem install is Debian 8. It had been my primary work install until I trashed some data files. It has been kept to reconstruct those files as I have time. sda9 - Current work install of Debian 9.1 Suggested diagnostics yielded: root@stretch-2nd:~# ls -l /sbin/init lrwxrwxrwx 1 root root 20 Jun 4 2017 /sbin/init -> /lib/systemd/systemd root@stretch-2nd:~# /etc/apt/sources.list indicates the install had been done with: deb cdrom:[Debian GNU/Linux stretch-DI-rc3 _Stretch_ - Official Snapshot i386 NETINST Binary-1 20170409-00:50]/ stretch main root@stretch-2nd:~# dlocate /sbin/init bash: dlocate: command not found root@stretch-2nd:~# journalctl -xb > jan11test The string of interest not present. /usr/share/initramfs-tools/ does not exist /etc/initramfs-tools/scripts has 10 empty folders
Re: [Diagnostic Summary] Re: Strange message during boot
On 2018-01-11 at 12:10, Richard Owlett wrote:
> I multi-boot several varieties of Debian.
> When booting one specific install, it displays many repetitions of:
>>> Begin: Running /scripts/local-block ... done.
>
> It then proceeds to bring up an apparently normal system.
> Suggested diagnostics yielded:
>
>> root@stretch-2nd:~# ls -l /sbin/init
>> lrwxrwxrwx 1 root root 20 Jun 4 2017 /sbin/init -> /lib/systemd/systemd
>> root@stretch-2nd:~#
Not particularly unexpected. (This also obviates any need to 'dlocate
/sbin/init', since it confirms which init system you're running.)
>> bash: dlocate: command not found
Install it ('apt-get install dlocate'), then try
'dlocate scripts/local-block'. If that fails, try running 'updatedb' to
initialize the search database, then run the command again.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: [Diagnostic Summary] Re: Strange message during boot
On Thu, 11 Jan 2018, Richard Owlett wrote: > I multi-boot several varieties of Debian. > When booting one specific install, it displays many repetitions of: > > > Begin: Running /scripts/local-block ... done. > > It then proceeds to bring up an apparently normal system. > Would this be logged somewhere? > Where? > > Specifics: > sda1 - Always has the latest version of Debian, currently 9.1 . >For housekeeping reasons it has the only copy of Grub >on my machine. > sda8 - The problem install is Debian 8. It had been my primary work >install until I trashed some data files. It has been kept to >reconstruct those files as I have time. > sda9 - Current work install of Debian 9.1 > > Suggested diagnostics yielded: > > > root@stretch-2nd:~# ls -l /sbin/init > > lrwxrwxrwx 1 root root 20 Jun 4 2017 /sbin/init -> /lib/systemd/systemd > > root@stretch-2nd:~# > > /etc/apt/sources.list indicates the install had been done with: > deb cdrom:[Debian GNU/Linux stretch-DI-rc3 _Stretch_ - Official Snapshot i386 > NETINST Binary-1 20170409-00:50]/ stretch main > > > > > root@stretch-2nd:~# dlocate /sbin/init > > bash: dlocate: command not found > > root@stretch-2nd:~# > > > > journalctl -xb > jan11test > The string of interest not present. > > /usr/share/initramfs-tools/ does not exist > /etc/initramfs-tools/scripts has 10 empty folders > Doesn't sound right. ls -l /usr/share/initramfs-tools/ total 52 drwxr-xr-x 2 root root 4096 Apr 25 2017 conf.d drwxr-xr-x 2 root root 4096 Jun 19 2017 conf-hooks.d -rw-r--r-- 1 root root 19249 Mar 6 2017 hook-functions drwxr-xr-x 2 root root 4096 Nov 10 07:57 hooks -rwxr-xr-x 1 root root 5960 Apr 23 2017 init -rw-r--r-- 1 root root 357 Mar 1 2015 modules drwxr-xr-x 2 root root 4096 Apr 25 2017 modules.d drwxr-xr-x 8 root root 4096 Nov 10 07:57 scripts ls -l /usr/share/initramfs-tools/scripts/ total 48 -rw-r--r-- 1 root root 9394 Mar 6 2017 functions drwxr-xr-x 2 root root 4096 Nov 10 07:57 init-bottom drwxr-xr-x 2 root root 4096 Nov 10 07:57 init-premount drwxr-xr-x 2 root root 4096 Nov 9 05:04 init-top -rw-r--r-- 1 root root 5607 Apr 8 2017 local drwxr-xr-x 2 root root 4096 Jun 19 2017 local-bottom drwxr-xr-x 2 root root 4096 Jun 19 2017 local-premount -rw-r--r-- 1 root root 3050 Feb 20 2016 nfs drwxr-xr-x 2 root root 4096 Nov 10 07:57 panic apt policy initramfs-tools initramfs-tools: Installed: 0.130 Candidate: 0.130 Version table: *** 0.130 500 500 http://http.us.debian.org/debian stretch/main amd64 Packages 100 /var/lib/dpkg/status
Re: Strange message during boot
On 2018-01-11 10:44 -0500, The Wanderer wrote: > On 2018-01-11 at 10:35, Greg Wooledge wrote: > >> wooledg:~$ ls -l /sbin/init >> lrwxrwxrwx 1 root root 20 Jul 5 2017 /sbin/init -> /lib/systemd/systemd >> wooledg:~$ cat /proc/1/comm >> systemd > > So it's smart enough to bypass the name of the symlink when populating > this node? No, it is systemd itself which sets its title, very early on in main(): , | static char systemd[] = "systemd"; | [...] | /* If we get started via the /sbin/init symlink then we are |called 'init'. After a subsequent reexecution we are then |called 'systemd'. That is confusing, hence let's call us |systemd right-away. */ | program_invocation_short_name = systemd; | (void) prctl(PR_SET_NAME, systemd); ` Cheers, Sven
Re: [Diagnostic Summary] Re: Strange message during boot
On 2018-01-11 at 12:35, bw wrote:
> On Thu, 11 Jan 2018, The Wanderer wrote:
>
>> On 2018-01-11 at 12:10, Richard Owlett wrote:
>>
>> > I multi-boot several varieties of Debian.
>> > When booting one specific install, it displays many repetitions of:
>> >>> Begin: Running /scripts/local-block ... done.
>> >
>> > It then proceeds to bring up an apparently normal system.
>>
>> > Suggested diagnostics yielded:
>> >
>> >> root@stretch-2nd:~# ls -l /sbin/init
>> >> lrwxrwxrwx 1 root root 20 Jun 4 2017 /sbin/init -> /lib/systemd/systemd
>> >> root@stretch-2nd:~#
>>
>> Not particularly unexpected. (This also obviates any need to 'dlocate
>> /sbin/init', since it confirms which init system you're running.)
>>
>> >> bash: dlocate: command not found
>>
>> Install it ('apt-get install dlocate'), then try
>> 'dlocate scripts/local-block'. If that fails, try running 'updatedb' to
>> initialize the search database, then run the command again.
>
> On stretch local_block is a function in a script named local, maybe using
> a stretch tool on jessie has things confused? or the initramfs-tools pkg
> is hosed on the bad system. Sounds complicated, one version of grub but
> separate boot partitions always gets me confused too.
>
> grep local_block /usr/share/initramfs-tools/scripts/local
> local_block()
> local_block "${dev_id}"
That's local_block; this appears to be local-block.
On my system (stable+testing, though with sysvinit rather than systemd):
$ dlocate scripts/local-block
mdadm: /usr/share/initramfs-tools/scripts/local-block
mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm
lvm2: /usr/share/initramfs-tools/scripts/local-block
lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: [Diagnostic Summary] Re: Strange message during boot
On 01/11/2018 11:35 AM, bw wrote: [snip] Sounds complicated, one version of grub but separate boot partitions always gets me confused too. Not sure best solution. But I'm used to it and have not discovered any potholes. YET ;/ I've had it that way since Squeeze in order to force update-grub to be run-able from only one environment. At the time I was doing multiple install in a day to experiment with package complement and configurations.
Re: Kernel problem?
On Wed 10 Jan 2018 at 19:48:57 (-0500), Felix Miata wrote: > deloptes composed on 2018-01-11 01:12 (UTC+0100): > > > David Wright wrote: > > >>> It seemed to install vmlinuz-4.9.0-5-686-pae (and associated config and > >>> image files, etc) in place of 4.9.0-4-686-pae versions. Now the system > > >> [spaces inserted] ↑↑↑ really? It's a different package so > >> it should install alongside the old one. > > > no, this is one and the same package - just a different debian revision - so > > the previous gets replaced AFAIK Sorry, but evidently you don't. > I think you missed this same thread post from yesterday: > https://lists.debian.org/debian-user/2018/01/msg00372.html I'm not sure that would help. The first half of that post showed a very idiosyncratic /boot listing which seems to be customised to support your own multibooting setup. I'm not sure whether it would help or confuse the OP. The second half didn't take any account of what the various parts of the version numbers mean. They're not just there as a joke, or an accident of punctuation. The kernel-image maintainers update the Debian versions, and *their* numbers, as quickly as possible. OTOH they strive to change the ABI number as *slowly* as possible. Your advice was wrong: you don't want to wait for an ABI change. You should only revert to the old ABI version to get the system up so that you can investigate why the new one won't work.¹ You should leave the new ABI version installed so that any normal upgrades of it will take place. (It's always possible that the reason the system didn't boot is because another bug was present, and gets fixed in the usual manner.) No one knows when the next ABI change will take place. It could be tomorrow; it could be years away. ¹ There may be folks, too, who have yet to make kernel module changes to suit the new ABI. Disclaimer: sorry if you get hacked. Cheers, David.
Re: 404 trying to use stretch/backports
Brian wrote: > I can see what you are saying about mixing stable and unstable but don't > completely follow it in this case. Only mc and mc-data from unstable are > needed and the libraries on stable are sufficient to produce a working > mc. Are you suggesting these libraries could be subject to future change? Brian, not future - present changes. You compile the code against higher version of the library and use it with lower version. If the library was changed (lower -> higher), the program can break when this part of the code is executed. This might be true for mc or not, we don't know, but the risk is there. If OP is lucky there won't be an issue, but there is no guarantee.
Re: System won't boot anymore after upgrade to jessie
Greg Wooledge wrote: > I don't actually know how many cpio archives are concatenated together > in that image. At least two, obviously, with the first uncompressed > and the second gzipped. This kernel is custom, produced on one stretch system. On other stretch system another custom image is as you describe it. Something must be responsible for producing those images on stretch in different format. Who knows what is that exactly - would save me some time - is it automatically done by size or an option somewhere? regards
Re: [Diagnostic Summary] Re: Strange message during boot
On Thu 11 Jan 2018 at 11:10:33 (-0600), Richard Owlett wrote: > I multi-boot several varieties of Debian. > When booting one specific install, it displays many repetitions of: > >>Begin: Running /scripts/local-block ... done. > It then proceeds to bring up an apparently normal system. […] > sda8 - The problem install is Debian 8. It had been my primary work >install until I trashed some data files. It has been kept to >reconstruct those files as I have time. Two questions: When did this start happening? In view of the portion quoted above, why bother? Cheers, David.
Re: Kernel problem?
David Wright composed on 2018-01-11 12:52 (UTC-0600): > On Wed 10 Jan 2018 at 19:48:57 (-0500), Felix Miata wrote: >> deloptes composed on 2018-01-11 01:12 (UTC+0100): >> > David Wright wrote: >> >>> It seemed to install vmlinuz-4.9.0-5-686-pae (and associated config and >> >>> image files, etc) in place of 4.9.0-4-686-pae versions. Now the system >> >> [spaces inserted] ↑↑↑ really? It's a different package so >> >> it should install alongside the old one. >> > no, this is one and the same package - just a different debian revision - >> > so >> > the previous gets replaced AFAIK > Sorry, but evidently you don't. Who didn't get what? >> I think you missed this same thread post from yesterday: >> https://lists.debian.org/debian-user/2018/01/msg00372.html > I'm not sure that would help. The first half of that post showed > a very idiosyncratic /boot listing which seems to be customised > to support your own multibooting setup. I'm not sure whether it > would help or confuse the OP. I expected it to. Here's the same listing with nonessential lines excised: -rw-r--r-- 1 17388979 Jan 9 17:45 initrd.img-4.9.0-4-686-pae -rw-r--r-- 1 17392772 Jan 9 17:44 initrd.img-4.9.0-5-686-pae -rw-r--r-- 1 3643920 Dec 22 19:39 vmlinuz-4.9.0-4-686-pae -rw-r--r-- 1 3645296 Jan 4 06:12 vmlinuz-4.9.0-5-686-pae Clearly, 4.9.0-4 and 4.9.0-5 pae kernels are present, the very kernels in the OP that, as I read, deloptes subsequently claimed were "one and the same package" (could not coexist). -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: 404 trying to use stretch/backports
bw composed on 2018-01-11 14:44 (UTC-0500): > I wouldn't install mc from unstable or testing on stretch, BUT I do love > the program. I don't consider it broken at all, Running which version(s)? > and over the years it has > been well-maintained and I appreciate it. I use it all day every day, so For me it or one of its OFM[1] relatives are indispensable. My systems have trivial uptime without at least one running. Typically more than one are open. > maybe the best way to get it backported is to setup a testing system and > test it and file some bugs. > The maintainer already has that on his radar, so maybe it's possible. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858808 I filed that bug 10 months ago, 5 months after the fix was committed upstream. 4.8.14, 4.8.15 and 4.8.16 had bugs that for me were not tolerable. 4.8.17 was good, but the only versions in http://ftp.debian.org/debian/pool/main/m/mc/ are 4.8.13 (ancient), 4.8.18 (by 858808 broken) and 4.8.19 (officially broken, but including the fix that was officially included in 4.8.20). [1] http://www.softpanorama.org/OFM/Paradigm/ https://en.wikipedia.org/wiki/File_manager#Orthodox_file_managers -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Keyboard language randomly changes to Arabic(?)
Hi everyone, I've encountered a strange problem where my keyboard layout/language changes when I'm typing. I'm running on Debian buster, upgraded with all the latest updates. But I think this problem has been around for a while (a few months at least). It is reproducible. 1. Open an xfce4-terminal or Libre Office Writer (and I suspect other programs will work too) 2. Type slowly the "pipe" character followed by the "space" character: "| ". This will produce the desired results. 3. Type rapidly the above two character combination and the keyboard language changes. As you can guess, this two character combination is extremely common when typing on the command line, and having the keyboard language change mid stream is not good. To the best of my knowledge, the keyboard language changes from English to what I think is Arabic (which runs from right to left). But it might be one of the other right to left languages from that part of the world. I have no clue how to change back to English other than killing and restarting the affected program, which is highly annoying. Has anyone else encountered this problem, and does anyone know a fix? Cheers, Tim Sent with [ProtonMail](https://protonmail.com) Secure Email.
Re: Keyboard language randomly changes to Arabic(?)
On Thu, Jan 11, 2018 at 10:40 PM, Tim Hume wrote: > Has anyone else encountered this problem, and does anyone know a fix? Very interesting and no real idea how to fix it, but similar actions. I tried your pipe-space recipe, and it killed Tor, my connection to Gmail. (Re-connect Tor.) And the other day, the xfce4 terminal started ignoring the letter 's'. I know for sure it wasn't the keyboard, but a reboot made it stop. I can't think of a reasonable explanation of how this could happen. -- Glenn English
Re: Kernel problem?
On Thu 11 Jan 2018 at 15:35:36 (-0500), Felix Miata wrote: > David Wright composed on 2018-01-11 12:52 (UTC-0600): > > > On Wed 10 Jan 2018 at 19:48:57 (-0500), Felix Miata wrote: > > >> deloptes composed on 2018-01-11 01:12 (UTC+0100): > > >> > David Wright wrote: > > >> >>> It seemed to install vmlinuz-4.9.0-5-686-pae (and associated config and > >> >>> image files, etc) in place of 4.9.0-4-686-pae versions. Now the system > > >> >> [spaces inserted] ↑↑↑ really? It's a different package so > >> >> it should install alongside the old one. > > >> > no, this is one and the same package - just a different debian revision > >> > - so > >> > the previous gets replaced AFAIK > > > Sorry, but evidently you don't. > > Who didn't get what? Here are the lines whose prefix-quoting displays the answer: > >> deloptes composed on 2018-01-11 01:12 (UTC+0100): > >> > no, this is one and the same package - just a different debian revision > >> > - so > >> > the previous gets replaced AFAIK [As Far As I Know] ↑___the extra > indicates which lines deloptes wrote. IOW who deloptes … what … was mistaken in distinguishing between "package name" and "Debian version" in the excerpt posted by the OP. > >> I think you missed this same thread post from yesterday: > >> https://lists.debian.org/debian-user/2018/01/msg00372.html > > > I'm not sure that would help. The first half of that post showed > > a very idiosyncratic /boot listing which seems to be customised > > to support your own multibooting setup. I'm not sure whether it > > would help or confuse the OP. > > I expected it to. Here's the same listing with nonessential lines excised: > > -rw-r--r-- 1 17388979 Jan 9 17:45 initrd.img-4.9.0-4-686-pae > -rw-r--r-- 1 17392772 Jan 9 17:44 initrd.img-4.9.0-5-686-pae > -rw-r--r-- 1 3643920 Dec 22 19:39 vmlinuz-4.9.0-4-686-pae > -rw-r--r-- 1 3645296 Jan 4 06:12 vmlinuz-4.9.0-5-686-pae That's much clearer. But then your post went on to talk about deleting and copying the (duly noted) additional symlinks. These (as seen in your earlier post) are things that you've made for yourself for a purpose that's clear to you, but probably not clear to most people running a more conventional booting setup. > Clearly, 4.9.0-4 and 4.9.0-5 pae kernels are present, the very kernels in the > OP > that, as I read, deloptes subsequently claimed were "one and the same package" > (could not coexist). That's right: deloptes claim was mistaken, which I pointed out because errors of fact need correcting. I didn't mean to mystify you (or anybody else). It follows that if you don't dist-upgrade (apt-get's sense) when the ABI is bumped, the new package won't be installed. If you don't have the generic metapackage installed, you might not even be aware that the ABI *has* been bumped—you just stop getting kernel upgrades for no discernible reason. AIUI (do correct me) only the latest ABI's version gets updated after the change. Cheers, David.
Re: Keyboard language randomly changes to Arabic(?)
On Thu, 11 Jan 2018, Tim Hume wrote: > I've encountered a strange problem where my keyboard layout/language > changes when I'm typing. I'm running on Debian buster, upgraded with > all the latest updates. I'm not certain, but I wonder if you're accidentally hitting the layout switch key when you type '| ' quickly. Often it's mapped to shift-caps or something like that. setxkbmap -print; should tell you what your default keymap is set to and what the possible alternates are. [There may also be an XFCE specific way of setting this.] -- Don Armstrong https://www.donarmstrong.com "Them as can do has to do for them as can't. And someone has to speak up for them as have no voices." -- Grandma Aching in _The Wee Free Men_ by Terry Pratchett p227
debian CD's DVD's
Hi there! In the past it was possible to download debian cd's dvd's so one could have a full debian at home. Now this is not possible, I am missing some links? The jigdo files do not work nowadays too. The maximum debian you can get nowadays is 3 DVD's. The rule seems to be a fast internet connection nowadays! Am I missing some links? Thanks, and a happy new year!
Re: debian CD's DVD's
On 01/11/18 20:17, arne wrote: In the past it was possible to download debian cd's dvd's so one could have a full debian at home. Now this is not possible, I am missing some links? The jigdo files do not work nowadays too. The maximum debian you can get nowadays is 3 DVD's. The rule seems to be a fast internet connection nowadays! Am I missing some links? https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ Only the first few images are available! Where are the rest? We don't store/serve the full set of ISO images for all architectures, to reduce the amount of space taken up on the mirrors. You can use the jigdo tool to recreate the missing ISO images instead. https://www.debian.org/CD/jigdo-cd/ It looks like only a few CD's are available: https://cdimage.debian.org/debian-cd/current/amd64/jigdo-cd/ But the full set of DVD's and BD's are available: https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd/ https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/ David
Re: Kernel problem?
David Wright wrote: > That's right: deloptes claim was mistaken, which I pointed out > because errors of fact need correcting. > I didn't mean to mystify you (or anybody else). Sorry I agree with you, I also learned something, thanks.
