On the standard ISO I cannot boot to a livecd session it stops at this loop and will not go on..
a start job is running for live-config contains the components that configure a live system during the boot process
it is a systemd error and has a 0 time loop (infinite) which sucks... I cannot trace where this issue is unfortunately
Only item I found is a sloution for Kali Linux - which is also Debian based:
kali linux live usb stuck (https://forums.kali.org/showthread.php?37982-A-start-job-is-running-for-live-config-contains-Problem)
graphics issue.
Tried several things all day (including that)... no success..
I am going to do a listing of files on each ISO to try and determine what is different on each ... something appears to be updated or not updated on one even though both are at equal levels
I just booted the live CD.
I had that message for ~20 seconds then it completed booting to the desktop.
Intel i3 chip and graphics.
You are using the lite versions... I have not uploaded a stock ISO that has the issue
I am uploading one to test if you want to test it ...
See this edit
I burned this image:
VSIDO_x64_12Jan2018.iso
that's a lite image?
Correct.. I have only uploaded lite images to both the Standard and Lite folders until this is resolved
In another 7 minutes the (Broken) standard version will complete uploading to the Test folder
OK, I should be able to get to it sometime today.
Thanks... the x64 full ISO is now uploaded to here (http://www.nixnut.com/vsido/test/.index.php)
downloading .......
The sha256sum checked out ok, but the live-session boot hangs with that error message. I let it go for 2min 30sec then powered off.
Reverted back to the other iso so it would boot, still sat for about 20 sec then completed.
On both boots, it hangs right after I get the message about Bluetooth patch not applying. I checked the dmesg output after a successful boot, and Bluetooth is followed by a bunch of networking messages for eth0 (the wired interface on this laptop). Is the dmesg output in order, so maybe a networking/dhcp issue?
I took the quiet section out of the boot paramater (kernel line) and watched it get all through the network successfully.. it appears to load everything as it should and gets to the hand off to userspace (live-config) but somehow sees a late userspace change
In short it all looks normal until the actual login as live
Beginning to wonder if this is a lightdm issue... something that should be handed of to lightdm is failing perhaps
That wouldn't surprise me at all - lightdm seems to break a lot. Been beta testing ArchLabs for Matt, lightdm is wonky in that distro too (Arch overall, I suspect).
The bullshit part of it is that it's systemd stopping this on an endless loop... Why? You would think it should be allowed to error out just to get to some logging to see what the hell is happening
I cannot even get to another tty which means X is not starting at all
Quote from: VastOne on January 13, 2018, 09:10:25 PM
The bullshit part of it is that it's systemd stopping this on an endless loop... Why? You would think it should be allowed to error out just to get to some logging to see what the hell is happening
I cannot even get to another tty which means X is not starting at all
One would think. The good old days when it drop you out to runlevel 1 so you could fix the system.
Is there something you can do at the grub menu after hitting "e" - some parameter to boot to the console; suspend the lightdm service?
hello VastOne hello everyone
See your chat about 64, so machine here grabbed _x32 for trial. Live is running. This is the _x32_12Jan2018.
A bit confused about Lite or not-Lite version so here is the shasum for what is running _32..
c57c8f66b5782b40bb69a384a4fc69a56fd4cb406f01561954ec94ac0a3c0b47
hope you can know from that number what machine likes here.
next to the _64 dated 12Jan but uploaded 13Jan. hopefully not-Lite one ready for next.
All ISO's for download (except the one in Test) is the lite version...
The lite version is the only ISO that will boot properly now
Thanks!
hello VastOne
okay. The Lite 32 is working wonderfully live. I have a hdd here poised to blow off another xp install, hoping the _64 can do that. will trial 64 test. Thank You.
hello VastOne
Hi Lite.
The highlight is: The Lite though not standard -x64 does
provide the vsido_64 for live and for installation.
this one lung, one legged, one eyed old pc is scrambling faster than I have ever seen it on
Lite 12Jan2018 : installed. this sent up from installation=
System: Host: evi Kernel: 4.13.0-1-amd64 x86_64 (64 bit, gcc: 6.4.0)
Desktop: Fluxbox 1.3.5 info: xfce4-panel dm: lightdm Distro: VSIDO_x64 V-Ger V-Ger
Machine: System: HP Pavilion 061 product: RB042AV-ABA a1410y version: 0n31211CT101ALHEN00
Mobo: Hewleet-Packard model: Alhena version: 1.0 Bios: American Megatrends version: 3.18 date: 08/17/2006
CPU: Single core Intel Celeron D CPU (-UP-) cache: 512 KB bmips: 6664.93 clocked at 3332.466 MHz
CPU Flags: acpi apic bts cid clflush cmov constant_tsc cpuid cx16 cx8 de ds_cpl dtes64
dts fpu fxsr ht lahf_lm lm mca mce mmx monitor msr mtrr nopl nx pae pat pbe pdcm pebs
pge pni pse pse36 sep ss sse sse2 syscall tm tsc vme xtpr
Graphics: Card: Advanced Micro Devices [AMD/ATI] RC410 [Radeon Xpress 200/1100] bus-ID: 01:05.0 chip-ID: 1002:5a61
X.Org: 1.19.5 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1920x1080@60.00hz
GLX Renderer: llvmpipe (LLVM 5.0, 128 bits) GLX Version: 3.0 Mesa 17.3.2 Direct Rendering: Yes
Network: Card-1: Realtek RTL-8100/8101L/8139 PCI Fast Ethernet Adapter
driver: 8139too ver: 0.9.28 port: b800 bus-ID: 02:05.0 chip-ID: 10ec:8139
Card-2: ASUSTek USB-N13 802.11n Network Adapter (rev. B1) [Realtek RTL8192CU]
driver: rtl8192cu usb-ID: 003-003 chip-ID: 0b05:17ab
Drives: HDD Total Size: 38.6GB (7.6% used)
Repos: Active apt sources in file: /etc/apt/sources.list
deb http://ftp.us.debian.org/debian/ sid main non-free contrib
Active apt sources in file: /etc/apt/sources.list.d/vivaldi-snapshot.list
deb http://repo.vivaldi.com/snapshot/deb/ stable main
Info: Processes: 108 Uptime: 7 min Memory: 404.6/931.4MB Runlevel: 5 Gcc sys: N/A
Client: Shell (bash 4.4.12 running in xfce4-terminal) inxi: 1.9.14
Interesting... I let this run for 13 minutes and it booted...
Surprised the hell out of me
At least now I can trace what is going on
I have spent most of the last 36 hours with my head down digging into this issue and am still just as frustrated... I like to think I am pretty good at getting to the bottom of broken issues and solving them but this one has me FUCKED!
What I know.. Only on the Stock VSIDO ISO's and NOT on the lite this happens on every live-cd boot and it stops
a start job is running for live-config contains the components that configure a live system during the boot process
12 minutes and 12 seconds later it will boot fine.. this is a constant and reproducible stop and start on every ISO built
I have found the way to make the 12 minutes and 12 seconds down to 10 seconds but all that does is cause it to boot without the VSIDO login or /home directory built.. In other words broken.. So it appears that in that 12 minutes and 12 seconds, somehow the /home/vsido and vsido account is built by the live-config function.. the follwoing is what actually happens in the live-config script (one of these appears to be the broken part)
debconf hostname user-setup sudo locales tzdata
I have re-installed all of these components (including live-config) one by one with no luck
Attached are two journalctl -b runs on the live-cd... the first is after the 12 minute and 12 second delay and the other is on a Lite build (that is not having this issue at all)
One of the very first things you might pick up on is apparmor.. I have never installed apparmor, and even though I have wiped it out it is still there
I could use another set of eyes that might see something I am not
Thanks
After booting the live session with the 12 min 12 sec wait, would it help you to run:
systemd-analyze critical-chain
and
systemd-analyze blame | head
Those commands give the start and total times for services to run don't they; maybe a comparrison to the lite version?
systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @12min 21.186s
└─multi-user.target @12min 21.186s
└─wicd.service @12min 13.555s +7.628s
└─dbus.service @12min 13.151s
└─basic.target @12min 12.884s
└─live-config.service @1.892s +12min 10.989s
└─local-fs.target @1.887s
└─run-user-1000.mount @12min 20.619s
└─local-fs-pre.target @1.865s
└─lvm2-monitor.service @940ms +924ms
└─lvm2-lvmetad.service @1.436s
└─lvm2-lvmetad.socket @932ms
└─system.slice @821ms
└─-.slice @814ms
systemd-analyze blame | head
12min 10.989s live-config.service
7.628s wicd.service
3.714s apt-daily.service
3.711s exim4.service
3.661s udisks2.service
3.203s dev-sr0.device
2.649s networking.service
2.510s ModemManager.service
2.426s dev-loop0.device
1.490s quota.service
Going to take out wicd from the startup to see if that is an issue...
On a wider scale, the live-config.service encompasses a mass amount of scripts that are run from /lib/live/config directory
VSIDO lite doesn't have ntp & ntpdate. journ_bad.txt does have following that looks a bit fishy,
Jan 19 02:45:05 vsido kernel: audit: type=1400 audit(1516329905.984:8): apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/usr/local/sbin/" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido kernel: audit: type=1400 audit(1516329905.984:9): apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/usr/local/bin/" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido kernel: audit: type=1400 audit(1516329905.984:10): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="rw/usr/sbin" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido kernel: audit: type=1400 audit(1516329905.984:11): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="usr/bin" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido kernel: audit: type=1400 audit(1516329905.984:12): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="sbin" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido kernel: audit: type=1400 audit(1516329905.984:13): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="bin" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido audit[925]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/usr/local/sbin/" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido audit[925]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/usr/local/bin/" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido audit[925]: AVC apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="rw/usr/sbin" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido audit[925]: AVC apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="usr/bin" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido audit[925]: AVC apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="sbin" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido audit[925]: AVC apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="bin" pid=925 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 19 02:45:05 vsido ntpd[925]: ntpd 4.2.8p10@1.3728-o (1): Starting
Jan 19 02:45:05 vsido systemd[1]: Started Network Time Service.
Jan 19 02:45:05 vsido ntpd[925]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 111:120
Jan 19 02:45:05 vsido ntpd[1006]: proto: precision = 1.117 usec (-20)
Jan 19 02:45:06 vsido ntpd[1006]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
Jan 19 02:45:06 vsido ntpd[1006]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2018-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Jan 19 02:45:06 vsido ntpd[1006]: Listen and drop on 0 v6wildcard [::]:123
journ_good.txt doesn't have the above lines.
Might give you a hint or two ;)
Cheers!!!
QuoteOn a wider scale, the live-config.service encompasses a mass amount of scripts that are run from /lib/live/config directory
Are the scripts different from the lite iso so that you can narrow it down? The 12 min 10 sec run time is awefully suspicious.
The only thing I can think of right now is that one of the applications in the list you posted in the other thread is related to the apparmor error. At first I thought it was something like pam looking to authenticate somehthing, but I didn't notice anything pam related in the logs/journals.
Results for the lite iso -
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @22.760s
└─lightdm.service @21.873s +885ms
└─systemd-user-sessions.service @21.750s +121ms
└─network.target @21.749s
└─wpa_supplicant.service @20.640s +1.108s
└─dbus.service @20.190s
└─basic.target @20.189s
└─live-config.service @8.213s +11.974s
└─local-fs.target @8.210s
└─tmp.mount @8.204s +5ms
└─local-fs-pre.target @8.202s
└─keyboard-setup.service @1.259s +6.942s
└─systemd-journald.socket @1.099s
└─system.slice @1.095s
└─-.slice @1.094s[/b]
11.974s live-config.service
6.942s keyboard-setup.service
4.288s dev-loop0.device
4.287s dev-sdb1.device
2.020s ModemManager.service
1.616s user@1000.service
1.310s rsyslog.service
1.108s wpa_supplicant.service
996ms systemd-tmpfiles-setup-dev.service
981ms lvm2-monitor.service
@hakerdefo... on one of my 900 ISO builds trying to fix this I did remove those files and it made no difference.. I do appreciate your help!
@RatMan The scripts are identical.. the same error in the same time every time is what is so curious about this...
On another note.. I am asking myself over and over... what for? The Lite version has everything I care about and is 250 mib smaller than the Stock... It is also easier to maintain and rebuild.. That is why I posted the differential between the two just in case anyone wants to add the missing pieces... But the real question is, what is actually missing? Another factor is the size.. I have not really added anything to VSIDO in 3 years and yet it has ballooned to 670 MiB due to Debian Growth Bloat...
perhaps I am just tired of it
I saw your most recent post on this with the Lite ISO systemd-analyze results.. it is very curious that wicd does not even show up... and honestly, seeing wicd on the Stock one is the first thing I have seen that gives me some kind of hope.. I am building a new ISO now so I'll let you know in an hour or so
Enough babbling... Thanks for the help!
Hmmm.... out of no where a new version of one of the culprits shows up - user-setup
This is one of the files I have suspected as being broken somehow
Neither fixed the issue.. the new user-setup or removing wicd from the startup mattered
Running out of patience and desire
At the risk of a necrobump ;)
I have had the same issue trying to build a new version of dwmX 'distrolette'
https://sourceforge.net/projects/dwmx/
I started with a fresh minimal Debian Buster install...BUT...[using REFRACTA tools]
Burning an ISO of my development distro the new ISO boot paused for +/-12 minutes [WTF ???]...at the end of boot...with the same message as per head of thread.
I am now trying to build a new version on Devuan and so far I have built a pre-alpha 'dwmXdev' version with sysvinit,boots no issues, to a modest 160MB RAM @ idle.
Any feedback welcome ;)
Keep up the great work team 8)
https://sourceforge.net/p/spacefm/discussion/general/thread/e4c703f5/