I did forget to actually put in the command 'halt', heh. Thanks for the bug report, that's fixed now.
Back to top

in #smxi today :

[19:15] < nadar_> selecting mirrors i get
[19:15] < nadar_> Updating /etc/apt/sources.list.d/sidux.list now...
[19:15] < nadar_> sed: -e expression #1, char 67: unterminated `s' command
[19:15] < nadar_> but the script goes on
Back to top

thanks, haven't even looked at that section for ages. Hard to track down the issue for sure though.

I guess I'd have to do a test vm install of sidux new then run smxi first time on it to see where the issue actually occurs.
Back to top

Two problems:

1. smxi does obviously not do a check if there is enough space on the filesystem before the dist-upgrade. Today I encountered that the system needs to download 1.6GB, I had only 1GB free so the dist-upgrade stopped and did some serious trouble to some dpkg status files...
2. Then, after a restart, KDE would not start. So I just tried again a dist-upgrade hoping that it would help (it did not). Problem here: KDM was still running in background and it was not reacting anymore. smxi recognized this and took autmatically two tries to bring the system to runlevel 3 by terminating KDM. First try did not succeed, second neither, but smxi continued with the script like everything would be ok... There must be a bug when smxi tries to go to runlevel 3.

Now I need to get my system back to running...
Back to top

smxi shows you how much space there is in your root partition, if you read it.

smxi has no way to know how much room will be used, although I guess it could attempt that, but that's getting pretty fine grained.

The bug in this case was not reading the output smxi shows about partition data, that's what it was added, for exactly this reason.

Generally, if you are trying to run a / partition with more than about 1/2 the total available gB used, you need to pay attention.

For example, a standard kde realworld install takes up between 5 and 8 gigabytes over time. So the / partition should be 10-20 gB large. If it's smaller, you need to pay attention, and if you made it too small and have extra space, you should expand it. Also, if you have a standard / /home partition setup, and if you use apt to update, you have to use apt-get or aptitude clean once in a while or your apt cache will grow to many gigabytes.

If you are using / for /home as well, which of course means if you fill /home, root will cease to function, then it might be a good idea to start using /home and leaving root to run the core system, as was intended in unix from the very start.

However, as a feature request, it's a fine feature request, to grab the partition / size pre du, and try to extract the to be downloaded data/size on disk data from the du output.

Working with that data, however, is a pain, but I do it already to compare packages added/removed, so it is possible and the logic is there, just requires more processing.

But until or if this feature is added, you'll have to take a bit of charge over your system and actually read the partition available output in smxi.

Keep in mind, smxi doesn't really pay much attention to the white output, that's from other applcations, like apt-get, aptitude, dpkg, and so on, only the green/colored text is smxi.
Back to top

Now that nouveau made reinstalling the proprietary NVIDIA driver after a kernel upgrade a bit more troublesome, I think sgfxi is missing something.
After a kernel upgrade, nouveau is still enabled and as such the X environment doesn't load.
So I ran sgfxi and I think it added the 'nomodeset' parameter to /etc/default/grub (is that it?) and blacklisted the nouveau kernel module but couldn't install the driver because nouveau was loaded so it said it had set the driver to vesa and asked for a reboot and to run it again.
I rebooted and it loaded nouveau again so I had to run an update-grub and reboot again for the sgfxi NVIDIA installation to work because I figured that the nomodeset parameter hadn't been added to the boot line.
So I suspect that after the first sgfxi run after a kernel upgrade, when it does the basic preparations for the installation of the 'blob' (like blacklisting nouveau etc.) maybe it's missing a call for an update-grub.

Could anyone confirm that?
Back to top

sounds like it's worth a try updating grub, that wasn't required on fedora, but debian wasn't tested as much.

I've yet to see any nouveau issue myself but some systems are reporting issues, hard to really debug but adding in an update-grub is a good idea I'd say.

I think it edits the default file but also edits the grub.cfg file, the one that is generated, I thought that would be enough, but maybe grub 2 requires running update-grub like lilo used to require, that wouldn't surprise me, a regression in usablity would seem standard for grub 2.
Back to top

Just to put in the details:
Liquorix was updated and when booting to the new kernel it couldn't go to the login screen. I had already installed NVIDIA's driver in the older kernel.
If I remember well, when I booted into the new kernel it loaded nouveau, I guess because it wasn't blacklisted. But why it didn't go to the desktop, I don't know, must have to do with me having installed NVIDIA's driver in the older kernel.
So I ran sgfxi, it popped its messages (I don't remember exactly the one about nomodeset since I had it already setup in /etc/default/grub because of the earlier driver installation) like the nouveau module blacklisting, failed to remove nouveau (because of it being in use) and asked for a reboot (including suggesting that it could be even better to shutdown and wait for a minute).
I rebooted and it loaded nouveau again, then I checked /etc/default/grub and nomodeset was set there, I also checked grub.cfg and saw that nomodeset wasn't there for this kernel so I ran update-grub, rebooted and could go on with the driver installation.
What intrigued me was that nomodeset wasn't in grub.cfg even if it was already set in /etc/default/grub and obviously update-grub was run after the kernel installation. But now I think I know why: since it's in the GRUB_CMDLINE_LINUX_DEFAULT= line then maybe it 's only set to the running kernel (or to the 'default' line for GRUB)?
Anyway, regarding sgfxi, there would be no sense in editing grub.cfg directly except if nomodeset is needed only for the driver installation and then no more because if it isn't added to GRUB_CMDLINE_LINUX_DEFAULT= in /etc/default grub then it will disappear in the next update-grub (it wasn't meant to be edited, after all).
I don't remember if I had this issue the first time I installed the driver (but then I was already a bit confused because the main GRUB is in another system and so I have to run update-grub in the system I'm installing the driver on then boot to the main system and run update-grub there too).

Anyway, if it's just a matter of adding 'nomodeset' to the boot line and blacklisting nouveau and then reboot to install NVIDIA's driver then the proper way would be to add nomodeset to /etc/default/grub and run update-grub before the reboot.
Back to top

I did mention how much I hate grub 2 didn't I? And nouveau?

But thanks for looking further into it, dealing with both grub 2 and nouveau is basically immersing oneself into the very worst 'free software' has to offer us today. So I don't enjoy that at all, which is why I don't follow it. But I'm glad you may have found the actual issue.

The idea behind editing grub.cfg directly was to avoid having to run update-grub, and the idea of adding it to grub/default was that next time a kernel was installed it would get updated in grub.cfg automatically.

Clearly the idea needs some tweaking.
Back to top

Sorry for that, I thought we all had to deal with GRUB2 nowadays ; )

Anyway, I actually ain't sure why I ended without nomodeset for the new installed kernel since from what I knew and experienced too, it being in the default line in /etc/default/grub should guarantee that it was added at the kernel upgrade.
Maybe I had removed it? I doubt it, but who knows.
I'll have to wait for the next liquorix update to pay a careful attention to the process.
Back to top