Well I have a few things perhaps of interest.
I have problems with the firstboot setup and root password. I am using the installer script and the --norootpass option. When I am prompted at the setup, I ignore the setting of the root password. Fortunately I also did not set my user password and made my user have admin priv. Because when I got to login, it wanted a password for root and I could not figure out what. In the past I would just provide 'root' for the login and I was good. So I logged in with my user and did a 'sudo passwd root' to set the root password to what I wanted.
Also with the setup prompts, the timezone option has a display problem. I select America, which takes 3 screens to display on my serial console. I noticed that the line right after the 'press enter' gets skipped. In my case, city 46 is Detroit, where I live. 45 is the last in the first column on the second screen-worth. I press enter and city 47 is listed. I figured out that 46 was Detroit by the ordering, and providing 46 resulted in 'Detroit' being listed as my timezone city.
So I get logged in, with NO usb devices installed. I install a USB drive and nothing. The light does not come on on the USB drive. Nothing new is shown with 'ls /dev/' No sda etc.
I powered off and tried again. Same behaviour. I plugged in a USB keyboard and that got recognized and I was able to login on the monitor console.
[ 138.712000] usb 4-1: new low-speed USB device number 2 using ohci-platform [ 138.919037] usb 4-1: New USB device found, idVendor=0e8f, idProduct=0022 [ 138.925807] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 138.932985] usb 4-1: Product: USB KB V11 [ 138.936987] usb 4-1: Manufacturer: GASIA [ 138.953314] input: GASIA USB KB V11 as /devices/platform/soc@01c00000/1c14400.usb/usb4/4-1/4-1:1.0/0003:0E8F:0022.0001/input/input0 [ 139.018993] hid-generic 0003:0E8F:0022.0001: input,hidraw0: USB HID v1.10 Keyboard [GASIA USB KB V11] on usb-1c14400.usb-1/input0 [ 139.046090] input: GASIA USB KB V11 as /devices/platform/soc@01c00000/1c14400.usb/usb4/4-1/4-1:1.1/0003:0E8F:0022.0002/input/input1 [ 139.113550] hid-generic 0003:0E8F:0022.0002: input,hidraw1: USB HID v1.10 Device [GASIA USB KB V11] on usb-1c14400.usb-1/input1
But still no recognition of the USB drive.
So I started a timer to see what was going to happen. While waiting the following appeared on the serial console:
[ 898.271682] dnf (1081) used greatest stack depth: 3840 bytes left
I am assuming this is not important, but passing it along.
Finally after 45 minutes I get:
[ 3133.396767] usb 4-1: USB disconnect, device number 2
on the serial console, and the keyboard is unresponsive. A check with journalctl produced:
Feb 19 10:57:47 localhost.localdomain kernel: usb 4-1: USB disconnect, device number 2 Feb 19 10:57:47 localhost.localdomain systemd-udevd[423]: error opening USB device 'descriptors' file
So Minimal has the problem, as one would suspect. I wonder if the problem is my Cubietruck; USB drive not even registering is worrisome. I will try F21 on it to see. I only have the one CT to test wtih, but I have one Cubieboard2. I am building an SD card to test on it. Will have that testing information in a while.
Power...
I have been powering my Cubietruck via the otg, rather than the powerplug. I figured since I was not powering a sata drive, I could get by with the lower amps via otg.
So I thought, well why isn't a usb drive being recognized? That is REALLY wierd. Power....
Switched to the power plug connector (2A max) and USB drive recognized. It is coming up as it should as /dev/sda.
I suspect that the keyboard will go ok as well. I have set a timer and will see if I can get past the timeouts I have seen in the past.
ARGH!!! :)
On 02/19/2015 11:16 AM, Robert Moskowitz wrote:
Well I have a few things perhaps of interest.
I have problems with the firstboot setup and root password. I am using the installer script and the --norootpass option. When I am prompted at the setup, I ignore the setting of the root password. Fortunately I also did not set my user password and made my user have admin priv. Because when I got to login, it wanted a password for root and I could not figure out what. In the past I would just provide 'root' for the login and I was good. So I logged in with my user and did a 'sudo passwd root' to set the root password to what I wanted.
Also with the setup prompts, the timezone option has a display problem. I select America, which takes 3 screens to display on my serial console. I noticed that the line right after the 'press enter' gets skipped. In my case, city 46 is Detroit, where I live. 45 is the last in the first column on the second screen-worth. I press enter and city 47 is listed. I figured out that 46 was Detroit by the ordering, and providing 46 resulted in 'Detroit' being listed as my timezone city.
So I get logged in, with NO usb devices installed. I install a USB drive and nothing. The light does not come on on the USB drive. Nothing new is shown with 'ls /dev/' No sda etc.
I powered off and tried again. Same behaviour. I plugged in a USB keyboard and that got recognized and I was able to login on the monitor console.
[ 138.712000] usb 4-1: new low-speed USB device number 2 using ohci-platform [ 138.919037] usb 4-1: New USB device found, idVendor=0e8f, idProduct=0022 [ 138.925807] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 138.932985] usb 4-1: Product: USB KB V11 [ 138.936987] usb 4-1: Manufacturer: GASIA [ 138.953314] input: GASIA USB KB V11 as /devices/platform/soc@01c00000/1c14400.usb/usb4/4-1/4-1:1.0/0003:0E8F:0022.0001/input/input0 [ 139.018993] hid-generic 0003:0E8F:0022.0001: input,hidraw0: USB HID v1.10 Keyboard [GASIA USB KB V11] on usb-1c14400.usb-1/input0 [ 139.046090] input: GASIA USB KB V11 as /devices/platform/soc@01c00000/1c14400.usb/usb4/4-1/4-1:1.1/0003:0E8F:0022.0002/input/input1 [ 139.113550] hid-generic 0003:0E8F:0022.0002: input,hidraw1: USB HID v1.10 Device [GASIA USB KB V11] on usb-1c14400.usb-1/input1
But still no recognition of the USB drive.
So I started a timer to see what was going to happen. While waiting the following appeared on the serial console:
[ 898.271682] dnf (1081) used greatest stack depth: 3840 bytes left
I am assuming this is not important, but passing it along.
Finally after 45 minutes I get:
[ 3133.396767] usb 4-1: USB disconnect, device number 2
on the serial console, and the keyboard is unresponsive. A check with journalctl produced:
Feb 19 10:57:47 localhost.localdomain kernel: usb 4-1: USB disconnect, device number 2 Feb 19 10:57:47 localhost.localdomain systemd-udevd[423]: error opening USB device 'descriptors' file
So Minimal has the problem, as one would suspect. I wonder if the problem is my Cubietruck; USB drive not even registering is worrisome. I will try F21 on it to see. I only have the one CT to test wtih, but I have one Cubieboard2. I am building an SD card to test on it. Will have that testing information in a while.
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
If it's any consolation, my Beagleboard does the same thing. No power to USB from OTG power, but no problems when using the normal power port.
On 2/19/15 11:37 AM, Robert Moskowitz wrote:
Power...
I have been powering my Cubietruck via the otg, rather than the powerplug. I figured since I was not powering a sata drive, I could get by with the lower amps via otg.
So I thought, well why isn't a usb drive being recognized? That is REALLY wierd. Power....
Switched to the power plug connector (2A max) and USB drive recognized. It is coming up as it should as /dev/sda.
I suspect that the keyboard will go ok as well. I have set a timer and will see if I can get past the timeouts I have seen in the past.
ARGH!!! :)
On Thu, 19 Feb 2015, Robert Moskowitz wrote:
Well I have a few things perhaps of interest.
I have problems with the firstboot setup and root password. I am using the installer script and the --norootpass option. When I am prompted at the setup, I ignore the setting of the root password. Fortunately I also did not set my user password and made my user have admin priv. Because when I got to login, it wanted a password for root and I could not figure out what. In the past I would just provide 'root' for the login and I was good. So I logged in with my user and did a 'sudo passwd root' to set the root password to what I wanted.
I have to assume systemd is starting something like:
/bin/bash -i
rather than the former (and familiar) root shell without login authentication. The same behaviour may be done under older initscripts
And put this in /etc/inittab if you want the behavior where it is not prompted:
1:2345:respawn:/bin/bash -i
Robert -- could you check your system and see, and advise the list of the results of your examination?
-- Russ herrold
On 02/19/2015 01:16 PM, R P Herrold wrote:
On Thu, 19 Feb 2015, Robert Moskowitz wrote:
Well I have a few things perhaps of interest.
I have problems with the firstboot setup and root password. I am using the installer script and the --norootpass option. When I am prompted at the setup, I ignore the setting of the root password. Fortunately I also did not set my user password and made my user have admin priv. Because when I got to login, it wanted a password for root and I could not figure out what. In the past I would just provide 'root' for the login and I was good. So I logged in with my user and did a 'sudo passwd root' to set the root password to what I wanted.
I have to assume systemd is starting something like:
/bin/bash -i
rather than the former (and familiar) root shell without login authentication. The same behaviour may be done under older initscripts
And put this in /etc/inittab if you want the behavior where it is not prompted:
1:2345:respawn:/bin/bash -i
Robert -- could you check your system and see, and advise the list of the results of your examination?
Help me a little here. Do I build a SD card, mount it and look in /etc/inittab? Or do I log in with my user account and see what it has set for root? The install script does:
# Remove root password if [ "$NOROOTPASS" = "1" ] ; then echo "= Removing the root password." sudo sed -i 's/root:x:/root::/' /tmp/root/etc/passwd fi
But what does the firstboot setup do that overrides this?
On 02/19/2015 01:16 PM, R P Herrold wrote:
On Thu, 19 Feb 2015, Robert Moskowitz wrote:
Well I have a few things perhaps of interest.
I have problems with the firstboot setup and root password. I am using the installer script and the --norootpass option. When I am prompted at the setup, I ignore the setting of the root password. Fortunately I also did not set my user password and made my user have admin priv. Because when I got to login, it wanted a password for root and I could not figure out what. In the past I would just provide 'root' for the login and I was good. So I logged in with my user and did a 'sudo passwd root' to set the root password to what I wanted.
I have to assume systemd is starting something like:
/bin/bash -i
rather than the former (and familiar) root shell without login authentication. The same behaviour may be done under older initscripts
And put this in /etc/inittab if you want the behavior where it is not prompted:
1:2345:respawn:/bin/bash -i
The first line, and comment, in /etc/inittab says this file is no longer used and any changes in it will have no effect on your system. All in caps by the way.
Robert -- could you check your system and see, and advise the list of the results of your examination?
So how is systemd started?
Well I have a few things perhaps of interest.
I have problems with the firstboot setup and root password. I am using the installer script and the --norootpass option. When I am prompted at the setup, I ignore the setting of the root password. Fortunately I also did not set my user password and made my user have admin priv. Because when I got to login, it wanted a password for root and I could not figure out what. In the past I would just provide 'root' for the login and I was good. So I logged in with my user and did a 'sudo passwd root' to set the root password to what I wanted.
I have to assume systemd is starting something like:
/bin/bash -i
rather than the former (and familiar) root shell without login authentication. The same behaviour may be done under older initscripts
And put this in /etc/inittab if you want the behavior where it is not prompted:
1:2345:respawn:/bin/bash -i
The first line, and comment, in /etc/inittab says this file is no longer used and any changes in it will have no effect on your system. All in caps by the way.
Robert -- could you check your system and see, and advise the list of the results of your examination?
So how is systemd started?
From the initrd. It's PID 1
On 02/19/2015 01:16 PM, R P Herrold wrote:
On Thu, 19 Feb 2015, Robert Moskowitz wrote:
Well I have a few things perhaps of interest.
I have problems with the firstboot setup and root password. I am using the installer script and the --norootpass option. When I am prompted at the setup, I ignore the setting of the root password. Fortunately I also did not set my user password and made my user have admin priv. Because when I got to login, it wanted a password for root and I could not figure out what. In the past I would just provide 'root' for the login and I was good. So I logged in with my user and did a 'sudo passwd root' to set the root password to what I wanted.
I have to assume systemd is starting something like:
/bin/bash -i
rather than the former (and familiar) root shell without login authentication. The same behaviour may be done under older initscripts
And put this in /etc/inittab if you want the behavior where it is not prompted:
1:2345:respawn:/bin/bash -i
Robert -- could you check your system and see, and advise the list of the results of your examination?
So again the installer script does:
sudo sed -i 's/root:x:/root::/' /tmp/root/etc/passwd
This results in /etc/passwd entry for root being:
root::0:0:root:/root:/bin/bash
This is from checking before installing the card in the Cubie. But after running firstboot, and NOT responding to the 'root password not set', I see from logging in as me with admin priv:
root:!!$1$oIqdSlOQ$AkrPPHJnLMO2g7CbEklLn1:0:0:root:/root:/bin/bash
So firstboot is sliding something in for the root password, overriding the nopassword option in the installer script.
I suppose if I had quit out of the setup, it might have left root alone...
And what decides if there is the serial console setup or the graphical config? The presense of the serial console connection?
On Thu, 19 Feb 2015 15:56:05 -0500 Robert Moskowitz rgm@htt-consult.com wrote:
On 02/19/2015 01:16 PM, R P Herrold wrote:
On Thu, 19 Feb 2015, Robert Moskowitz wrote:
Well I have a few things perhaps of interest.
I have problems with the firstboot setup and root password. I am using the installer script and the --norootpass option. When I am prompted at the setup, I ignore the setting of the root password. Fortunately I also did not set my user password and made my user have admin priv. Because when I got to login, it wanted a password for root and I could not figure out what. In the past I would just provide 'root' for the login and I was good. So I logged in with my user and did a 'sudo passwd root' to set the root password to what I wanted.
I have to assume systemd is starting something like:
/bin/bash -i
rather than the former (and familiar) root shell without login authentication. The same behaviour may be done under older initscripts
And put this in /etc/inittab if you want the behavior where it is not prompted:
1:2345:respawn:/bin/bash -i
Robert -- could you check your system and see, and advise the list of the results of your examination?
So again the installer script does:
sudo sed -i 's/root:x:/root::/' /tmp/root/etc/passwd
This results in /etc/passwd entry for root being:
root::0:0:root:/root:/bin/bash
This is from checking before installing the card in the Cubie. But after running firstboot, and NOT responding to the 'root password not set', I see from logging in as me with admin priv:
root:!!$1$oIqdSlOQ$AkrPPHJnLMO2g7CbEklLn1:0:0:root:/root:/bin/bash
So firstboot is sliding something in for the root password, overriding the nopassword option in the installer script.
I suppose if I had quit out of the setup, it might have left root alone...
And what decides if there is the serial console setup or the graphical config? The presense of the serial console connection?
you should use initial-setup to configure root password, timezone, language and user if desired. the option in the installer script is for use in cases where you can't access initial-setup. I would suggest that going forward you just use initial-setup as that is how things are designed to be done.
Dennis
On 02/19/2015 05:16 PM, Dennis Gilmore wrote:
On Thu, 19 Feb 2015 15:56:05 -0500 Robert Moskowitz rgm@htt-consult.com wrote:
On 02/19/2015 01:16 PM, R P Herrold wrote:
On Thu, 19 Feb 2015, Robert Moskowitz wrote:
Well I have a few things perhaps of interest.
I have problems with the firstboot setup and root password. I am using the installer script and the --norootpass option. When I am prompted at the setup, I ignore the setting of the root password. Fortunately I also did not set my user password and made my user have admin priv. Because when I got to login, it wanted a password for root and I could not figure out what. In the past I would just provide 'root' for the login and I was good. So I logged in with my user and did a 'sudo passwd root' to set the root password to what I wanted.
I have to assume systemd is starting something like:
/bin/bash -i
rather than the former (and familiar) root shell without login authentication. The same behaviour may be done under older initscripts
And put this in /etc/inittab if you want the behavior where it is not prompted:
1:2345:respawn:/bin/bash -i
Robert -- could you check your system and see, and advise the list of the results of your examination?
So again the installer script does:
sudo sed -i 's/root:x:/root::/' /tmp/root/etc/passwd
This results in /etc/passwd entry for root being:
root::0:0:root:/root:/bin/bash
This is from checking before installing the card in the Cubie. But after running firstboot, and NOT responding to the 'root password not set', I see from logging in as me with admin priv:
root:!!$1$oIqdSlOQ$AkrPPHJnLMO2g7CbEklLn1:0:0:root:/root:/bin/bash
So firstboot is sliding something in for the root password, overriding the nopassword option in the installer script.
I suppose if I had quit out of the setup, it might have left root alone...
And what decides if there is the serial console setup or the graphical config? The presense of the serial console connection?
you should use initial-setup to configure root password, timezone, language and user if desired. the option in the installer script is for use in cases where you can't access initial-setup. I would suggest that going forward you just use initial-setup as that is how things are designed to be done.
But then I have to figure out a password that is accepted by the new very strict rules!
Passwords that in the past scored strong are now weak. Etc.
If you skip the initial-setup password and do it with passwd, you can 'get by' with the old rules.
I actually think there is an error in the password strenght logic. I suspect it is looking at the text and saying, boy there are words there so it is crackable. Even if there are 6 words, each of different length. I know this as the 6 word one I tried got flagged as weak.
On 19 February 2015 at 15:31, Robert Moskowitz rgm@htt-consult.com wrote:
But then I have to figure out a password that is accepted by the new very strict rules!
Yes this is a bug being discussed on the main devel and anaconda lists. Try Fedora_Project123! the set it to whatever you want afterwords. If that doesn't work use "YouHaveToBeKiddingMeYouIdioticInstaller" (the " are part of the password.) I change out Idiotic with various Anglo Saxon Norse words which are not proper to use on a mailing list.
Passwords that in the past scored strong are now weak. Etc.
If you skip the initial-setup password and do it with passwd, you can 'get
by' with the old rules.
I actually think there is an error in the password strenght logic. I suspect it is looking at the text and saying, boy there are words there so it is crackable. Even if there are 6 words, each of different length. I know this as the 6 word one I tried got flagged as weak.
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 02/19/2015 05:57 PM, Stephen John Smoogen wrote:
On 19 February 2015 at 15:31, Robert Moskowitz <rgm@htt-consult.com mailto:rgm@htt-consult.com> wrote:
But then I have to figure out a password that is accepted by the new very strict rules!
Yes this is a bug being discussed on the main devel and anaconda lists. Try Fedora_Project123! the set it to whatever you want afterwords. If that doesn't work use
"YouHaveToBeKiddingMeYouIdioticInstaller" (the " are part of the password.) I change out Idiotic with various Anglo Saxon Norse words which are not proper to use on a mailing list.
You got that right!
Yes, I have read up on this on the main devel list and put one comment in on it.
Look up Rich Smith's cryptosmith.org on password sanity.
Let's say the english dictionary has 5x10^5 words. A string of 6 words would take a 5x10^30 rainbow table to look up. Yet such a password gets flagged as weak. Perhaps there are some shortcuts that make the space smaller, but I can't see it being so much smaller.
Hopefully this will be resolved sooner rather than later.
Passwords that in the past scored strong are now weak. Etc. If you skip the initial-setup password and do it with passwd, you can 'get by' with the old rules. I actually think there is an error in the password strenght logic. I suspect it is looking at the text and saying, boy there are words there so it is crackable. Even if there are 6 words, each of different length. I know this as the 6 word one I tried got flagged as weak. _______________________________________________ arm mailing list arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/arm
-- Stephen J Smoogen.