First Release Candidate of Grml version 2014.03 released
Hi,
so we did it again, the first release candidate of the upcoming Grml version 2014.03, code-named 'Ponywagon' was released.
This Grml release provides fresh software packages from Debian testing (AKA jessie). As usual it also incorporates up2date hardware support and fixes known bugs from the previous Grml release.
For detailed information about the changes between 2013.09 and 2014.03 have a look at the official release announcement:
http://grml.org/changelogs/README-grml-2014.03-rc1/
Please test the ISOs and everything you usually use and report back so we can complete the stable release soon. If no major problems come up, the next iteration will be the stable release, which is scheduled for the end of March (2014 ;)).
PS: As you might notice the ISOs increased again (e.g. from ~350MB to 400MB for grml-full), if someone is interested in reducing the ISO we welcome any patches, concrete feedback,..
Thanks to all contributors!
regards, -mika- - for the Grml.org project
Michael Prokop wrote...
For detailed information about the changes between 2013.09 and 2014.03 have a look at the official release announcement:
Great to hear.
Please test the ISOs and everything you usually use and report back so we can complete the stable release soon.
Feedback to the devel list here?
Using grml32small: I had never reported the CPU kernel options got a bit to tight in 2013.09 the latest (cx8 and cmov were needed). You reverted that on your own, and so a ten-year old VIA C3 based board boots again. (Not that I really care, that box is no longer in production.)
Just using it for a first test, on a probably not-that-common setup: grml toram fetch=http://...
There are some messages from live-boot, all typos are mine:
Begin: Copying /etc/resolv.conf to /root/etc/resolv.conf ... cp: can't create '/root/etc/resolv.con': No such file or directory
Being: Preconfiguring networking ... /init: line 93: can't create /root/etc/resolv.conf: nonexistent directory. sh: !: unknown operand cat: can't open '/root/etc/resolv.conf': no such file or directory
A /etc/resolv.conf does exists after startup and it has sound content, so perhaps this is rather cosmetical.
More tests to come.
PS: As you might notice the ISOs increased again (e.g. from ~350MB to 400MB for grml-full), if someone is interested in reducing the ISO we welcome any patches, concrete feedback,..
Can't hear ya!
Christoph
Hej,
* Christoph Biedl [Mon Mar 24, 2014 at 11:22:38PM +0100]:
Michael Prokop wrote...
Please test the ISOs and everything you usually use and report back so we can complete the stable release soon.
Feedback to the devel list here?
Sure, also welcome :)
Using grml32small: I had never reported the CPU kernel options got a bit to tight in 2013.09 the latest (cx8 and cmov were needed). You reverted that on your own, and so a ten-year old VIA C3 based board boots again. (Not that I really care, that box is no longer in production.)
Ok, we basically follow what Debian is doing with their kernel to keep it as close to Debian as possible.
Just using it for a first test, on a probably not-that-common setup: grml toram fetch=http://...
There are some messages from live-boot, all typos are mine:
Begin: Copying /etc/resolv.conf to /root/etc/resolv.conf ... cp: can't create '/root/etc/resolv.con': No such file or directory
Being: Preconfiguring networking ... /init: line 93: can't create /root/etc/resolv.conf: nonexistent directory. sh: !: unknown operand cat: can't open '/root/etc/resolv.conf': no such file or directory
A /etc/resolv.conf does exists after startup and it has sound content, so perhaps this is rather cosmetical.
Ah, not really beautiful, right - thanks for reporting.
More tests to come.
Great, thanks!
PS: As you might notice the ISOs increased again (e.g. from ~350MB to 400MB for grml-full), if someone is interested in reducing the ISO we welcome any patches, concrete feedback,..
Can't hear ya!
:p
regards, -mika-
On 03/24/2014 03:22 PM, Christoph Biedl wrote:
Just using it for a first test, on a probably not-that-common setup: grml toram fetch=http://...
There are some messages from live-boot, all typos are mine:
Begin: Copying /etc/resolv.conf to /root/etc/resolv.conf ... cp: can't create '/root/etc/resolv.con': No such file or directory
Being: Preconfiguring networking ... /init: line 93: can't create /root/etc/resolv.conf: nonexistent directory. sh: !: unknown operand cat: can't open '/root/etc/resolv.conf': no such file or directory
A /etc/resolv.conf does exists after startup and it has sound content, so perhaps this is rather cosmetical.
So everything works as expected? Which squashfs are you downloading with fetch=? Your own? Is it 64 or 32 bit? I made some tests with our squashfs files and I only had similar error messages when booting the 64 bit version. But it eventually fails with "Format exec error" which is obvious ;) (The 64 bit version works though when booting with grml64-full)
greets Jimmy
Andreas "Jimmy" Gredler wrote...
So everything works as expected? Which squashfs are you downloading with fetch=? Your own? Is it 64 or 32 bit?
This part worked so far. And don't worry, no dirty tricks. It's just all three files from the grml32small image itself.
I made some tests with our squashfs files and I only had similar error messages when booting the 64 bit version. But it eventually fails with "Format exec error" which is obvious ;) (The 64 bit version works though when booting with grml64-full)
Cannot continue testing netboot, ipxe is driving me nuts one more time. If anybody has an idea why a bitwise identical undionly.kpxe works perfectly on one host but yields the dreaded "menu: command not found" on a second one ... now running out of time I'd rather spend for more tests.
Completely different story: Could somebody verify, using qemu-kvm as in Debian wheezy (1.1.2+dfsg-6)
- Run "kvm -cdrom grml32-small_2014.03-rc1.iso" - Trigger reboot, either "echo b /proc/sysrq_trigger" or "system_reset" on the qemu console (Alt-Ctrl-2) - Choose "disable framebuffer" (to be able to read the early kernel messages"
=> "XZ-compressed data is corrupt"
This did not happen with grml32-small_2013.09.iso but might be a kernel/qemu bug as well.
Christoph
Christoph Biedl wrote...
Cannot continue testing netboot, ipxe is driving me nuts one more time. If anybody has an idea why a bitwise identical undionly.kpxe works perfectly on one host but yields the dreaded "menu: command not found" on a second one ...
Nasty feature of qemu, not a Grml problem.
(...)
=> "XZ-compressed data is corrupt"
This did not happen with grml32-small_2013.09.iso but might be a kernel/qemu bug as well.
Reproducible using libvirt, could not reproduce on real hardware or in virtualbox. So I suspect some oddities in qemu's handling of virtualized memory that collide with some assumptions of the xz compressor. Investigating into that is a fascinating challenge but I don't expect to have time for that before the weekend.
Mention this issue in the release notes?
Could somebody check using xen?
Christoph
Christoph Biedl wrote...
Completely different story: Could somebody verify, using qemu-kvm as in Debian wheezy (1.1.2+dfsg-6)
- Run "kvm -cdrom grml32-small_2014.03-rc1.iso"
(...)
Trying to reproduce that using grml64-small_2014.03-rc1.iso made things worse:
grml stalls for some time (minute?) at "Begin: Mount root file system ...", then eventually drops into the rescue shell. I call that "unusable".
Reproducer, as already mentioned above: qemu-kvm as in Debian wheezy (1.1.2+dfsg-6), command line is
$ kvm -cdrom grml64-small_2014.03-rc1.iso
Christoph
On 03/24/2014 11:58 PM, Christoph Biedl wrote:
Andreas "Jimmy" Gredler wrote...
Completely different story: Could somebody verify, using qemu-kvm as in Debian wheezy (1.1.2+dfsg-6)
- Run "kvm -cdrom grml32-small_2014.03-rc1.iso"
- Trigger reboot, either "echo b /proc/sysrq_trigger" or "system_reset" on the qemu console (Alt-Ctrl-2)
- Choose "disable framebuffer" (to be able to read the early kernel messages"
=> "XZ-compressed data is corrupt"
Same here with Debian wheezy :(
greets Jimmy
* Andreas Gredler [Fri Mar 28, 2014 at 11:09:05AM -0700]:
On 03/24/2014 11:58 PM, Christoph Biedl wrote:
Andreas "Jimmy" Gredler wrote...
Completely different story: Could somebody verify, using qemu-kvm as in Debian wheezy (1.1.2+dfsg-6)
- Run "kvm -cdrom grml32-small_2014.03-rc1.iso"
- Trigger reboot, either "echo b /proc/sysrq_trigger" or "system_reset" on the qemu console (Alt-Ctrl-2)
- Choose "disable framebuffer" (to be able to read the early kernel messages"
=> "XZ-compressed data is corrupt"
Same here with Debian wheezy :(
Can someone reproduce this problem on a different system than Debian wheezy? (kvm/qemu-system-x86 1.7.0+dfsg-3 is available on jessie+sid, of course it would be interesting to know current on systems other than Debian as well)
regards, -mika-
Michael Prokop wrote...
[ "XZ-compressed data is corrupt" ]
Can someone reproduce this problem on a different system than Debian wheezy? (kvm/qemu-system-x86 1.7.0+dfsg-3 is available on jessie+sid, of course it would be interesting to know current on systems other than Debian as well)
That error did not occur when using qemu-kvm 1.7.0+dfsg-3, ran in a jessie chroot.
Christoph
* Christoph Biedl [Sat Mar 29, 2014 at 09:20:52PM +0100]:
Michael Prokop wrote...
[ "XZ-compressed data is corrupt" ]
Can someone reproduce this problem on a different system than Debian wheezy? (kvm/qemu-system-x86 1.7.0+dfsg-3 is available on jessie+sid, of course it would be interesting to know current on systems other than Debian as well)
That error did not occur when using qemu-kvm 1.7.0+dfsg-3, ran in a jessie chroot.
Jey, so I don't consider this a release stopper. Thanks a lot for verification!
regards, -mika-
On 03/29/2014 12:02 PM, Michael Prokop wrote:
- Andreas Gredler [Fri Mar 28, 2014 at 11:09:05AM -0700]:
Same here with Debian wheezy :(
Can someone reproduce this problem on a different system than Debian wheezy? (kvm/qemu-system-x86 1.7.0+dfsg-3 is available on jessie+sid, of course it would be interesting to know current on systems other than Debian as well)
Tested with jessie and it works without any problems. Tested with Ubuntu 13.10 (kernel 3.11 and kvm 1.5.0...) and it seems to work. In my first tests I sometimes had to send system_reset twice and sometimes booting took longer than the first boot. But the last 5 test runs worked without any problems, so maybe something was wrong on my host system Tested with openSUSE (nested virt. in vSphere 5.5) and it works.
(Tested on my netbook which is X121e with AMD! Last tests were on my X230 with Intel)
greets Jimmy
* Andreas Gredler [Sat Mar 29, 2014 at 02:05:56PM -0700]:
[possible kvm issue]
Tested with jessie and it works without any problems. Tested with Ubuntu 13.10 (kernel 3.11 and kvm 1.5.0...) and it seems to work. In my first tests I sometimes had to send system_reset twice and sometimes booting took longer than the first boot. But the last 5 test runs worked without any problems, so maybe something was wrong on my host system Tested with openSUSE (nested virt. in vSphere 5.5) and it works.
Jey, thanks a bunch. :)
regards, -mika-
On Mon, Mar 24, 2014 at 11:22:38PM +0100, Christoph Biedl wrote:
Just using it for a first test, on a probably not-that-common setup: grml toram fetch=http://...
I do the same, and 2013.09 works just fine.
With 2014.03-rc1, the kernel boots, inits the network, loads the squashfs via http, and then says "Killed" three times and stops dead.
My grml.ipxe: #!ipxe
kernel http://192.168.192.254/boot/grml64-small_2014.03-rc1/boot/grml64small/vmlinu... quiet lang=de boot=live noquick noeject noprompt bootid=grml64small201403rc1 radeon.modeset=1 keyboard=de fetch=http://192.168.192.254/boot/grml64-small_2014.03-rc1/live/grml64-small/grml6... ethdevice-timeout=30 initrd http://192.168.192.254/boot/grml64-small_2014.03-rc1/boot/grml64small/initrd... boot
Greetings Marc
Marc Haber wrote...
With 2014.03-rc1, the kernel boots, inits the network, loads the squashfs via http, and then says "Killed" three times and stops dead.
Your configuration works for me. Could you try on different hardware?
Christoph
On Fri, Mar 28, 2014 at 03:30:53PM +0100, Christoph Biedl wrote:
Marc Haber wrote...
With 2014.03-rc1, the kernel boots, inits the network, loads the squashfs via http, and then says "Killed" three times and stops dead.
Your configuration works for me. Could you try on different hardware?
It's a KVM VM, configured with virt-manager
Greetings Marc
Marc Haber wrote...
With 2014.03-rc1, the kernel boots, inits the network, loads the squashfs via http, and then says "Killed" three times and stops dead.
We discussed the issue in IRC since I still cannot reproduce the issue.
My assumption is the squashfs corrupted during download. But I was a bit surprised nobody would have noticed so far.
We've checked the files' hashsums, they are correct.
These are some things to try next: * Host CPU (Marc uses an AMD, mine is a Core i5) * Host Kernel (Marc is on 3.13.x, I use 3.10.x) * KVM Version (Marc uses a wheezy backport of 1.7)
Christoph
In Fri, Mar 28, 2014 at 02:42:34PM +0100, Marc Haber wrote:
With 2014.03-rc1, the kernel boots, inits the network, loads the squashfs via http, and then says "Killed" three times and stops dead.
2014.03-rc1 needs more memory than 2013.09. In a 512 MB VM, the release candidate runs just fine.
Greetings Marc
Christoph Biedl wrote...
Using grml32small:
(...)
There are some messages from live-boot, all typos are mine:
Begin: Copying /etc/resolv.conf to /root/etc/resolv.conf ... cp: can't create '/root/etc/resolv.con': No such file or directory
(...)
Re-testing on an other hardware shows the same behaviour. Using grml64small on that one is fine. Quite odd since all relevant files in the initrd are identical.
But due to ...
A /etc/resolv.conf does exists after startup and it has sound content, so perhaps this is rather cosmetical.
... I think other issues deserve more attention.
Christoph
On 03/28/2014 08:12 AM, Christoph Biedl wrote:
Christoph Biedl wrote...
Using grml32small:
(...)
There are some messages from live-boot, all typos are mine:
Begin: Copying /etc/resolv.conf to /root/etc/resolv.conf ... cp: can't create '/root/etc/resolv.con': No such file or directory
(...)
Re-testing on an other hardware shows the same behaviour. Using grml64small on that one is fine. Quite odd since all relevant files in the initrd are identical.
Could you please try the latest daily build? This should be fixed now.
greets Jimmy
Andreas "Jimmy" Gredler wrote...
Could you please try the latest daily build? This should be fixed now.
That one looks good:
616266705a5cc1adc41659414745d20534b51f74 grml32-small_testing_build815.iso
Christoph
Hi,
On Mon, Mar 24, 2014 at 10:03:36PM +0100, Michael Prokop wrote:
so we did it again, the first release candidate of the upcoming Grml version 2014.03, code-named 'Ponywagon' was released.
[...]
Please test the ISOs and everything you usually use and report back
Choosing 32 bit full on http://grml.org/download/prerelease/ worked fine, but clicking on "Get Checksum/Signature" brought me to http://ftp.halifax.rwth-aachen.de/grml//devel/grml32-full_2014.03-rc1.iso.sh... which gave a 404.
Started it via grml-rescueboot on my EeePC 900A.
The font in the boot menu seems to be truncated at the bottom of each line, especially the letters g, p and y are cut off at the font's base line.
Interestingly this is not the case in the help text below the menu, i.e. the "y" in "E to edit menu entry" looks fine. (This does not happen if I use grub-imageboot, only with grml-rescueboot. The menu looks different, like syslinux vs grub or so.)
If I choose "copy grml to RAM" I get an error message about something with "error: null src bitmap in grub_video_bitmap_create_scaled" and "Press any key to continue", but it continues after 5 seconds or such anyway (took me several reboots to manually copy the message) and boots grml without further issues. Does not happen if I use the default boot entry.
Starting X works fine, but Ctrl-Alt-Backspace doesn't work. Need to use the menu of the window manager.
PS: As you might notice the ISOs increased again (e.g. from ~350MB to 400MB for grml-full), if someone is interested in reducing the ISO we welcome any patches, concrete feedback,..
gcc-4.7-base and libprocps0 can be removed without harm, they're no more needed. (procps depends on libprocps3 nowadays and there's no gcc-4.7 left on the system.)
debconf-i18n (> 1 MB) can probably removed, too.
iproute (transitional package to iproute2) could be removed, if grml-shlib, isc-dhcp-client and vlan wouldn't still depend on it. grml-hwinfo still recommends it. (At least the grml-* packages could be fixed by grml. :-)
xcursor-themes seems just convenience. It's not needed if X's default cursors are fine. grml-x works fine without for me. (Or is it needed for people with visual disabilities?)
Does grml really need tasksel and tasksel-data? (> 1,2 MB together)
The following transitional packages can be safely removed:
* libblas3gf * lynx * libertas-firmware
The above (without iproute) saves about 7 MB over all according to aptitude.
Kind regards, Axel
* Axel Beckert [Tue Mar 25, 2014 at 01:14:48AM +0100]:
On Mon, Mar 24, 2014 at 10:03:36PM +0100, Michael Prokop wrote:
so we did it again, the first release candidate of the upcoming Grml version 2014.03, code-named 'Ponywagon' was released.
[...]
Please test the ISOs and everything you usually use and report back
Choosing 32 bit full on http://grml.org/download/prerelease/ worked fine, but clicking on "Get Checksum/Signature" brought me to http://ftp.halifax.rwth-aachen.de/grml//devel/grml32-full_2014.03-rc1.iso.sh... which gave a 404.
Thanks, signatures have been missing, just uploaded them now.
Started it via grml-rescueboot on my EeePC 900A.
The font in the boot menu seems to be truncated at the bottom of each line, especially the letters g, p and y are cut off at the font's base line.
Interestingly this is not the case in the help text below the menu, i.e. the "y" in "E to edit menu entry" looks fine. (This does not happen if I use grub-imageboot, only with grml-rescueboot. The menu looks different, like syslinux vs grub or so.)
That's strange.
If I choose "copy grml to RAM" I get an error message about something with "error: null src bitmap in grub_video_bitmap_create_scaled" and "Press any key to continue", but it continues after 5 seconds or such anyway (took me several reboots to manually copy the message) and boots grml without further issues. Does not happen if I use the default boot entry.
Hm ok, which grub version are you using here?
Starting X works fine, but Ctrl-Alt-Backspace doesn't work. Need to use the menu of the window manager.
Ok, that might need further configuration to work again with recent X.org versions.
PS: As you might notice the ISOs increased again (e.g. from ~350MB to 400MB for grml-full), if someone is interested in reducing the ISO we welcome any patches, concrete feedback,..
gcc-4.7-base and libprocps0 can be removed without harm, they're no more needed. (procps depends on libprocps3 nowadays and there's no gcc-4.7 left on the system.)
They seem to be brought in via depends/suggests/... since there's no explicit dependency on it in grml-live, needs investigation.
debconf-i18n (> 1 MB) can probably removed, too.
Same here
iproute (transitional package to iproute2) could be removed, if grml-shlib, isc-dhcp-client and vlan wouldn't still depend on it. grml-hwinfo still recommends it. (At least the grml-* packages could be fixed by grml. :-)
grml-shlib already uses "iproute2 | iproute" in its Depends, so nothing to do here from my PoV.
xcursor-themes seems just convenience. It's not needed if X's default cursors are fine. grml-x works fine without for me. (Or is it needed for people with visual disabilities?)
We use the whiteglass theme since ages.
Does grml really need tasksel and tasksel-data? (> 1,2 MB together)
Nope, wondering which packages brings that in... thanks
The following transitional packages can be safely removed:
- libblas3gf
Seems to be pulled in via a package
- lynx
Thanks, fixed: https://github.com/grml/grml-live/commit/2601da4bd0e6c98fbda1a9e1e65a6d4836c...
- libertas-firmware
Thanks, fixed: https://github.com/grml/grml-live/commit/b586e553fbddd1e54bdcead285d69b5d97e...
The above (without iproute) saves about 7 MB over all according to aptitude.
So from my PoV we could investigate where gcc-4.7-base, libprocps0, debconf-i18n, tasksel and tasksel-data are coming from.
regards, -mika-
On Tue, Mar 25, 2014 at 09:20:07AM +0100, Michael Prokop wrote: ...
Does grml really need tasksel and tasksel-data? (> 1,2 MB together)
Nope, wondering which packages brings that in... thanks
aptitude suggests tasksel witch depends on tasksel-data that would proably be my guess on how it gets pulled in.
regards, albert
Hi,
On Tue, Mar 25, 2014 at 09:20:07AM +0100, Michael Prokop wrote:
Started it via grml-rescueboot on my EeePC 900A.
The font in the boot menu seems to be truncated at the bottom of each line, especially the letters g, p and y are cut off at the font's base line.
Interestingly this is not the case in the help text below the menu, i.e. the "y" in "E to edit menu entry" looks fine. (This does not happen if I use grub-imageboot, only with grml-rescueboot. The menu looks different, like syslinux vs grub or so.)
That's strange.
The font issue or the different boot loaders?
If I choose "copy grml to RAM" I get an error message about something with "error: null src bitmap in grub_video_bitmap_create_scaled" and "Press any key to continue", but it continues after 5 seconds or such anyway (took me several reboots to manually copy the message) and boots grml without further issues. Does not happen if I use the default boot entry.
Hm ok, which grub version are you using here?
The one currently in Debian Unstable, 2.02~beta2-7.
Starting X works fine, but Ctrl-Alt-Backspace doesn't work. Need to use the menu of the window manager.
Ok, that might need further configuration to work again with recent X.org versions.
.oO( Sounds familiar. :-)
gcc-4.7-base and libprocps0 can be removed without harm, they're no more needed. (procps depends on libprocps3 nowadays and there's no gcc-4.7 left on the system.)
They seem to be brought in via depends/suggests/... since there's no explicit dependency on it in grml-live, needs investigation.
Haven't grml running currently but "aptitude search '?depends(gcc-4.7-base) ~i'" or "aptitude search '?recommends(gcc-4.7-base) ~i'" should help to find the culprit.
debconf-i18n (> 1 MB) can probably removed, too.
Same here
If you install recommends by default, this looks obvious to me: debconf recommends debconf-i18n.
iproute (transitional package to iproute2) could be removed, if grml-shlib, isc-dhcp-client and vlan wouldn't still depend on it. grml-hwinfo still recommends it. (At least the grml-* packages could be fixed by grml. :-)
grml-shlib already uses "iproute2 | iproute" in its Depends, so nothing to do here from my PoV.
Ah, sorry, I just looked at the reverse dependencies, but not how they specify it. My fault, I just saw a transitional package and looked at its reverse dependencies.
Does grml really need tasksel and tasksel-data? (> 1,2 MB together)
Nope, wondering which packages brings that in... thanks
Similar aptitude commands as above may help here, too. I've run the following on a machine with Stable, Testing and Unstable in its sources.list:
$ aptitude search '( ?recommends(tasksel) | ?depends(tasksel) | ?suggests(tasksel) ) !^task !-tasks$' i A aptitude - terminal-based package manager p aptitude:i386 - terminal-based package manager c aptitude-gtk - terminal-based package manager (GUI and terminal interfaces) p dpkg-www - Web based Debian package browser p synaptic - Graphical package manager p synaptic:i386 - Graphical package manager
If grml pulls in Suggests by default, it's likely aptitude. I've found no other explanation so far.
The following transitional packages can be safely removed:
- libblas3gf
Seems to be pulled in via a package
IIRC libblas3gf and libblas3 are often used in alternative dependencies.
Kind regards, Axel
Hi,
Just a summary of what we just discussed on IRC in #grml:
On Tue, Mar 25, 2014 at 12:48:56PM +0100, Axel Beckert wrote:
gcc-4.7-base and libprocps0 can be removed without harm, they're no more needed. (procps depends on libprocps3 nowadays and there's no gcc-4.7 left on the system.)
They seem to be brought in via depends/suggests/... since there's no explicit dependency on it in grml-live, needs investigation.
We now suspect it comes from the base tar ball which is used to bootstrap the build. gcc-*-base packages are of priority required and hence never get removed automatically even if they is marked as automatically installed via a dependency.
debconf-i18n (> 1 MB) can probably removed, too.
Same here
If you install recommends by default, this looks obvious to me: debconf recommends debconf-i18n.
But grml doesn't do that. Until a few years ago, debconf had a hard dependency on debconf-i18n which later got downgraded to Recommends (IIRC when the previous alternative dependency debconf-english got merged back into debconf). So this likely also comes from the base tar-ball.
mika plans rebuild the base tar ball later today, so we should get rid of these packages soon.
Does grml really need tasksel and tasksel-data? (> 1,2 MB together)
Nope, wondering which packages brings that in... thanks
I suspect the base tar ball for that one, too. There's some tight relationship with d-i and aptitude, but I forgot the details. (At some time in the past tasksel needed aptitude, at least for some features used by d-i.)
The following transitional packages can be safely removed:
- libblas3gf
Seems to be pulled in via a package
IIRC libblas3gf and libblas3 are often used in alternative dependencies.
If in the past there was one dependency which only depended on libblas3gf and it made it's way in the base tar ball that way, the issue should be probably also solved by rebuilding the base tar ball.
Since mika asked how I found that stuff: I used the same aptitude search patterns I used for finding disk space eating cruft on my EeePC 701 with only 4 GB of disk space. You get quite good in doing so after a while. ;-)
Here are a few of these recipes, mostly from https://github.com/xtaran/zshrc/blob/master/zsh.d/50-alias#L201 and http://noone.org/blog/English/Computer/Debian/CoolTools/Finding%20packages%2...
Show packages which are not marked as automatically installed and don't have any reverse dependencies:
aptitude -o "Aptitude::Pkg-Display-Limit=~i !~M !?reverse-depends(~i)"
Find installed packages with "dummy" or "transition" in their description:
aptitude -o "Aptitude::Pkg-Display-Limit=~i ( ~d transition | ~d dummy )"
The used search terms also can be used with "aptitude search" on the commandline if someone prefers the CLI interface over the TUI interface (which I use primarily).
Plus remembering which packages I removed on quite some of my boxes. :-)
Kind regards, Axel
Teilnehmer (6)
-
Albert Dengg -
Andreas "Jimmy" Gredler -
Axel Beckert -
Christoph Biedl -
Marc Haber -
Michael Prokop