Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - filip

Pages: [1] 2 3 4
Feedback & Suggestions / Re: Connman network manager GTK frontend
« on: April 19, 2017, 03:09:07 PM »
Awesome filip!

Like it!

Looks better than connman-ui


Indeed, it's awesome really. Looks good, stays out of the way and it's usable when needed.  :)

Btw, I haven't mentioned it here, I'm not the actual author.
I just packaged and patched it to enable window toggling from tray icon.

Looks good.

One item though, don't mean to nit-pick but on your git page you have:


 GTK >= 3.10

Shouldn't connman be on the list, this isn't a stand alone application is it?

Well, it should be, though it implies itself since it's a front-end for it ( not a stand alone )...
Anyhow, it's fixed now.  :)

Successfully compiled it on Void Linux.

Nice work.

I'll have to run connman for a while; much smaller memory footprint than NetworkManager or wicd.

Also seems to require root privleges to connect/roam with wireless. Will that be the case on Debian as well?

I'm using it for atleast 6 months and honestly have no idea it's even there. The damn thing JustWorks™.  :D

As to WiFI & root, I wouldn't know since I don't have a WiFi to test ( desktops on LAN all around ).
Though ( on Debian atleast ) I am finding it odd that the "connmanctl" command is installed in /usr/sbin ( thus requiring root privileges )...  ::)
For example, on Arch it goes to /usr/bin...

With that said, you may try to symlink it to /usr/bin:
Code: [Select]
sudo ln -s /usr/sbin/connmanctl /usr/bin/connmanctlI'm not sure that the front-end will even look for it there ( both connman and GUI might need rebuilding for this to work ).

And, after symlinking do verify that it actually works without root:
Code: [Select]
connmanctl scan wifi; connmanctl services
and then try to connect to one of WiFi's listed with:
Code: [Select]
connmanctl connect wifi_xxxxxxxxxx
Also, see:

Feedback & Suggestions / Connman network manager GTK frontend
« on: April 15, 2017, 08:57:08 PM »
As promised in the installer topic, I've pushed the connman-gtk to git, including debian packaging and a small patch allowing main window to be toggled by clicking the tray icon.

For details and more screenshots see:

Build instructions:

1. Clone & cd:
Code: [Select]
git clone && cd connman-gtk
2. Install build deps:
Code: [Select]
mk-build-deps --install ./debian/control      # if "mk-build-deps" is missing install "devscripts" package first
3. Build and install:
Code: [Select]
dpkg-buildpackage -j$(nproc)
Code: [Select]
cd ../ && sudo apt install ./connman-gtk_1.1.1-2_amd64.deb
Enjoy & god-forbid there be any issues, let me know!  :)

@filip Great work on the installer  8)
Keep it up  :)


Thank you!  :)


The "resume device" hang propagated to Stretch as well. And for once it actually has nothing to do with systemd.
You were right, issue was introduced in "initramfs-tools", v128 in order to fix the bug where some NVMe drives were slow to enumerate partitions causing the system to fail to resume from hibernation...

See changelog and a bug report.

The weird part is the wait time they've set ( ~20sec ). I mean what for, seriously!? Even the guy who reported the bug said that adding a 1sec delay fixed the issue for him...  ::)

Anyway, until they sort it out, the quick fix is to add the "resume=/dev/sdXY" to the "GRUB_CMDLINE_LINUX_DEFAULT" in "/etc/default/grub" file, where "/dev/sdXY" is your swap partition ( worked for me atleast @Stretch ).  :)
You might even get away with any partition ( not just swap ), as long as you don't have any data on it ( untested!!! ).


I've also looked at the actuall shell scripts used, however I'm having a bit of a hard time reading them ( I've never really understood why Debianers always write shell scripts in such obfuscated and "hard to read" way  ::) ).
I'll let you know If I get anywhere with that...

I do not have that on any line, I do not use swap and never ever have used hibernation even when I do use a laptop

This has also started to happen on this my build machine that is also completely up to SID levels..

This is nothing new in SID, just a hiccup that is only a concern if someone boots VSIDO on a new install and does not wait the 20 seconds on the boot and gets frustrated..


Yeah, it's some update ( possibly systemd ) related then. :)

... I do not always cover that anymore.. Simply, I have been selfless forever and it has gotten me nowhere

No problem!
I know that feeling...  ::)

To answer your question I did solve the network issue on V-Box with a tweak to a refracta file used in building the ISO

Great, thanks!  :)

Be aware that on the latest SID updates (and on VSIDO installs with the new ISO) there is a delay of about 20 seconds and then a message

Code: [Select]
gave up waiting on suspend/resume device
and then it boots normally

Not sure where the message even comes from as it is immediate .. possibly initramfs update but I am not sure

It is not causing any issues other than a blank 20 second delay.. strange one I have never seen before

Does NOT happen boot of ISO to LiveCD, only after installed..

It could also be an SSD issue since that is what I am running on

Try this:

1. Reboot
2. Remove "resume=/dev/sdxy" from kernel cmdline ( press "e" when grub shows, then find it on the "linux" line and remove ) & hit F10 to boot.

If the error goes away, and you haven't formated/deleted/moved the swap partition, then it's likely some systemd bustage ( though changelog doesn't indicate anything related ).

When you hibernate your machine, RAM content is dumped onto the swap partition for a persistent storage. Then, when you turn back on, "resume=/dev/sdxy" line is used to point the kernel to that partition as the resume device containing the previous state.

So, if you're not using hibernation, it's safe to remove the same line from "GRUB_CMDLINE_LINUX_DEFAULT" in "/etc/default/grub" file, and then run "update-grub", however do keep in mind that if you ever hibernate the machine, it will NOT resume into previous state, but boot normaly instead! :)
Otherwise if you moved your swap, correct the "/dev/sdxy" in the same file & update-grub.

^ You say you do not see this on the Trios side right?  What distro level are they?

My thinking is this could be a SID issue ..



I have a feeling it's one of those dumbest ass things that on the "outside" appear perfectly normal and fine, yet silently casue issues and a major pain to detect.  >:(
And when you finally find it, you go like "I don't wanna live on this planet anymore"...  ;D

Anyhow, as they say, it's just a matter of time.... ;)
Will post progress updates as they come.  :)

Update @mkfs:

I'm perplexed and out of ideas really.   :-[

Been sifting trough the installer for most of the evening --> found nothing obviously wrong. 
Heck, "partprobe" is being executed before every call to "mkfs", for the very reason of avoiding the issue we're seeing, which btw shouldn't be even needed, since we're just formating existing partitions, no changes were made to them or the partition table, warranting a need for "partprobe"...

HAHA  ... the garage at Jedi's is a definite place for the mind to relax and chill.. to the point of grand illusions   8)  8)  8)  8)  ???

Well, that explains it then...  :D :D ;D ;D

A perfect install .. no delays, a perfect boot

And STILL less than three minutes even with new procedures during the installation


I also attached is the installation log of the install if you wanted to check it out

Awesome!  :)

Though you might wanna recreate the partition table on that hdd ( via Gparted or installer ), to avoid potential issues in future testing.  ;)
Code: [Select]
GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645

How To's / Re: How To: Building the VSIDO Installer
« on: April 08, 2017, 09:38:52 PM »

Updated How-To is spot on, except that the entire "After installation" section is redundant and no longer needed ( since installer v7.0.7~fd2 ).

Also, "bricks" module is not used in VSIDO ( and cannot be used, without modifications ), so you might as well remove it's section to keep things simpler.  :)


Log looks perfectly fine. No errors, and most importantly GRUB is corectly installed and updated ( btw, going by the log, there shouldn't be a need to update it manualy on first boot! ):

Installer doesn't support the swapfile at all, so unless we're looking at another "mkfs"-like wierdness, it couldn't have came from installer itself. :)

@filip, yes it went perfectly.  As you saw in the log, there was indeed no need of any grub finessing   With the 02Apr ISO it warned me about not choosing a swap file but that it was fine to proceed.  On the 04Apr ISO, this did not happen, and the line in fstab did not show up either. (mkfs? beats me) All in all, a pretty impressive result and jump forward for VSIDO...

My initial testing with the 02Apr ISO should probably be totally disregarded.  I did most of it in the garage.  Never a conducive work environment.  Turns out it's a lonely winter up here!  I really need some Spring...

Great!  :)

While I certanly understand where you're coming from, I do on the other hand have to differ about it not being a conducive work env. But I guess it depends on the actual garage ( I see mine as a den of sorts )...  :D ;D

fstab preseed for EFI partition is now exposed and preset in "vsido-base" to "x-systemd.automount,x-systemd.device-timeout=2".

For now, preseed is applied only if EFI partition is formated with FAT16 or FAT32 (vfat actually)!
Can be easily extended for other FS's if the need be. :)


Log looks perfectly fine. No errors, and most importantly GRUB is corectly installed and updated ( btw, going by the log, there shouldn't be a need to update it manualy on first boot! ):
Code: [Select]
Installing for x86_64-efi platform.
Installation finished. No error reported.
Found Debian V-SID-O jedi (V-Ger) on /dev/nvme0n1p1
Found Manjaro Linux (17.0) on /dev/nvme0n1p5
Adding boot menu entry for EFI firmware configuration

I forgot it last time:
I simply deleted the swapfile line in fstab and it solved the 90 sec issue...
Installer doesn't support the swapfile at all, so unless we're looking at another "mkfs"-like wierdness, it couldn't have came from installer itself. :)

I've been quite busy in the last couple of days, so the actual fstab/mkfs work/investigation will have to wait for the weekend ( I'll also push a "connman-gtk" with some fixes and packaging to GitLab, so you can take it for a spin if you'd like ).
In the mean time, unrelated, but you might be interested to know that unfortunately Ignorant Guru is no longer developing SpaceFM, however there's now a fork and a new version at :)

I have a good understanding of the preseed methodology and what it can do but have never used one in the installer to know how to make the changes.. I could use a How To on it if there is one. I did a search and have found very little info on it

Regarding the Guest Additions, can't you just install them on your end with the ISO? they had a huge amount of space to the ISO if I include them

Well, here's a somewhat sparse wiki page @Semplice, however, besides the short documentation of the existing preseeds, there's also the issue of missing ones, which occasionaly popup as needed ( like it's the case with "fstab", or was for rEFInd etc. ).
The only way around second one is to actually code them in, which is not hard per se, but it does requires basic knowledge of Python and installer internals.
I'm certanly willing to write a HowTo if you're up for it. :)

As an example, here you can see what it took to add the "copy specified file to /etc/network/interfaces" functionality I've added for VSIDO ("custom_net_ifaces" preseed):

On the doc side, I will eventualy get to documenting and explaining existing preseeds, however that is not likely to happen soon.

@VBox GA:
Of course I can, however I need them in live mode, since there I'm testing and fixing the installer on-the-fly...
Anyway, it's not a must have, I've basically asked for this one time exception, mostly because it would make the ^work much faster and easier to do.  :)


Thanks for testing mate! :)

Please do post the installation log for me to take a look at. It's at "/var/log/installation.log".

you can probably axe the 'proc' line as well.
I think that /proc is actually a must for the "update-grub" to find partitions/mount info.
At least I was never able to restore/reinstall GRUB from a live system without binding it to the mounted root first ( eg mount --bind /proc /path/to/root/partition/proc ).

I am perplexed.. I can successfully install and on the first reboot from the installation V-Box sees grub and efi and all is good...
Likewise/confirmed.  ???

Does the efi partition need to be anything special other than fat16? Does it need to be sda or sda1? Does it need to be flagged as a boot device from gparted?

- AFAIK, it should be (any) FAT, most likely because every BIOS will support it.
- Should be a first one ( sdX1, nvmeXnXp1 etc ), though not a must, however the same "support issue" as above still applies.
- Yes, it needs "esp" flag to be set, which is what Parted/Gparted actually does when you set a "boot" flag.

Installer-wise, it sets the "boot" flag using parted itself, so that's unlikely to be the cause ( see here, @line 509 )

And there is nothing I can do to change it during the installation.. it is something that needs to be added or edited after the install

That won't be too hard to implement as preseed ( including the entire "options" part of "fstab" for every file system available ).

I have finished building and testing a new ISO for testing uEFI hardware and it has been uploaded to the test download page

Looking good!  :)
Btw, should another build be required while we're debuging these issues, may I ask you to build with VBox Guest Additions ( I'm sorely missing the shared clipboard when fixing/testing installer stuff on a live system )? :)


I can't be of much help here, since besides the usuall stuff, it's exactly the network nonsense that keeps me away from systemd. Random connection drops, changing cable from one LAN port to another breaks the network on both, the famouse "doesn't brings up the net on boot", device name changing....

Anyway, quick workaround for live is to just run "dhclient".  :)
And if I may suggest you to take a look at "connman"... If doesn't have issues with systemd, it might be perfect for VSIDO, given that it has tiny footprint* and a solid Gtk GUI ( not pacakged yet, unfortunately ), and the best off all is that nothing else is needed ( nm, wicd etc... ).

* Along the lines of 5-8MB of RAM for both the daemon and the GUI.


Looks like you didn't setup an EFI partition ( fat16, about 30-100MB, mountpoint=/boot/efi ).  ;) :)

it not seeing the installation but it most likely has to do with grub-efi is not being installed correctly
I don't have that issue -- Box weirdness galore.  ;D
Though it would be nice if you could post the installation log from it ( boot live -- mount root -- cat /var/log/installation.log ), it should tell us more about what happened.  :)

Pages: [1] 2 3 4