Jump to content
XPEnology Community

Change MAC address AFTER DSM 6 install?


thinksitdo

Recommended Posts

I successfully did a clean install of DSM 6 on a Microserver Gen8 with the original MAC address. I would like to use my old 212j MAC address now I have migrated over all my files so I can use QuickConnect. Can I alter this on the USB boot drive and would it have any affect or would I have to alter additional file on DSM? Or, would I have to do a clean install?

 

Many thanks

 

Scott

Link to comment
Share on other sites

The use of QuickConnect with an Xpenology box is a violation of Synology's services. QC is aimed exclusively to Synology's customers. Using QC with Xpenology simply destroys this project and give us a bad reputation. I highly recommend you do not use QC. Any discussion on how to abuse Synology will be closed.

 

Simply use your real NIC MAC address by modifying the grub.cgf file in your USB boot drive and then set up a custom DDNS instead of QuickConnect. Have a read at the tutorial >>> viewtopic.php?f=2&t=22100

Link to comment
Share on other sites

  • 7 months later...

Hello  @Polanskiman, I understand what you say and totally agree, Personally, I won't be using quickconnect, however I don't see a reploy to the question of the original title... can we change the mac adress after? :-(

 

I did a fresh install of DSM 6 on a proliant gen8 in a microsd and everything went smoth. As I used microsd card I didn't have to change PID, VID and therefore also forgot to change mac-adress as it just loaded straight forward. Is that serious and can provoke potential issues?

I realized it was not clean when I tried to install xpenlogy on a nother VM in the same LAN...obviously same mac with different @IP cause conflicts...

 

I tested then to set up a new flash usb stick setting VID PID and mac (with OSF mount) but when starting the server the "syno assistant", it provides a DHCP @IP as it was a "new install"? and just propose a "repair". I guess it's logical because of the new mac adress...

 

What should I do? Should I proceed with the repair? I don't want to lose all my config!

 

Changing the mac adress from the grub menu itself pressing "c" would be better? won't it break anything?

 

 

Please help!!!! I would like to avoid a fresh install

Edited by siulman
Link to comment
Share on other sites

Responding to myself and maybe in order to help if someone is in the same situation as @mikhan stated below, chaning the mac adress from the grub menu worked perfectly. 

--> by pressing C in grub menu, enter "mac1 your_mac" in command line, then ESC and boot.

 

I still don't know why creating another usb stick didn't work, if someone can provide some clarity on this it would be great...

 

 

Thanks!

 

Link to comment
Share on other sites

easiest way of changing mac might be to use the microsd card or usb stick in windows and edit the grub.cfg (notepad++, its a unix file!)

changing with grub bootloader at boot does work too but its not so comfortable

 

why did a new created stick did not work? - most likely is you used jun's original from the start (that contains DSM 6.1.(0) kernel), installed dsm 6.1.3 or 6.1.4 and in this process the new kernel was written to the usb stick so installed dsm an disk and kernel on usb stick match

when replacing the usb stick with a new created from jun's image it contained the kernel from 6.1.0 and that does not mach the system on disk anymore, thats re repair is for

in synology original real life situation that would be like having  actual dsm, mainboard broken, getting a replacement "chassis" (with new mainboard containing usb laoder with older dsm kernel) and inserting the disks with newer dsm on it, that needs to be fixed without emptying the "good" (data containing) disks

 

to address this sbv3000 made a version containing the kernel of 6.1.3 (15152)

if a 6.1.4 is installed it would need a image with the matching kernel, so it would need a version for every major version of dsm 6.1, if its woth it is not decided yet as it would mean images for 6.1.1, 6.1.2, 6.1.3, 6.1.4 and for all 3 version - can get confusing for people and also easy to use the wrong image with so many

i theory it should be possible to refresh the stick with the content of the installed dsm *.pat file manually, so o written howto would be the thing to do?

 

Link to comment
Share on other sites

Hello @IG-88,

 

Thank you for your response. This is a pretty good explanation. In understand now why "version" "6.1.0" was displayed in my "syno in assistant soft" when I tried to boot with the new USB Flash using 1.02b indeed. I though upgrades did not write anything in the USB stick/microsd. I realize now that it does!

 

Concerning the first point... I was not able to open the partition where the "grub.cfg" is in a my microsd card. Windows10 just propose to format de partition but apparently can't open it.

 

Concerning the second point, allow me to ask:

 

What happens is my microsd fails tomorrow? How can I restore my system? Giving the fact I am running 6.1.4-15217 update 3 in a DS3615xs in a proliant gen8 and there is no bootloader for this kernel....

What is the procedure in this worst scenario? Is there a tutorial or somehing? would the "repair" work?

 

Edited by siulman
Link to comment
Share on other sites

4 hours ago, siulman said:

Giving the fact I am running 6.1.4-15217 update 3 in a DS3615xs in a proliant gen8 and there is no bootloader for this kernel....

What is the procedure in this worst scenario?

 

to prevent any untested manual work for now i would suggest

 

1. make a backup with Win32Diskmager after a major update (dd if its linux)

or

2. use virtualbox vm, create usb as usual with a 6.1.0, create a vm for dsm (should be documented here in the forum), hand over the usb to the vm and boot from that stick, install the dsm you use in baremetal and after that your usb has the version you need, just change mac/sn as needed and you are ready to go

alternatively to usb stick you can use a vmdk text file referencing to jun's img file (he had this in 1.02a together with the img file), that way you modify the img by installing dsm and can work as in the normal intall howto so after updating the img by installing newer dsm use osfmount to edit grub.cfg for mac/sn, and win32diskimager to write it to usb

 

4 hours ago, siulman said:

Is there a tutorial or somehing? would the "repair" work?

 

no, i have only checked the usb stick for newer files and the files come from the dsm *.pat file

i wrote that here:

 

in win10 (creators update or later, win7 or earlier win10 only show 1st partition) you see both partitions of the usb stick when you connect it so it should be easy to copy the files

other method would be so read the usb stick with win32diskimage modify the image with osfmount and write the iage back to usb

Link to comment
Share on other sites

Among all what you said, I decided to do a “win32imager” of my current microsd. I flashed it in a pendrive changing vid/pid and worked perfectly. I think it’s the easyest way.

I am just entering into the xpenology world. This is great, however, I still have a doubt. What happens if someday for some reason I do an upgrade and it fails. How to roll back?

Link to comment
Share on other sites

Well I guess you will need to come here and provide details of what the problem would be. It is difficult to tell you what would need to be done for something that has not yet happened.

 

In general updates don't fails per say. What actually fail are external modules not been up to date following a major update or simply the loader not having been updated for the new DSM update; e.i. a major update usually has a different kernel version than its predecessor and so modules need to be recompiled in order for the hardware to be detected by DSM; The loader also needs to be re-worked to make sure it will boot up DSM properly. Regarding modules, this usually applies to network adapters or disk controllers which modules have been added by a third party like developers here. This does not apply for modules which are part of DSM simply because the update will provide such newly compiled modules.

 

Simply come to forum regularly and check out the Critical Update forum as well as other sections of the forum. Never update a production machine prior updating a test machine first or checking the forum for compatibility issues.

Link to comment
Share on other sites

On 19/12/2017 at 6:25 AM, Polanskiman said:

Well I guess you will need to come here and provide details of what the problem would be. It is difficult to tell you what would need to be done for something that has not yet happened.

 

In general updates don't fails per say. What actually fail are external modules not been up to date following a major update or simply the loader not having been updated for the new DSM update; e.i. a major update usually has a different kernel version than its predecessor and so modules need to be recompiled in order for the hardware to be detected by DSM; The loader also needs to be re-worked to make sure it will boot up DSM properly. Regarding modules, this usually applies to network adapters or disk controllers which modules have been added by a third party like developers here. This does not apply for modules which are part of DSM simply because the update will provide such newly compiled modules.

 

Simply come to forum regularly and check out the Critical Update forum as well as other sections of the forum. Never update a production machine prior updating a test machine first or checking the forum for compatibility issues.

 

 

Hello @Polanskiman,

 

Thank you for your response. Message received and understood. Before any update I always check the forum and make sure people succeded with the same hardware as me + I test the update on my VM.

However, how to proceed if the update fails? Is there a roll-back method? I understand when you proceed with an upgrade you are flashing the bootloader usb key but also performing some modifications in the primary disk where the system is installed. So, even if you reflash the usb key with the previews bootloader, is the primary disk blocking for the roll-back? or can you do a "repair" thing ?

 

Thanks

Link to comment
Share on other sites

  • 3 weeks later...

Hello everyone,

 

just wanted to inform I have tested to plug into my server a pendrive with an old bootloader version. Using the "syno assistant" just clicked on "repair" and everything just booted with the old version. So I guess if and update fails, I just have to flash a pendrive with and old working bootloader and "repair" to boot.

Link to comment
Share on other sites

4 hours ago, siulman said:

Hello everyone,

 

just wanted to inform I have tested to plug into my server a pendrive with an old bootloader version. Using the "syno assistant" just clicked on "repair" and everything just booted with the old version. So I guess if and update fails, I just have to flash a pendrive with and old working bootloader and "repair" to boot.

Yes that should work, but only 'within' the DSM version eg 6.1, if you tried the 6.0 loader it would probably fail

Link to comment
Share on other sites

  • 1 year later...

@siulman  wrote in this old thread ... "by pressing C in grub menu, enter "mac1 your_mac" in command line, then ESC and boot." I simply cannot make this work. 

I have no problems getting into the grub menu pressing c. Then I get the command line.

If I finish the mac1 command with <enter> it will say unknown command; if I go into the e menu/screen I can move the cursor to the MAC position and modify the mac address. This will work for one boot,  but it won't keep the changed after a reboot.

 

Could you or somebody else shed some light on what I am doing wrong, please

 

Thanks :)

Link to comment
Share on other sites

13 hours ago, OldSmurf said:

@siulman  wrote in this old thread ... "by pressing C in grub menu, enter "mac1 your_mac" in command line, then ESC and boot." I simply cannot make this work. 

I have no problems getting into the grub menu pressing c. Then I get the command line.

If I finish the mac1 command with <enter> it will say unknown command; if I go into the e menu/screen I can move the cursor to the MAC position and modify the mac address. This will work for one boot,  but it won't keep the changed after a reboot.

 

Could you or somebody else shed some light on what I am doing wrong, please

 

Thanks :)

 

Sorry if it sounds obvious but did you write mac1 xx:xx:xx:xx:xx:xx and then pressed "enter" ?

you need to write de mac adress next to the "mac1" command and only then press "enter".

Link to comment
Share on other sites

I also tried to modify in the other menu ... this does actually change SN and MAC, but it doesn't retain the changes after a reboot.

grub-error2.jpg

 

 

I might add that I have XPenology running on a ESXi 6.0 server.

 

Edited by OldSmurf
Link to comment
Share on other sites

@OldSmurf

You can mount loader partition in telnet/ssh session and then edit grub.cfg

Admin@your_DS:~$ sudo -i
Password:
root@your_DS:~# mkdir -p /tmp/synoboot_part0
root@your_DS:~# cd /dev
root@your_DS:/dev# mount -t vfat synoboot1 /tmp/synoboot_part0
root@your_DS:/dev# ls /tmp/synoboot_part0
bzImage  EFI  grub  info.txt
...
root@your_DS:/dev# cd /
root@your_DS:/# umount /tmp/synoboot_part0
root@your_DS:/# rm -r /tmp/synoboot_part0

 

Edited by Olegin
Link to comment
Share on other sites

@Olegin

Thank you so much for your reply. I am a noob in Linux so it took me way too long to figure things out. But when I figured out that the line with the three dots indicated when I should edit the grub.cfg things started to work (mind you - the VIM editor and me are not good friends)

So I have now successfully changed the MAC address .. and this time the XPe keeps it after a reboot :)

 

Thanks again :)

Link to comment
Share on other sites

7 часов назад, OldSmurf сказал:

But when I figured out that the line with the three dots indicated when I should edit the grub.cfg things started to work (mind you - the VIM editor and me are not good friends)

@OldSmurf Ohhh, sorry, "three dots indicated when I should edit the grub.cfg" - i didn't write it 😫

 

Link to comment
Share on other sites

@OldSmurf I know you have sorted it all out now, but I noticed a small "error"

in the screen-dump you posted in post #16, it seems like when you tried to issue the "mac1" command, you forgot the ":" used as a divider in the address.

Not sure if you should have gotten a different error than you did though...

Link to comment
Share on other sites

@bearcat

Thanks for following up on this ... actually I tried pretty much all combinations; with the ":" in the address, without, with ":" after "mac1". You name it - I tried it. The darn grub just won't recognize the "mac1" command. Which in a way makes sense - if I list all grub commands with the "TAB" key, mac1 definitely isn't one of them.

Anyway - as you also mention ... it's sorted out now :)

If you are curious  why I am spending so much time on this issue, it's because I want to have a number of XPe's running on my ESXi. This way I can do some tests without messing up my main XPe. My primary ESXi (and the entire XPe data VMDK) crashed the other day ... that hurt😭. So moving forward caution and backups are going to be my main focus 🤓

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...